How to avoid modern day public GPL floggings

How to avoid modern day public GPL floggings

Summary: 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.

SHARE:

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]»

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.

Topics: Linux, Hardware, Legal, Mobility, Open Source, Operating Systems, Software, Windows

About

Jason Perlow, Sr. Technology Editor at ZDNet, is a technologist with over two decades of experience integrating large heterogeneous multi-vendor computing environments in Fortune 500 companies. Jason is currently a Partner Technology Strategist with Microsoft Corp. His expressed views do not necessarily represent those of his employer.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

57 comments
Log in or register to join the discussion
  • How to publish your GPL code &^)

    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!
    FantaStyx
    • This is a problem with the GPL

      I hear users all the time here on ZDNet and elsewhere bashing Microsoft and the Mono project. They are generally dismissing the Mono project because they say that the use of C# and an OSS implementation of the .NET framework opens up Linux and it's developer community to potential legal action from Microsoft. Although I believe these concerns are unfounded, I can see where they are coming from. What I can't understand is why these same people don't mind that companies are being sued over the GPL because of some alleged violations.

      To be quite honest with you, the license to be afraid of is the GPL. I actually considered toying with some development projects relating to GPL code, but after investigating, I decided the restrictions imposed are far too great to be worth my time. You also always hear the MS bashers talk about Microsoft wanting control of everything. Isn't control the same thing the GPL license imposes on those who decide to work with GPL'd code?

      Why not use the BSD license model? Are you afraid that someday somewhere somebody will make money off code you originally had written? This just doesn't make any sense to me.

      Any company that doesn't want to expose themselves to potential legal action should stay far away from the GPL license and any software distributed under it. It's just too dangerous to take a chance on a long legal fight when there are much better alternatives available.
      Tiggster
      • BSD embedded

        The problem is, if you're using Linux as the embedded OS, you've still got the Linux kernel at bare minimum. To host an embedded Linux environment you need kernel, plus uclibc and a few other things, which are also GPL. If you really want to ditch GPL you need to be using a BSD-based embedded OS, which isnt as palatable from a driver support standpoint. If developers are really worried about Linux and GPL they need to bring embedded BSD and its corresponding toolsets up to Linux levels of embedded compatibility.

        Frankly, the ideal company to make this toolset available is Apple and the iPhone OS for licensing, since it's already reached that level of maturity and is based on Darwin which is BSD-derived. But like the Mac OS and Intel and PCs, they will NEVER do this.

        Interestingly Google seems to have taken a fairly GPL-averse path since they only use a limited amount of GPL material in Android. The Linux kernel in Android is GPL, but Dalvik and its supporting libraries are Apache. So it would seem that Android might be a good choice for embedded device development, as long as the OS can do what you need it to do.

        http://arstechnica.com/old/content/2007/11/why-google-chose-the-apache-software-license-over-gplv2.ars
        jperlow
      • When to GPL

        Simply put, the OS should be GPL while applications could be either GPL or BSD-style. No one wants custom OS function (i.e. closed source like Windoze), but a developer should have the flexibility to use whatever license they need.
        Roger Ramjet
      • Troll much?

        Much better alternatives like WRITING YOUR OWN CODE!

        What you're saying is 'I am lazy/cannot/don't-know-how to code would like to take someone else's hardwork and use it instead without any kind of compensation'.

        What do you mean by 'toying with some development project related to gpl'? Let's see you toy with some commercial code then. Or you can always trawl through the public domain for code and do as you please with it.

        What nonsense!
        spinit
        • You hit his nail smack on the head

          THAT'S what the code rustlers don't like about the GPL. It frowns on stealing GPL code and publishing (selling) it as their (the rustler's) own.

          There is no credible excuse for such chicanery.
          Ole Man
        • Know what you are talking about much?

          A lot of times the GLPed code in question are class libraries. They make short work of dealing with very complex problems. A well written class library can cut your coding from hundreds or even thousands of lines to just a few function calls. They are just a means to do things like abstract a database or dealing with encryption algorithms, or file systems or zip files or a host of other tasks. As the the saying goes, why reinvent the wheel?

          In the developers world these are just tools, much like hammers and saws to a carpenter. They are as common as dirt and freely available. So if a developer unwittingly or unknowingly uses a GPLed class library in commercial code all of their companies IP suddenly becomes free for the asking.

          That is the WHOLE point of the article.

          But you knew that... didn't you?
          Slunk
          • Please

            Every programmer knows that glib*, gnutools and busy box are GPL. Another program often violated by embedded devices and for purchase software video players/converters is mplayer. Not libraries the entire program.

            It's not ignorance, they use open source because it's good and free. Less work more profit. It's classic "take until it costs you business practice". That's why the have to file lawsuits to get compliance. No standard distribution method will change it but it couldn't hurt especially in court.
            shaunehunter
          • And?

            [i]"So if a developer unwittingly or unknowingly uses a GPLed class library in commercial code all of their companies IP suddenly becomes free for the asking."[/i]

            If GPL code has been introduced into their closed source program then they have an obligation to remove that code or cease distribution of the program. It only becomes "free for the asking" if they make a distribution and [b]comply[/b] with the terms of the GPL. If they make a distribution and refuse to release the source code then it's a copyright violation.

            In any case it was the employee, or the auditor in most cases, who was not diligent enough to check the licensing of the libraries. It would be the same as if a class library with a different license was used and the terms of that license were violated.
            MisterMiester
          • In the developers world? WHAT???

            Are you saying that a "DEVELOPER" (or yourself) would "use" or link to something that he/she/you don't even know what is or where it came from?

            Gitouttahere! That's "the WHOLE point of the article.
            Ole Man
          • Yes.

            Get a fucking life.
            Duke E. Love
          • How long have you been posting here?

            A year? two? Are you paid for it? Or do you just come here to be an asshole and talk smack? Have fun pounding sand, maybe one day it will turn in to glass and you can play marbles with it. With all the effort you put into pounding that sand into glass you could have built a house or started a company or taught a child to fish or play baseball or anything but be a prick troll on zdnet...
            Duke E. Love
          • Much longer than you

            But I still haven?t attained your level of vulgar, uncouth, rude, crass, and witless personal insults, and couldn?t hold a candle to your blundering insensitive lowbrow evacuation of bovine excrement.

            Perhaps with a little practice I can pick it up ALMOST as fast as you, eh? Hope Springs Eternal
            http://www.livescience.com/health/071024-brain-optimism.html
            Hope springs eternal and we sing that the sun will come out tomorrow despite the lack of hard evidence to support upbeat forecasts.
            Now some scientists know why. They've identified the brain clusters responsible for optimism.
            Optimism is a common human trait. For instance, people tend to expect to live longer and be more successful than average, and underestimate their chances of getting divorced.
            Ole Man
    • Not gonna fly

      This obviously wouldn't fly, because scanned pages of source in a photo gallery are not a "medium customarily used for software interchange."
      mattflaschen
  • RE: How to avoid modern day public GPL floggings

    A better and easier solution is to not use GPL code at all. The trend is becoming that if you use GPL code you will get sued. There are so many better licenses out there for open source code that the GPL itself is obsolete. GPL doesn't do anything for the end user but get them in trouble, and all this talk about GPL and freedom is a bunch of crap. The GPL actually restricts your freedom by forcing you to release code. Most companies do not want to do that and find that their code is proprietary. Bottom line, get the GPL out of your life.
    Loverock Davidson
    • Even better is don't use code that hasn't been developed in-house.

      That way you just never have to worry about any licenses at all.
      Letophoro
      • That is the best solution

        And while I agree with it most of the time, its not always practical.
        Loverock Davidson
        • Then you have to put up with the license.

          If you don't write it yourself, then you must accept whatever license you acquire the code under.
          Letophoro
    • Hey Donovan...

      Read <a href="http://talkback.zdnet.com/5208-17924-0.html?forumID=1&threadID=72900&messageID=1411823">this</a>.
      The Mentalist
    • I'll give you a free computer

      if you sign a document that says you will be the only user. After you sign, you flip me off and have all your friends start using it. I tell you to stop and you blow me off. I then am forced to sue you. NOW you gripe about "freedom".

      I hope you catch the analogy.
      Roger Ramjet