If you wanted to be a real devil, I suppose you could:
1) Import all of your source code into a word processor
2) Change the font to Wingdings, and set the font size to 3
3) print out the resulting pages
4) scan the printed pages in as jpegs
5) post the jpegs on your website in a photo gallery
... then say voila, I published my source code!
Public floggings and executions like the recent SFLC lawsuit could be avoided if actual standards and procedures for compliance with the GPL and other Free and Open Source licenses actually existed.
This week, the Software Freedom Law Center, an organization related to the Free Software Foundation and affiliated with Free Software advocate and attorney Eben Moglen, filed a lawsuit against 14 companies on behalf of Erik Anderson, the author of BusyBox, a popular GPLv2-licensed command interpreter used in the development of embedded Linux devices.
Why are these firms being sued? In short, they violated the terms of the GPLv2 license, which states implicitly that if you use GPLv2 software in any product, be it software or hardware, then you have to publish the source, as well as any modifications to that source, which is where the “Copyleft” angle of Free Software comes into play.
Sounds simple, really. Publish the source — which is basically just a copy of the source you downloaded from whatever project that used it — along with the changes.
There’s a problem with this, though. While GPLv2 and GPLv3 effectively says “Publish the source”, it doesn’t explicitly tell you HOW. It does say you can charge a fee for transferring the published code to whoever requests it, but as to the mechanics of how source is published, that’s not said. The GPLv2, under which BusyBox is licensed, was drafted in 1991.
In 1991, the Internet really wasn’t much to talk about. Yeah, there was CompuServe and other places where this stuff could be distributed, but back then, nobody was really building consumer electronics devices with Linux and other GPLv2 components into it.
Linux-based consumer electronics devices, for the most part, have only been in common use in the last 10 years, and have exploded in the last 3 to 5. For what its worth, even the GPLv3, published in 2007, doesn’t explicitly say what mechanisms can and should be used for compliance. It just says “comply”, period.
Suffice to say that the FSF itself doesn’t provide an awful lot of assistance when it comes to helping companies comply with software licensed under the GPL and other Free and Open Source licenses. Instead, there is a cottage industry of lawyers as well as companies like Black Duck that provide licensing consulting.
The SFLC itself will also assist companies in becoming compliant, although usually it happens as a result of an enforcement issue that is privately settled before it ever comes to litigation. If you want to stay away from litigation as a CE device manufacturer that uses GPLed components, I encourage you to read the SFLC’s guide to GPL Compliance.
Right now, it’s in English only. If you have Korean, Chinese and Japanese translation skills, and/or are a legal professional which can deal in those languages, the SFLC would really like your help.
The fourteen companies that which the SFLC is suing apparently not only did not publish the source and modifications to BusyBox as required by GPLv2, but they did not comply after repeated attempts by the SFLC through standard communication channels to get them to publish the said Busybox source they used and any modifications they may have made to it.
Now, since no discovery process has gone underway and the lawsuit hasn’t made it yet into an actual courtroom, it has not yet been made public exactly how many times the SFLC had to bug these companies. I’m assuming it had to be a lot more than two or three times, over a period of several months or more before resorting to a lawsuit. As stated in the public announcement of the litigation,
“The SFLC confirmed BusyBox violations in nearly 20 separate products cited in the complaint and gave each defendant ample time to comply with the requirements of the license. “We try very hard to resolve these types of issues privately with companies, as we always prefer cooperation” said SFLC counsel Aaron Williamson. “We brought this suit as a last resort after each of these defendants ignored us or failed to meaningfully respond to our requests that they release the source code”.
I think what we have here is a classic case of large companies having little or no clue of how to deal with Free Software and Open Source licensed software or what they actually need to do to comply. Consumer Electronics companies aren’t usually accustomed to thinking about complex stacks with many individually licensed components and having to comply with those licenses separately.
Traditionally, if a Consumer Electronics device used an embedded OS as opposed to running on home-grown machine language firmware, it was a commercial embedded OS (such as VXWorks, or QNX, or Kadak) that was licensed in whole, so there was no need to deal with all this FOSS compliance stuff. If there were other licensed products that were used in a CE device’s stack, the company paid for them, through a business negotiation.
Let’s have a better look at some of the companies in question. Quite a few of these are American subsidiaries of Asian companies that are producing the devices in question.
Samsung, JVC, Humax and Astak (which is primarily a US importer and reseller/rebrander of Chinese goods) are the standouts, but I’ll bet that the other “American” parties in question, such as Best Buy, which is infringing due to its use of BusyBox in its signature line Blu-Ray DVD player are simply reselling goods made and developed in Asia.
Duhhhhhhhh, right?
[Next: Unraveling code repository messes and Publishing Source]»
