1534 lines
76 KiB
TeX
1534 lines
76 KiB
TeX
% Tutorial Text for the Detailed Study and Analysis of GPL and LGPL course
|
|
|
|
% 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, 2014 \hspace{1mm} \= \hspace{1.mm} \= \kill
|
|
Copyright \> \copyright{} 2014 \> Bradley M. Kuhn. \\
|
|
Copyright \> \copyright{} 2014 \> Denver Gingerich \\
|
|
Copyright \> \copyright{} 2003, 2004, 2014 \> 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 \url{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.
|
|
|
|
% FIXME: make this section properly TeX-formatted
|
|
\chapter{ThinkPenguin Wireless Router: Excellent CCS}
|
|
\label{pristine-example}
|
|
|
|
Too often, case studies examine failure and mistakes. Indeed, most of the
|
|
chapters that follow herein will consider the myriad difficulties discovered
|
|
in community-oriented GPL enforcement for the last two decades. However, to
|
|
begin, this is a case study in how copyleft compliance can indeed be done correctly.
|
|
|
|
This example is, in fact, more than ten years in the making. Since almost
|
|
the inception of for-profit corporate adoption of Free Software, companies
|
|
have requested a clear example of a model citizen to emulate. Sadly, while
|
|
community-oriented enforcers have vetted uncounted thousands of ``Complete,
|
|
Corresponding Source'' (CCS) candidates from hundreds of companies, this
|
|
particular CCS release described herein is the first ever declared a ``pristine
|
|
example''.
|
|
|
|
% FIXME (above): link to a further discussion of CCS in the compliance guide
|
|
% when a good spot exists, then (below) link to a ``CCS iteration''
|
|
% discussion in compliance-guide.tex when one exists. (the ``iteration
|
|
% process'' is discussed in~\ref{} of this guide)
|
|
|
|
Of course, most CCS examined for the last decade has (eventually) complied
|
|
with the GPL, perhaps after many iterations of review by the enforcer.
|
|
However, in the experience of the two primary community-oriented enforcers
|
|
(Conservancy and the FSF), such CCS results routinely
|
|
``barely comply with GPL's requirements''. To use an academic analogy:
|
|
while a ``C'' is certainly a passing grade, any instructor prefers to
|
|
disseminate to the class an exemplar sample that earned an ``A''.
|
|
|
|
Fortunately, thanks in large part to the FSF's
|
|
``Respects Your Freedom'' (RYF) certification campaign\footnote{\href{http://www.fsf.org/resources/hw/endorsement/respects-your-freedom}{RYF is
|
|
a campaign by FSF to certify products that truly meet the principles of
|
|
software freedom}. Products must meet
|
|
\href{http://www.fsf.org/resources/hw/endorsement/criteria}{strict
|
|
standards for RYF certification}, and among them is a pristine example of
|
|
CCS\@.}, a few electronics products on the market meet
|
|
a higher standard of copyleft compliance. As such, for the first
|
|
time in the history of copyleft, CCS experts have pristine examples to study
|
|
and present as exemplars worthy of emulation.
|
|
|
|
This case study therefore examines the entire life-cycle of a GPL compliance
|
|
investigation: from product purchase, to source request, to CCS review, and concluding
|
|
in a final compliance determination.
|
|
Specifically, this chapter discusses the purchase, CCS provision, and a
|
|
step-by-step build and installation analysis of a specific, physical,
|
|
embedded electronics product:
|
|
\href{https://www.thinkpenguin.com/gnu-linux/free-software-wireless-n-broadband-router-gnu-linux-tpe-nwifirouter}{the
|
|
``TPE-NWIFIROUTER'' wireless router by ThinkPenguin}.\footnote{The FSF of
|
|
course performed a thorough CCS check as part of its certification process.
|
|
The analysis discussed herein was independently performed by Software
|
|
Freedom Conservancy without reviewing the FSF's findings. Thus, this
|
|
analysis is ``true to form'', and explains the typical procedures Conservancy
|
|
uses when investigating a potential GPL violation. In this case, obviously, no
|
|
violation was uncovered.}
|
|
|
|
\section{Consumer Purchase and Unboxing}
|
|
|
|
The process for copyleft compliance investigation, when properly conducted,
|
|
determines whether users inclined to exercise their rights under a copyleft
|
|
license will be successful in their attempt. Therefore, at every stage, the
|
|
investigator seeks to take actions that reasonably technically knowledgeable
|
|
users would during the ordinary course of their acquisition and use of
|
|
copyleft-covered products. As such, the investigator typically purchases the device on the
|
|
open market to verify that distribution of the copylefted software therein
|
|
complies with binary distribution requirements (such as those
|
|
\tutorialpartsplit{discussed in \textit{Detailed Analysis of the GNU GPL and
|
|
Related Licenses}}{discussed earlier in \S~\ref{GPLv2s3} and
|
|
\S~\ref{GPLv3s6}}).
|
|
|
|
% FIXME: Above is my only use of \tutorialpartsplit in this chapter. I just
|
|
% got lazy and that should be fixed by someone.
|
|
|
|
\label{thinkpenguin-included-ccs}
|
|
|
|
Therefore, the investigator first purchased the TPE-NWIFIROUTER through an
|
|
online order, and when the package arrived, examined the contents of the box.
|
|
The investigator immediately discovered that ThinkPenguin had taken advice
|
|
from \S~\ref{offer-for-source}, and exercised
|
|
\hyperref[GPLv2s3a]{GPLv2\S3(a)} and \hyperref[GPLv3s6]{GPLv3\S6}, rather than
|
|
using the \hyperref[offer-for-source]{problematic offer for source
|
|
provisions}. This choice not only accelerated the investigation (since there
|
|
was no CCS offer to ``test''), but also simplified the compliance requirements for
|
|
ThinkPenguin.
|
|
|
|
\section{Root Filesystem and Kernel Compilation}
|
|
|
|
The CD found in the box was labeled ``libreCMC v1.2.1 source code'', and
|
|
contained 407 megabytes of data. The investigator copied this ISO to a
|
|
desktop GNU/Linux system and
|
|
examined its contents. Upon doing so, the investigator immediately found a
|
|
file called ``README'' at the top-level directory:
|
|
|
|
\lstset{tabsize=2}
|
|
\begin{lstlisting}[language=bash]
|
|
$ dd if=/dev/cdrom of=libreCMC_v1.2.1_SRC.iso
|
|
$ mkdir libCMC
|
|
$ sudo mount -o loop ./libreCMC_v1.2.1_SRC.iso libCMC
|
|
mount: block device /path/to/libreCMC_v1.2.1_SRC.iso
|
|
is write-protected, mounting read-only
|
|
$ ls -1 libCMC
|
|
bin
|
|
librecmc-u-boot.tar.bz2
|
|
librecmc-v1.2.1.tar.bz2
|
|
README
|
|
u-boot_reflash
|
|
$ cat libCMC/README
|
|
...
|
|
\end{lstlisting}
|
|
\label{thinkpenguin-toplevel-readme}
|
|
The investigator therefore knew immediately to begin the CCS check should
|
|
begin with a study of the contents of ``README''. Indeed, that file contained the appropriate
|
|
details to start the build:
|
|
\begin{quotation}
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Simply running ``make'' will build your firmware. The build system will
|
|
download all sources, build the cross-compile toolchain, the kernel and all
|
|
chosen applications.
|
|
|
|
To build your own firmware you need to have access to a GNU/Linux system
|
|
(case-sensitive filesystem required).
|
|
\end{quotation}
|
|
|
|
In other words, the first ``script'' that investigator ``ran'' was the above.
|
|
This was not a software script, rather the processor for the script was the investigator's own
|
|
brain --- like a script of a play. Less glibly stated: instructions written in
|
|
English are usually necessary for the build and installation operations
|
|
that demand actual intelligence.
|
|
In this case, the investigator ascertained the host system requirements
|
|
for construction of this embedded firmware.
|
|
|
|
GPL does not give specific guidance on the form or location of
|
|
``scripts used to control compilation and installation of the executable''
|
|
and/or ``Installation Information''. Community-oriented GPL enforcers apply a
|
|
``reasonableness standard'' to evaluate such instructions. If an investigator of
|
|
average skill in embedded firmware construction can surmise the proper
|
|
procedures to build and install a replacement firmware, the instructions are
|
|
likely sufficient to meet GPL's requirements. Fortunately, in this case, the
|
|
instructions are more abundant and give extra detail.
|
|
|
|
Nevertheless, these instructions offer more options than the reader
|
|
typically sees in other CCS candidates. More typically, top-level build
|
|
instructions name an exact host distribution to use, such as
|
|
``Debian 7 installed on an amd64 system with the following packages
|
|
installed''. Of course, if the build will fail on any other system,
|
|
instructions \textit{should} include such details. However, this CCS builds
|
|
on a wide range of distributions, and thus it was appropriate (and preferred)
|
|
that the build instructions do not specify a specific distribution.
|
|
|
|
\label{thinkpenguin-specific-host-system}
|
|
|
|
In this specific case, the developers of the libreCMC project (a Free
|
|
Software project that forms the base system for the TPE-NWIFIROUTER) have
|
|
clearly made an effort to ensure the CCS builds on a variety of host systems.
|
|
The investigator was in fact dubious upon seeing these instructions, since
|
|
finicky embedded build processes usually require a very specific host system.
|
|
Fortunately, it seems such doubts were generally unfounded (although the
|
|
investigator did find
|
|
\hyperref[thinkpenguin-glibc-214-issue]{a minor annoyance that could be
|
|
resolved with more detailed instructions}).
|
|
|
|
Anyway, since these instructions did not specify a specific host system, the
|
|
investigator simply used his own amd64 Debian GNU/Linux 6 desktop system. Before
|
|
beginning, the investigator used the following command:
|
|
|
|
\lstset{tabsize=2}
|
|
\begin{lstlisting}[language=bash]
|
|
$ dpkg --list | egrep '^iii' | less
|
|
\end{lstlisting}
|
|
|
|
to verify that the required packages listed in the README were
|
|
installed\footnote{The ``dpkg'' command is a Debian-specific way of
|
|
finding installed packages.}.
|
|
|
|
|
|
Next, the investigator then extracted the primary source package with the
|
|
following command:
|
|
|
|
\lstset{tabsize=2}
|
|
\begin{lstlisting}[language=bash]
|
|
$ tar --posix -jxpf libCMC/librecmc-v1.2.1.tar.bz2
|
|
\end{lstlisting}
|
|
|
|
The investigator did notice an additional source release, entitled
|
|
``librecmc-u-boot.tar.bz2''. The investigator concluded upon simple
|
|
inspection that the instructions found in ``u-boot\verb0_0reflash'' were
|
|
specific instructions for that part of the CCS\@. This was a minor
|
|
annoyance, and ideally the ``README'' would so-state, but the CCS filesystem
|
|
layout met the reasonableness standard; the skilled investigator determine the correct
|
|
course of action with a few moments of study.
|
|
|
|
The investigator then noted the additional step offered by the ``README'',
|
|
which read:
|
|
\begin{quotation}
|
|
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.
|
|
\end{quotation}
|
|
|
|
This instruction actually exceeds GPL's requirements.
|
|
Specifically, the instruction guides users in their first step toward
|
|
exercising the freedom to modify the software. While the GPL does contain
|
|
requirements that facilitate the freedom to modify (such as ensuring the CCS is
|
|
in the ``preferred form \ldots for making modifications to it''), GPL
|
|
does not require specific instructions explaining how to undertake
|
|
modifications. This specific instruction therefore exemplifies
|
|
the exceptional quality of this particular CCS\@.
|
|
|
|
%FIXME: add a \hyperref to some ``preferred for for modification'' stuff above.
|
|
|
|
However, for purposes of the CCS verification process, typically the
|
|
investigator avoids any unnecessary changes to the source code during the
|
|
build process, lest the investigator err and cause the build to fail through
|
|
his own modification, and thus incorrectly identify the CCS as inadequate.
|
|
Therefore, the investigator proceeded to simply run:
|
|
|
|
\lstset{tabsize=2}
|
|
\begin{lstlisting}[language=bash]
|
|
$ cd libCMC
|
|
$ make
|
|
\end{lstlisting}
|
|
|
|
and waited approximately 40 minutes for the build to complete\footnote{Build
|
|
times will likely vary widely on various host systems.}. The investigator
|
|
kept a
|
|
\href{https://gitorious.org/copyleft-org/tutorial/source/master:enforcement-case-studies_log-output/thinkpenguin_librecmc-complete.log}{full
|
|
log of the build}, which is not included herein due its size (approximately
|
|
7.2K of text).
|
|
\label{thinkpenguin-main-build}
|
|
|
|
Upon completion of the ``make'' process, the investigator immediately found
|
|
(almost to his surprise) several large firmware files in the ``bin/ar71xx''
|
|
directory. Typically, this step in the CCS verification process is
|
|
harrowing. In most cases, the ``make'' step will fail due to a missing
|
|
package or because toolchain paths are not setup correctly.
|
|
|
|
In light of such experiences, the investigator speculated that ThinkPenguin's engineers did
|
|
the most important step in self-CCS verification: test one's own instructions
|
|
on a clean system. Ideally, an employee with similar skills but
|
|
unfamiliar with the specific product can most easily verify CCS and identify
|
|
problems before a violation occurs.
|
|
|
|
% FIXME: Is there stuff about the above in the compliance guide? If so, link
|
|
% to it. If not, write it, then link to it. :)
|
|
|
|
However, upon completing the ``make'', the investigator was unclear which
|
|
filesystem and kernel images to install on the TPE-NWIFIROUTER hardware.
|
|
Ideally, the original ``README'' would indicate which image is appropriate
|
|
for the included hardware. However, this was ultimately an annoyance rather
|
|
than a compliance issue. Fortunately,
|
|
the web UI (see next section) on the TPE-NWIFIROUTER performs firmware image
|
|
installation. Additionally, the router's version number was specified on the
|
|
bottom of the device, which indicated which of the differently-versioned images
|
|
we should install. The investigator would prefer instructions such as
|
|
those found at
|
|
\url{http://librecmc.org/librecmc/wiki?name=Tp+MR3020}{instructions similar
|
|
to these} in the README itself; however, application of the reasonableness
|
|
standard here again indicates compliance, since a knowledgeable user can easily
|
|
determine the proper course of action.
|
|
|
|
|
|
\section{U-Boot Compilation}
|
|
|
|
%FIXME: link to u-boot reflash, maybe put it in log-output dir?
|
|
|
|
The investigator then turned his attention to the file,
|
|
``u-boot\verb0_0reflash''. These instructions explained how to
|
|
build and install the bootloader for the device.
|
|
|
|
The investigator followed the instructions for compiling U-Boot, and found
|
|
them quite straight-forward. The investigator discovered two minor
|
|
annoyances, however, while building U-Boot:
|
|
|
|
\begin{itemize}
|
|
|
|
\item The variable \verb0$U-BOOT_SRC0 was used as a placeholder for the name
|
|
of the extracted source directory. This was easy to surmise and was not a
|
|
compliance issue (per the reasonableness standard), but explicitly stating
|
|
that fact at the top of the instructions would be helpful.
|
|
|
|
\label{thinkpenguin-glibc-214-issue}
|
|
\item Toolchain binaries were included and used by default by the build
|
|
process. These binaries were not the appropriate ones for the
|
|
investigator's host system, and the build failed with the following error:
|
|
|
|
\lstset{tabsize=2}
|
|
\begin{lstlisting}
|
|
mips-librecmc-linux-uclibc-gcc.bin: /lib/libc.so.6:
|
|
version `GLIBC`_2.14' not found
|
|
(required by mips-librecmc-linux-uclibc-gcc.bin)
|
|
\end{lstlisting}
|
|
|
|
(The
|
|
\href{https://gitorious.org/copyleft-org/tutorial/source/master:enforcement-case-studies_log-output/thinkpenguin_u-boot-build_fail.log}{complete
|
|
log output from the failure} is too lengthy to include herein.)
|
|
|
|
This issue is an annoyance, not a compliance problem. It was clear from
|
|
context that these binaries were simply for a different host architecture, and
|
|
the investigator simply removed ``toolchain/bin'' and created a symlink to
|
|
utilize the toolchain already built earlier (during the compilation
|
|
discussed in \S~\ref{thinkpenguin-main-build}):
|
|
|
|
\lstset{tabsize=2}
|
|
\begin{lstlisting}
|
|
$ ln -s \
|
|
../../staging_dir/toolchain-mips_34kc_gcc-4.6-linaro_uClibc-0.9.33.2/bin \
|
|
toolchain/bin
|
|
\end{lstlisting}
|
|
|
|
|
|
After this change, the U-Boot build completed successfully.
|
|
\end{itemize}
|
|
|
|
The
|
|
\href{https://gitorious.org/copyleft-org/tutorial/source/master:enforcement-case-studies_log-output/thinkpenguin_u-boot-finish_build.log}{full
|
|
log of the build} is not included herein due its size (approximately 3.8K
|
|
of text). After that, the investigator found a new U-Boot image in the
|
|
``bin'' directory.
|
|
|
|
\section{Root Filesystem and Kernel Installation}
|
|
|
|
The investigator next tested installation of the firmware. In particular,
|
|
the investigator connected the TPE-NWIFIROUTER to a local network, and
|
|
visited \url{http://192.168.10.1/}, logged in, and chose the option sequence:
|
|
``System $\Rightarrow$ Backup / Flash Firmware''.
|
|
|
|
From there, the investigator chose the ``Flash new firmware image'' section
|
|
and selected the
|
|
``librecmc-ar71xx-generic-tl-wr841n-v8-squashfs-sysupgrade.bin'' image from
|
|
the ``bin/ar71xx'' directory. The investigator chose the ``v8'' image upon
|
|
verifying the physical router read ``v8.2'' on its bottom. The investigator
|
|
chose the ``sysupgrade'' version of the image because this was clearly a
|
|
system upgrade (as a firmware already came preinstalled on the
|
|
TPE-NWIFIROUTER).
|
|
|
|
Upon clicking ``Flash image\ldots'', the web interface prompted the
|
|
investigator to confirm the MD5 hash of the image to flash. The investigator
|
|
did so, and then clicked ``Proceed'' to flash the image. The process took
|
|
about one minute, at which point the web page refreshed to the login screen.
|
|
Upon logging in, the investigator was able to confirm in the ``Kernel Log''
|
|
section of the web interface that the newly built copy of Linux had indeed been
|
|
installed.
|
|
|
|
The investigator confirmed that a new version of ``busybox'' had also been
|
|
installed by using SSH to connect to the router and ran the command
|
|
``busybox'', which showed the newly-compiled version (via its date of
|
|
compilation).
|
|
|
|
%FIXME: dg: can you get me a screen shot for the Kernel Log above, and paste
|
|
%in the output of running busybox ?
|
|
%FIXME: bkuhn: the screen shot for the Kernel Log is in the log output dir at
|
|
%thinkpenguin_librecmc-built-kernel_log.png and the BusyBox output is in the
|
|
%same directory at thinkpenguin_librecmc-built-busybox_output.log - you may want
|
|
%to only use part of the BusyBox output (maybe even just the login) for brevity
|
|
|
|
\section{U-Boot Installation}
|
|
|
|
The U-Boot installation process is substantially more complicated than the
|
|
firmware update. The investigator purchased the optional serial cable
|
|
along with the TPE-NWIFIROUTER, in order to complete the U-Boot installation
|
|
per the instructions in ``u-boot\verb0_0reflash'' in its section ``Installing
|
|
u-boot to your router'', which reads:
|
|
|
|
\begin{quotation}
|
|
\begin{enumerate}
|
|
|
|
\item Install and configure any TFTP server on your PC (tftp-hpa).
|
|
Set a fixed IP address on your PC \ldots and connect it to the router,
|
|
using RJ45 network cable \ldots
|
|
|
|
\item Connect USB to UART adapter to the router and start any application to
|
|
communicate with it, like PuTTY. \ldots
|
|
|
|
\item Power on the router, wait for a line like one of the following and
|
|
interrupt the process of loading a kernel:
|
|
\begin{verbatim}
|
|
Autobooting in 1 seconds
|
|
(for most TP-Link routers, you should enter tpl at this point)
|
|
Hit ESC key to stop autoboot: 1 (for 8devices Carambola 2, use ESC key)
|
|
Hit any key to stop autoboot: 1 (for D-Link DIR-505, use any key)
|
|
\end{verbatim}
|
|
\item Set ipaddr and serverip environment variables:
|
|
\lstset{tabsize=2}
|
|
\begin{lstlisting}
|
|
hornet> setenv ipaddr 192.168.1.1
|
|
hornet> setenv serverip 192.168.1.2
|
|
\end{lstlisting}
|
|
|
|
\end{enumerate}
|
|
\end{quotation}
|
|
|
|
|
|
%FIXME: image of the serial cable available anywhere to put here:
|
|
% https://www.adafruit.com/images/970x728/954-02.jpg
|
|
|
|
The investigator used the purchased serial cable, which was a USB serial
|
|
adapter with a male USB type A connector to 4 female jumper wires. The
|
|
female jumper wires were red, black, white, and green.
|
|
|
|
The instructions here were slightly incomplete, since they did not specify
|
|
how to connect the wires to the router. However, the investigator found
|
|
general information available online at
|
|
\url{http://wiki.openwrt.org/toh/tp-link/tl-wr841nd#serial.console} which
|
|
described the proper procedure. While the ``power'' and ``ground'' cables
|
|
were obvious, some trial and error was necessary to find the RX and TX
|
|
cables, but this was easily determined since miswiring TX and RX yields no
|
|
I/O and proper wiring yields the output as expected. Using the pin gender
|
|
changer included with the adapter, the investigator was able to stably wire
|
|
the pins for use once the proper RX and TX connections were determined.
|
|
|
|
The investigator then used the recommended 115200 8N1 for serial console
|
|
settings, leaving all flow control off, and tested both with the
|
|
\verb0minicom0 and \verb0screen0 commands. The investigator found that if
|
|
all 4 wires were connected on the USB serial adapter that the router would
|
|
start without additional power and the console would receive the startup
|
|
messages. The investigator 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.
|
|
|
|
At this point, the on-screen messages as described in the installation
|
|
instructions appeared, but the investigator found that no key events sent via
|
|
the serial port appeared to reach the U-Boot console. In other words, while
|
|
the investigator saw both U-Boot and kernel boot messages in the serial
|
|
console, the investigator was unable to interrupt the boot process as
|
|
instructed by ``u-boot\verb0_0reflash''. Hitting a key simply did
|
|
\textit{not} interrupt the boot process and yield the \verb0hornet>0 prompt.
|
|
|
|
After additional trial and error over a period of hours, the investigator had
|
|
finally to consider this question for the first time during the process:
|
|
``Has ThinkPenguin violated the GPL?'' More specifically, the immediate
|
|
question was: ``Given this failure, has the distributor met
|
|
\hyperref[GPLv2s3-build-scripts]{the requirements for `scripts used to
|
|
control \ldots installation of the executable' (GPLv2)} and
|
|
\hyperref[GPLv3-installation-information]{necessary `Installation
|
|
Information' (GPLv3)}?''
|
|
|
|
The appropriate answer to the question (at this specific stage) is ``possibly,
|
|
but more information is needed''. Embedded installation and configuration is
|
|
a tricky and complex technical process. While the GPL requires documentation
|
|
and clear instructions for this process, the investigator did not immediately blame the distributor
|
|
for what may be an honest, correctable mistake, or an issue legitimately explained by
|
|
feasible alternative theories.
|
|
|
|
In this case, upon remembering the issues of wiring, the investigator wonder
|
|
if perhaps the power pin was accidentally connected for a moment to the RX
|
|
pin while live. Such action could easily fry the RX pin, and yield the
|
|
observed behavior. Since the investigator could not rule out the possibility
|
|
of accidental connection of power to the RX pin mentioned, the investigator
|
|
had to assume the instructions would work properly if he had not made that
|
|
error.
|
|
|
|
That conclusion, while correct, also left the investigator with only two
|
|
option to complete the final verification of the CCS:
|
|
|
|
\begin{itemize}
|
|
|
|
\item Purchase a new router and cable anew, and reattempt the installation
|
|
process while taking extra care not to miswire any cables.
|
|
|
|
\item Seek assistance from the libreCMC community to find an alternative
|
|
method of installation.
|
|
|
|
\end{itemize}
|
|
|
|
The investigator chose the latter and then contacted a libreCMC developer
|
|
familiar with the product. That developer, who agreed the the RX pin was
|
|
likely ruined, described an alternative method for console access using the
|
|
{\tt netcat}. The libreCMC developer described the process as follows:
|
|
|
|
\begin{quotation}
|
|
|
|
\begin{itemize}
|
|
|
|
\item Change the IP address of the router to 192.168.1.1.
|
|
|
|
\item Change the IP address of a desktop GNU/Linux system to 192.168.1.2.
|
|
|
|
\item Power on the router while holding the reset button for 7 seconds.
|
|
|
|
\item Use the {\tt netcat} command (as below) on the desktop, and press
|
|
enter to receive U-Boot's prompt:
|
|
|
|
\lstset{tabsize=2}
|
|
\begin{lstlisting}[language=bash]
|
|
$ nc -u -p 6666 192.168.1.1 6666
|
|
uboot>
|
|
\end{lstlisting}
|
|
\end{itemize}
|
|
\end{quotation}
|
|
|
|
Upon following this procedure, the investigator was able to confirm the
|
|
(original) shipped version of U-Boot was still installed:
|
|
\begin{lstlisting}[language=bash]
|
|
$ nc -u -p 6666 192.168.1.1 6666
|
|
uboot> version
|
|
U-Boot 1.1.4 (Jul 28 2014)
|
|
\end{lstlisting}
|
|
|
|
Thereafter, the investigator followed the instructions from
|
|
``u-boot\verb0_0reflash''. Specifically, the investigator configured a TFTP server
|
|
and placed the newly built firmware into \texttt{/srv/tftp}. The investigator
|
|
also followed the remaining instructions in ``u-boot\verb0_0reflash'', but
|
|
used the \texttt{netcat} console rather than the serial console, and
|
|
used U-Boot's \texttt{reset} command to reboot the router.
|
|
|
|
Upon reboot, the serial console (still connect with working output) showed
|
|
the message \texttt{U-Boot 1.1.4 (Oct 17 2014)}, and thus confirmed a
|
|
successful reflash of the U-Boot image built by the investigator.
|
|
|
|
\section{Firmware Comparison}
|
|
|
|
Next, to ensure the CCS did indeed correspond to the firmware original
|
|
installed on the TPE-NWIFIROUTER, the investigator compared the built
|
|
firmware image with the filesystem originally found on the device itself.
|
|
The comparison steps were as follows:
|
|
|
|
\begin{enumerate}
|
|
|
|
\item Extract the filesystem from the image we built by running
|
|
\href{https://gitorious.org/copyleft-org/gpl-compliance-scripts/source/master:find-firmware.pl}{find-firmware.pl}
|
|
on ``bin/ar71xx/librecmc-ar71xx-generic-tl-wr841n-v8-squashfs-factory.bin''
|
|
and then running
|
|
\href{http://www.binaryanalysis.org/en/content/show/download}{bat-extratools}'
|
|
``squashfs4.2/squashfs-tools/bat-unsquashfs42'' on the resulting
|
|
morx0.squash, using the filesystem in the new squashfs-root directory for
|
|
comparison.
|
|
|
|
\item Login to the router's web interface (at \url{http://192.168.10.1/ }) from a computer
|
|
connected to the router.
|
|
|
|
\item Set a password using the provided link at the top (since the router's
|
|
UI warns that no password is set and asks the user to change it).
|
|
|
|
\item Logged into the router via SSH, using the root user with the
|
|
aforementioned password.
|
|
|
|
\item Compared representative directory listings and binaries to ensure the set of
|
|
included files (on the router) is similar to those found in the firmware
|
|
image that the investigator created (whose contents are now in the local squashfs-root directory). In
|
|
particular, the investigator did the following comparisons:
|
|
|
|
\begin{enumerate}
|
|
\item Listed the /bin folder (``ls -l /bin'') and confirm the list of files is the same
|
|
and that the file sizes are similar.
|
|
|
|
\item Checked the ``strings'' output of ``/bin/busybox'' to confirm it is 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.)
|
|
\item Repeated the above two steps for ``/lib/modules'', ``/usr/bin'', and other directories with
|
|
a significant number of binaries.
|
|
|
|
\item Checked that the kernel was sufficiently similar. The investigator
|
|
compared the ``dmesg'' output both before and after flashing the new
|
|
firmware. As the investigator expected, the kernel version string was
|
|
similar, but had a different build date and user@host indicator. (The
|
|
kernel binary itself is not easily accessible from an SSH login, but was
|
|
retrievable using the U-Boot console (the start address of the kernel in
|
|
flash appears to be 0x9F020000, based on the boot messages seen in the
|
|
serial console).
|
|
\end{enumerate}
|
|
\end{enumerate}
|
|
|
|
\section{Minor Annoyances}
|
|
|
|
As discussed in detail above, there were a few minor annoyances, none of
|
|
which were GPL violations. Rather, the annoyances briefly impeded the
|
|
build and installation. However, the investigator, as a reasonably skilled
|
|
build engineer for embedded devices, was able to complete the process with
|
|
the instructions provided.
|
|
|
|
To summarize, no GPL compliance issues were found, and the CCS release was
|
|
one of the best ever reviewed by any investigator at any community-oriented
|
|
enforcement organization. However, the following annoyances were discovered:
|
|
|
|
\begin{itemize}
|
|
\item Failure to explain how to extract the source tarball and then where to run the
|
|
``make'' command.
|
|
\item Failure to explain how to install the kernel and root filesystem on the
|
|
device; the user must assume the web UI must be used.
|
|
|
|
\item Including pre-built toolchain binaries that don't work on all systems,
|
|
and failure to copy and/or symlink built toolchain binaries in the right location.
|
|
|
|
\item Failure to include information in the U-Boot installation instructions for
|
|
wiring the serial cable.
|
|
|
|
\item Ideally, the U-Boot installation instructions would also include the
|
|
{\tt netcat} method of installation.
|
|
|
|
\item Finally, the instructions should note that the new U-Boot firmware
|
|
should be placed into \texttt{/srv/tftp} when using TFTP on most GNU/Linux
|
|
desktops.
|
|
\end{itemize}
|
|
|
|
Thus, no CCS is absolutely perfect, but GPL violation investigators always
|
|
give the distributors the benefit of any doubts and seek to work with the
|
|
vendors and improve their CCS for the betterment of their users, customers,
|
|
and the entire software freedom community.
|
|
|
|
\section{Lessons Learned}
|
|
|
|
Companies that seek to redistribute copylefted software can benefit greatly
|
|
from ThinkPenguin's example. Here are just a few of the many lessons that
|
|
can be learned here:
|
|
|
|
\begin{enumerate}
|
|
|
|
\item Even though copyleft licenses have them,
|
|
\hyperref[thinkpenguin-included-ccs]{\bf avoid the offer-for-source
|
|
provisions}. Not only does including the CCS alongside binary
|
|
distribution make violation investigation and compliance confirmation
|
|
substantially easier, but also (and more importantly) doing so
|
|
\hyperref[offer-for-source]{completes the distributor's CCS compliance
|
|
obligations at the time of distribution} (provided, of course, that the
|
|
distributor is otherwise in compliance with the relevant copyleft license).
|
|
|
|
\item {\bf Include top-level build instructions in a natural language (such
|
|
as English) in a \hyperref[thinkpenguin-toplevel-readme]{clear and
|
|
conspicuous place}.} Copyleft licenses require that someone reasonably
|
|
skilled in the art can reproduce the build and installation. Typically,
|
|
instructions written in English are necessary, and often easier than writing
|
|
programmed scripts. The ``script'' included can
|
|
certainly be more like the script of a play and less like a Bash script.
|
|
|
|
\item {\bf Write build/install instructions to the appropriate level of
|
|
specificity}. The upstream engineers
|
|
in this case study \hyperref[thinkpenguin-specific-host-system]{clearly did
|
|
additional work to ensure functionality on a wide variety of host build
|
|
systems}; this is quite rare. When in doubt, include the maximum level
|
|
of detail build engineers can provide with the CCS instructions, but also
|
|
double-check to investigate if a more generalized solution (such as other
|
|
host systems) work just as well for the build.
|
|
|
|
\item {\bf Seek to adhere to the spirit of copyleft, not just the letter of
|
|
the license}. Encouragement of users to improve and
|
|
make their devices better is one of ThinkPenguin's commercial differentiators. Copyleft advocates
|
|
that other companies have undervalued the large and lucrative
|
|
market of
|
|
users who seek hackable devices. By going beyond the
|
|
mere minimal requirements of GPL, companies can immediately reap the
|
|
benefits in that target market.
|
|
|
|
\item Community-oriented enforcement organizations do not play ``gotcha''\footnote{For lack of a better
|
|
phrase.} with distributors regarding GPL
|
|
violations. The goal in the GPL enforcement process is to achieve
|
|
compliance and correct mistakes and annoyances. Such organizations
|
|
therefore take an ``innocent until proven guilty $\rightarrow$ assume guilty
|
|
due to honest error rather than malicious action '' approach. The goal
|
|
is compliance (in direct contrast with
|
|
the \hyperref[Proprietary Relicensing]{discussion in \S~\ref*{Proprietary Relicensing} about the
|
|
proprietary relicensing} business model).
|
|
|
|
\end{enumerate}
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\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}
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
% 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 Gingerich Michlmayr LGPL
|
|
% LocalWords: Slashdot sublicensed Vigorien Vigorien's Haxil Polgara GPL'd
|
|
% LocalWords: Thesulac Polgara's Haxil's Thesulac's SDK CD's tpb CCS RYF cd
|
|
%% LocalWords: ThinkPenguin TPE NWIFIROUTER Unboxing copylefted GPLv mkdir
|
|
%% LocalWords: Filesystem libreCMC README tabsize libCMC sudo reflash gcc
|
|
%% LocalWords: binutils bzip perl getopt libz dev libc menuconfig amd dpkg
|
|
%% LocalWords: toolchain filesystem thinkpenguin egrep posix jxpf ar UI ln
|
|
%% LocalWords: ThinkPenguin's versioned bootloader SRC mips librecmc linux
|
|
%% LocalWords: uclibc symlink tl wr squashfs sysupgrade preinstalled TFTP
|
|
%% LocalWords: busybox tftp hpa IP RJ UART PuTTY ipaddr serverip setenv nc
|
|
%% LocalWords: miswiring minicom startup miswire netcat uboot extratools
|
|
%% LocalWords: morx Login dmesg login ccs toplevel readme differentiators
|
|
%% LocalWords: hackable Relicensing relicensing toolkits OEM reaudited
|
|
%% LocalWords: redistributor cryptographic
|