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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development