I just read an interesting blog by Savio questioning the value of LGPL. IMO, he has something right, the OSS license chosen for a project is not that important as far as adoption or business goes. The most important driver for OSS is and always has been the brand of the project. Like their commercial counterparts, how the project is perceived by consumers is what drives both adoption and business. So, I agree, LGPL doesn’t add a lot of value. But, it goes both ways, the Apache license is also not that important either.
If you boil it down, the distinctions betwen GPL, LGPL, and ASL are pretty much meanlingless to most consumers of OSS. How so?
1. The viral nature of GNU bases licenses is only triggered when binaries are distributed. Most consumers of open source do not distribute software publicly.
2. LGPL is also not an issue for ISVs as long as they leave the binary as-is. Its viral nature is triggered when the project is both modified and distributed.
So, when you take these two points together, the number of people affected by the differences between GPL, LGPL, and ASL become fewer and fewer. GPL does not affect > 90% of OSS consumers. For LGPL, the number of people actually affected by the license becomes a number that you can probably count on one hand. The ones affected are the ones who actually want to use derivatives of the project within their own competing initiatives that are not LGPL-based. So, do you see how meaningless it truly is?
Why making these distinctions is damanging
This all brings me to my final point. The whole push by Apache.org and its minions that ASL is the one true license is just damaging to open source. When you consider the handful of individuals affected, you got to question the motivation for it, especially when you match it up to LGPL. The thing is though, highlighting the differences only helps those handful of people that have selfish motives and/or want to exploit OSS for commercial gain. Believe me I’ve lived this.
Back in 2003, a group of JBoss contributors tried to fork both the JBoss code base and the JBoss business. IMO, their motives were mostly financial. They wanted a bigger piece of the pie that Marc Fleury was unwilling to give up. Whether or not they were right to do this is besides the point, there are good arguments on both sides, and whats done is done. They initially derived themselves from the JBoss codebase, went to Apache, and thus Geronimo was born. We complained that their derivation was both a copyright and LGPL violation. In the end, they started over from scratch (don’t think the LGPL had value for JBossians back then? think again!). When Geronimo 1.0 came out, their feature set was vastly inferior to JBoss so their push was that it was the only Java EE implementation that was ASL. That LGPL was scary and the only way to get over the fear was to use ASL-based projects. IBM got into the act when they purchased Gluecode (and all the Geronimo developers) and embraced Geronimo as their children’s edition of Websphere. Again, the main push was that Geronimo was ASL based.
We then come full circle to 2010 with history repeating itself (well, sort of). You have Tom Bayerns leaving Red hat for Alfresco to create a competing BPM engine. Now, I consider Tom a friend, and I completely understand his reasons for leaving Red Hat. That being said, launching a new open source BPM engine with the premise being “we want to create something in ASL because it is better for our business”, is not the way to go about it. Again, it smacks all over of having nothing but the zero-add of the ASL distinction. And, is just completely irresponsible.
If you are an Apache guy, you should be appalled by behavior like this when it happens. Individuals and companies that use ASL as a weapon to further their own selfish and commercial needs should be castigated and called out instead of championed as the reason why ASL is so cool and LGPL is so bad. Respect the choice of other open source developers, propagating the myth that an ASL project is superior to a LGPL project because of license distinctions does nothing but hurt the open source movement as a whole. We need to stop eating our own.
Finally, I just don’t want to bash on Apache and ASL. Joining the GPL revolution isn’t so hot either. The fear of GPL virality is used extensively in the dual-licensing ploy of commercial interests. Think MySQL. For me, I would never pick GPL, because I believe in the freedom of letting ISVs distribute my stuff as-is. As for LGPL vs. ASL? I could care less, it really doesn’t matter. You don’t see JBoss caring so much either. Drools is still ASL as well as a number of other jboss.org projects.
Anyways, have fun with this, and remember taking any one position to seriously is unhealthy.
May 19, 2010 @ 18:32:58
I don’t agree with this and it is definitely not just perceptions.
I work for a big company (Nokia) that is an active contributor in many OSS communities. Dealing with the viral nature of the GPL is as far as I know a royal pain in the ass for any big company. Like it or not, big companies have a huge investment in legacy code. Nokia actually went through the effort of open sourcing a lot of their code recently (i.e. Symbian), of which we are rightly proud. This was a major undertaking and a big investment. Since this is an industry with many players and vested interests, Nokia chose a business friendly license: the Eclipse Public License. The EPL is very similar in nature to the Apache License. Both Apache and Eclipse are well respected and widely used OSS licenses. Both are business friendly in the sense that they are non viral and low risk. Our legal people require lots of checks and balances before we use GPLed/lGPLed code because the potential for accidental infringement is huge and mostly not considered worth the trouble. Checks for EPL & Apache licensed code are a lot more relaxed.
Both the Eclipse and Apache licenses are widely used in some of the largest OSS communities in the Java world, e.g. Spring, Eclipse, Android, Apache Harmony, Tomcat, Geronimo, etc. All these communities have strong industry participation with regular contributions from major players in the industry. If I look at JBoss I see a community where most of the committers are Red Hat employees and a decline in popularity that has been going on for several years now. The type of companies that could reasonably be expected to be interested in committing on Jboss are instead (very) active in the apache and eclipse community. I’m pretty sure license and IPR considerations are a big part of that story.
Licensing is a complex issue and I agree it is best to be pragmatic about it. But from community point of view it matters. If you want to build a community around your software, Apache and Eclipse style licensing is going to make it a lot easier to get big corporations on board. If you are not interested in community building, the license doesn’t matter that much either. If I look at how big corporations have actually been using GPL3 I cannot but include it is being used because of its virality. E.g. Sun has wielded dual licensing, GPL 2 & 3 and the so-called classpath exception to ensure most depending companies come to them for a commercial license. There’s very little of that going on in the Apache and Eclipse communities.
May 21, 2010 @ 13:01:46
Jilles,
I wholeheartedly agree that GPL (but not LGPL) is toxic to open source. Its why I never used the license. You have to remember though that Nokia is a distributor of software and that you are in a very small minority of those that consume open source software. Also remember that Red Hat has practically a billion dollar business built on top of GPL and LGPL based software a well as a large set of ISVs and OEMs that we partner with. In other words, we wouldn’t have a business if the differences between ASL and GPL and LGPL weren’t so meaningless. Also, while I do think GPL is a bit of a barrier to contributing, you can’t ignore the vast success of the Linux community and even MySQL. Many large companies contribute to these efforts.
On the LGPL side you have, beyond JBoss App Server, you have very vibrant communities in the Java space like Seam, Hibernate, jBPM, Infinispan, and even somewhat RESTEasy. To discount all these vibrant LGPL communities just because a bunch of lawyers at Nokia make contributing to LGPL projects difficult is wrong. Again, Nokia is in the small minority of companies that actually are affected by these licenses.
As far as JBoss App server goes, I agree there is a definite problem with community building there. The problem has been that JBoss Inc. and then Red Hat have cannibalized contributors faster than they could be created. Once you’ve reach a critical mass of employees for your project (and level of maturity (Jboss is 10 years old)) you become really lazy about community building. Well, not lazy, just really busy with productization and the next version of the project. Community building and managing takes effort and doesn’t happen magically just because your ASL based or not. Besides, the only real credible momentum has come from Glassfish, which is CDDL based. CDDL is very similar to LGPL. Anyways, who are all these companies you talk about that flock to EPL/APL? My $5 bet is that many of them in some way or another compete with Red Hat.
May 28, 2010 @ 09:57:03
FYI: Nokia has been extensively using/OEMing LGPL software for its own products for a long time now.
May 20, 2010 @ 02:51:30
Hey Bill. Nice to see you kicking the coals again. 🙂
I have to say that I agree with the comments about ASL attracting more outside contributors. I think the primary reason for this, as already mentioned, is that corporations are inherently more comfortable with allowing their staff contribute to ASL projects than they would GPL projects. This corporate policy is mainly driven by the lawyers who don’t necessarily understand the licenses to begin with, but see that large companies like IBM are fine with contributing to Apache projects, so feel like it must be legit (i.e. no legal boogie monster to be scared of).
I personally feel like LGPL is really the best of both worlds in that it does not have the viral trigger based on distribution, but on modification. This means that companies can distribute LGPL code all they like without concern of their own product being tainted. However, if they wish to modify the code, they must contribute it back (and technically this only means make the modified source code available, not necessarily commit to the original project’s source code repository). If the company is not willing to contribute modifications back, it is usually because they want to private label or do other things that transform the open source project into a private, commercial product (i.e. compete with the open source project at some level). This prevents the LGPL projects from being cannibalized by corporations who contribute for a while to get a solid base (on the backs of others in the process) and then internalize for a closed source product… which I’ve seen happen first hand with an ASL project. It’s too bad LGPL maintained it’s parent GPL name which gives it such a bad reputation by association.
One final point is to beware of thinking that having a large and diverse contributor base is always a good thing. Having many large companies with vast resources, such as an array of platforms and environments for testing and benchmarking, contribute to an open source project is certainly a good thing. However, there can often be the problem of “too many cooks in the kitchen” which can cripple a project. Although not an actual open source project, this was often seen within the JCP where vendors would intentionally stall or hobble specification because their product wouldn’t be able to implement the spec in a timely manner and their competition would use it against them in the market place. Having all oars in the water, rowing in the same direction is critical.
Tom Elrod
CTO, Co-founder
LoopFuse
http://www.loopfuse.com
May 21, 2010 @ 13:07:14
Tom, I agree with your point that this is lawyer driven, and not necessarily because the lawyers understand the license. If Big Blue likes ASL then some will blindly follow. This goes with my point that Apache (not ASL) is damaging to open source. Feeding the false perception does a discredit to those who have chosen GPL or LGPL.
May 21, 2010 @ 13:09:28
Also, BTW, at least as far as RESTEasy goes. I wouldn’t want some big corporation to come and say they want to contribute. It would create 10 times more work for me. Even when big companies contribute, there’s usually a big mess that us maintainers have to clean up after the fact.
May 23, 2010 @ 19:55:18
Wow. Totally agree. Except that license patriotism can be damaging in the other direction. Like if Red Hat zealously started GPLing everything JBoss. It would be a big headache for a lot of legal departments and risk advisors. One of the things I have to do at work is advise companies on license compliance (not as a legal adviser but a practitioner and I work with the legal team to help unravel things). The FEAR that license diversity in software projects creates is much greater than the actual risk. Most of my customers are (as you say) not OEMs and do not distribute software, or if they do it is like MySQL, but their product isn’t *based* on MySQL. The few that do distribute proprietary software, do have to be careful with GPL, but not as careful as they often are. I’ve had some tell me they don’t support Linux because they don’t want to GPL. The challenge for most companies is to put in the right tools for compliance while simultaneously not killing the “light cost of adoption” that makes open source advantageous to them. License zealots do not help matters and basically feed proprietary software vendor sponsored FUD.
Oct 31, 2011 @ 21:27:55
Don’t forget that there is also a simple license, that copylefts the code and is friendly to companies, and I’m talking about the BSD License, one doesn’t need a multi-paragraph license to be simultaneously copyleft and company friendly, a simple three paragraph license is enough, and BSD proved that. And maybe if FreeBSD had come earlier we would have FreeBSD today instead of Linux, and all of Linux crew would just be part of BSD. Plus, if you think that a Linux system is only GPL and LGPL, think again, Xorg isn’t GPL or LGPL, and also a lot of other components. That’s why FSF, as a list of licenses compatible and incompatible with GPL and LGPL, so that people can read that page and choose wisely and because Gnu/Linux would just be incomplete with only GPL and LGPL products. Now why does it exist so many licenses? In the point of view of the developer, I’m interested in delivering to the consumer the BEST piece of software, not the BEST piece of software with license X, which is also great.
Feb 02, 2014 @ 23:23:51
Believe it or not there are still companies that ship software, or provide custom software licensed on a per seat basis. Your assertion that folks don’t distribute OSS software is simply not true I’ve worked for such companies and with clients who have that business model, and have the possibility that one client may switch their model to a distribution oriented model. I am not a Lawyer, but the key issue I see with LGPL is the reverse-engineer clause. No company that distributes code wants to give away the right to reverse-engineer their proprietary code.
———-
4. Combined Works.
You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:
———
This grants the right to reverse engineer any part of the combined work, including the proprietary portion. Since ANY modification to the LGPL code is allowed this would include a modification one that exposes a service (web service? RMI?) utilizing the proprietary code, accessed via reflection (java example) or other run-time binding.
I could be wrong… If so please tell me why.
Feb 03, 2014 @ 16:00:33
Article I wrote a long time ago…but…”Most” != “ALL”. Most companies that consume OSS don’t distribute it. “Most” to me, in my experience is a very large majority. As for “Combined Work” comment, IANAL, but I’m pretty sure this is talking about the LGPL library itself, and not the Application code. Its talking about reverse engineering of the library within the combined work, not the application code itself.