Liferay Adopting the LGPL License

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.
 
The LGPL
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.  
 

 

Blogs
Well, it's a legitimate detriment to us. Our company has a policy preventing the incorporation of any open source product licensed under GPL or LGPL in any of our products. Irrespective of one's opinion as to the wisdom or necessity of this, there are many organizations that have similar policies. The practical effect to our team is that we will have to switch our pilot implementation to some other portal -- which means that we'll never come round asking about Liferay EE.
Hi Dave, in that case, wouldn't using our Enterprise Edition, which is not under a GPL or LGPL license, obviate that issue? Further, if you are looking to pilot our software, there is always the option of a trial.
I'm not certain that it would obviate the issue... as others have stated, Liferay depends on certain libraries which are, in turn, licenced under GPL, etc. The fact that you license an Liferay EE does not obviate the integral library licenses UNLESS Liferay has licensed them for resale...

Further, I think the change in license structure is a bit disingenuine at the 6.0 stage as I am certain Liferay depended on the feedback and contributions they received under the prior license. Accordingly, I believe there is an issue in any attempt to change licensing that involves those contributions (including code) which were advanced under the prior license.

Maybe I just see things a bit differently because I am also an attorney LOL.
Jorge's response reminded me that Dave's issue is not just limited to just Liferay, but should also be inclusive of the LGPL libraries that we redistribute with our product. As such, if using LGPL or GPL is against company policy, choosing between CE or EE is irrelevant.
Dave, if not for the company policy, are you opposed to the principle of developing a common core platform that everyone can benefit from and build extensions for?
Have you considered another weak copy license like the Eclipse Public License (EPL)? The LGPL and EPL are very similar in spirit but EPL has a bit more protection when it comes to patent retaliation and other things.
Hey Dave,

Liferay was already using several LGPL libraries including some of the defacto standars in their field such as C3P0, Hibernate, jGroups, etc. so if your company policy was ok with those they will probably be ok with Liferay's code being LGPL too.
We are currently plan to use Liferay as a platform for our business applications. We are not going to charge for Liferay at all (that was never an issue to us). So, LGPL is not going to charm us in any way. I understand that it's a bit of a shame to make software someone other renamed and sold as its own.
As for Dave - it's pretty naive to prevent use of GPL/LGPL based software in your company. I don't want to even think how my life would look like without Apache, Tomcat, JBoss. Life would be dull without GPL. Cheer up, go and evangelize your management, because you guys are making a huge mistake.
I'm going to start off and say that I love Liferay. I think that for a free product, it's a really good one. You guys are "this close" to being all that and a bag of chips.

That said, I don't think that LGPL or MIT is your core problem. As long as the price tag stays free and the user is still protected, it doesn't really change anything. If anything, I think it will help you. The GPL and LGPL are much better known, thanks to products like Apache.

Changing your license won't do much if you're not really an enterprise ready product. Saying that you're "Enterprise" means certain things in this business and you guys don't deliver. If you want to push Liferay as an "enterprise" product, you have to get some of your major issues fixed.

One of the main ones is the security through obscurity issues that you have. Authenticating anyone with an NTLM user name, which can be obtained from the web site itself, and invalid password isn't an "enterprise" security model. Those sorts of problems are going to be a definite bar to entry to any company who wants to have a web site open to the public. Just hiding buttons and links really isn't sufficient when you can send a properly formed URL and have administrative control of certain functions. Having to have god rights to the database in order to function is also a no-no. Having to grant portal wide rights to a community administrator is another no-no.

You're going to have fix some of the other things too. Your data structure in your database is just insane. That makes it really hard for the community to contribute back because we can't figure out where a lots of stuff is stored. And it makes doing backups, restores, and other BCP "enterprise" functions unnecessarily difficult.

You've got to fix the special character problems that you have. Not being able to have special characters in blog titles, wiki titles, job titles, etc. is really hard on us, and we're strictly an english web site. You're absolutely killing the russians, koreans, etc. who's language is in an alphabet that entirely counts as special characters. And, just so you know, not being able to use !, &, or ? makes you not an enterprise product. So does not supporting internationalization.


