@@ -732,192 +732,197 @@ Linux. A decade later, this situation remains largely unresolved.
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: expand title, etc.
\chapter{ThinkPengiun Wireless Router: A study in Excellent CCS}
% FIXME
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 ThinkPengiun. 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.
% 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.
* Since the instructions didn't mention a specific distro to use, we ran the
build on an amd64 Debian 6 machine we had, after confirming the packages were
installed. In particular, we ran "make", as described in the instructions in
the README. The instructions said that "make menuconfig" could be used to
adjust the settings, but it appeared this step was optional ("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.") so we chose to
skip straight to the "make" step instead. This was done after extracting the
librecmc-v1.2.1.tar.bz2 tarball, which was not explicitly spelled out (this
should ideally be added to the README), but was implied by the
"u-boot_reflash" file (in the same directory as the README), which explicitly
used the other tarball. The build took about 40 minutes to run on our system.
* 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.
* The "make" step completed successfully on our system and resulted in several
files being generated in the bin/ar71xx directory, namely firmware images.
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.
* 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{U-Boot Compilation}
* As mentioned above, we also found a "u-boot_reflash" 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_SRC" 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_2.14' not found (required by mips-librecmc-linux-uclibc-gcc.bin)
* 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_dir/toolchain-mips_34kc_gcc-4.6-linaro_uClibc-0.9.33.2/bin
* 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.
\section{Installation}
% FIXME: add more details once install tests have been completed
\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.
% 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.