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.

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?

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.

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.

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.

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.

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.

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 might want to be aware that we moved the discussion into the forums at http://www.liferay.com/community/forums/-/message_boards/message/4732251

Hey Vineet,

We're looking to release the next RC2 this week. It's a TON of work Thanks for waiting.