The fact that I have to set the event types in a text file and restart the entire Liferay portal to add one new event type - that's not an enterprise ready feature. Changing a very minor configuration option should not require restarting the server. I guess that's ok if you have 5 people browsing your church web site but when you sell a very expensive product and you have a large user base downtime = lost income. Nor is this the only thing like that. And that needs to be fixed before you're really an enterprise product.

Moderation of comments, forum posts, and blog posts and other user contributed content is another feature that is going to have to be addressed before you can truly be enterprise. For most of us, we have LEGAL liability issues around allowing unmoderated content, never mind the spam. Because it cannot currently be moderated, we have it disabled. Yet this is precisely one of the features that drew us to your platform. I cannot tell you how disappointing it is not to be able to use it.

You also have to fix the field length for a lot of things. I know that some job titles seem long to your developers, but you know, that happens in an enterprise. When you have a lot of people, some companies start handing out very descriptive and thus long, job titles. You have no idea of the crap storm when you have to tell the Senior Vice President of Staff Management, Retention & Compensation that he can't have his job title because it has a & and it's too long.

Sadly, this isn't the entire list of really basic features that need to be addressed. If you're going to claim to be enterprise, you need to be enterprise, and IMHO, you ain't there yet. I've worked with true enterprise products from Oracle, IBM, Sun, SAP, and even Joomla doesn't have some of your issues. I've been watching the Proposals Wiki to see what's going to be included and so far, I'm not seeing much. It's certainly not any of the issues that I would consider critical for you to fix.

You guys have a lot bigger fish to fry than what license you release your CE under. GateIn - the combination of JBOSS and EXO, is definitely poised to give you a run for your money. It is also open source - LGPL. And from what I understand, EXO was originally a fork from Liferay. There is already a mechanism to port Liferay portlets to GateIn. Given the traction that EXO and JBOSS have historically had separately, having them merge has to concern you. The one thing that JBOSS has historically been lacking is a good default set of portlets. The merger with EXO provides that for them. I would think that instead of addressing the license, you'd be addressing your competition. Something on why we should choose Liferay over GateIn might be appropriate.

I am hoping that this serves as a wake up call to the Liferay. OSS is littered with "flash in the pan" projects that were hot for a while but got eclipsed because they weren't responsive in fixing serious problems. OSS is very darwinian, by its very nature. You grow and evolve or you wither and die. Its my sincere hope that Liferay doesn't end up on the scrap heap.
Excellent choice for the new license, but... Are you going to continue 'pretending' to be an open source company? Holding back critical security patches from the community as only available in the EE license is NOT a practice you find in a REAL open source project. Sure your eventually pass them on in the next release, but you also pass on the next round of vulnerabilities at the same time. Real open source projects protect their community and release these patches as they come available. I don't expect you to manage the upgrades for me as a CE user, but I sure expect to get patches without having to pay for an EE license. If you're doing this to foster the community, you should look at this practice and do something about it. Until you do you'll just be another company leeching off the open source community to sell an 'Enterprise' version.
I understand your reasons and goals, and I do agree to them.
But I'm not so sure whether you took the right action to achieve those goals.

We deliver Liferay to our customers including some portlets developed by us to access our main product. We always made it very clear that "our" portal is based upon Liferay, what is part of Liferay, and what is our contribution. From it's intention we have no problem with the new license, but I'm not so sure whether our lawyers will see this the same way.

But quite often it was necessary to change or fix something in the Liferay core system. At the beginning we contributed our findings and patches using the forum and jira. But in most cases there was no reaction from Liferay, so we stopped doing it and just fixed our code version.

As others stated above, Liferay has to improve the community feedback loop. Don't hold back important fixes for the EE version. And give a timely response to user suggestions and contributions, because this will encourage the community to contribute.

PS: Dear fellow commenters, stop justifying the change to LGPL with successful projects like Apache and Tomcat - that's apache license and totally different from LGPL. If at all it's an example against using LGPL!
Hi Rainer, you can leverage Plugins like Portlets, Themes, Layout Templates, Webs, Hooks and Ext.

