% Tutorial Text for the Detailed Study and Analysis of GPL and LGPL course % % Copyright (C) 2003, 2004 Free Software Foundation, Inc. % License: CC-By-SA-4.0 % The copyright holders hereby grant the freedom to copy, modify, convey, % Adapt, and/or redistribute this work under the terms of the Creative % Commons Attribution Share Alike 4.0 International License. % This text is distributed in the hope that it will be useful, but % WITHOUT ANY WARRANTY; without even the implied warranty of % MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % You should have received a copy of the license with this document in % a file called 'CC-By-SA-4.0.txt'. If not, please visit % https://creativecommons.org/licenses/by-sa/4.0/legalcode to receive % the license text. \part{Case Studies in GPL Enforcement} {\parindent 0in This part is: \\ \begin{tabbing} Copyright \= \copyright{} 2003, 2004 \= \hspace{.2in} Free Software Foundation, Inc. \\ \end{tabbing} \vspace{1in} \begin{center} Authors of this part are: \\ Bradley M. Kuhn \\ John Sullivan \vspace{3in} Copy editors of this part include: \\ Martin Michlmayr \vspace{3in} The copyright holders hereby grant the freedom to copy, modify, convey, Adapt, and/or redistribute this work under the terms of the Creative Commons Attribution Share Alike 4.0 International License. A copy of that license is available at \verb=https://creativecommons.org/licenses/by-sa/4.0/legalcode=. \end{center} } % ===================================================================== % START OF SECOND DAY SEMINAR SECTION % ===================================================================== \chapter*{Preface} This one-day course presents the details of five different GPL compliance cases handled by FSF's GPL Compliance Laboratory. Each case offers unique insights into problems that can arise when the terms of the GPL are not properly followed, and how diplomatic negotiation between the violator and the copyright holder can yield positive results for both parties. Attendees should have successfully completely the course, a ``Detailed Study and Analysis of the GPL and LGPL,'' as the material from that course forms the building blocks for this material. This course is of most interest to lawyers who have clients or employers that deal with Free Software on a regular basis. However, technical managers and executives whose businesses use or distribute Free Software will also find the course very helpful. \bigskip These course materials are merely a summary of the highlights of the course presented. Please be aware that during the actual GPL course, class discussion supplements this printed curriculum. Simply reading it is not equivalent to attending the course. %FIXME-LATER: write these %\chapter{Not All GPL Enforcement is Created Equal} %\section{For-Profit Enforcement} %\section{Community and Non-Profit Enforcement} \chapter{Overview of Community Enforcement} The GPL is a Free Software license with legal teeth. Unlike licenses like the X11-style or various BSD licenses, the GPL (and by extension, the LGPL) is designed to defend as well as grant freedom. We saw in the last course that the GPL uses copyright law as a mechanism to grant all the key freedoms essential in Free Software, but also to ensure that those freedoms propagate throughout the distribution chain of the software. \section{Termination Begins Enforcement} As we have learned, the assurance that Free Software under the GPL remains Free Software is accomplished through various terms of the GPL: \S 3 ensures that binaries are always accompanied with source; \S 2 ensures that the sources are adequate, complete and usable; \S 6 and \S 7 ensure that the license of the software is always the GPL for everyone, and that no other legal agreements or licenses trump the GPL. It is \S 4, however, that ensures that the GPL can be enforced. Thus, \S 4 is where we begin our discussion of GPL enforcement. This clause is where the legal teeth of the license are rooted. As a copyright license, the GPL governs only the activities governed by copyright law --- copying, modifying and redistributing computer software. Unlike most copyright licenses, the GPL gives wide grants of permission for engaging with these activities. Such permissions continue, and all parties may exercise them until such time as one party violates the terms of the GPL\@. At the moment of such a violation (i.e., the engaging of copying, modifying or redistributing in ways not permitted by the GPL) \S 4 is invoked. While other parties may continue to operate under the GPL, the violating party loses their rights. Specifically, \S 4 terminates the violators' rights to continue engaging in the permissions that are otherwise granted by the GPL\@. Effectively, their rights revert to the copyright defaults --- no permission is granted to copy, modify, nor redistribute the work. Meanwhile, \S 5 points out that if the violator has no rights under the GPL, they are prohibited by copyright law from engaging in the activities of copying, modifying and distributing. They have lost these rights because they have violated the GPL, and no other license gives them permission to engage in these activities governed by copyright law. \section{Ongoing Violations} In conjunction with \S 4's termination of violators' rights, there is one final industry fact added to the mix: rarely does one engage in a single, solitary act of copying, distributing or modifying software. Almost always, a violator will have legitimately acquired a copy of a GPL'd program, either making modifications or not, and then begun distributing that work. For example, the violator may have put the software in boxes and sold them at stores. Or perhaps the software was put up for download on the Internet. Regardless of the delivery mechanism, violators almost always are engaged in {\em ongoing\/} violation of the GPL\@. In fact, when we discover a GPL violation that occurred only once --- for example, a user group who distributed copies of a GNU/Linux system without source at one meeting --- we rarely pursue it with a high degree of tenacity. In our minds, such a violation is an educational problem, and unless the user group becomes a repeat offender (as it turns out, they never do), we simply forward along a FAQ entry that best explains how user groups can most easily comply with the GPL, and send them on their merry way. It is only the cases of {\em ongoing\/} GPL violation that warrant our active attention. We vehemently pursue those cases where dozens, hundreds or thousands of customers are receiving software that is out of compliance, and where the company continually offers for sale (or distributes gratis as a demo) software distributions that include GPL'd components out of compliance. Our goal is to maximize the impact of enforcement and educate industries who are making such a mistake on a large scale. In addition, such ongoing violation shows that a particular company is committed to a GPL'd product line. We are thrilled to learn that someone is benefiting from Free Software, and we understand that sometimes they become confused about the rules of the road. Rather than merely giving us a postmortem to perform on a past mistake, an ongoing violation gives us an active opportunity to educate a new contributor to the GPL'd commons about proper procedures to contribute to the community. Our central goal is not, in fact, to merely clear up a particular violation. In fact, over time, we hope that our compliance lab will be out of business. We seek to educate the businesses that engage in commerce related to GPL'd software to obey the rules of the road and allow them to operate freely under them. Just as a traffic officer would not revel in reminding people which side of the road to drive on, so we do not revel in violations. By contrast, we revel in the successes of educating an ongoing violator about the GPL so that GPL compliance becomes a second-nature matter, allowing that company to join the GPL ecosystem as a contributor. \section{How are Violations Discovered?} Our enforcement of the GPL is not a fund-raising effort; in fact, FSF's GPL Compliance Lab runs at a loss (in other words, it is subsided by our donors). Our violation reports come from volunteers, who have encountered, in their business or personal life, a device or software product that appears to contain GPL'd software. These reports are almost always sent via email to $<$license-violation@fsf.org$>$. Our first order of business, upon receiving such a report, is to seek independent confirmation. When possible, we get a copy of the software product. For example, if it is an offering that is downloadable from a Web site, we download it and investigate ourselves. When it is not possible for us to actually get a copy of the software, we ask the reporter to go through the same process we would use in examining the software. By rough estimation, about 95\% of violations at this stage can be confirmed by simple commands. Almost all violators have merely made an error and have no nefarious intentions. They have made no attempt to remove our copyright notices from the software. Thus, given the third-party binary, {\tt tpb}, usually, a simple command (on a GNU/Linux system) such as the following will find a Free Software copyright notice and GPL reference: \begin{quotation} {\tt strings tpb | grep Copyright} \end{quotation} In other words, it is usually more than trivial to confirm that GPL'd software is included. Once we have confirmed that a violation has indeed occurred, we must then determine whose copyright has been violated. Contrary to popular belief, FSF does not have the power to enforce the GPL in all cases. Since the GPL operates under copyright law, the powers of enforcement --- to seek redress once \S 4 has been invoked --- lie with the copyright holder of the software. FSF is one of the largest copyright holders in the world of GPL'd software, but we are by no means the only one. Thus, we sometimes discover that while GPL'd code is present in the software, there is no software copyrighted by FSF present. In cases where FSF does not hold copyright interest in the software, but we have confirmed a violation, we contact the copyright holders of the software, and encourage them to enforce the GPL\@. We offer our good offices to help negotiate compliance on their behalf, and many times, we help as a third party to settle such GPL violations. However, what we will describe primarily in this course is FSF's first-hand experience enforcing its own copyrights and the GPL\@. \section{First Contact} The Free Software community is built on a structure of voluntary cooperation and mutual help. Our community has learned that cooperation works best when you assume the best of others, and only change policy, procedures and attitudes when some specific event or occurrence indicates that a change is necessary. We treat the process of GPL enforcement in the same way. Our goal is to encourage violators to join the cooperative community of software sharing, so we want to open our hand in friendship. Therefore, once we have confirmed a violation, our first assumption is that the violation is an oversight or otherwise a mistake due to confusion about the terms of the license. We reach out to the violator and ask them to work with us in a collaborative way to bring the product into compliance. We have received the gamut of possible reactions to such requests, and in this course, we examine four specific examples of such compliance work. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{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. \section{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 \S 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. \label{davrik-build-problems} 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: \begin{quotation} 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. \end{quotation} 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. \section{Lessons} This case introduces a number of concepts regarding GPL enforcement. \begin{enumerate} \item {\bf 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 {\bf 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 \S 3(b)), it reduces the chances for user frustration and inappropriate community outcry about an alleged GPL violation. \item {\bf 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. \item {\bf 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. \item {\bf 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 \S 1 and \S 3 is to {\em 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. \item {\bf 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 \S 6 and \S 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. \end{enumerate} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Bracken: a Minor Violation in a GNU/Linux Distribution} In this case study, we consider a minor violation made by a company whose knowledge of the Free Software community and its functions is deep. \section{The Facts} Bracken produces a GNU/Linux operating system product that is sold primarily to OEM vendors to be placed in appliance devices used for a single purpose, such as an Internet-browsing-only device. The product is almost 100\% Free Software, mostly licensed under the GPL and related Free Software licenses. FSF found out about this violation through a report first posted on a Slashdot\footnote{Slashdot is a popular news and discussion site for technical readers.} comment, and then it was brought to our attention again by another Free Software copyright holder who had discovered the same violation. Bracken's GNU/Linux product is delivered directly from their Web site. This allowed FSF engineers to directly download and confirm the violation quickly. Two primary problems were discovered with the online distribution: \begin{itemize} \item No source code nor offer for source code was provided for a number of components for the distributed GNU/Linux system; only binaries were available \item An End User License Agreement (``EULA'') was included that contradicted the permissions granted by the GPL\@ \end{itemize} FSF contacted Bracken and gave them the details of the violation. Bracken immediately ceased distribution of the product temporarily and set forth a plan to bring themselves back into compliance. This plan included the following steps: \begin{itemize} \item Bracken attorneys would rewrite the EULA to comply with the GPL and would vet the new EULA through FSF before use \item Bracken engineers would provide source side-by-side with the binaries for the GNU/Linux distribution on the site (and on CD's, if ever they distributed that way) \item Bracken attorneys would run an internal seminar for its engineers regarding proper GPL compliance to help ensure that such oversights regarding source releases would not occur in the future \item Bracken would resume distribution of the product only after FSF formally restored Bracken's distribution rights \end{itemize} This case was completed in about a month. FSF approved the new EULA text. The key portion in the EULA relating to the GPL read as follows: \begin{quotation} Many of the Software Programs included in Bracken Software are distributed under the terms of agreements with Third Parties (``Third Party Agreements'') which may expand or limit the Licensee's rights to use certain Software Programs as set forth in [this EULA]. Certain Software Programs may be licensed (or sublicensed) to Licensee under the GNU General Public License and other similar license agreements listed in part in this section which, among other rights, permit the Licensee to copy, modify and redistribute certain Software Programs, or portions thereof, and have access to the source code of certain Software Programs, or portions thereof. In addition, certain Software Programs, or portions thereof, may be licensed (or sublicensed) to Licensee under terms stricter than those set forth in [this EULA]. The Licensee must review the electronic documentation that accompanies certain Software Programs, or portions thereof, for the applicable Third Party Agreements. To the extent any Third Party Agreements require that Bracken provide rights to use, copy or modify a Software Program that are broader than the rights granted to the Licensee in [this EULA], then such rights shall take precedence over the rights and restrictions granted in this Agreement solely for such Software Programs. \end{quotation} FSF restored Bracken's distribution rights shortly after the work was completed as described. \section{Lessons Learned} This case was probably the most quickly and easily resolved of all GPL violations in the history of FSF's Compliance Lab. The ease with which the problem was resolved shows a number of cultural factors that play a role in GPL compliance. \begin{enumerate} \item {\bf Companies that understand Free Software culture better have an easier time with compliance.} Bracken's products were designed and built around the GNU/Linux system and Free Software components. Their engineers were deeply familiar with the Free Software ecosystem, and their lawyers had seen and reviewed the GPL before. The violation was completely an honest mistake. Since the culture inside the company had already adapted to the cooperative style of resolution in the Free Software world, there was very little work for either party to bring the product into compliance. \item {\bf When people in key positions understand the Free Software nature of their software products, compliance concerns are as mundane as minor software bugs.} Even the most functional system or structure has its problems, and successful business often depends on agile response to the problems that do come up; avoiding problems altogether is a pipe dream. Minor GPL violations can and do happen even with well-informed redistributors. However, resolution is reached quickly when the company --- and in particular, the lawyers, managers, and engineers working on the Free Software product lines --- have adapted to Free Software culture that the lower-level engineer already understood \item {\bf Legally, distribution must stop when a violation is identified.} In our opinion, Bracken went above and beyond the call of duty by ceasing distribution while the violation was being resolved. Under GPL \S 4, the redistributor loses the right to distribute the software, and thus they are in ongoing violation of copyright law if they distribute before rights are restored. It is FSF's policy to temporarily allow distribution while compliance negotiations are ongoing and only in the most extreme cases (where the other party appears to be negotiating in bad faith) does FSF even threaten an injunction on copyright grounds. However, Bracken --- as a good Free Software citizen --- chose to be on the safe side and do the legally correct thing while the violation case was pending. From start to finish, it took less than a month to resolve. This lapse in distribution did not, to FSF's knowledge, impact Bracken's business in any way. \item {\bf EULAs are a common area for GPL problems.} Often, EULAs are drafted from boilerplate text that a company uses for all its products. Even the most diligent attorneys forget or simply do not know that a product contains software licensed under the GPL and other Free Software licenses. Drafting a EULA that accounts for such licenses is straightforward; the text quoted above works just fine. The EULA must be designed so that it does not trump rights and permissions already granted by the GPL\@. The EULA must clearly state that if there is a conflict between it and the GPL, with regard to GPL'd code, the GPL is the overriding license. \item {\bf Compliance Officers are rarely necessary when companies are educated about GPL compliance.} As we saw in the Bortez case, FSF asks that a formal ``GPL Compliance Officer'' be appointed inside a previously violating organization to shepherd the organization to a cooperative approach to GPL compliance. However, when FSF sees that an organization already has such an approach, there is no need to request that such an officer be appointed. \end{enumerate} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Vigorien: Security, Export Controls, and GPL Compliance} This case study introduces how concerns of ``security through obscurity'' and regulatory problems can impact GPL compliance matters. \section{The Facts} Vigorien distributes a back-up solution product that allows system administrators to create encrypted backups of file-systems on Unix-like computers. The product is based on GNU tar, a backup utility that replaces the standard Unix utility simply called tar, but has additional features. Vigorien's backup solution added cryptographic features to GNU tar, and included a suite of utilities and graphical user interfaces surrounding GNU tar to make backups convenient. FSF discovered the violation from a user report, and determined that the cryptographic features were the only part of the product that constituted a derivative work of GNU tar; the extraneous utilities merely made shell calls out to GNU tar. FSF requested that Vigorien come into compliance with the GPL by releasing the source of GNU tar, with the cryptographic modifications, to its customers. Vigorien released the original GNU tar sources, but kept the cryptographic modifications proprietary. They argued that the security of their system depending on keeping the software proprietary and that regardless, USA export restrictions on cryptographic software prohibited such a release. FSF disputed the first claim, pointing out that Vigorien had only one option if they did not want to release the source: they would have to remove GNU tar from the software and not distribute it further. Vigorien rejected this suggestion, since GNU tar was an integral part of the product, and the security changes were useless without GNU tar. Regarding the export control claims, FSF proposed a number of options, including release of the source from one of Vigorien's divisions overseas where no such restrictions occurred, but Vigorien argued that the problem was insoluble because they operated primarily in the USA\@. The deadlock on the second issue was resolved when those cryptographic export restrictions were lifted shortly thereafter, and FSF again raised the matter with Vigorien. At that point, they dropped the first claim and agreed to release the remaining source module to their customers. They did so, and the violation was resolved. \section{Lessons Learned} \begin{enumerate} \item {\bf Removing the GPL'd portion of the product is always an option.} Many violators' first response is to simply refuse to release the source code as the GPL requires. FSF offers the option to simply remove the GPL'd portions from the product and continue along without them. Every case where this has been suggested has led to the same conclusion. Like Vigorien, the violator argues that the product cannot function without the GPL'd components, and they cannot effectively replace them. Such an outcome is simply further evidence that the combined work in question is indeed a modified version of the original GPL'd component. If the other components cannot stand on their own and be useful without the GPL'd portions, then one cannot effectively argue that the work as a whole is not a based on the GPL'd portions. \item {\bf The whole product is not always covered.} In this case, Vigorien had additional works aggregated. The backup system was a suite of utilities, some of which were the GPL and some of which were not. While the cryptographic routines were tightly coupled with GNU tar and clearly made a whole new combined work of both components, the various GUI utilities were separate and independent works merely aggregated with the distribution of the GNU-tar-based product. \item {\bf ``Security'' concerns do not exonerate a distributor from GPL obligations, and ``security through obscurity'' does not work anyway.} The argument that ``this is security software, so it cannot be released in source form'' is not a valid defense for explaining why the terms of the GPL are ignored. If companies do not want to release source code for some reason, then they should not base the work on GPL'd software. No external argument for noncompliance can hold weight if the work as a whole is indeed a modified version of a GPL'd program. The ``security concerns'' argument is often floated as a reason to keep software proprietary, but the computer security community has on numerous occasions confirmed that such arguments are entirely specious. Security experts have found --- since the beginnings of the field of cryptography in the ancient world --- that sharing results about systems and having such systems withstand peer review and scrutiny builds the most secure systems. While full disclosure may help some who wish to compromise security, it helps those who want to fix problems even more by identifying them early. \item {\bf External regulatory problems can be difficult to resolve.} The GPL, though grounded in copyright law, does not have the power to trump regulations like export controls. While Vigorien's ``security concerns'' were specious, their export control concerns were not. It is indeed a difficult problem that FSF acknowledges. We want compliance with the GPL and respect for users' freedoms, but we certainly do not expect companies to commit criminal offenses for the sake of compliance. We will see more about this issue in our next case study. \end{enumerate} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{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. \section{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~\ref{davrik-build-problems}). 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. \section{Lessons Learned} \begin{enumerate} \item {\bf 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. \item {\bf 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. \item {\bf Compliance problems of upstream providers do not excuse a violation for the downstream distributor.} To paraphrase \S 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. \item {\bf 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. \item {\bf 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. \end{enumerate} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % FIXME: make this section properly TeX-formatted \chapter{ThinkPenguin Wireless Router: A study in Excellent CCS} This case study does a step-by-step build and installation analysis of one of the best Complete, Corresponding Source (CCS) releases we've seen. The CSS release studied here was provided for the binary distribution of a physical product by ThinkPenguin. The product is the model ``TPE-NWIFIROUTER'', a wireless router. The method of distribution (complete source accompanying the product) and the way the source was laid out provide very good examples of how to make things easier for both the distributor and the purchaser of the hardware containing GPLed components. \section{Root Filesystem and Kernel Compilation} * We found a CD included in the box that the ThinkPenguin TPE-NWIFIROUTER shipped in, labelled "libreCMC v1.2.1 source code". On the CD, there was a README file at the top level, which mentioned that to build the software, one needed a GNU/Linux system as well as a list of approximately 10 packages. These sorts of plain text instructions are helpful because we know what kind of system we are expected to use, and what commands we should run on it. Such instructions are not strictly required, as an obviously-named shell script may suffice, but they are helpful in clarifying any ambiguities that may arise. ** Since it appears that this source release will build on a wide range of distributions, it was fine that no specific distribution was specified. However, most source releases we see will only build on a very specific distribution, due to a variety of assumptions made about the build environment. While such a situation is not ideal in the general sense, it is fine to specify a particular distribution that must be use to build the source release (such as "Debian 7 amd64"), from a compliance perspective. As an example, we noticed such an assumption later on in this source release, but it would be easy to correct in the instructions in this situation (see "`GLIBC\verb0_02.14' not found" below). % FIXME: Spend some time here (admittedly a digression: maybe refer to % another section later?) about how it's ok to specify a specific build % environment. % FIXME(dg): Hopefully the above will suffice. I can expand more/differently if % such is desired. * The actual building of the source code was completed in the following way: ** Since the instructions didn't mention a specific distro to use, we ran the build on an amd64 Debian 6 machine we had. The only distro requirement was: To build your own firmware you need to have access to a GNU/Linux system (case-sensitive filesystem required). ** The README mentioned that: "In order to build firmware images for your router,the following needs to be installed : gcc, binutils, bzip2, flex, python, perl, make, find, grep, diff, unzip, gawk, getopt, libz-dev and libc headers." So we ran "dpkg --list" and confirmed that each package was installed (this is indicated by a leading "ii" on the line containing the package). Other GNU/Linux distributions may have other ways of determing which packages are installed. ** We then extracted the LibreCMC tarball by running "tar --posix -jxpf /media/libreCMC\verb0_0v1\verb0_02\verb0_01\verb0_0SRC/librecmc-v1.2.1.tar.bz2". The CD did contain another tarball (librecmc-u-boot.tar.bz2), but there appeared to be separate instructions for that (in the u-boot\verb0_0reflash text file in the same directory). Having the README be more explicit about this would be nice but did not ultimately prevent us from determing the proper steps to execute. ** The README mentioned the following optional step, which we skipped because we did not need to modify the configuration for our initial build: Please use "make menuconfig" to configure your appreciated configuration for the toolchain and firmware. Please note that the default configuration is what was used to build the firmware image for your router. It is advised that you use this configuration. ** The next instruction was 'Simply running "make" will build your firmware.' So we entered the "librecmc" directory that had been created from the above "tar" command and then ran "make". The build took about 40 minutes to run on our system. The command used and output from running it are available here: enforcement-case-studies\verb0_0log-output/thinkpenguin\verb0_0librecmc-complete.log % FIXME: Above, I'd like to see more ``walk through'' of the step by step % instructions. The text is a bit terse: could be expanded to talk more. % FIXME(dg): Hopefully the above will suffice. I can expand more/differently if % such is desired. * It was helpful to know that we could use "make menuconfig" for configuration changes, as being able to modify the source is an important part of the GPL's requirements. Adding instructions like these shows that the distributor is aware of and interested in promoting the spirit of the GPL, by making it easier to modify the source than may be strictly required by the GPL's text. % FIXME: We should somewhere (perhaps on each step we discuss) talk about % what often goes wrong on those steps, and why this is right. As written % now, there is no driving home of the fact that it is uncommon that things % are so smooth. :) % FIXME(dg): Hopefully the below will suffice. I can expand more/differently if % such is desired. (I presume the above comment relates to the below text.) * The "make" step completed successfully on our system and resulted in several files being generated in the bin/ar71xx directory, namely firmware images. ** This step is normally where we run into the greatest number of build issues (and thus compliance problems). In many cases, the "make" step will fail due to a missing package or because toolchain paths are not setup correctly. As a result, it is important to test the provided instructions on a clean system before distributing the binaries and corresponding source. Listing the specific GNU/Linux distribution and any non-default packages required for the build (ie. those installed before testing the instructions) in the build instructions makes it easier for the end user to successfully build the source release. * There appeared to be several filesystem and kernel images, for different hardware versions. It was unclear which one to install on the particular device we received or how to install it, both of which should have been mentioned in the README. % FIXME: Below, we probably want to talk to them to add this, and also, be a % bit more expansive. * The above installation issue is mitigated by the availability of a web UI in the product that performs firmware image installation. It would be best if instructions like those at http://librecmc.org/librecmc/wiki?name=Tp+MR3020 were included in the README, as the user cannot be expected to infer that or to find such a link. \section{Root Filesystem and Kernel Installation} As mentioned above, the specific steps for installing an updated firmware image were not provided, but we found that the firmware update method available in the web interface worked fine. In particular, we went to http://192.168.10.1/ in our browser, then logged in and chose System -> Backup / Flash Firmware. From there, we went to the "Flash new firmware image" section and selected the librecmc-ar71xx-generic-tl-wr841n-v8-squashfs-sysupgrade.bin image in the bin/ar71xx directory mentioned above. We chose the "v8" image because we found our router said "v8.2" on the bottom and "sysupgrade" because we were doing a firmware upgrade rather than a fresh install. When we clicked "Flash image...", we were prompted to confirm the MD5 hash of the image to flash and then clicked "Proceed" to flash the image. The process took about one minute, at which point we were back at the web UI login screen. We logged in and found that the Kernel Log section showed we were running the new kernel. We then logged in via SSH again and ran "busybox", which printed the new version string, showing it was using our newly-compiled version (given the date). \section{U-Boot Compilation} * As mentioned above, we also found a "u-boot\verb0_0reflash" file at the top level of the included source CD. We followed the instructions for compiling U-Boot, which were fairly straight-forward. One modification would be to mention that "\$U-BOOT\verb0_0SRC" referred to the extracted source directory, which was implied, but should have been explicit. * Additionally, we noticed that the included toolchain binaries, which were used by the U-Boot compilation process by default, did not run on our system. In particular, we received this error: mips-librecmc-linux-uclibc-gcc.bin: /lib/libc.so.6: version `GLIBC`\verb0_02.14' not found (required by mips-librecmc-linux-uclibc-gcc.bin) The complete log output (including the command used to run it) is here: enforcement-case-studies\verb0_0log-output/thinkpenguin\verb0_0u-boot-build\verb0_0fail.log * We found that by removing toolchain/bin and symlinking the toolchain built for the filesystem/kernel above in its place, we were able to complete the U-Boot build. Specifically, we symlinked toolchain/bin to: ../../staging\verb0_0dir/toolchain-mips\verb0_034kc\verb0_0gcc-4.6-linaro\verb0_0uClibc-0.9.33.2/bin Output from the symlink operation can be found here: enforcement-case-studies\verb0_0log-output/thinkpenguin\verb0_0u-boot-create\verb0_0symlink.log * Ideally the pre-built toolchain binaries should not be included and a symlink as mentioned above should be created by default, with a mention that the U-Boot build depends on the previous build for its toolchain. * After compilation completed successfully, we found a new U-Boot image in the bin directory. The instructions explained how to install it on the device. Output from the successful build (after the symlink was created) is here: enforcement-case-studies\verb0_0log-output/thinkpenguin\verb0_0u-boot-finish\verb0_0build.log \section{U-Boot Installation} We obtained a serial cable along with our router, in order to complete the U-Boot installation per the instructions in u-boot\verb0_0reflash. However, we were only able to read data from the serial port; we were unable to interrupt the boot process or access the U-Boot console to complete the U-Boot re-flash. Here are the steps we tried: * We found the serial cable included was a USB serial adapter that had a male USB type A connector on one end and 4 female jumper wires at the other end. These female jumper wires were red, black, white, and green. * The instructions did not specify how to connect these wires, but we were able to determine this in part using the "v8.4" image (close to our "v8.2" router) at \url{http://wiki.openwrt.org/toh/tp-link/tl-wr841nd#serial.console} . Aside from power and ground (red and black), we did have to guess which of the wires was RX and TX. By experimentation we found that green was RX and white was TX. When we tried the other way, we received no data to our serial console at boot time. * We did have to use the included jumper pin gender changer with the USB serial adapter, which we put through the holes on the router's mainboard and then connected to the USB serial adapter. The fit was fairly loose so it would be nice if future router versions included a tighter gender changer or (ideally) had the jumper pins soldered onto the board to begin with (so no gender changer would be required). * We used 115200 8N1 as our serial console settings (with no hardware or software flow control). This was tested with both the minicom and screen commands. We found that if we connected all 4 wires on the USB serial adapter that the router would start without additional power and our console would receive the startup messages. We could replicate the same behavior by omitting the power cable from the USB serial adapter (red wire) and connecting the main power adapter to the router instead. * While we did see the U-Boot and kernel boot logs in our serial console, we were unable to interrupt the boot process as u-boot\verb0_0reflash indicated we should. We suspect this is a misconfiguration of our serial console, but it's unclear exactly how it is misconfigured, as we were able to receive data fine (we just couldn't send data to the router). * As a result, we were unable to complete the U-Boot installation test. We did appreciate that installation instructions were included, though these instructions should be updated to include more specifics about connecting the serial cable. Since ThinkPenguin does have the option to ship a serial adapter with the router, it would be helpful if instructions specific to that adapter were included, as the wiring configuration one should use was unclear. * Additionally, instructions for removing the router's case should be included. We found that the two screws that needed removal to open the case were hidden underneath rubber feet on the case. Indicating which feet need removal to unscrew the case would be helpful. The instructions should also note that the case needs to be carefully separated once the screws are removed; it effectively snaps apart, but care must be taken to avoid breaking the plastic fasteners that keep the case together after the screws are removed. \section{Firmware Comparison} To ensure that the CCS did indeed correspond to the firmware that was shipped on the router, we compared the firmware image that we built using the above steps with the filesystem we found on the device itself. The comparison steps we used were: * Extract the filesystem from the image we built by running find-firmware.pl from https://gitorious.org/gpl-compliance-tools/gpl-compliance-scripts on librecmc-ar71xx-generic-tl-wr841n-v8-squashfs-factory.bin from the bin/ar71xx directory mentioned above (we noticed that our router said "Ver:8.2" on the bottom). Then run squashfs4.2/squashfs-tools/bat-unsquashfs42 from bat-extratools (at http://www.binaryanalysis.org/en/content/show/download ) on the resulting morx0.squash and use the filesystem in the new squashfs-root directory for comparison. * Login to the web interface (at http://192.168.10.1/ ) from a computer that is connected to the router. * Set a password using the provided link at the top (the UI warns that no password is set and asks the user to change it). * Login to the router via SSH, using the root user and the password we just set. * Compare representative directory listings and binaries to ensure the set of included files (on the router) is similar to those found in the firmware image we created (whose contents are now in the local squashfs-root directory). In particular, we did the following comparisons: ** List the /bin folder ("ls -l /bin") and confirm the list of files is the same and that the file sizes are similar. ** Check the "strings" output of /bin/busybox to confirm it was similar in both places (similar number of lines and content of lines). One cannot directly compare the binaries because the slight compilation variations will cause some bits to be different. ** Do the above two steps for /lib/modules, /usr/bin, and other directories with a significant number of binaries. ** To check that the kernel is sufficiently similar, compare the "dmesg" output both before and after flashing the new firmware. The kernel version string should be similar, but should have a different build date and user@host indicator. The kernel binary itself is not easily accessible from an SSH login, but may be retrievable using the U-Boot console (the start address of the kernel in flash appears to be 0x9F000000, based on the u-boot\verb0_0reflash instructions). We were not able to verify this, due to the serial connection issues (see above section on U-Boot installation). \section{Minor Infractions} As mentioned above, there were a few minor infractions. These made it slightly difficult to complete the build and installation without additional context, but did not make the build impossible to complete without more information, such as missing source code for kernel modules or depending on a specific cross-compiler but not mentioning which one or, better yet, including its source code, which are both more problematic infractions. These minor infractions were: % FIXME: clarify seriousness of no install instructions; lack of clarity in % which version to install could be more problematic * Not mentioning how to extract the source tarball and then where to run the "make" command. * Not mentioning how to install the kernel and root filesystem on the device; this is the biggest of these 3 issues but a bit less troublesome than it would otherwise have been since the web-based firmware update process is well-known. * Using pre-built toolchain binaries that don't work on all systems instead of the ones that are built in a separate step, but not moved to the right place. We were able to build corresponding toolchain binaries from source (though for a slightly different target) so this is not a severe toolchain violation of the type we normally find (where toolchain binaries are provided without source). However, including instructions to use the built toolchain binaries instead would be best, or alternatively specifying the distribution on which the toolchain binaries must be run (to avoid being unable to run them as we were). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % COMMENT OUT THIS CHAPTER. % FIXME: is this material moot now that we include the compliance guide? % Either way, it should be merged into compliance guide. %\chapter{Good Practices for Compliance} 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: \begin{itemize} \item Talk to your software engineers and ask them where they got the components they use in the products they build. Find out if GPL'd components are present. \item Teach your engineering staff to pay attention to license documents. Give them easy-to-follow policies to get approval for using a Free Software component. \item Build a ``Free Software Licensing'' committee that handles requests and questions about the GPL and other Free Software licenses. \item Add ``What parts of your products are under the GPL or other Free Software licenses?'' to your checklist of questions to ask when you consider mergers, acquisitions, or joint ventures. \item Encourage your engineers to participate collaboratively with GPL'd software development. The more knowledge about the Free Software world your organization has, the better equipped it is to deal with this rapidly changing field. \item When someone points out a potential GPL violation in one of your products, do not assume the product line is doomed. The GPL is not a virus; merely having GPL'd code in one part of a product does not necessarily mean that every related product must also be GPL'd. And, even if some software needs to be released that was not before, the product will surely survive. In FSF's enforcement efforts, we have not yet seen a product line die because source was released to customers in compliance with the GPL. \end{itemize} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % LocalWords: proprietarize redistributors sublicense yyyy Gnomovision EULAs % LocalWords: Yoyodyne FrontPage improvers Berne copyrightable Stallman's GPLs % LocalWords: Lessig Lessig's UCITA pre PDAs CDs reshifts GPL's Gentoo glibc % LocalWords: TrollTech administrivia LGPL's MontaVista OpenTV Mitek Arce DVD % LocalWords: unprotectable protectable Unfreedonia chipset CodeSourcery Iqtel % LocalWords: impermissibly Bateman faire minimis Borland uncopyrightable Mgmt % LocalWords: franca downloadable Bortez Bortez's % LocalWords: Slashdot sublicensed Vigorien Vigorien's Haxil Polgara % LocalWords: Thesulac Polgara's Haxil's Thesulac's SDK CD's