Surprising. I’ve read about cases going to court in Europe and naturally assumed, given the litigious environment of the US, that something had happened long ago stateside. So, I was a bit surprised to hear about the first GPL lawsuit down there.
For the first time in the U.S., a company and software vendor, Monsoon Multimedia, is being taken to court for a GPL violation. Previously, alleged GPL violations have all been settled by letters from the FSF (Free Software Foundation) or other open-source organizations, pointing out the violation. (Linux Watch)
Hmmm. Maybe not – recent news is that they’re now in settlement discussions. In any event, this gives me yet another excuse to rant, once again, about open source software, or for that matter, any third party code that companies out there may wish to use or build into their products.
As some of you may know, I personally quite like open source stuff. In fact, this blog is written using a giant truckload of the stuff, which works remarkably well for something developed by folks who aren’t paid (for the most part) to develop any of it. Open source can also be a great asset to many companies out there, whether in use or in development.
BUT (and surely you must be expecting a but by now), to the extent you are going to develop with open source code, public domain code or for that matter ANY third party code, you absolutely, positively, MUST keep track of it and make sure you use it both in compliance with the terms under which it is licensed and: (a) make sure the license terms are appropriate for the intended purpose; and (b) make sure you comply with the license terms.
Why is (a) important? To give a very simply illustration, if you plan on building a company whose primary asset and value is based on closed and (ostensibly) proprietary code, you should not be putting GPL code into your product, since one of the requirements of doing so would be an obligation to make your code publicly available on the same terms. This is probably a vast oversimplification of the terms of the GPL but I hope it illustrates the point. And if you don’t think this is likely to have an impact on your company, well, think again. Regardless of what you may think about (b) (which we’ll be getting to in a second), a potential acquiror of your company may feel quite differently about the risks of unintended use of open source code if, for example, it has been told your product is proprietary. And they definitely will find out about it. In fact, there are very, very effective tools to do so, like the one provided by Black Duck. And it is becoming a rather normal practice in acquisition due diligence to run code through Black Duck or something similar if there is the possibility of undisclosed open source.
Why is (b) important? Well, in addition to what’s described above, there is a real risk associated with contravening the GPL, the LPGL or other open source licenses. Just because its free does not mean that someone will not invest the time and effort to find out about contraventions of such licenses and make sure their terms are complied with, including the Software Freedom Law Center. In addition to institutions like those, there are also many, many folks out there keeping an eye out for possible breaches of GPL and reporting them to bodies like the SFLC.
All that being said, I should make it clear that I do think that open source software does have a place in profit-driven companies, as do open source development models. JBoss, MySQL, and Sleepycat are just a few in the latter category that have been quite successful. The key of course, is to make sure that how you use those tools works consistently both with your intended business model and with the terms under which apply to their use. Which will be a good topic for another day.