The powerful hooks mechanism can be used to modify Liferay core behavior without modifying the core. In fact, even Liferay EXT environment is now available as a plug-in; in LGPL terms, it will be considered a linked piece of software and therefore it is not subject to the reciprocity rules of the LGPL.
Will this really be enough?

For example this issue we experienced in the past:
We use Derby DB as default database because this way we can ship a bundle including database to our customers. Is a redistribution of Liferay in this form allowed with LGPL?
The SQL upgrade scripts and the auto upgrade classes for Derby coming with Liferay have been broken several times. We fixed it (and posted a patch to jira, where it was ignored) and shipped the fixed version to our customers.
I don't think this is possible with any hook or plug-in, or is it?
Obviously, I do not know the exact specifics, but if I'm understanding you correctly, this should be possible via our Ext. Our upgrade scripts are fired off from a list compiled in the portal.properties, under the property "upgrade.processes". You could then easily extend our own class (or write your own) and then plug it in via the same property.
Wouldn't it be the better was that bug fixes are integrated by Liferay instead of having to deal with such issues?

The question is NOT, if something like this is possible.
The question IS, why we have to do such workarounds?
It is NOT a question of the license.
It IS a question, how to deal with contributions!
Hey Tobias,

We have several engineers whose responsibility is to review contributed code and to bring it back into SVN.

There are about 750 to 1000 new tickets each month. It can take anywhere from 5 minutes to 3 days to process a contribution.

Processing a contribution takes a lot of time because we need to:

1.) Make sure it is a real problem and that the contributor is not misunderstanding something. I've seen people change code for things that had a configuration setting.

2.) Some issues take a long time to duplicate because it requires extensive setup. Think of all the combinations of database servers, LDAP servers, app servers, operating systems, and JDKs.

3.) Read through every line of code to make sure it's not a malicious virus. I've caught a few of them myself where people submit a "fix" that is a backdoor to give them Admin access. Sometimes the code is VERY clever and not immediately obvious. It takes experience and I invest a lot into training up my team to be able discern those issues.

4.) Regression test possible ramifications. We currently have about 3000 integration tests, but the problem is that no matter how many automated tests we have, nothing beats understanding the code and having the intuition to see how it can affect the rest of the application. I'm not going to commit something even if it passes our tests unless it's been read by someone I've trained who knows the code well. I've been bitten before by careless checkins, so I'm pretty stringent about what gets in.

And to be honest, all of this requires a lot of money. I work 80 to 90 hours a week on this project because I enjoy it and believe that it's my calling to serve others through a solid open source product. I did this even when I wasn't paid to (I started Liferay back in 2000 out of my garage because my pastor asked me to a build a website for our church). But the rest of my engineers don't go through community contributions because it's their #1 passion. They do it because it pays the bills AND because it's challenging / fun. But the key is, it pays bills.

I'd love to staff more full time engineers to go through community contributions, and I promise you we'll do that as we sell more EE licenses. 10 years ago, I had do everything myself (and man I suck at JavaScript and design). Today, we have a full time staff of over 120 people. We're looking to hire about 20 to 30 more engineers in Los Angeles. So if you're willing to relocate, send me your resume at careers@liferay.com. And if you're tired of waiting, ask your boss to buy an EE license so we can staff a trained engineer to take care of your needs.
I understand those aspects!
I have to deal with similar problems with our own customers.

But lets have look at this issue (just as an example): http://issues.liferay.com/browse/LPS-2371
Did anyone read this one at all?
There is no comment about it.

Something like this is very frustrating and the sum of all occurrences like this prevents me from contributing (or even filing) more issues.
I just file those hat are very annoying (or severe in my point of view)!

We are already in negotiations about EE (and we had some contact with Liferay in Germany).
The problem is: We give the portal for free to our customers (as an additional tool to out Software).
So there is no additional revenue created by the portal and we need to find a way to cover up those extra expenses created by using the EE.

But nevertheless: The CE shouldn't be the "ugly nephew" of the EE (this might be exaggerated, but hopefully it helps to make clear my position).
@Mauro Those are very good questions. I want to be very clear here that the change of license does not change anything for consultants doing a Liferay project for a client. That is, you can of course use all types of plugins, and in that case you can also modify liferay's files (such as the JSP you mention) since the purpose is not to redistribute them but to use it internally. The LGPL only specifies that whenever you *redistribute* a change to the original source code then you have to also make it open source. In other words, this characteristic of the LGPL affects to companies creating products based on Liferay in which they have modified the original code (either directly or by making copies of it).

In your specific example, if you create a plugin (hook, portlet, it's all the same) in which you have started from Liferay's code and you use it in an internal project (incl. for a single customer) you ar fine. But if you redistribute it, then the LGPL license requires you to make the plugin Open Source too.

@Rainer Redistributing Liferay with a Derby DB is perfectly fine. In fact, as long as you don't modify the source code included by Liferay there is no difference between the LGPL and the MIT.

Regarding the fix you contributed, I'm sorry if it hasn't been accepted, we've probably missed it. Can you post a message linking to it to the "Contributions" category in the message boards to make sure we don't miss it this time?

@Mickey Thanks for the link, it was an interesting read. Although what I've understood from the article is rather the opposite. It's saying that SUN didn't contribute back to the Open Source projects it was basing it's products on, which at the same time Linux had a GPL license and people were contributing. LGPL is not as restrictive as the GPL but our purpose is the same, to get companies that make a business out of Liferay to contribute either economically or opening the code to the community.

@Lisa Thanks for your comments. They are always humbling but let me tell you that we are listening and we are doing our best to keep improving the way we do things.
@Jorge When ends internal use and starts "redistribution"? Suppose I create plugin, where I start from Liferay's code, I use it for a single customer. After a while, I use the same plugin (or almost the same) for another customer in another project, and then maybe for some other customers too. Is it still ok? What is "redistribution" precisely?
@Jorge: I think it is very important what Rafal asked here. I think, this has to be made very clear and written to some License-FAQ. I have thought about Your answer, Jorge, and it could be possibly interpreted also in the following way:

1. If I create the plugin or other derive some extension based on some liferay code and will distribute it "as a plugin" or "as such an other product", then I have to release it under LGPL too.

2. If I just make the individual solution for the concrete customer based on Liferay and add to it such "my own" extensions based on Liferay code, I do not to release such a stuff under LGPL...

Is it so? I did not understand the LGPL I can do something like I described in the point 2...

How is it? Thank You in advance to make it so clear as possible...
Why are we beating around the bushes, we all are Liferay developers, why are we talking in general terms. They are only 4 ways to develop against Liferay:

1- Create a JSR 168/286 with other Tools such as Eclipse. That's clearly has nothing to do with Liferay License.

2- Create Prtlets, Themes, Layouts, Hooks,...in Plugin SDK. What License these fall under: LGPL or MIT?

3- You modify the behaviour of the code using Liferay Extension Enviorment: What License these fall under: LGPL or MIT?

4- You modify the code in the Kernel. That's clearly will be under LGPL.

So anyone can answer the 2 and 3?

Thanks
I'm hard on you guys, I know, but I *really* want to see you succeed. And success isn't easy. I've seen too many projects that operate in their own little "hot house" environment until harsh cold reality crashes through the glass. Its easy to get caught up in the praise and attention that goes on inside and not to see the blizzard that's raging outside. I don't really know how else to describe it.

Because of so many of the things I see happening with Liferay the company, I have the feeling that this has been going on there. I think you need some reality in small doses before it bites you - HARD.

If I didn't care, I wouldn't say anything. I just wander off and find something else to spend my time and energy on. I'm glad that you guys are listening. I've got a lot of experience with this stuff from other products and time in the field dealing with them. I'm happy to share it with you guys.

And if you'd let me, I'd be happy to help where I can. I'm not much of a Java coder, but I am good at documentation and lot of other things that no one else wants to do. There are plenty of others around here who would also be happy to contribute. Let us help you.
@Lisa Thanks for your comments.

I hope you, and the community, don't think that we're just another company out to fill our own pockets. There's a reason why our tag line says "For Life". A lot of us have poured our sweat into making this company great, not for our own glorification, but so that we can continue to do _greater_ things in this world. And by greater, I mean like donating to charities like World Vision that provide support to those in need in Haiti or Chile that are suffering from the earthquakes. Being profitable affords us a means to that end.

We certainly are not and do not want to be one of those companies that have the large corporate expense accounts that burn through cash without a second thought. In fact, we've always been the type of company that has prided itself on growing organically - perhaps too much so.

Many of you have asked: "How is Liferay dealing with contributions?" We are, and continue to, accept contributions from the community. But as Brian Chan stated, there are conditions that need to be met in order for us to incorporate those contributions first. Our goal is to hire the right talent that will enable us to continue to improve our product, which in turn will result in our being able to review more of the 750-1000 tickets that come in every month.

And while we want Liferay to ultimately succeed as a company, and we want to ensure our own job security, a lot of our own folks believe in the vision of this company and what we're trying to achieve. And since you brought up Proverbs, this is what I personally like to remind myself of:

Proverbs 30:8
"Give me neither poverty nor riches, but give me only my daily bread."

We're always open to speaking with our community and getting constructive feedback. Documentation is always a great way to contribute - we may just have to take you up on your offer. =)
Thanks Simpson - if you are at Gartner PCC next week - I'll be there and we can grab coffee - I'll be the one wearing a tie (sorry - inside joke).

If not - ring me up sometime and maybe we can meet for lunch - my treat.
Hi Rainer, thanks. This kind of upgrade process fixes can be done in plugin Ext same as that you have done in Ext Environment. It would be good news to use plugin Ext rather than Ext Environment. In this case, LGPL changes nothing for customization of Liferay portal core.
All fine but problem is here, (in FAQ stated above)
I have some modifications I've made to LGPL-licensed Liferay code, but Liferay has not accepted my contribution. Am I violating the LGPL?

No, in that case you are not violating the LGPL as long as you do not re-distribute the modification.


My question is, we modify the core class (ex: for login or etc.,) which more depends on our requirements and related to our organisation (& sister orgs). In which way it is usefull (& acceptable contribution) to liferay.
so this is the clause which creates a problem in new licence.
I think there are same confusion about what we can and what we can't do with LGPL'ed software.

The issue arise when a company, or a professional, install Liferay CE to a customer and start to customize it developing plugins or extlets

Which kind of personalizations could be done? Portlets are ok, Themes are ok, Layout Templates are ok.

And Hooks?

With hooks you can replace portal's jsp. With hooks you can extend services (via spring).

Are they really ok?

One 'real' use cases.

My customer want to have localized document library: title and description have to be localized.

Forget for a while that this feature will be included into Liferay 6.0, and suppose that this kind of customization is possible with a hook that:
* add 2 custom fields to DLFileEntry
* allow user to add localized info into these fields (standard title and description have default language values)
* show default or custom fields value depending of the active language.

Create custom fields is easy with Expando and StartupAction hook.

Now we have to 'extend' edit_file_entry.jsp to add localized input infrastructure (written from scratch o copied from a page having it?)

How can we do that?

a) use "liferay-util:buffer" to render original jsp into a string and make some string manipulation to add our changes

b) copy portal file edit_file_entry.jsp into my hook portlet and make the changes in it


And now the questions to Liferay Team and licence experts.

1) Is a) allowed by MIT licence?
2) Is b) allowed by MIT licence?
3) Is a) allowed by LGPL licence?
4) Is b) allowed by LGPL licence?

with allowed I mean: can I make the customization and give a "closed" licence to my portet?

5) Is this "hook portlet" configurable as a Liferay redistribution?


I think that this small example represents only a portion of customization needs.

Ext environment allow you to change Liferay in a deeper way.

But some changes involves an "if" in the middle of a class method.

Were this kinds of "ext changes" allowed with MIT?

Will be this kinds of "ext changes" allowed with LGPL?

A product based on Liferay with this kinds of "ext changes" has to be LGPL? Has the entire ext sent back to the community?
I would strongly suggest, because I really do care, that those who are decision-makers at liferay take a few minutes and read this blog. http://blogs.zdnet.com/BTL/?p=31418&tag=nl.e539 It attributes the downfall of Sun to the very same licensing issues that Liferay is proposing.

To say the least, I am still very disappointed.
You know I read that too! It's not just the licensing issues. A big piece of he's talking about in the article is not using code, fixes, and solutions that are contributed by the community. Unfortunately, this is exactly what Mr. Kim seems to be suggesting. If Ranier has a better answer, why not incorporate it so that we can *all* benefit from it? Are you so arrogant that you think that only the developers at Liferay can code for your product? SUN certainly was and all I have to say is you people need to read Proverbs 16:18 and take that to heart. (Pride goeth before destruction, and an haughty spirit before a fall. - for those of you who aren't familiar with the verse)

Isn't making use of community contributions the very foundation of open source? Perhaps Jef is right and you're just pretending to be an open source product.

There are other similarities that I see that didn't get mentioned in his article. One of the main ones is what I refer to as the "call to install" business model where the installation and/or configuration of the software is so convoluted that you have to call in the high priced consultant to do it for you. Doing anything but the simplest of tasks also requires the expensive consultant. Great if your the consultant but sucky if you're the sales guy trying to talk an IT manager into the product.

The refusal to innovate despite customer requirements and requests.

Management who was more concerned with their quarterly bonuses, perks, and other things than actually growing the company, continuing research & development, or otherwise investing in the continued existence of the company. I doubt "fiscal responsibility" is not a term that is used much.

The "rockstar" engineer/managers who are all about showing up for events and "repping" the company, when they should have been back at the office keeping an eye on the business itself and getting some work done. Unfortunately, the "rockstars" usually have a corporate charge card and/or expense account and next to no accountability. They end up bleeding the company on both ends. First from not minding the shop and getting work done. Secondly, from spending a lot of money the company really doesn't have to do "media appearances". A good marketing and PR person could do just as well for a fraction of the price.
Mickey,
I took your advice and read the posting. In it, Jeremy argues that Sun's acquisition by Oracle resulted from Sun's restrictive control of the code - but - there were many product strategies in Sun defined by individual teams after evaluating their industry, community and technology.

Note: I was very involved in the management of GlassFish, Hudson, OpenPortal, OpenMQ, OpenSocial, WebStack (Tomcat, ApacheHTTP, etc.), Sailfin, as well as others, while my friends and peers also managed MySQL, Mozilla, OpenSSO, OpenDS, OpenOffice, Netbeans, Solaris and more - so I am familiar with many activities and decisions surrounding open source at Sun. Each of Sun's open source teams was required to determine their strategy for success in the market. Every one of the examples above had a different action plan often based on a lead, mentor, or partnership strategy, e.g., GlassFish was to "Lead" in the Application Server layer (partly due to Java EE leadership and Tomcat success) while Sun Portal was to "Partner" with Liferay (because of Liferay's leadership and capabilities).

