Rick is a DZone Zone Leader and has posted 36 posts at DZone. You can read more from them at their website. View Full User Profile

Are You At Risk? Abrupt OS License Changes

04.22.2008
| 11381 views |
  • submit to reddit

What do you do if you build your project with an open-source library, but that library then changes its license to one you cannot easily work with? For example, you choose a library licensed under the terms of the LGPL, but later the provider announces that the new version is licensed under the more restrictive GPL? (or is it less restrictive!) Would you:

  • do nothing and just continue using the original version?
  • replace the library with an alternate solution?
  • fork the original and seek help maintaining it under the LGPL?
  • accept the GPL and whatever that implies for your project?
  • approach the library author to negotiate an exception?

These are real-world issues and questions that probably occur more often than most of us realize. For example, the popular open source Javascript library, Ext-JS, has recently switched from a “nearly LGPL” license to the GPL v3. On the surface, the license change seems to align Ext with a dual-licensing model popular among commercial open source offerings, but some Ext users feel left in the lurch.

The original developer, Jack Slocum, explains how Ext started as a labor of love but had to become commercial in order to continue. It's certainly a plausible story, but where does it leave the users who adopted Ext and helped make it popular under the more permissive license terms? Do they now have to ante up for commerical licenses, stop using new versions, or fork the project?

It's a dilemma, and it may be one you have faced or will face in the future. What would you do?

Comments

David Gilbert replied on Tue, 2008/04/22 - 8:12am

With all software, you bear the risk that the producer/vendor may change course and leave you stranded. Free / Open Source software at least affords you the option of continuing to maintain the original code base, if you need to. That may not always be practical, but it is at least possible. Get stuck with a proprietary product that's no longer being developed, and your list of options is short.

That said, if you are going to use Free / Open Source software for critical systems, you should look at how the projects are resourced and make an informed judgement about how long the project is likely to remain active. Decide what level of risk is acceptable, and don't blame anyone else if it doesn't turn out the way you hoped.

Rick Ross replied on Tue, 2008/04/22 - 8:29am in response to: David Gilbert

Your point about this issue applying to all software is absolutely correct, Dave. I do not mean to suggest otherwise.

It raises an underlying issue regarding an attitude of entitlement that many/most consumers have. If we have obtained something once at a certain price or under certain terms, then we often feel entitled to continue to do so. As the market repeatedly proves, this is not the case. Try to buy the once unthinkably expensive $70 barrel of oil in today's market! :)

James Sugrue replied on Tue, 2008/04/22 - 8:50am

It's a very interesting point. I think that the temptation is to just use the last version that fulfilled your own licence setup and stick with that, hoping for the best. 

Then, when it comes to the stage where you need something fixed in that library, it's time to look at alternative solutions, which is a good thing. Rather than becoming too dependent on any one library, it's good to continuously shop around for a better deal

James

Andrew McVeigh replied on Tue, 2008/04/22 - 9:40am in response to: David Gilbert

Free / Open Source software at least affords you the option of continuing to maintain the original code base,

I've had very good experiences with my own developments as far as open source s/w is concerned. Even when an open source project has been abandoned (e.g. the Jazz scene graph library) in favour of newer developments, access to the source has saved me time and again. I think this is part of the promise of open source -- free access, preventing information hoarding.

Having said that, your point about "critical systems" is valid. I am a lot more conservative with my commercial developments. Web frameworks in particular seem to cause me no end of problems.

Cheers,
Andrew

 

 

Jeroen Wenting replied on Wed, 2008/04/23 - 12:22am

We don't blindly upgrade to every "latest and greatest" version of OSS components we do use anyway. It's a futile and dangerous exercise at the technical level.
Best to stick with what you have and maybe modify it in-house as and when needed (you could even use that older version to create an OSS fork if you want to).

I've experienced the situation where an OSS project I worked on went commercial suddenly myself.
One morning I found myself locked out of CVS and the private parts of the project website. The next day the website was replaced and listed the licensing and pricing scheme. Project members didn't even get a free license for our troubles, we were just kicked out without any prior notice or even a thank you.

Nikita Ivanov replied on Wed, 2008/04/23 - 1:07am

Hm...

My take on this is that licensing is entirely up to the owner of the software. At GridGain, for example, we maintain 100% copyright right on all software we produce. Open source licensing (LGPL/Apache 2.0) is a pure business decision for us and pays out great for us:

  • our customers have absolutely zero barrier in trying and using us in commercial environment without almost any strings attached what-so-ever

  • in the same time we maintain extremely tight grip on development, design and architecture of the product plus legal copyright helping us provide legal indemnification, for example, where required

I think one of the problem many people still have is romanticism of open-source software.

Regards,
Nikita Ivanov.
GridGain – Grid Computing Made Simple

Steven Baker replied on Wed, 2008/04/23 - 1:53am

This has happened slightly differently for a company I used to work for.

It was originally developed using licences supported by keeping the product as a hosted service.

However, we are now in the transition of selling the product and have hit a problem with licencing on libraries.

 

I believe we are in the process of re-writing some of the libraries under our own code to keep it as it then belongs to us and we can do what we like with it, but others we're going to have to seek alternatives.

Also, I believe we also might need to simply sell the entire hosted service as a business to solve this problem.

Tricky messy stuff this all is, all because some developers didn't think about licences when we first started to seek 3rd party libraries. 

David Gilbert replied on Wed, 2008/04/23 - 2:29am in response to: Jeroen Wenting

[quote=jwenting]

I've experienced the situation where an OSS project I worked on went commercial suddenly myself.
One morning I found myself locked out of CVS and the private parts of the project website. The next day the website was replaced and listed the licensing and pricing scheme. Project members didn't even get a free license for our troubles, we were just kicked out without any prior notice or even a thank you.

[/quote]

I think for an OSS project to change its terms and not provide any advanced warning or notice, it plain sucks.  And frankly I wouldn't want to deal with those people on a commercial basis either.  But it never surprises me what people will do for money.

David Gilbert replied on Wed, 2008/04/23 - 2:50am in response to: Rick Ross

[quote=rick]

It raises an underlying issue regarding an attitude of entitlement that many/most consumers have. If we have obtained something once at a certain price or under certain terms, then we often feel entitled to continue to do so.

[/quote]

Agreed.  I think people do set their expectations too high for what they're entitled too from the producers of open source software, whether it be getting new releases under the exact same terms, or having bugs fixed, or getting free support.  If you're not paying for something, then I think you need to set your expectations low.  They'll often be exceeded, but not because you're entitled. 

That said, I think if an open source project is going to make a significant change in terms, then it's simple common(?) courtesy to provide a decent notice period of the change.  Sadly, there seem to be plenty of examples where this hasn't happened.

Andrew McVeigh replied on Wed, 2008/04/23 - 3:34am in response to: David Gilbert

I think for an OSS project to change its terms and not provide any advanced warning or notice, it plain sucks. And frankly I wouldn't want to deal with those people on a commercial basis either.

Things analogous to this happen in the commercial world too, and I have been stung by it a number of times. Case in point -- we started using toplink (an advanced ORM tool eventually bought by Oracle) because it touted that it charged based only on developer seats -- not on server-side licenses. They made a big point about the cost model being better etc. About a year after we were heavily using it, they changed the license terms to a server side model without any real warning. And as it is a proprietary API, we had not choice but to pay up.

To cut a long story short, vendor lock-in and the abuse of that power is a common feature of the commercial world too.

To look at the other side of the coin though, I suspect in many cases (e.g. the toplink one) that changing the license terms is often a matter of commercial survival, rather than a base need to extract the maximum amount of money from clients. If a commercial organisation isn't making enough money, then i'd (usually ;-) rather the licensing terms be changed (with consideration for existing users) than the company to go bankrupt. I guess in the open-source world, the creators would like (financial) consideration for their (often substantial) efforts. Unfortunately, moving from LGPL to GPL looks like a way to try to get your cake and eat it too -- a substantial user base because it's initially free, and then later monetisation of that base.

Cheers,
Andrew

 

Geoffrey De Smet replied on Mon, 2008/04/28 - 2:44am

Isn't the best way to protect yourself, ironically, to massively contribute and invest into the project?

If you create a patch and they apply it, you still own the copyright of your patch code, you just release it under their license(s).

If they decide to change the license, they have to ask you (as copyright holder) permission for the license change or dump your code. Unless they can pull it off to split of your code and keep that under the original license (which will be easier for them if the original license is ASL instead of LGPL).

I am not a lawyer though. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.