copyleft.org

WARNING: This document is made public for archival and historical purposes only. Not all of the information is current, and accuracy cannot be guaranteed.

Chapter 22
Bortez: Modified GCC SDK

In our first case study, we will consider Bortez, a company that produces software and hardware toolkits to assist OEM vendors, makers of consumer electronic devices.

22.1 Facts

One of Bortez’s key products is a Software Development Kit (“SDK”) designed to assist developers building software for a specific class of consumer electronics devices.

FSF received a report that the SDK may be based on the GNU Compiler Collection (which is an FSF-copyrighted collection of tools for software development in C, C++ and other popular languages). FSF investigated the claim, but was unable to confirm the violation. The violation reporter was unresponsive to follow-up requests for more information.

Since FSF was unable to confirm the violation, we did not pursue it any further. Bogus reports do happen, and we do not want to burden companies with specious GPL violation complaints. FSF shelved the matter until more evidence was discovered.

FSF was later able to confirm the violation when two additional reports surfaced from other violation reporters, both of whom had used the SDK professionally and noticed clear similarities to FSF’s GNU GCC. FSF’s Compliance Engineer asked the reporters to run standard tests to confirm the violation, and it was confirmed that Bortez’s SDK was indeed a modified version of GCC. Bortez had ported to Windows and added a number of features, including support for a specific consumer device chipset and additional features to aid in the linking process (“LP”) for those specific devices. FSF explained the rights that the GPL afforded these customers and pointed out, for example, that Bortez only needed to provide source to those in possession of the binaries, and that the users may need to request that source (if §3(b) was exercised). The violators confirmed that such requests were not answered.

FSF brought the matter to the attention of Bortez, who immediately escalated the matter to their attorneys. After a long negotiation, Bortez acknowledged that their SDK was indeed a modified version of GCC. Bortez released most of the source, but some disagreement occurred over whether LP was also derivative of GCC. After repeated FSF inquiries, Bortez reaudited the source to discover that FSF’s analysis was correct. Bortez determined that LP included a number of source files copied from the GCC code-base.

Once the full software release was made available, FSF asked the violation reporters if it addressed the problem. Reports came back that the source did not properly build. FSF asked Bortez to provide better build instructions with the software, and such build instructions were incorporated into the next software release.

At FSF’s request as well, Bortez informed customers who had previously purchased the product that the source was now available by announcing the availability on its Web site and via a customer newsletter.

Bortez did have some concerns regarding patents. They wished to include a statement with the software release that made sure they were not granting any patent permission other than what was absolutely required by the GPL. They understood that their patent assertions could not trump any rights granted by the GPL. The following language was negotiated into the release:

Subject to the qualifications stated below, Bortez, on behalf of itself and its Subsidiaries, agrees not to assert the Claims against you for your making, use, offer for sale, sale, or importation of the Bortez’s GNU Utilities or derivative works of the Bortez’s GNU Utilities (“Derivatives”), but only to the extent that any such Derivatives are licensed by you under the terms of the GNU General Public License. The Claims are the claims of patents that Bortez or its Subsidiaries have standing to enforce that are directly infringed by the making, use, or sale of an Bortez Distributed GNU Utilities in the form it was distributed by Bortez and that do not include any limitation that reads on hardware; the Claims do not include any additional patent claims held by Bortez that cover any modifications of, derivative works based on or combinations with the Bortez’s GNU Utilities, even if such a claim is disclosed in the same patent as a Claim. Subsidiaries are entities that are wholly owned by Bortez.

This statement does not negate, limit or restrict any rights you already have under the GNU General Public License version 2.

This quelled Bortez’s concerns about other patent licensing they sought to do outside of the GPL’d software, and satisfied FSF’s concerns that Bortez give proper permissions to exercise teachings of patents that were exercised in their GPL’d software release.

Finally, a GPL Compliance Officer inside Bortez was appointed to take responsibility for all matters of GPL compliance inside the company. Bortez is responsible for informing FSF if the position is given to someone else inside the company, and making sure that FSF has direct contact with Bortez’s Compliance Officer.

22.2 Lessons

This case introduces a number of concepts regarding GPL enforcement.

1.
Enforcement should not begin until the evidence is confirmed. Most companies that distribute GPL’d software do so in compliance, and at times, violation reports are mistaken. Even with extensive efforts in GPL education, many users do not fully understand their rights and the obligations that companies have. By working through the investigation with reporters, the violation can be properly confirmed, and the user of the software can be educated about what to expect with GPL’d software. When users and customers of GPL’d products know their rights, what to expect, and how to properly exercise their rights (particularly under §3(b)), it reduces the chances for user frustration and inappropriate community outcry about an alleged GPL violation.
2.
GPL compliance requires friendly negotiation and cooperation. Often, attorneys and managers are legitimately surprised to find out GPL’d software is included in their company’s products. Engineers sometimes include GPL’d software without understanding the requirements. This does not excuse companies from their obligations under the license, but it does mean that care and patience are essential for reaching GPL compliance. We want companies to understand that participating and benefiting from a collaborative Free Software community is not a burden, so we strive to make the process of coming into compliance as smooth as possible.
3.
Confirming compliance is a community effort. The whole point of making sure that software distributors respect the terms of the GPL is to allow a thriving software sharing community to benefit and improve the work. FSF is not the expert on how a compiler for consumer electronic devices should work. We therefore inform the community who originally brought the violation to our attention and ask them to assist in evaluation and confirmation of the product’s compliance. Of course, FSF coordinates and oversees the process, but we do not want compliance for compliance’s sake; rather, we wish to foster a cooperating community of development around the Free Software in question, and encourage the once-violator to begin participating in that community.
4.
Informing the harmed community is part of compliance. FSF asks violators to make some attempt — such as via newsletters and the company’s Web site — to inform those who already have the products as to their rights under the GPL. One of the key thrusts of the GPL’s §1 and §3 is to make sure the user knows she has these rights. If a product was received out of compliance by a customer, she may never actually discover that she has such rights. Informing customers, in a way that is not burdensome but has a high probability of successfully reaching those who would seek to exercise their freedoms, is essential to properly remedy the mistake.
5.
Lines between various copyright, patent, and other legal mechanisms must be precisely defined and considered. The most difficult negotiation point of the Bortez case was drafting language that simultaneously protected Bortez’s patent rights outside of the GPL’d source, but was consistent with the implicit patent grant in the GPL. As we discussed in the first course of this series, there is indeed an implicit patent grant with the GPL, thanks to §6 and §7. However, many companies become nervous and wish to make the grant explicit to assure themselves that the grant is sufficiently narrow for their needs. We understand that there is no reasonable way to determine what patent claims read on a company’s GPL holdings and which do not, so we do not object to general language that explicitly narrows the patent grant to only those patents that were, in fact, exercised by the GPL’d software as released by the company.