I would like to announce that starting with version 6, Liferay Portal will be made available under the Lesser GNU Public License (LGPL) v2.1.
The short history of commercial open source software vendors is littered with examples of vendors promising why these license changes made time-to-time are of benefit to the so-called “community” whereas the real motive is often to accommodate the vendor’s shifting monetization strategy. It would be reasonable then for you, the Liferay community, to be skeptical, were we to go down that familiar path of trying to justify something which may or may not really be for the community’s benefit.
So instead, let me explain what the different pros and cons are of the MIT and LGPL licenses, why the LGPL will benefit both Liferay and its community members, and where the license change fits in Liferay’s larger strategy to enable our community to build better business solutions that benefit end users using Liferay Portal.
The MIT (X11) License
Liferay has now been available under the MIT license for ten years. That’s an impressive history and we have a fondness for this license for its simplicity and its bold permissiveness. Brian Chan first chose the license because of the prestige of its namesake (though I argue we should have chosen the BSD instead for that reason!) and because it added the lowest number or words to the source. :)
Over the years we’ve enjoyed the benefits of the MIT license:
- It’s a permissive license that unlike the Apache (1.2) license is compatible with the GPL (v2 and 3)
- It completely mitigates any risk for prospective adopters of the software
- Anyone can do anything with MIT-licensed software, creating a proliferation of the technology and a wide footprint for that software. People are wiling to invest heavily in innovating around MIT-licensed software
Ultimately, our comfort with the MIT license lay in our confidence that in open source it’s not the IP that matters as much as the experts behind that IP, and this continues to be the case today. No one can innovate around user experience, portal, and collaborative technologies in Liferay as well as Liferay, Inc., can, and the community has always returned to the source for the latest in Liferay technology.
The Trust-based Model Has Drawbacks
At Liferay we also have a certain optimism about open source and those who believe in the open source philosophy. We believe that by extending the most freedom to Liferay users, they will extend their best to us and contribute to an ever richer platform with more and more capabilities.
On the whole, the ubiquitous adoption of the Liferay platform is good for the community because it gives Liferay credibility. The Liferay you are an expert in is the same Liferay chosen by so many high-profile technology vendors (including Novell and Sun) to be a very important part of their technology portfolio. We’ve definitely benefited from that publicity.
The downside of the permissive MIT license was that some companies (usually looking to sell a proprietary product) would redistribute Liferay without any monetary compensation to Liferay the company and without any contribution of features, fixes, or enhancements to the wider Liferay community. So not only are these vendors not giving to Liferay and its community, they are forcing others to pay them for a product that is 90% Liferay. If you are a community member, this is irksome because you’ve invested in that 90% that they are using without compensation. If you are Liferay, Inc., you suffer the double injustice of not counting the vendor as a customer AND possibly losing some other customers to this vendor.
Licenses and Business Models
To a degree, Liferay was comfortable with the tradeoff of permissiveness for the occasional lost prospect who decided to go it alone, but there were other side effects that would not fit with the future direction of the company. EE has been doing very well since its introduction last year, but we’ve known for some time that we want to expand Liferay’s impact in the software industry by accelerating its adoption as an enterprise application platform.
Several of the things needed for Liferay to be an effective platform are already in place:
- Ubiquity and compatibility across a breadth of infrastructure and technologies. This has been one of our core strengths since Liferay’s inception; vendor neutrality and technology independence are hallmarks of the Liferay brand.
- A plug-in architecture that can accommodate extensions and modifications. Liferay’s plug-in architecture has been evolving rapidly in the last two years and is now powerful enough to accommodate any customization or extension that might traditionally accomplished through direct modification of the code.
- A developer community. Liferay’s open source community has always been strong, and we’ve used Liferay’s own social networking capabilities to create a home for our developers on Liferay.com. We will continue to improve the Liferay.com community sub-site so they can truly collaborate, learn, develop their profile, and share their work.
- Improved tooling and APIs to empower developers. Liferay’s collaboration with Sun yielded the very helpful Portal Pack for NetBeans, and Liferay recently hired Greg Amerson, lead developer from MyEclipse, to build further tooling for the Liferay platform. We are also investing heavily in our new Alloy UI framework, which will greatly simplify the user experience portions of web and enterprise application development.
The last piece of the puzzle to bring this all together is a marketplace where the Liferay community and Liferay solution partners can market and sell their solutions to the Liferay eco-system, and the inception of the marketplace is one of our top goals for 2010. As we thought about the requirements for this marketplace in 2009, we saw an interesting drama playing out in the mobile market between Google’s Android and the Apple iPhone. Google had chosen a permissive Apache license for their OS, which led to a fractured market and constrained Google’s ability to foster a healthy marketplace for Android applications. Apple, by contrast, had retained tight control over the iPhone and the App Store and, combined with a healthy lead in the space, dominated with more than 100,000 apps to Android’s 20,000.
We realized that something similar was happening to Liferay. People were definitely building solutions (applications) “for" Liferay, but they were doing it in a way that would fracture the install base. Rather than building solutions compatible with a single common platform by properly isolating new code in a pluggable and segregated form, vendors were taking Liferay and modifying it directly to create slightly different products. Left unchecked, this had potential of becoming even more of a liability to Liferay than lost revenue, because a fractured install base would constrain the value and potential of the marketplace of complementary offerings. With the MIT license, we were in essence trading the “true” ubiquity of a tightly controlled core platform for a “false” ubiquity with many variants.
If Liferay were serious about engendering a marketplace of complementary monetizable products for a single consistent platform, we would have to consider a different license.
Liferay believes that the LGPL will provide the best benefits of the MIT license and the best protection against MIT’s limitations without any legitimate detriment to the community. It will secure the consistency of the core Liferay platform and broaden the reach of that single platform so that Liferay and its community members can build and monetize solutions for that platform.
The change from MIT to LGPL will alienate that small set of users that wish to be able to freely modify Liferay’s core and re-distribute without making any contribution (financial or source code) back to Liferay, Inc. and its community. And this is by design, for it is precisely these folks who might fracture Liferay’s install base and constrain our marketplace potential.
Every other constituency of the Liferay community will see even more benefits with the new license. The LGPL will refine the Liferay community to those who are willing to participate in the creation of a common stable platform for the benefit of all. Those on the fringes who would only use Liferay to their own benefit will be excluded, but some of those who would not otherwise have done so will now decide to make contributions. Most importantly, the addressable market for Liferay plugins and solutions will grow in size and value because of the single common platform enforced by use of the LGPL.
With the LGPL, Liferay will also be freer than ever to err on the side of being generous with the core platform’s capabilities, knowing that our efforts and the community’s are protected and that our indirect monetization opportunities are growing with the widening adoption of Liferay.
Continued Freedom to Innovate
It is important to point out that the terms of the LGPL allow users to modify LGPL-licensed software for their own internal use without redistribution. But even if this were not the case, the major architectural advancements Liferay has made over the last 18 months would still give our community maximum freedom without obligation to use Liferay Portal CE to build solutions based off the LGPL-licensed core. The powerful hooks mechanism introduced last year can be used to modify Liferay behavior without modifying the core. In fact, even Liferay’s EXT environment, which allows modification of the behavior of Liferay’s kernel, services, and UI, is now deployable as a plug-in, which in LGPL terms (as long as you follow best practices) will be considered a linked piece of software and therefore not subject to the reciprocity rules of the LGPL.
It is regrettable that in the past some chose to take Liferay and “hack" the source without contributing back, but some of them did so at a time when hooks and plug-ins were not mature yet as a technology. But with the new architectural developments there should now be no reason not to choose to invest in a common core (and improve it with contributions), even as people build strikingly different solutions. This will be a matter of architectural and community best practices, and the LGPL complements these practices well.
The Liferay Platform: A Marketplace of Solutions
As we continue to strengthen the quality and capability of the Liferay Portal core we are calling our community to the vision we put forth in 2009 at our global Symposia: let’s build effective business solutions that solve real problems for end users, and let’s make them available to all through open source and commercial models to create maximum value for all. Liferay has built a strong and valuable platform with the services and capabilities you need—portals, content (management and aggregation), collaboration, workflow, reporting, social networking, and a user experience framework are just a few of those. Our community will use that platform to create the next-generation of web-based enterprise applications that they can bring to a broader audience facilitated by the Liferay marketplace.
We are very excited about this change and look forward to journeying with you all for another 10 years building great open source software together. If any of you have any concerns or questions please don’t hesitate to ask.