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 25
Haxil, Polgara, and Thesulac: Mergers, Upstream Providers and Radio Devices

This case study considers an ongoing (at the time of writing) violation that has occurred. By the end of the investigation period, three companies were involved and many complex issues arose.

25.1 The Facts

Haxil produced a consumer electronics device which included a mini GNU/Linux distribution to control the device. The device was of interest to many technically-minded consumers, who purchased the device and very quickly discovered that Free Software was included without source. Mailing lists throughout the Free Software community erupted with complaints about the problem, and FSF quickly investigated.

FSF confirmed that FSF-copyrighted GPL’d software was included. In addition, the whole distribution included GPL’d works from hundreds of individual copyright holders, many of whom were, at this point, up in arms about the violation.

Meanwhile, Haxil was in the midst of being acquired by Polgara. Polgara was as surprised as everyone else to discover the product was based on GPL’d software; this fact had not been part of the disclosures made during acquisition. FSF contacted Haxil, Polgara, and the product managers who had transitioned into the “Haxil division” of the newly-merged Polgara company. Polgara’s General Counsel’s office worked with FSF on the matter.

FSF formed a coalition with the other primary copyright holders to pursue the enforcement effort on their behalf. FSF communicated directly with Polgara’s representatives to begin working through the issues on behalf of itself and the Free Software community at large.

Polgara pointed out that the software distribution they used was mostly contributed by an upstream provider, Thesulac, and Haxil’s changes to that code base were minimal. Polgara negotiated with Thesulac to obtain the source, although the issue moved very slowly in the channels between Polgara and Thesulac.

FSF encouraged a round-table meeting so that high bandwidth communication could occur between FSF, Polgara and Thesulac. Polgara and Thesulac agreed, and that discussion began. Thesulac provided nearly complete sources to Polgara, and Polgara made a full software release on their Web site. At the time of writing, that software still has some build problems (similar to those that occurred with Bortez, as described in Section 22.1). FSF continues to negotiate with Polgara and Thesulac to resolve these problems, which have a clear path to a solution and are expected to resolve.

Similar to the Vigorien case, Thesulac has regulatory concerns. In this case, it is not export controls — an issue that has since been resolved — but radio spectrum regulation. Since this consumer electronic device contains a software-programmable radio transmitter, regulations in (at least) the USA and Japan prohibit release of those portions of the code that operate the device. Since this is a low-level programming issue, the changes to operate the device form a single combined work with the kernel named Linux. A decade later, this situation remains largely unresolved.

25.2 Lessons Learned

1.
Community outrage, while justified, can often make negotiation more difficult. FSF has a strong policy never to publicize names of GPL violators if they are negotiating in a friendly way and operating in good faith toward compliance. Most violations are honest mistakes, and FSF sees no reason to publicly admonish violators who genuinely want to come into compliance with the GPL and to work hard staying in compliance.

This case was so public in the Free Software community that both Haxil’s and Polgara’s representatives were nearly shell-shocked by the time FSF began negotiations. There was much work required to diffuse the situation. We empathize with our community and their outrage about GPL violations, but we also want to follow a path that leads expediently to compliance. In our experience, public outcry works best as a last resort, not the first.

2.
For software companies, GPL compliance belongs on a corporate acquisition checklist. Polgara was truly amazed that Haxil had used GPL’d software in a major new product line but never informed Polgara during the acquisition process. While GPL compliance is not a particularly difficult matter, it is an additional obligation that comes along with the product line. When planning mergers and joint ventures, one should include lists of GPL’d components contained in the products discussed.
3.
Compliance problems of upstream providers do not excuse a violation for the downstream distributor. To paraphrase §6, upstream providers are not responsible for enforcing compliance of their downstream, nor are downstream distributors responsible for compliance problems of upstream providers. However, engaging in distribution of GPL’d works out of compliance is still just that: a compliance problem. When FSF carries out enforcement, we are patient and sympathetic when the problem appears to be upstream. In fact, we urge the violator to point us to the upstream provider so we may talk to them directly. In this case, we were happy to begin negotiations with Thesulac. However, Polgara still has an obligation to bring their product into compliance, regardless of Thesulac’s response.
4.
It behooves upstream providers to advise downstream distributors about compliance matters. FSF has encouraged Thesulac to distribute a “good practices for GPL compliance” document with their product. Polgara added various software components to Thesulac’s product, and it is conceivable that such additions can introduce compliance. In FSF’s opinion, Thesulac is in no way legally responsible for such a violation introduced by their customer, but it behooves them from a marketing standpoint to educate their customers about using the product. We can argue whether or not it is your coffee vendor’s fault if you burn yourself with their product, but (likely) no one on either side would dispute the prudence of placing a “caution: hot” label on the cup.
5.
FSF enforcement often avoids redundant enforcement cases from many parties. Most Free Software systems have hundreds of copyright holders. Some have thousands. FSF is in a unique position as one of the largest single copyright holders on GPL’d software and as a respected umpire in the community, neutrally enforcing the rules of the GPL road. FSF works hard in the community to convince copyright holders that consolidating GPL claims through FSF is better for them, and more likely to yield positive compliance results.

A few copyright holders engage in the “proprietary relicensing” business, so they use GPL enforcement as a sales channel for that business. FSF, as a community-oriented, not-for-profit organization, seeks only to preserve the freedom of Free Software in its enforcement efforts. As it turns out, most of the community of copyright holders of Free Software want the same thing. Share and share alike is a simple rule to follow, and following that rule to FSF’s satisfaction usually means you are following it to the satisfaction of the entire Free Software community.

Generally, from the experience of GPL enforcement, we glean the following general practices that can help in GPL compliance for organizations that distribute products based on GPL’d software: