Author Archive for Elizabeth Tatham

Guest post: 2010 - Threats to copyleft

This post is by Patrice-Emmanuel Schmitz, Director for European institution studies at Unisys Belgium (Brussels). His team is in charge of the www.OSOR.eu (Open Source Observatory and Repository), the Free/Libre/Open Source information platform and forge launched by the European Commission for public sector projects.

Combining freedoms and copyleft in the Gnu GPL license (invented by Richard Stallman) was the cornerstone of free software. This is now questioned due to the proliferation of incompatible copyleft licenses.

After counting 1,800 free software licenses used in hundreds of thousands of projects, the Black Duck company patented (Patent US 7,552,093 B2) the technology for controlling the use of open source licensing in a multi-source development process (meaning combined works, elaborated from multiple free components under different licenses).

No need to say that patenting proprietary technology to solve copyleft licenses incompatibility may not be seen by everyone as a major achievement!

Lamenting on license proliferation or blaming new license authors – who all call upon the best reasons of the world, looks useless. It would certainly be reasonable, as recommended by Bruce Perens, to deal with only four permissive and copyleft licenses, but this is wishful thinking. New licenses are presented every week by FLOSS authors and communities, and no benevolent dictator will limit human innovation regarding licensing.

The heart of the problem does not lie in the number of licenses, but in their incompatibility. I do not think that license proliferation is a failure of the FLOSS movement, it is rather the entire contrary: a testimony of the attractiveness of FLOSS models. In reality, license proliferation illustrates the failure of a certain model of strong copyleft, as it was initiated by the GPL in the 80’ and – unfortunately - reproduced by nearly all subsequent copyleft licenses. Once necessary and successful, this model looks not adapted anymore because it was copied and - seeing the Black Duck patent - one may question (like Ernest Park has done) if the way copyleft is applied does not generate today more jails than freedom.

According to my first study for the European Commission, the Gnu GPL v2 was used in 85% of the FLOSS projects in 2001. With a copyleft that was – maliciously – said “viral” by some, meaning that compatibility is always “upstream” (to itself) and never “downstream” (to other licenses), the adoption rate of the GPL should have been universal in 2010, confirming analysts’ assumption that “it is good for the community if people use a single copyleft license [1]”. However, the exact reverse happened: the GPLv2 (reducing) is still used in 50% of projects, the new GPLv3 reaches little more than 5% and other licenses are proliferating.

The fact a dozen of licenses are used by 90% of the FLOSS projects does not help very much, as the implementation of free solutions (which are often combined works) is done through integrating many components. It is enough to find only one incompatible license to compromise the distribution of these solutions.

The current situation is damaging for other reasons: it creates endless discussions on what could be considered as integration in combined works (dynamic or static linking) and it feeds disputes. To preserve their communities from schisms, gurus and acolytes urge followers not to use any other copyleft licenses, whatever their specific merits or advantages could be. It is time to admit that the strategy of keeping a “captive asset” of license users was not successful for avoiding proliferation, and that it is not the most appropriate way to reinforce the freedom, collaboration spirit and consistency within the fragmented FLOSS world.

In Europe, the recent - OSI approved and copyleft - European Union Public License (EUPL) meets some initial successes due to its compliance with Member States’ law and because it has equal value in the 22 languages of the Union. It has been selected by the German Federal Agency for Information Technologies, it is the license of choice in schemes published by the Dutch NOiV (see on the www.OSOR.eu site an English version of this scheme, translated by a member of the Swiss administration), a dedicated EUPL site was created in Italy, etc. In Spain, the Ministry of Industry, Tourism and Commerce (where the public agency Red.es is located, in charge of information technology) provides the following in call for tenders (software specifications):

“In case the contractor integrates in the development that is the object of the contract with modules or elements owned by third parties, he must first obtain from the legal owners the licenses and rights necessary to transfer the ownership of the development to , which will submit it, including the elements that are performed under the contract (such as fonts, dll, scripts, etc..) to the public license EUPL. In any case the total and final result of the development and the overall project will be subject to a license EUPL.”

Applying such provisions excludes strong copyleft components from the delivered combined work: all original developments are allowed; all “permissive” components are allowed (BSD, MIT, etc.); all “weak copyleft” components are allowed (i.e. LGPL), but no Gnu GPLv2 (or V3) components (except if the copyright owner is entitled to dual license the component under LGPL-like terms, for the purpose of addressing the contractual specifications).

The EUPL itself has an innovative approach to solve copyleft licenses conflicts: it publishes a downstream compatibility list (to other licenses). It is allowed to integrate EUPL components in a combined work that will be distributed under a compatible license. The concept is not new, as the FSF applied it with the LGPL a long time ago. The LGPL (now LGPLv3) is convenient for software libraries aimed to produce combined or derivative works: if the library is propagated on its own, it must be under the provision of its original license (LGPL), but if the library components are part of a derivative work, this work can be licensed under another license, while the original library remains LGPL. The EUPL compatibility is exactly the same, but its copyleft effect is stronger than in the LGPL (because compatibility is restricted to a limited and published list of other copyleft F/OSS licenses). Therefore it is not a weak but – say, a “tolerant copyleft”.

