FOSS license compliance in the consumer electronics market [LWN.net]

September 14, 2009

This article was contributed by Shane Coughlan & Armijn Hemel

[ This article is an opinion piece and does not contain legal advice. The authors are not lawyers. ]

[ Editor's note: This is part 1 in a series of three. Part 2 looks at compliance engineering and part 3 looks at license compliance for companies. ]

Free and Open Source Software (FOSS) license compliance is a contentious topic. There are different perspectives about when and how license terms apply, about which licenses can be used together, and about how potential issues should be resolved. The consumer electronics market is an area where FOSS license compliance is particularly problematic. This is primarily attributable to economic reasons rather than dishonesty, but in a market worth more than $335 Billion in 2008, it is an issue worth exploring.

Due to the relative youth of the FOSS ecosystem, there is a lack of case law and best practice information available. In the past, one of the few resources available to the community was Debian Legal, and businesses had little beyond Open Bar (USA) and ifrOSS (EU) to support them.

That situation is improving. Organizations like FSF's Free Software Licensing and Compliance Lab, gpl-violations.org, FSFE's Freedom Task Force and Software Freedom Law Center (SFLC) have helped push professional legal and business approaches to the forefront of FOSS discourse. The recent launch of the International Free and Open Source Software Law Review has provided a neutral platform for future discussions. As FOSS has matured so too has the level of information accessible to support businesses and projects.

The consumer electronics business

Consumer electronics are sold in high volumes for low margins, and competition in the market is fierce. The majority of sales take place during the first three months after launch and consumers focus on price and functionality when selecting new technology. Products are developed in Asia by original device manufacturers (ODMs) and original equipment manufacturers (OEMs) and shipped in completed form. There are few western companies doing their own development, and even those with in-house skills are unlikely to build a finished product themselves.

ODM/OEMs may develop products for competing western companies using a single board to save money. A board design and Software Development Kit (SDK) is provided by an upstream supplier like the chip vendor, the ODM/OEM will add hardware or software functions, and the finished system is placed into customized casings. Purchasing companies can label these variants as their own by adapting control panels, contact information, and documentation.

During this process issues can arise regarding license compliance. FOSS originating from a chip vendor may be supplied with incomplete source code to the ODM/OEM. If the source is supplied in complete form it may later be customized by the ODM/OEM and only partially re-integrated into source tree. The marketing team may forget to place licenses or written offers for source code in the product manuals. The list of potential points of failure is lengthy.

The fundamental issue is simple. If FOSS code and changes to that code are not integrated into source releases, or if other terms of popular licenses are not met, then compliance issues can occur. This problem is compounded when one board with a problem appears in devices supplied to a number of western companies. A host of violation reports spanning a dozen European and American businesses may eventually point towards a single mistake during development at an Asian supplier.

Why violations occur

There are many types of FOSS compliance issues. The specific issues depend on the license being used, but may include people forgetting to add a copy of the license text to products, forgetting to include the source code with shipped binaries, or having no policy to handle source code requests after providing a written offer promising this service. There is often a disconnect between support, website maintenance, and legal departments, so even correctly prepared material gets lost in the shuffle. At first glance it can appear daunting to perform due diligence.

However, FOSS compliance is not inherently more complex than proprietary compliance, and compliance in general is not so difficult as to be excusably ignored. There is even a field called compliance engineering where external specialists or in-house staff check that code shipped in products meets the required license terms. The problem for the consumer electronics market is that compliance engineering is perceived to endanger profit. There are two reasons for this.

The first reason is that market timing is extremely important, and a delay reaching consumers could mean being beaten by the competition. Compliance engineering with any reasonable fidelity will take a few days, and when companies will only have one or two test samples of the product available for checking functionality, it's hard to find a way to schedule time for compliance checking. Furthermore, any questions raised will have to be answered by the supplier and potentially other parties in the supply chain. Any missing source code will have to be located and integrated in the SDK. If there is missing code or a supplier in the chain who simply won't release required code (and this happens more than you might imagine), then it is possible that a device will face months of delays.

The second reason is that the cost of compliance engineering may drive a product out of profitability. A transaction cost of €1,200 for checking one device is reasonable given the current market rates, and this sum is a lot of money in the consumer electronics market. The initial release of a product is often a test run to check demand, and may consist of as few as 200 devices being made available to the public. A compliance check at this stage would raise the price of the product by €6, and while justified by law - license compliance is not based on quantity shipped - it may be difficult from an economic perspective. Even after the test run is complete and additional orders are made, if the company plans to ship 10,000 or fewer devices the cost per unit is still at least 12 cents.

[PULL QUOTE: Because of these two pressures the companies involved often don't spend too much time trying to understand FOSS licensing or putting the infrastructure in place to ensure compliance. They may see themselves as facing a choice of shipping non-compliant software and risking a court case or facing a market loss from missed sales. END QUOTE]

Because of these two pressures the companies involved often don't spend too much time trying to understand FOSS licensing or putting the infrastructure in place to ensure compliance. They may see themselves as facing a choice of shipping non-compliant software and risking a court case or facing a market loss from missed sales. With court cases relatively rare in FOSS today, risking a legal challenge may appear to be a less painful option than the alternative.

Whether this perception will continue is debatable. Gpl-violations.org has made what appear to be permanent changes to how businesses approach FOSS in Europe since 2004, and SFLC have started to become pro-active in seeking compliance for projects in the USA. Community tolerance for negligent behavior by commercial entities is waning.

This market adjustment is predictable given the status of FOSS technology. The European Commission estimated that the ecosystem of FOSS applications with reasonable quality control and distribution in 2007 was worth around €12 billion. The cost of obtaining this code is adherence to the license terms, and with rising value creators are naturally less tolerant of misuse then they may have been when FOSS was still in its infancy.

What developers can do to protect their rights

Developers who own the copyright on code have various ways to ensure people obey the licenses. If you are not a copyright holder on code but have found clear evidence of a violation it is a good idea to tell the copyright holders. Ensuring fair play with using the licenses helps maintain confidence in the FOSS ecosystem. It means people can make a decision about how their code will be used and be reasonably sure everyone will stick to the terms.

Perhaps the most important thing when assessing violations is to get the facts right. SFLC's Legal issues primer for Open Source and Free Software projects can assist with this, as can its Practical guide to GPL compliance. The second most important thing is to be fair and professional. Emotion or lack of understanding won't help correct a problem and it certainly won't help foster a potentially useful working relationship.

If you are pretty sure a violation has taken place you can decide what route to take regarding enforcement (if you are a copyright holder) or informing the code owners (if you are not a copyright holder). The first step for everyone is probably to document everything carefully. FSFE and gpl-violations.org published a brief document on reporting and fixing license violations that explains some of the key points that you need to cover. The suggestion is that you should make a report with:

The name of the product affected

The reason why a violation is believed to exist

The name of the project code that may have been violated

A statement regarding what license this code is under

A link to the project site

This information can then be used by you, the affected project, your lawyers, the infringing company, or a third party like gpl-violations.org, FSFE, FSF or SFLC, to examine the situation as applicable. Avoid doing things like forwarding email threads or inserting commentary as this makes it difficult to assess the situation.

For copyright holders there is an established formal mechanism to enforce copyright through legal action. This can be done by taking an infringing party to court or by seeking an out-of-court settlement. There is no doubt this approach is effective, as members of the gpl-violations.org project can attest, though it can also be costly in time and initial fees. Other avenues for correcting misuse of licenses also exist and may be quicker in some circumstances. For example, informal discussions can work with accidental infringement, and mediation by FSFE's Freedom Task Force or FSF's Free Software Licensing and Compliance Lab has also proven to be effective in the past. When it comes to legal advice, independent professionals like Carlo Piana provide excellent advice for both developers and companies with concerns.

Gaining compliance is most often an educational exercise. FOSS has a lot of a new adopters and many of the commercial entities using code in the consumer electronic market come from a proprietary background. That's no excuse for not understanding the licenses, but it is a strong case for considering how these companies can be turned into good community citizens. Productive compliance efforts should use carrots and/or sticks to encourage people to communicate and cooperate with the code creators, projects, and other businesses in this area.

Punishment is not the name of the game. Working together in good faith is.

About the authors

Armijn Hemel is a technology consultant with Loohuis Consulting in The Netherlands and the primary engineer for the gpl-violations.org project.

Shane Coughlan is a business and technology consultant with Opendawn in Japan. He is an expert in Free/Open Source Software licensing, standardization, communication methods and business development

(Log in to post comments)

FOSS license compliance in the consumer electronics market

Posted Sep 14, 2009 18:56 UTC (Mon) by iabervon (subscriber, #722) [Link]

My impression of proprietary licensing of embedded code is that the obligations are entirely fulfilled in the upstream interaction. That is, when company A writes code used in the hardware made by company B and sold by company C, the agreement between A and B doesn't including any obligations to company C. And the more significant difference is that none of these agreements include any obligations to the customers of company C.

The normal comparison is between FOSS licenses and licenses directly from the copyright holder to the end user, from the point of view of the end user. In this case, it is always no harder to comply with the FOSS license. But for the case of being an intermediary of software that goes through intermediaries, compliance is often easier with a proprietary license, where the intermediary can be done with their obligations when they ship.

Of course, this makes me wonder if there might be a market for a company that will write and sell FOSS code to ODMs and act as an intermediary between the ODM and the brand-name seller. That is, when the ODM wants to release something including code from their software supplier, they tell the software supplier, who checks that the firmware image matches the source, and who takes the responsibility for distributing the firmware to the brand-name company; the brand-name company only gets the binary image (generally pre-installed on the hardware) and the offer, which they pass on to the end users; the FOSS supplier has the responsibility for fulfilling requests based on the offer. This would allow ODMs and brand-names to care only minimally about compliance: the ODM has to perform an extra release step (effectively, an off-site backup of the firmware source with validation that it really produces the firmware image, which is not a bad idea in any case), and the brand-name gets a page for their manual (with the offer). Also, the entity which is fulfilling requests for source would be the company that wrote and customized it in the first place, and this company benefits directly from doing it well (in terms of visibility to potential customers).

(In practice, it would probably be that the FOSS company sends source to the ODM, who makes further changes and sends it back; the FOSS company then makes the release binary and sends it to the ODM with an offer for source; the ODM checks that the binary is what they expect in all important ways, and puts it on their hardware; then the ODM sends out the hardware with the binary and an offer from the FOSS company for the source; at this point, the ODM has no further obligations with respect to the firmware, enabling them to put all of their resources into developing the next version.)