The GPL Compliance Engineering Guide

[Posted December 18, 2009 by ris]

Armijn Hemel has released version 3.0 of the The GPL Compliance Engineering Guide (PDF). "Compliance engineering and checking for licensing issues tends to endanger profit. First of all, it delays the release. Proper compliance engineering could take a few days (depending on the device), any questions regarding sources have to go back to the factory, sources have to be shipped, and so on. Often the factory won't or can't release all sources (because they bought it too) and it could take many months before the device is compliant. Arriving a few months later than the competition will mean you lost the race. Companies often also don't get more than one or two test samples, which they cannot afford to lend out to a compliance engineer when they need to test functionality."

to post comments

The GPL Compliance Engineering Guide

Posted Dec 18, 2009 21:21 UTC (Fri) by alvieboy (guest, #51617) [Link] (9 responses)

This document is not a compliance guide at all, it's a resumé of what you might be able to do to find information about what ships on a blob, and does not tell you actually anything if they are indeed infringing licensing rules.

Disappointed.

Álvaro

Mislabelled

Posted Dec 18, 2009 21:36 UTC (Fri) by dwheeler (guest, #1216) [Link] (7 responses)

It's not a bad document for what it is, it's just it's mislabelled. It's more a "guide to how to find out what's running on an embedded box". If you're doing compliance engineering of someone ELSE's box, this isn't a bad first step, but then you have to actually do the compliance-checking (which this document doesn't really go in to).

And regarding the front matter's description of the embedded marketplace: yes, there are short deadlines and margins. But it is still illegal to take someone's code and redistribute copies without permission. It shouldn't be costing that much to check compliance, in time or money... the problem is that we have a whole industry that thinks it's okay to operate illegally. Perhaps some more companies need to have their entire shipments confiscated at the border; then they'll start paying attention.

Mislabelled

Posted Dec 19, 2009 7:09 UTC (Sat) by jmm82 (guest, #59425) [Link] (2 responses)

"The GPL Non-Compliance Engineering Guide"

This document is only useful for resellers and not actual vendors creating
an open source product, except if the vendors are looking for how to cover
their tracks. A section on proper methods of distribution of necessary
source would be nice to add some positive to the document. Also, it would
show what to expect to accompany a complying device.

This similar article was published on LWN recently.

Mislabelled

Posted Dec 20, 2009 0:43 UTC (Sun) by bfields (subscriber, #19510) [Link] (1 responses)

except if the vendors are looking for how to cover their tracks.

Or trying to monitor themselves?

I've got no experience with this kind of situation, but it's easy to imagine that in a company with a history of problems, even if there's some will to reform, it may take some effort to educate everyone responsible, and it may be worth assigning someone to do a little periodic auditing of the company's own products....

Mislabelled

Posted Dec 20, 2009 1:02 UTC (Sun) by jmm82 (guest, #59425) [Link]

If the company(vendor) is actually making the product themselves I would
hope they are able to determine without hacking into their own system.

I agree more vendors will slowly comply, but this article does not discuss
at any point how to comply. It shows how resellers can catch their vendor.
I am not saying that that is not a piece of the puzzle, but it is not how
to comply.

Mislabelled

Posted Dec 19, 2009 12:04 UTC (Sat) by armijn (subscriber, #3653) [Link] (2 responses)

Regarding costs and money: the checking itself indeed does not cost that much time or money. Fixing the problems does. There are huge cultural barriers and many companies involved in making a product (not just one factory in China or Taiwan). Getting a product in compliance may take weeks. In those same weeks a competitor, who ignores all this, will have taken the market.

It is no excuse, but it is the reality: getting caught and fined for violations is cheaper than selling no devices at all. This is not the fault of the companies per se: it is the fault of the whole consumer electronics industry.

Mislabelled

Posted Dec 19, 2009 13:05 UTC (Sat) by sebas (guest, #51660) [Link] (1 responses)

If you compare the costs of being compliant to the costs of just stealing
code and completely ignoring the intellectual property of it, it's indeed
expensive.

If you compare the costs of being compliant to the costs of writing the
software yourself, being compliant is probably a lot cheaper.

This is also interesting in the light of the recent commentary from Bruce
Perens about BusyBox. Raising the costs of not being compliant with
licenses (even if you can easily get at the code) makes it relatively
cheaper to be compliant.

Mislabelled

Posted Dec 19, 2009 21:44 UTC (Sat) by Wol (subscriber, #4433) [Link]

It also only takes ONE company to get stung for compliance, for them to start actively monitoring their competitors.

If you have to prove compliance (or face contempt of court proceedings), you're going to wnat to make damn sure your competitors have to do the same ... :-)

Cisco's been clobbered - what's the betting that part of the deal includes free access by busybox copyright holders to Cisco's lawyers to clobber other violators? That would be well within Cisco's interests, I would have thought.

Cheers,
Wol

Mislabelled

Posted Dec 20, 2009 19:39 UTC (Sun) by laf0rge (subscriber, #6469) [Link]

It is doing gpl compliance engineering on some blackbox, independent of who made it. It is not simply only about somebody ELSE's box.

The nature of the consumer electronics business with its indefinitely deep supply chain makes sure that this is the normal case. So let's say you are a branad company like HP or Dell, or even Linksys or Asus. You want to buy some ODM product and sell it under your brand.

The supplier from whom you are buying this product is likely to claim that he respects copyright and that there are no license problems with this product. Sometimes he even claims that there is no Linux inside. In way too many cases, that supplier has not even the slightest clue himself, so he might not even be trying to decieve you. Also, consider the chip maker shipping some software (a BSP) which is GPL-incompliant, but already claiming to your supplier that it is GPL compliant.

How do you verify what's actually happening? By procedures described in the compliance engineering guide.

The GPL Compliance Engineering Guide

Posted Dec 19, 2009 11:54 UTC (Sat) by armijn (subscriber, #3653) [Link]

Well, there is a reason for that. If a company is actually infringing licensing rules depends on quite some things like what license a piece of software has, what other software it is linked to, and so on. Actual legal license interpretation is something that I leave to legal professionals.

This guide is intended for compliance engineers who get either a device, or a blob of software and have to find out what is in there.

If you are disappointed then I can understand that, because for most people who have been doing embedded Linux development this is no different from what they would do to debug a firmware. For the rest of the world, and particularly companies who are into consumer electronics, this is all very dark voodoo. But these companies are the ones that get sued and who need to be able to verify claims from their vendors and from end users regarding if something is in a firmware or not.

The GPL Compliance Engineering Guide

Posted Dec 19, 2009 10:10 UTC (Sat) by bronson (subscriber, #4806) [Link] (4 responses)

First step to GPL Compliance at more than one company I know of (including one very large and well known one): avoid GPLv3 like it's the plague. It's not a good idea to hook your product to something so complex and poorly understood.

Alas.

The GPL Compliance Engineering Guide

Posted Dec 19, 2009 10:36 UTC (Sat) by quotemstr (subscriber, #45331) [Link]

It took ages for corporate cultures to come to accept the GPLv2; I imagine the GPLv3 will also be accepted once the beancounters realize it's not a boogeyman.

The GPL Compliance Engineering Guide

Posted Dec 19, 2009 14:16 UTC (Sat) by adulau (guest, #1131) [Link] (2 responses)

> "to hook your product to something so complex and poorly understood."

Just like all the complex proprietary licenses that nobody understood. I personally think that a free license like GNU General Public License is much more analysed than any of the custom, complex and obscure proprietary license made in standalone mode by a legal department in a large corporation.

There is one big difference...

Posted Dec 20, 2009 8:45 UTC (Sun) by khim (subscriber, #9252) [Link] (1 responses)

Proprietary licensing problems can always be fixed with money (yes, even if it's license from scary company like Microsoft or Oracle they always want money, never anything else) - and usually post-factum. Yes, it can be expensive, but in the end - you get an amended license and go from there. Basically: it's all between legal departments and CFO, developers are not really even involved.

The fact that free licenses demand something upfront is not news to companies bosses (all licenses require different strange things), the fact that it can not be fixed with just a payment is.

There is one big difference...

Posted Dec 20, 2009 11:04 UTC (Sun) by tialaramex (subscriber, #21167) [Link]

Not true, you've over-simplified so much that you miss the point. If you do something that's antithetical to what the big corporation wants, then no amount of money is going to fix that. They just want you to (metaphorically) die in a fire.

For example, maybe you've got a way to get Visual Studio to spit out apps fixed up to run using WINE and make into a static ELF binary. Sure, it uses a lot of Microsoft libraries to do this, but that's just a licensing problem, right? Suddenly 95% of corporate in-house software can run on Linux as easy as click the button.

How much do you think Microsoft wants from you to make this product and its output legal? Will 100 million dollars, up front, do it? Nope. The only way you're going to make a product like that legal is if you manage a hostile takeover of Microsoft so that you're calling the shots. Because it's a stake through the heart for their current business model.

The same applies to trying to fix a GPL violation with money. The whole point is Free Software, and so if your problem is the font size, the lack of support for Token Ring or whatever then that's great - we can talk. But if the problem is you don't want to release source code, then there's nothing to talk about, you can go die in a fire.