A Bit of Licence
One of the striking aspects of the free software community is its obsession with licences. It's as if within every hacker there's a lawyer struggling to get out. But maybe it's not so surprising; as Larry Lessig reminded us, “code is law”, and the reverse is also true in the sense that the licence adopted has a big impact on how the software is produced. That explains, in part, why recent discussions of Oracle's proposed acquisition of Sun – and hence MySQL – have once more put free software licences under the microscope.
For example, here's Monty Widenius, one of the main authors of the original MySQL, on why the GNU GPL places limitations on what forks of MySQL can do, and hence how viable companies based around them might be:
MySQL is not an end user application, but an infrastructure project that is quite deep in the system stack. Most of the technology partners, where most of the innovation in the MySQL space happen nowadays, depend on being able to get licenses for MySQL so that they can combine their closed source application or closed code (like storage engines) with MySQL. If you take the license revenue and add it to all direct and indirect money that comes from these kind of partners, this is a huge part of the MySQL economic infrastructure (i.e., where the money is).
The GNU GPL allows the copyright owner to use dual licensing, but companies based on forks of that code are restricted to offering pure GPL solutions – it's not possible to re-licence the fork under commercial, non-free licences. As a result:
A fork of an infrastructure GPL project can't work with any of the above mentioned partners and the fork can't be used by anyone who needs to distribute it with their own closed source parts or use it with others closed source parts. If there would be no way for partners to combine their code with MySQL, these partners and users would have to put their efforts on some other project and the money flow and a big part of the innovation around MySQL would stop. Over time other projects that allow everyone to participate and make money will take over the MySQL business.
It's possible to create companies doing support for MySQL, but without the economics, there will not be enough money and incentive to pay enough for the development of MySQL to satisfy the requirement of all the MySQL users. Any such company will just make MySQL 'die slower', but not be able to save it.
That seems to suggest that the company holding the copyrights to a GPL-licensed project has advantages over anyone else trying to earn money from it. But this long and interesting post by RedMonk's Stephen O'Grady notes that there is also a significant downside to the the dual-licensing approach:
For smaller firms, the primary limitation is the development. Unlike non-dual licensed projects which need only concern themselves with the quality and provenance of code contributions from external parties, dual-license vendors need also consider the question of copyright ownership. Because dual licensing depends on ownership of copyright for the entirety of the asset in question, third parties must either assign or be willing to jointly hold the copyright for any potential contributions. Early in a project’s lifecycle, this is a minor concern because the project owner likely employs most of those qualified to improve it. As a project matures and becomes more popular, however, this is a more pressing issue. First, because it acts to inhibit community participation (see slide 18 of this deck produced by Monty), but second – and more problematically – it means that third parties can, in practical terms, offer a more complete product.
Jeremy Zawodny made reference to the practical implications of the dual license in a post from December of last year entitled “The New MySQL Landscape.” In it, he made the assertion that “You can get a ‘better’ MySQL than the one Sun/MySQL gives you today. For free.” This is the cost of the dual licensing model: in return for the right to exclusively relicense the code, you forfeit a.) the right to amortize your development costs across a wide body of contributors, and b.) the right to uniformly integrate the best patches/fixes/etc that are made available under the original license because you cannot always acquire the copyright.
That's an argument the GNU GPL isn't so problematic in terms of creating viable forks that can support commercial ventures, because of certain aspects of the software community that forms around it. But here's a different view on the relationship of the community contribution to the licensing that sees another problem with the GPL: that its attempt to prevent “freeloaders” makes it unduly restrictive:
‘Freeloaders’ – people who use or modify the open source project for their own ends but give no code or community contribution back – are always going to exist; even under the GPL it’s easy to freeload, if you make your money from hosting services for example, and thus license choice has little impact on the scale (if not the nature) of the freeloading. Besides the annoyance of ‘that guy took my work and made some money out of it’ – which you have to accept as an inevitable outcome of going open source, so stick to making proprietary software if that bugs you – freeloaders have little negative effect on an open source project... The key is to recognise that in practice you can really just ignore freeloaders, and instead concentrate on maximising the positive contributors in your community.
If you are indeed happy to ignore freeloaders, you can adopt a more permissive approach by using the Apache, Eclipse or BSD licences. They, in turn, make it easier for other companies to create businesses around the code, and thus avoid any of the potential problems of dual-licensed GPL code discussed by Widenius.
But I do wonder about that central premise, that there will always be some kind of freeloading going on – through hosted services, for examples – and therefore potential contributors should just ignore that factor in their decision whether or not to join in. My impression is that people *do* feel very strongly about the idea of their work being taken and used for gain without something being given back, and that there is a significant difference between code being used for Web services, say, and being incorporated into a distinct software application that is then licensed.
Maybe the wide range of licences available is a response to people's differing responses to the freeloader issue. Those that don't particularly care will be happy to work on projects with more permissive licences; those that do care will stick to those using the GNU GPL to fend off the freeloaders. Such a correlation might also explain why something apparently so dry as licensing provokes such powerful and abiding passions: it's actually tapping into something very deep and personal that helps define how we look at the world, and hence who we are.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide