Open Source Licensing

I recently wrote [[Git Gotchas for the Savvy Svn'r]] where I mentioned in passing that some companies like monolithic software repos because it aids in Black Duck auditing.  I then received a couple of emails asking what this was and why it was important.  I also recently had a consulting engagement where the improper use of open source software had the potential to cost them a large portion of their revenue.  At around the same time Heartbleed (the OpenSSL bug) came into the light and suddenly there was a "open source vs closed source" debate.  All of this is important and you should understand it if you want to be a good architect.  

I don't want to get into a religious debate about open vs closed source.  Pick whatever works for you.  Rather, the underlying licensing of any software you are using in your projects is critical.  I consult for various ISVs and all of them srutinize third-party licensing of closed source software if they are going to redistribute any portion of it under their umbrella.  I've mentioned in the past ([[How to save a *lot* of money with SQL Server Express]]) how a lawyer for an ISV I worked for really scrutinized how I was using SQL Express.  Eventually all parties (including M$) were satisfied that I was breaking no licensing terms, but my point is that when it comes to redistributing closed source software we, as an industry, tend to scrutinize everything.  

That is good.  But we don't tend to scrutinize open source software that we use.  And we should.  

Black Duck audits essentially look at your software portfolio for areas where your OSS (open source software) is out-of-compliance with the underlying licensing.  If you use OSS, you should be familiar with Black Duck, or something similar.  If you think Open Source = Free Software...you have a BIG problem.  There are tons of free and open source software licensing.  Frankly, I don't understand them all, and I'm not a lawyer so I won't attempt to explain the nuances you'll find in these.  But there are two basic types...these are my words..."free free" (example Apache licensing) and "copyleft" ("free, if your careful"...example is GPL).  

(screenshot of wikipedia's entry for comparison of free and open source licenses.  Note that this is just the licenses at the beginning of the alphabet.)

My Personal Feelings

I have personal reservations about Intellectual Property (IP) rights.  But even though I don't like IP, I have to respect it in my daily dealings.  Open source licensing, in general, disgusts me because if you are a bit lax, even accidentally, your OSS vendor can swoop in and claim large portions of your profits as its own, legally.  In many regards these licenses are far more punitive and Draconian than anything I've ever seen from a closed-source vendor like M$ or Oracle.  Why is this?

OSS vendors have to Make Money.  Choice-of-license is how they do it

Some people believe that OSS vendors chose the open source model because of some kind of altruism.  "We provide our software for free to make the world a better place."  Bullshit!  Every company has to make money.  How a vendor chooses to license their product is how they make it.  There are open source licenses that foster "building a community" prior to building sustaining revenue (example, Apache licensing) and there are licenses meant to generate revenue first, often sneakily (example, GPL).  

Let's take two examples.  Company A develops some software and decides the best way it can make money with it is to build a community of avid users of the software.  "Build it and they will come", if you will.  The Apache License best meets that goal.  As a business-owner and independent consultant for ISVs I look first for software with Apache licensing (or BSD, MIT, or similar).  These licenses are business-friendly.  I'm not an attorney and I bear no responsibility for any misinformation given in this post, but essentially an Apache License gives the licensee full control to do with the software anything it wants to do with it, as long as the copyright notice is preserved.  It's about as close to free as it gets.  No royalties necessary.  In this case Company A believes the Apache License affords it the best method of gaining market momentum.  So, how does Company A make money if its software is "free"?  There are many ways, but in-app advertising and paid services (support) are the two most common.  This example is straightforward and is what most people think of with OSS.  You really have to do something stupid to get in trouble using this variety of OSS.  

GPL, "Copyleft", and Derivatives

Company B would rather sustain its business with licensing revenue (just like Oracle or M$) but it still wants to call itself OSS.  Just my opinion, but this is sneaky and bordering on dishonest.  Here's how it works.  Company B chooses a "copyleft" licensing scheme like GPL or AGPL.  Again, I'm not a lawyer but copyleft works by saying the license is just like an Apache license except that derived works must also be released as open-sourced, copyleft works.  Said differently, the license must be moved forward.  

Huh?  Company C is an ISV that would like to use some open source software to augment its closed source software.  If Company C uses an Apache-licensed piece of software then they may continue to keep their software closed-sourced without paying royalties.  But if they decide to use a GPL license then Company C *must* open source its software or it will be in violation of the GPL.  That means the GPL "moves forward".  

So, how does Company C use GPL'd software in its closed-source product?  Carefully.  All "copyleft" ISVs like Company B will offer both a GPL version of its product and then another version with a non-open-source license that the licensee can then use in its closed-source product without having to open source everything or violate the GPL. The GPL'd version is still "free", the alternatively-licensed version can have whatever royalties and terms that it desires, just like a closed source product.  By "version" I don't mean a separate set of binaries (like Windows Standard vs Enterprise), rather a different "version" of the license. 

A True Horror Story

An ISV I worked for loved using OSS whenever it could.  The OSS always used Apache licensing (or equivalent) whenever we redistributed our code.  If it was software used in-house for administration or development only then nobody really cared about the licensing covenants.  There was a secret push to begin using a NoSQL alternative to SQL Server for some aspects of data persistence for a skunkworks project.  Cost was the reason.  SQL Server was deemed too expensive.  I was not involved in the evaluation or recommendation of the OSS product but a company-that-shall-remain-nameless gave a demo of their "free" distributed document store software to the skunkworks team.  I was not invited.  The product worked well and our developers coded a bunch of stuff against it that was not yet released.  

Soon the secret was out that there was a group developing against a new data persistence engine.  This is when I found out.  I knew this OSS package was GPL and its use could radically alter our business model.  The vendor would not give me a straight answer as to exactly how much of our product would need to be open-sourced if we took on their product.  At this point I could've gotten our legal department involved but that tends to be slow.  Much better to have the vendor speak to our management team directly.  

I organized another presentation with the NoSQL vendor and they started out touting the free, open source nature of their product, case studies of its success, etc.  This time the audience was the senior architects and the management team.  About 10 minutes into it I raised my hand and asked very pointedly, "How much will your product cost us in licensing if we choose NOT to open source our product under the terms of the GPL?"  The vendor attempted to deflect but I kept pushing.  Eventually the vendor opened a different Prezi that discussed alternative closed source licensing arrangements.  Clearly they had different presentations based on where the customer was in its implementation of their product.  The vendor did not realize that I did my homework and knew this was going to happen.  Neither did our management.  Or our architects.  "Deer in the headlights" does not do justice to the looks on everyone's faces.  

The alternative licensing was MORE EXPENSIVE per node than SQL Server, not to mention it was a distributed document store which would have meant LOTS of small, little licenses for small, little nodes.  It was eye-opening for management.  There would be no cost savings.  We quickly had our developers pick a document store that was Apache licensed and we delayed our release for a few months until we could rewrite.  

From then on there were policies on which OSS licenses we could use and rules regarding what could be redistributed.  Our Legal Department was now required to sign off on ANY third party tool where the code was checked in and integrated with our source code.  This event scared management so much that they brought in Black Duck Software to make sure our exisitng software portfolio wasn't hiding any other potential OSS timebombs.  (It was).  

Since then customers of our software have also performed the equivalent of Black Duck audits on our software to make sure we were being thorough and honest.  This is mission-critical software.  With GPL software it isn't just the licensee that can get caught up in a licensing battle, it is the "licensee or assigns", which means anyone who purchases our software.  The ramifications of this is really scary.  You could purchase a piece of software and through no fault of your own find yourself on the receiving end of a lawsuit because your vendor was improperly using GPL'd software.  This is another reason why IP rights are so dangerous.  

Choosing Licensing Carefully...Example: Postgresql vs MySQL

When I work with OSS in my personal life I pay ZERO attention to the licensing.  I use what is best for the task at hand.  In my professional life, working for ISVs, I'm much more careful.  Take Postgresql vs MySQL.  If you ask 10 experts you'll likely find that 50% prefer Postgres and 50% prefer MySQL.  No big difference regarding performance or feature-completeness.  They are both very awesome DBMSs.  Usually the choice comes down to comfort and prior experience or specific feature requirements.  That's totally anecdotal of course.  YMMV.  

However, if I needed to propose which one to use for an ISV project I'm ALWAYS proposing Postgres.  Every time.  Why?  Licensing.  Postgres is MIT licensed (similar to BSD and Apache...basically just don't alter the copyright notice and you are free to do whatever you want with it).  MySQL is GPLd and Oracle (who owns MySQL) does have some goofy rules about when a commercial license is required for redistribution.  I'm hesitant to risk another GPL nightmare and choose MySQL unless there was some compelling feature requirement.  

This is just my opinion but I believe that over time Postgres will have a higher installed base than MySQL, merely due to licensing differences.  Most OSS that needs data persistence will offer a choice in backends...usually MySQL, Postgres, or SQLite.  In these cases I choose Postgres because I believe the licensing will eventually cause it to pull away from MySQL and be the preferred data persistence engine.  SQLite is totally public domain (no license AT ALL) so it may even fare better.  

Apache licensing is always preferred to GPL-style licensing?

Not so fast.  If you aren't redistributing or selling your software then it probably doesn't matter what you use.  Check with an expert or a lawyer though.  

Apache licensing has problems too, IMHO, that you should be aware of.  The business model for Apache licensed software brings its sustainability into question, always.  An example is OpenSSL.  It is Apache licensed and is supported by the equivalent of a handful of full-time developers.  It has almost ZERO revenue to sustain the software.  Something like Heartbleed was bound to happen under this situation.  OpenSSL has a large, avid following.  Cisco and M$ use it...heck, it's embedded in EVERYTHING.  And very few users have given ANY money to the project to sustain it because it is Apache licensed (IMHO) and therefore viewed as totally free (without cost).  "Let someone else pay for it".  The very backbone of security on the internet is in the hands of a few OpenSSL developers because no one wants to contribute money.  It is an 800 lb gorilla.  In this case maybe GPL software is a bit better.  If the price isn't too steep.  And since Heartbleed there are some new GPL'd alternatives to OpenSSL that may be safer and more sustainable simply because the revenue-generation model is better.  Only time will tell of course.  Others have pointed out that something as critical as OpenSSL should be closed source anyway.  Again, time will tell.  Perhaps the best answer is a consortium of vendors that can take over OpenSSL and give it the care and feeding it needs, without resorting to GPL.  I'm certainly no expert in any of this.  But it is fascinating.  

Why is this so gd complicated?  Another story

Now you see why I think IP rights cause more grief than they solve and why EVERYTHING I do on this website is public domain with ZERO licensing, not even Apache licensing.  (I always appreciate an attribution, but I'm not going to sue you if you don't).  It's just not worth it to me to deal with all of this licensing.  I don't even have a copyright notice on this site, although I probably should.  

I do some side work as a Drupal consultant.  Drupal is GPL.  Yet there is a lot of Drupal code out there that is available only for a fee.  Especially themes.  People often wonder how that arrangement is possible.  If GPL forces derivational products to also be GPL'd, then how can a themer charge for a Drupal theme?  Very easily.  The themer must provide the source code for any theme and therefore the customer can do anything with it thereafter, including give it away for free.  

Sounds goofy doesn't it?  

I once bought a theme for $50 because it had everything my customer wanted...cool graphics, the ability to skin minutae, it was "responsive" (the ability to resize dynamically to the new form-factor devices coming to market daily), and had lots of other features not available elsewhere.  After I got the code for the theme I realized I was sold a lemon.  The theme did nothing advertised and had ZERO documentation.  I politely asked for my money back and was denied by the vendor, who spoke little English.  I then threatened to simply follow the terms of the GPL license and modify a few bits and re-release the new theme as my own and give it away for free.  

I had his attention now.  He told that was not legal that his theme was his, not mine.  "Nope, sorry, you supplied me with a Drupal theme.  Drupal is GPL therefore your theme is GPL too.  I can modify it however I choose and re-release it to the world.  I can't wait to give your hard work away under my name."  Needless to say my $50 was promptly refunded.  

Summary

There is no right or wrong answer to any of this.  The takeaway is that open source software is not cost-free software, usually.  And these vendors aren't always altruistic just because they are OSS.  You must spend some time and understand what you are getting yourself into when you decide to use OSS.  In most cases you will be fine.  If you are an ISV, be a bit more careful.  If you are an ISV that produces OSS then I implore you to be a little more open and honest about how your licensing really works.  Be forthright that you have multi-licenses for different use cases and note the pricing clearly.  Not every small ISV has a cadre of lawyers that understand open source licensing, it would be nice if GPL and GPL-like product vendors would stop trying to hide behind the "free software" label.  It's akin to bait-and-switch.  

You have just read "[[Open Source Licensing]]" on davewentzel.com. If you found this useful please feel free to subscribe to the RSS feed.