OSS Watch team blog

Running an open source project without a governance model is like building a house without plans: a recipe for disaster. A governance model describes how a project is managed and how third parties can interact with that project. In particular, it describes how decisions are made within the project, the ground rules for participation in the project and the processes for communicating and sharing within the project team and the community.

The community is the lifeblood of the project and as such should be protected and nurtured. One of the most important aspects of this is the licensing of the project. There are several types of open source licence available; the choice will depend on the future plans for the software.

Contrary to the traditional concept of a licence, open source licences are designed to increase rather than restrict the freedom of the licensee, to encourage contributions to its functionality by modifying the source code. The GPL, for example, is a copyleft licence designed to ensure that the code it covers remains free and open source by dictating that derivative works, should they be distributed, inherit the same licence as their parent project and cannot be incorporated into non-FOSS products. At the other end of the spectrum is the permissive licence, such as the Apache Software License. Unlike copyleft licences, it allows the inclusion of FOSS in non-FOSS projects and the licensing of derivative works in any way the distributor pleases.

What implications does the choice of licence have on community development? Copyleft licences may restrict the uptake of the code, and therefore the size of the community, because of their ‘viral’ nature: they are seen to ‘infect’ all derivative software with the same restrictions, thus limiting the business models available to projects building on that code. Since copyright holders have additional rights over licences, centralised ownership of copyleft-licensed materials can add additional community concerns because of the scope for ‘abuse’ of that community. Witness the case of Oracle’s planned buyout of Sun, which would make Oracle the exclusive holder of the open source MySQL copyright and trademark. This could have potentially damaging consequences for the project’s future, and possibly result in higher prices for database software.

Permissive licences, on the other hand, encourage greater uptake of the software and wider participation from outside the project because they don’t dictate terms under which derivatives can be distributed. Thus, relinquishing control over what can be done with the code fosters community development, which in turn increases the opportunities for innovation. Permissive licences allow almost any business model except dual licensing and are therefore more appealing to commercial developers.

The contrast between copyleft and permissive licences is illustrated by SpringSource’s recent decision to move from the GPL to the Eclipse Public License (EPL) for its OSGi application server. The company originally chose the GPL because, in the words of CEO Rod Johnson, ‘there’s a lot of technical innovation under the hood [and] if we’re giving that technology away in open source, we wanted others who build on it to also give away results in open source’. The move to the EPL suggests that the company recognises the value of a wider adoption of their technology through more permissive licensing and collaborative community development.

However, permissive licences don’t ensure the ongoing freedom advocated by Richard Stallman, which underpins the FOSS philosophy. Significantly, though, Stallman is himself beginning to accept that they are sometimes necessary, as evidenced in a recent article in which he admits to having mixed feelings on selling licence exceptions. Could this shift in Stallman’s thinking be evidence of a fundamental change in the broader licensing landscape?