Making open source more “open”

Share on LinkedIn
Bookmark this on Delicious
Share on Facebook

This paper was prepared for a talk at Open Source Days in Copenhagen 10 March 2012. A PDF copy can be downloaded here (Making open source more open (10-03-2012)). This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License.

Most presentations on open source at conferences for lawyers, and the majority of legal articles on open source, focus on different legal aspects of the General Public License (GPL). This focus on the GPL is partly historical, partly due to choice of business models and partly a natural consequence of lawyers’ tendency to focus on the more litigation-prone areas of open source.

In this sense, the focus from the time open source became commercially interesting—and, accordingly, from the time that lawyers started to take an interest in the field of open source licensing—has been on the more “closed” types of open source licences, where “closed” is understood as referring to more “restrictive” licences.

The all important and coincidental exponent of this type of restrictive licence is the General Public Licence (GPL)[1]. This paper aims to present a new trend within open source licensing that is becoming more and more apparent. That is the waning importance of the GPL and other copyleft licences. This trend is supported by statistics and by important new business models and technological change.

I will not argue that open source licensing in general is losing importance. On the contrary, I argue that open source as a licensing model is continuing the dramatic rise that started about 10 years ago. But open source licensing seems to be moving in the direction of increased use towards more permissive licences. Open source licences are thus becoming less restrictive, more permissive and, in that sense, open source is becoming more open, hence the title of the paper.

When the first lawyers started to take an interest in open source—at least in the case of the majority of lawyers—the focus was on the viral effect of the GPL. Lawyers pointed to the hazardous effects of the GPL in Mergers and Acquisitions when using open source software together with proprietary software and so on. This tendency was typical of the often very defensive attitude taken by lawyers in advising their clients on open source: “We can help you not become infected with a bad virus of open source software that is due to the nature of the GPL”.

Fortunately, today most firms—and most clients—have learned that open source means business and that the principle approach to using open source software should be a constructive and positive approach: “How can we make money by using open source software released by others or by releasing our own software under open source licences?”

In reports from the last years by Gartner[2] and Accenture[3], it was stressed that the situation for almost all large national and international companies was such, that these companies now would have to explain themselves to the market if they did not have plans for using open source incorporated in their IT strategy. This is in opposition to the previous mindset, when the same companies would have had to explain why they had decided to use open source software.

This radically more positive approach to open source software has coincided with a change in attitude within the open source community to the primacy of the General Public License. Black Duck Software and others that are tracking users of different open source licences have observed that, in the last couple of years, the prevailing trend has been a decline of the use of the GPL in open source projects[4]. What accounts for this decline vis-à-vis a more prevalent usage of more permissive open source licences such as the Apache and MIT licenses?

There are many possible explanations but I would like to highlight three. First, the GPL is very complicated from a legal perspective, which naturally gives a preference for more permissive and less complicated open source licences. Second, new developments in open source business models are better accommodated by the use of permissive licences. Third, the increasing importance of open data and open APIs decreases the need for a strong copyleft licence, such as the GPL, in open source projects.

As mentioned, the GPL is a complex software licence. GPL version 2 was almost unintelligible. Arguably, all lawyers with experience within open source would agree that there are certain parts—maybe many parts—of GPL version 2 that they will not be able to explain properly to clients. Instead of being able to explain exactly how the wording worked, lawyers still have to refer to community standards and practices instead.

Key concepts, such as what constitutes a combined work and what constitutes distribution, were and still are being discussed over and over again. The author of this paper did a presentation on the topic of distribution of software in open source licenses at Itechlaw Asia 3 years ago and the forthcoming issue of IFOSSLR[5] will feature an article by Heather Meeker[6], one of the most experienced open source lawyers, on distribution in the context of GPL alone.

GPL version 3 has made life easier for lawyers but, nevertheless, different sections of the licence are often very difficult to explain and understand. In particular, this is still the case because understanding the GPL continues to require extensive insight into how computer-code interacts and how applications interoperate, despite the intention of the authors of the new version to make it more user friendly (read: easier to use for lawyers).

The historical background of the GPL also makes its use less prone to pragmatism and adaptability. The GPL has widely been considered as a kind of constitution of the Free Software Movement[7] as well as the primary tool for achieving the goals of freeing software from the chains of copyright and providing free software for the whole world. This almost religious attitude to the GPL by its opponents has adorned the licence with the kind of power or force that rightly frightens a lot of business people.

In recent months (beginning of 2012), there has been a lot of discussion in the open source community about the use of the GPL as part of the BusyBox project. This usage highlights why many business people have concerns with the GPL.

BusyBox software provides several strip-down Unix tools in a single executable. It was specifically created as an open source project for embedded operating systems with very limited resources, such as set-top boxes for TVs, Wi-Fi routers and the like. It has been called the Swiss Army Knife of embedded Linux and has been deployed in a vast number of both enterprise and consumer hardware.

BusyBox is released under the GPL and the licensors’ rights have been exercised and upheld by the Software Freedom Conservancy, which is an institution affiliated with the Software Freedom Law Center and the Free Software Foundation.

