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.
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.
[Next: Unraveling code repository messes and Publishing Source]»
As someone who has worked with Asian consumer electronics companies before in a consulting capacity, I can tell you that the first major obstacle in dealing with any American product launch, particularly if you are operating as a subsidiary in the United States and are re-marketing products for the North American market, is the issue of communication between the subsidiaries.
The issue is even more complicated if you are acting as just a simple rebrander/reseller and are involved in some presales engineering to make the product more palatable for the American market.
If you are an employee of the American subsidiary, only speak English and are based in the US and have to go through someone who is an interpreter, and then have to talk to overseas software developers who do not speak English, you've got a whole mess of problems right there.
Never mind the fact you don't speak the same language, you're not even close to operating in the same time zone. You're lucky to get a 24 hour turnaround on an email and the times which you can conference call are extremely limited.
Then there is the issue of how Free and Open Source Software is maintained at said Asian companies. I'm not going to name names here, but in many instances where these companies try to comply and retrieve the source they used, they can't because they don't have a version control system or a build system that allows them to cleanly track what exactly was the origin of the upstream code they used.
For companies like this, It's not just a simple matter of "We used BusyBox from BusyBox.net, here's the version we used and the changes, download it off our web site". Sure, some companies, like SONY, actually have their act together. But a lot of them do not, and that's where they get into trouble.
Maybe they used some obscure "bundle of stuff" they downloaded from somewhere and it's been Frankenstein-ed over time into something unrecognizable using some custom-made build system rather than something that came out of a standardized toolset (Such as Google Android's SDK, or Wind River/MontaVista or other commercial Linux development stack that ensures code integrity) or some ancient SDK or "bundle of Open Source stuff" that they purchased/copied from someone else.
Maybe the guy who originally maintained the code in China/Korea/Japan for the product left the company and now the developers in that far away land are stuck maintaining a jumbled, undocumented mess of junk which has hooks to proprietary and non proprietary stuff that they can't untangle.
And then the SFLC or the originating developer of said GPLv2'ed software component contacts the American subsidiary, who then has to contact his counterpart in China/Korea/Japan, who has to contact their upstream SDK vendor, et cetera to try -- and then fail to sort the whole thing out. It's a mess.
Clearly, if you are a US-based company or subsidiary that sells products that come from Asia -- or anywhere for that matter that uses GPL components, you want the products to use standardized SDKs with version control and build systems that allows you to easily reproduce what you put on the device target.
And if you are someone that resells these products under your brand name, such as a Best Buy, you probably want an indemnification clause in the contract with whoever is building the said device for you so you can cover your rear end if the SFLC comes knocking on your door.
Coming up with the code shouldn't be difficult. Consumer Electronics companies already understand standards compliance and certifications -- they have to do this for each product in order to get the CE designation for Europe and UL listings and the FCC in United States, among other things that are required before it is allowed to be sold.
I don't know if we need an Underwriter's Laboratories or a CCL for Open Source. Maybe that sort-of already exists in the form of companies like Black Duck. However, it's clear that as Linux has becomes more prevalent on devices, the issue of "where did the code come from" is not going to go away.
Do we need a "Standardized bundle of Code", or a free Linux embedded SDK standard with a build system created by some Pan-Asian or global consortium for Consumer Electronics? And do we need to create and apply ITIL-like practices for GPL and Open Source code maintenance on Consumer Electronics devices?
Do we need code maintenance standards as well as code licensing compliance certification for Linux-based Consumer Electronics in order to avoid further GPL lawsuits? Talk Back and Let Me Know.