Such flexibility removes incompatibility barriers and restores developers’ freedom, while keeping it in the limits of the desired copyleft effect.

While the EUPL solution may be considered as a conceptual progress, its tangible impact will stay very limited as long other copyleft licenses will not give some reciprocity: the quantity of available EUPL-ed material is quite small today, compared to the mass of components that are already available under the GPL terms. Extending the list of EUPL compatible licenses (i.e. by adding the still missing GPLv3) will not change the issue resulting from the Spanish specifications, where the government requires the facility to distribute the received combined work under the single license of its choice (the EUPL in this case).

Solving problems related to the proliferation of copyleft licenses requires setting up interoperability provisions between these main licenses. It will create, and focus attention, on a kind of “circle of trust” where the original copyleft licensing condition of a software will never be changed, but where – just to take an example – a GPL component could be part of a combined work that the recipient (let’s say the French or the Spanish government) could distribute as a whole under the provision of the copyleft license of its choice (i.e. CeCILL or the EUPL) provide these licenses are allowed in the compatibility list.

The Gnu GPLv3 includes (in its section 13) the exact provision corresponding to the above need, but it is directed to the AGPLv3 only. The intellectual effort to extend this provision in direction of a small list of interoperable licenses seems easy to deliver. The reciprocal condition must be added: in the example above, the combined work could be also (as the need may be) distributed under the provisions of the GPLv3.

This could be a way out to the deadlock where we are, due to the proliferation of incompatible licenses.

Looking for alternative? Pay a Black Duck patent license!

Patrice-Emmanuel Schmitz – www.OSOR.eu

[1] R.T. Nimmer, Legal issues in Open Source and Free Software distribution, The Law of Computer technology, Ch. 11 (1997, 2005 Supp.) (“Two different copyleft licenses are usually “incompatible”, which means it is illegal to merge the code using one license with the code using the other license; therefore it is good for the community if people use a single copyleft license (GPL)”).

Jacobsen v. Katzer case settled

In the closing chapter of this complex story, the intricacies of which have previously been explained in this blog, the parties in Jacobsen v. Katzer have filed a settlement agreement with the California district court. The ruling, which favours Jacobsen, is also seen as a significant victory for the FOSS community in that it establishes for the first time in the US a developer’s right to prevent their copyright and authorship acknowledgements from being removed from their code, and their right to collect damages if the terms of the licences they choose are violated. The implications for the UK are not yet clear, but there is no doubt that the outcome of this closely watched case strengthens the legal standing of open source licensing and could set an important precedent.

Control versus community

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?

Writing for the Web: a few tips

My worst nightmare at school was having to think of something for show and tell. I had the same feeling today, when I was asked to write a blog post as part of my new job as content editor for OSS Watch.

I have never written a blog before, and seldom read them, so I had a few questions for my colleagues. What shall I write about? Oh, anything really. Who am I writing for? Oh, anyone and everyone. Scary. All the more so because blogging is  personal and immediate - quite the opposite of the book publishing process I am used to, where the product is carefully crafted over several weeks or months and there’s a team to share the responsibility.

Luckily I went on a course yesterday, so at least I have something to write about. The course was called Writing for the Web, and I was keen to go on it because I wanted to know how the writing and editing processes for the Web differ from those in book publishing.

The course outline looked very promising: devising a strategy for your website; understanding how people read online; structuring your information; writing skills; managing your website; editing and proofreading; and creating reusable material. For me, it didn’t quite deliver on all fronts, but I did pick up some useful tips:

  • a website should not be seen as whole, and is non-linear, unlike most books
  • reading on screen is uncomfortable, so presentation is important (see http://webpagesthatsuck.com for examples of how not to do it)
  • consider the reader’s environment and accessibility issues
  • use storyboarding to plan the site, and to demonstrate layout of screens and navigation links
  • navigation reflects the relationship between information and also readers’ need to access it
  • people don’t read the text, they scan it, so make it scannable: use highlighted keywords, meaningful sub-headings and bulleted lists
  • keep headings short; the first two words are the most important
  • paragraphs should contain a maximum of two sentences
  • keep it short and simple (see http://www.plainenglish.co.uk/) and focus on the action
  • avoid ’speed bumps’: inconsistent use of terms, jargon, slang, non-descriptive headings, marketing hype

All in all, it was a useful day away from the office. I will now be able to look at our website in a new light, and think about how we could apply some of these principles to improve it, and the documents we write for it, for our readers. Pity we didn’t cover blogging.