Over the past couple of years, the BusyBox project has been in the centre of many lawsuits regarding the enforceability of the GPL in particular and open source licences in general. This has, of course, overall been very beneficial for the entire open source community by establishing legal precedence that open source licences are to be respected just as any other licences. However, the very rigid approach and often bombastic communication by the Software Freedom Conservancy in its enforcement of the GPL—and here I am not in any way disputing that this enforcement has been fully within the legal limits of the GPL—has been a boon to opponents of the GPL and proponents of more permissive licensing.

To exemplify, the last month has seen a harsh discussion within the open source community as to what was alleged to be a new approach taken by the Software Freedom Conservancy to enforce compliance will the GPL[8]. It was rumoured that the Software Freedom Conservancy had taken the position that, in order to reinstate a licence in cases where the licensee had been found to be non-compliant with the GPL, the reinstatement was made conditioned upon the licensee released its own proprietary code found to be covered by the combined work clause of the GPL—not only going forward, but retroactively as well. This demand of retroactive disclosure and distribution of source code and proprietary code is not-it was argued-something that can be interpreted into the obligations of a GPL licensee.

Luckily, it seems that the end result of this discussion has been that the Software Freedom of Conservancy has acknowledged that it should not make the reinstatement of the licence conditioned upon such retroactive disclosure requirements. But, nevertheless, the whole controversy discussion surrounding this issue has, indeed, not endeared the GPL to its sceptics within business and industry.

Traditionally, the GPL has been an integral part of some of the most successful open source business models used by companies. Interestingly, the GPL’s usefulness as part of the business model has been exactly due to its deserved reputation as the most restrictive and complex open source licence.

The business model that I am referring to here is that of dual licensing. Dual licensing is based on the exclusive right granted to the copyright holder to release the work under as many licences as he or she chooses; among those being both proprietary and open source licenses.

Under a dual licensing business model, a software company will typically release and continue to release an updated version of its core application under the GPL. This, of course means, that everybody, even competitors, can freely use, modify, and redistribute the core application.

However, due to the copyleft provision of the GPL, any competitor who chooses to use the application and to then modify it or combine it with its own proprietary software in a manner covered by the GPL’s copyleft provision, will have to release that other software under the GPL as well, if the combined work is distributed. As almost all business models of relevant competitors would exactly entail distribution of software, most often the copyleft provision of the GPL would effectively deter competitors from using the software of dual licensing software companies[9].

The poster child of dual licensing has been MySQL, initially acquired by Sun Microsystems and, through Oracle’s acquisition of Sun, now a part of Oracle. MySQL releases its core database application under the GPL but offers customers to buy traditional commercial licences (or the equivalent) as support and maintenance agreements. As part of a commercial licence, the customer, the licensee, would get the right to use the database in its products and solutions together with its own proprietary code in a way that would have triggered the copyleft provision under the GPL but which has been waived under the commercial licence. Thus, in effect, the dual licensing business model of MySQL relies heavily on the wishes of professional customers to avoid the legal intricacies and consequences of the GPL.

The dual licensing model à la MySQL is still popular. The new open source business models, however, rely more on single licensing of the software on a permissive open source licence, such as the Apache or the MIT license. Preeminent examples of these are the following:

  • Hadoop, the open source data-crunching platform based on Google’s software infrastructure,
  • Open Stack, a global collaboration with developers and cloud computing technologists producing the ubiquitous open source cloud computing platform for public and private clouds,
  • Cassandra, an open source distributed database management system designed to handle a very large amount of data spread out across many commodity servers while providing a highly available service with no single point of failure. It was originally developed by Facebook and powered Facebook’s inbox search feature.
  • CloudFoundry, an open source competing platform as a service (PAAS) software developed by VMware, primarily written in Ruby,
  • Note.js, a software system designed for writing scalable Internet applications (notably web-servers) and which was elected by InfoWorld for the Technology of the Year Award in 2012,
  • FlockDB, an open source database and Bootstrap an open source web-developer toolkit released by Twitter,
  • HP’s web OS platform for the Palm,
  • Android, the Google sponsored open source OS for smartphones and tablets and,
  • Different software projects released by NASA.

Common for many of these new open source projects is that they are either originated from or are heavily used by large companies such as Facebook, Yahoo, Google, Amazon, and the like. Obviously, these companies are not in the business of selling software. So, from that point of view, they do not have any interests in keeping tight control of the applications and its source code through restrictive open source license.

However, what is more important, is that the new open source projects consist of applications that are parts of the software stack that forms the IT infrastructure of the companies that use the software, of their customers IT infrastructure and the Internet itself. The applications under the open source projects are not what can be called business-differentiating applications. It is not through the control of the code that the companies that produce or use the software differentiate themselves from their competitors.

Many companies smaller than Facebook, Yahoo, Google, Amazon, and the like take advantage of this new trend of open source projects towards more collaboration and distribution with emphasis on sharing the cost of research and development[10]. Many of the new open source projects seem to reap benefits—not from controlling the code and its licensing terms—but more from sharing the cost of maintaining, error-correcting, improving and developing a mutual IT infrastructure. Many small companies have seen a business in providing services to other users of the new open source software projects, such as traditional service and maintenance, adaptation of the software to special environments, hosting, education, and so forth.