Jeremy's article - was by one individual on one project who wasn't supportive of the decision made by their product team. There was no universal decision on restricting access to code and Sun had a selfless approach to open source which resulted in many highly successful communities and products (see list above). Bryan's blog perfectly details our concerned desire for the future of our technology, community, customers and partners.
Things I have never been clear about are:

1. Liferay uses Hibernate which is LGPL(and jbpm), so if you use Liferay you are actually adopting MIT and LGPL licenses which is not transparent or good
2. I assume Liferay takes contributions from the community. People have contributed under the MIT license. So does the code and IP (that's the important bit) mean they have to be consulted if their the license associated with there IP changes? If they are not consulted could they thus potentially sue?

Not expecting a clear answer to this because there is no clear answer to LGPL, that is problem it which this thread demonstrates.

I understand that your unhappy that you believe the community is being stiffed by certain commercial companies who don't contribute back and you no have more salaries to pay then when you started out, but:

1. If Liferay is really an Open Source community, do you have a right to make this decision on the behalf the community you believe you are protecting a community that grew based on the MIT license. Surely if thsi is a community then
2. Are you sure even those companies you believe to be stealing the communities IP are not contributing arnt. They download and install if they do this they tested liferays install procedure, they used documentation, they raised forum posts, they spread the world, they trained people. Community is not just about cutting code.
3. if you can take Open Soured Liferay and package it as enterprise with extra add ons not available to the community (V6 release notes mention enterprise only customers), then why do you object to other organisations that do this or in fact do you really regard Liferay as your product and Open Source community as customers?

For what its worth (and in this community the evidence would suggest that it actually does not matter much), I'd suggest that whilst you may think you have thought this through based on your somewhat naive responses to date you have not, although for the majority of users I suspect this will make little difference.
The new license is absolutely unclear to me.

If we create customer specific portlets and install them together with Liferay at the customer's site are we forced to make the portlets open source?
Nope your fine. That's like creating a shell script on Linux which you can sell (if you can find a market).

Now if you took a liferay portlet as your base code and modified it then under the LGPL license you are obligated to make that source code available. This does not mean you have to commit back to liferay, you just have to make the code available (publish it on a web site, distribute it with your binaries etc) and apply the GPL terms to your (your plus there's) source code/libraries, see bottom of

http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html

Additionally if your portlet is based on a liferay portlet and you then add in some of your propriety code then this code also has to be open sourced i.e its not just the changes to the Liferay portlet code that you have to open source but your propriety code which is deemed to have been derived on top of the liferay code. This is the viral nature of LGPL and is why Apache foundation (not to be confused with the general Apache 2.0 license) wont touch it and why Jboss take great pains to provide very well defined interfaces that can be used to extend their open source projects with out infecting other third party code with LGPL.

Basically if your not changing Liferay code or your using the defined liferay interfaces for extending Liferay or your happy to open sourced and changes you make to Liferay code your fine.

Hope this helps.
If I may... a little off-topic. What should I do to receive pricing for Liferay EP? I tried the online form and emailing sales@liferay.com last week, but so far with no response. Maybe I'm doing something wrong, but it would be splendid to finally receive information on Liferay cost.
Wow - I guess it was foreseeable that this decision would create some buzz. But mostly I don't get the fear people express here:

As I understand it, LGPL is about "Change" via "Add". If you add to code through some means of plugin mechanism, it's yours. If you change some code distributed under LGPL, it's LGPL. (overly simplified)

What does Redistribution under LGPL mean? You need to grant the source code and freedom of the LGPL only to those parties that you distribute your products to! You're not obliged to publish it on your homepage, nor are you forced to host it on sourceforge or anywhere else. You don't need a public source control repository or a community - you need to offer the source code to your direct customers only (as I understand it).

Of course, those customers can take your code and publish it on sourceforge. But - be honest - how many customers would you expect to do so? It's usually not a business model to buy software and publish them somewhere, so usually nobody bothers. If they do you're most likely way ahead of them, as the one party knowing your code best is you.

And if you have some very secret code, you just need to package it as plugin (e.g. "add") to liferay, to use liferay code as a library. This way you're free to use any license you want.

It'll be nice to see some clarification, perhaps with examples, about this topic. There have been numerous scenarios here in the comments that can serve as starting points to get into it.

Note that the message boards also have a section related to the change: https://www.liferay.com/community/forums/-/message_boards/message/4682861 - I guess they are way better suited for discussing the amount of comments generated here.

The rest is not really a comment to your blog post, but to many comments already here:

Regarding contributions in Jira, I understand that not everything fits and can be taken back, but I'd like to see some reaction to contributed tickets: See this list: http://issues.liferay.com/secure/IssueNavigator.jspa?reset=true&&status=10001&sorter/field=issuekey&sorter/order=DESC&sorter/field=updated&sorter/order=ASC (filtered by "contributed solution", ordered by "last update date". I'd like this list to be way shorter - either by marking the issues as "outdated", "rejected", "evaluating", "need more work" or whatever. Think about the motivation that's lost by not recognizing anything at all - some people here also post about having no incentives to give back.

There's so much more I'm tempted to comment, but it's hard to separate the different topics in such a post with no threading at all...

Over all, the license change is fine with me. I don't get the fear the lawyers have whenever a license contains a capital "G". Plus, I'd definitely like to see a more active CE. 5.2.3 is out for a while now, there's some service releases to EE already and no 6 yet. If LGPL helps to open the branches again or to have a more active CE, everybody wins. I'd *love* to see that.
Basically, if I take one of the portlets that is in Liferay now and I'm going to use the Calendar as an example. The calendar doesn't really do much for any of us. The functionality just isn't there. So if I start with their calendar and I spend hundreds of man houses tomake massive modifications to it, even to the point that it no longer even vaguely resembles their portlet, instead of being able to sell my portlet, I have to make it publically available. I cannot sell my portlet. However, under the current MIT licenses this would be perfectly permissible.

As for the contributions that Liferay hasn't had time to vet for compatibility, I've set up a separate project on Source Forge under the North Texas Liferay Users Group. Here's what I'm thinking. Package it up as a hook, plug-in, or portlet. Submit it to the NTXLUG Source Forge project and let the community test it.

Think of it as the community contributed modules that you get with Joomla or ZenCart or WordPress.
You can still charge, to quote from the license:

"You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. "

You just have to identify the code as being a derivative of a LGPL librray see bottom of http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html and the make the source code available on request (or ship it with your distribution).

As the previous post stated LGPL is usable by commercial applications/service companies, you just have to have an improved level of governance around how you use it.

However what I'm finding difficult to understand is that the Liferay company did not consult the Liferay community that its supposedly trying to protect and grow, before making this change. I'd of thought the North Texas Liferay Users Group and groups like it would have got a heads up in a some form of consultation process?
I've just come to the Liferay site, and I have to say that having seen other projects on the internet fall apart due to licence changes I have to post a few comments.

1) You have published the following FAQ

I have some modifications I've made to LGPL-licensed
Liferay code, but Liferay has not accepted my
contribution. Am I violating the LGPL?

No, in that case you are not violating the LGPL as long
as you do not re-distribute the modification.

The right to re-distribution is not limited in any way by the changes being accepted (or not) into Liferay's systems.

2) Liferay needs to provide it's basic range of portlets under a different licence (such as MIT) otherwise developers new to the product do not have access to a good stock of 'active' source code to build on. One poster has already commented on having used the Calendar portlet to create something of 'worth' at the moment his work is covered by the MIT licence, but is it worth Liferay losing future developers by restricting such basic modules.


3) For those people making comments that they are not allowed GPL and LGPL based solutions in house you will just need to point out how much of the average business environment is already based on such licences. In my own environment my IBM SANs are running Linux (GPL), by QLogic SAN switch is linux and even my HP printers state that they have LGPL software inside.

To people at Liferay can I say that so far these threads read very much as Liferay has decided and that's that, which is not a good direction for things to go in.
You might want to be aware that we moved the discussion into the forums at http://www.liferay.com/community/forums/-/message_boards/message/4732251
Does the LGPL extend to modifications of plugins - portlets, themes, etc that come out of the box? Or it is in reference to the framework?
Hi Bryan,
Users in most of the forums are curious to know when Liferay 6 will be released. I am involved with Liferay since version 4 but this is the first time I am seeing so much of delay in releasing a version.
Is there any specific reason why Liferay is not committing any dates on release of Liferay 6?

PS: There was a date in the roadmap but it has already passed.

Thanks,
Vineet
[...] Liferay has been talking about App Marketplaces for a few years now, and with much fanfare we announced the Liferay Marketplace last year. It's been a while in the making, but we should see the first... [...] Read More