Courtesy: The H
The GNU GPL might seem the obvious answer. After all, the GPL was drawn up specifically to make collaboration work and to create a community based on sharing code. But the experience of the last ten years of open source business has shown that, ironically, the GNU GPL actually allows companies that adopt it to act more, not less, like a traditional closed-source company.
When a company offers its software under the GNU GPL, it generally requires external contributors to assign the copyright of their code to the company. The reasoning usually given is that the company needs the copyright so that it can also offer commercial – that is, non-free – licences to the product in order to make money so that it can pay for work on the free versions.
Superficially, that’s a reasonable line, but there’s a hidden sting in the tail. Although the GNU GPL licence means that others can use the code commercially, and even fork it, the copyright assignment ensures that only the original company can offer the software under non-free licences. This places rivals to that company at a distinct disadvantage, and pretty much ensures that the holder of the copyright is able to act as a monopolist, shutting out business rivals – hardly what Richard Stallman had in mind when he drew up the GPL.
It is partly for this reason that the Apache licence is being widely adopted for new projects – for example, the recently-announced Open Stack. The key difference here is that anyone can take the code and turn it into a proprietary offering: the original copyright holder does not have any advantages in this respect, and so a more vibrant business ecosystem can grow up around it – or so the theory runs.
The downside, of course, is that any company can take code licensed in this way and turn it into a proprietary product – even if they don’t contribute back. As the Apache Licensing FAQ explains:
You can keep your changes a secret if you like. Maybe your modifications are embarrassing, maybe you’ll get rich selling those improvements. Whatever. But please seriously consider giving your changes back! We all benefit when you do.
This is the classic free-rider problem that the GNU GPL was designed in part to avoid. It means that contributors to Apache-licensed projects must be willing to accept that their work may well end up in closed-source products, maybe multiple times. In this respect, it is worse than the GNU GPL with copyright assignment, where only *one* company can do that.
A third possibility
But there is a third possibility. The chief disadvantage of the GPL and related licences like the LGPL in a commercial context, comes from the assignment of all the copyright to a company, and the unique power it gives to the latter. There are two alternatives to this. The first is simply to allow copyright to remain with the author of each piece of code: this is the approach adopted by the Linux kernel community. The disadvantage is that it becomes almost impossible to act in concert – for example, to upgrade an entire project to a new version of the licence – because it is not practical (or perhaps even possible) to obtain every copyright-holder’s agreement.
The other option is to assign all of the copyright to a single entity, but to make that a non-commercial one. This is what happens with FSF projects:
Under US copyright law, which is the law under which most free software programs have historically been first published, there are very substantial procedural advantages to registration of copyright. And despite the broad right of distribution conveyed by the GPL, enforcement of copyright is generally not possible for distributors: only the copyright holder or someone having assignment of the copyright can enforce the license. If there are multiple authors of a copyrighted work, successful enforcement depends on having the cooperation of all authors.
In order to make sure that all of our copyrights can meet the record keeping and other requirements of registration, and in order to be able to enforce the GPL most effectively, FSF requires that each author of code incorporated in FSF projects provide a copyright assignment, and, where appropriate, a disclaimer of any work-for-hire ownership claims by the programmer’s employer. That way we can be sure that all the code in FSF projects is free code, whose freedom we can most effectively protect, and therefore on which other developers can completely rely.
As well as those “procedural advantages”, the other benefit in assigning copyright to a foundation like the FSF is that it produces a completely level playing-field for companies. Anyone can take that GPL’d or LGPL’d code and use it as the basis of a commercial offering; however, no company can gain an advantage over any other by offering a closed-source version too. This means that the larger free-rider problem of Apache-licensed code is avoided.
Against that background, it may well be that the “golden age of open source” that some people are prophesying might also be a golden age for open source foundations. Already, in the light of Oracle’s lawsuit against Google, some are suggesting that OpenOffice.org might be safer as a project run by a foundation (admittedly, an idea that’s been around for years).
Most of the GNOME core software has always been licensed under copyleft licenses, such as the GPL and LGPL. Some of GNOME’s goals in choosing copyleft were and are:
to make sure no one organization dominates GNOME.
to ensure that all contributors to GNOME, corporate and individual, are on equal footing, which helps avoid conflicts and disagreements between contributors.
to grant both commercial and non-commercial users and developers equal rights and privileges to copy, modify, and redistribute the software.
to provide individuals the assurance that their code will be propagated in line with the spirit of the copyleft.
to provide transparency and openness in the development process, in order to create trust in the licensing framework of GNOME.
Some copyright assignment policies are consistent with these goals. Other copyright assignment policies, depending on their structure, can sometimes contradict these goals. The GNOME Foundation Board of Directors therefore carefully considers, on a case-by-case basis, any proposal to include packages with mandatory copyright assignment policies into GNOME.
The GNOME Foundation has also produced a more detailed exploration of copyright assignment. I strongly recommend anyone interested in the future of licensing – and hence of open source and the businesses created around it – to spend some time perusing its detailed discussion of what may well become the focus for yet more heated discussions in the future.