Common for all these new projects is the choice of a permissive licence, primarily Apache version 2.0[11] and the MIT licence[12]. These licences give users maximum choice and place almost no restrictions on users; at least nowhere near the same restrictions with respect to copyleft that are found in the GPL.

With smaller worries about IT architecture and interoperability and interdependency, no fear of the viral effect of the GPL, and less need for legal investigations and reviews, the road has become wide open for widespread adaptation of these new software projects entirely on the merits of the quality of software itself. The risk that companies will freeride—that is, that companies will only use the software and not contribute back to the common software pool—does not seem costly and important enough as to outweigh a widespread adaptation and sharing of standards and research and development among those companies who do choose to contribute code back the projects.

Finally, another very important trend has also diminished the need for restrictive open source licences like the GPL. In a recent blog post, Jay Lyman[13], an insightful open source analyst at the research firm 451Group, has argued that “open APIs are the new open source.”[14] He argues that “the real keys to openness and its advantages in today’s technology world—where efficient use of cloud computing and supporting services are paramount—exist in open application programmes and interfaces (APIs).”

Open source, open standards, open cloud computing and, in particular, open data are the key to the openness trend in modern IT. But in Lyman’s view, APIs have emerged today as even more critical to openness than the four previously mentioned cornerstones of openness. According to Lyman, several trends underscore the importance of open API’s.

Today, most environments and strategies are defined by cloud-computing, services and the so-called DevOps. Devops are an emergent set of principles, methods and practices for communication, collaboration and integration between software development and IT operations. DevOps are a driver of API importance as different applications have to interact through APIs.

Secondly, so-called Polyglot programming also emphasises the importance of open APIs. Polyglot programming means that several different languages and frameworks, including Java, HTML5, Note.js, PHP, Python, Ruby, and so on have become the basis for mobile, web, enterprise, consumer. Applications developed in different languages have to interact through open APIs.

Ten years ago or so was the time when just using open source software was considered sufficient in itself. Back then, open source software’s raison d’être was as a viable, often lower cost, lower hassle alternative to the proprietary software. Today, all software is generally more open and, again, according to Jay Lyman, we have reached a point where most non-open source software is also considered “open enough” to be useful.

A good example of this is Amazon’s proprietary software that is, indeed, neither open source nor open standards but is considered “open enough.” Amazon’s software is effectively capable of providing value by interacting with other software applications mong these open source applications, such as Eucalyptus, through Amazon’s open APIs.

In conclusion, we are witnessing a world where proprietary software is becoming more “open” not through its terms of licences but through the choice of interacting with the rest of the world through APIs. At the same time, we are witnessing that open source software is “opening up more” to integration with proprietary software, again through the de facto technological necessity of open APIs but indeed, also, through the choice of licence. IT is becoming more open and that openness has even spread to open source.



[1] http://www.gnu.org/copyleft/gpl.html

[2] Gartner Survey Reveals More than Half of Respondents Have Adopted Open-Source Software Solutions as Part of IT Strategy at http://www.gartner.com/it/page.jsp?id=1541414

[3] Investment in Open Source Software Set to Rise, Accenture Survey Finds at http://newsroom.accenture.com/article_display.cfm?article_id=5045

[4] Top 20 Most Commonly Used Licenses in Open Source Projects from Black Duck Software at http://osrc.blackducksoftware.com/data/licenses/ The statistical numbers from Black Duck Software have been disputes by proponents of Free Software. A summary of this debate at http://blogs.the451group.com/opensource/2012/03/05/thats-not-science/

[5] International Free and Open Source Software Law Review at http://www.ifosslr.org/

[6] http://www.heathermeeker.com/

[7] http://www.fsf.org/

[8] Cutting Through The Anti-Copyleft Political Ruse by Bradley M. Kuhn at http://ebb.org/bkuhn/blog/2012/02/11/harald-on-enforcement.html

[9] As an inserted note, new technologies have changed the rationale and dynamics behind dual licensing. Since many software solutions that were previously distributed and installed at the customers’ computers are now being delivered as SaaS, the deterrent effect of the copyleft provision in the GPL is being diminished. The software is delivered, or will be delivered, as a service. No distribution of software code takes place and, thus, the copyleft provision is not triggered. This is a topic for another paper.

[10] Open Sourcers Drop Software Religion for Common Sense by Cade Metz at http://www.wired.com/wiredenterprise/2012/02/cloudera-and-apache/

[11] http://www.apache.org/licenses/LICENSE-2.0.html

[12] http://www.opensource.org/licenses/mit-license.php

[13] https://www.451research.com/biography?eid=301

[14] http://www.technewsworld.com/story/74419.html

Enhanced by Zemanta
Dette indlæg blev udgivet i English, Lexlinux og tagget , , , , , , , , , . Bogmærk permalinket.

Der er lukket for kommentarer.