Changeset - 0bbf9ec882d0
[Not reviewed]
0 2 0
Martin Michlmayr (tbm) - 10 years ago 2014-04-24 23:12:21
tbm@cyrius.com
Misc copy editing
2 files changed with 21 insertions and 21 deletions:
0 comments (0 inline, 0 general)
compliance-guide.tex
Show inline comments
...
 
@@ -63,57 +63,57 @@ violations were pursued this way until the early 2000's.
 
By that time, Linux-based systems such as GNU/Linux and BusyBox/Linux had become very common, particularly in
 
embedded devices such as wireless routers.  During this period, public
 
ridicule of violators in the press and on Internet fora supplemented
 
ongoing private enforcement and increased pressure on businesses to
 
comply.  In 2003, the FSF formalized its efforts into the GPL Compliance
 
Lab, increased the volume of enforcement, and built community coalitions
 
to encourage copyright holders to together settle amicably with violators.
 
Beginning in 2004, Harald Welte took a more organized public enforcement
 
approach and launched \verb0gpl-violations.org0, a website and mailing
 
list for collecting reports of GPL violations.  On the basis of these
 
reports, Welte successfully pursued many enforcements in Europe, including
 
formal legal action.  Harald earns the permanent fame as the first copyright
 
holder to bring legal action in a Court regarding GPL compliance. 
 
holder to bring legal action in a court regarding GPL compliance.
 

	
 
In 2007, two copyright holders in BusyBox, in conjunction with the
 
Software Freedom Conservancy (``Conservancy''), filed the first copyright infringement lawsuit
 
based on a violation of the GPL\@ in the USA. While  lawsuits are of course
 
quite public, the vast majority of Conservancy's enforcement actions 
 
are resolved privately via
 
cooperative communications with violators.  As both FSF and Conservancy has worked to bring
 
cooperative communications with violators.  As both FSF and Conservancy have worked to bring
 
individual companies into compliance, both organizations have encountered numerous
 
violations resulting from preventable problems such as inadequate
 
attention to licensing of upstream software, misconceptions about the
 
GPL's terms, and poor communication between software developers and their
 
management.  This document highlights these problems and describe
 
best practices to encourage corporate Free Software users to reevaluate their
 
approach to GPL'd software and avoid future violations.
 

	
 
Both FSF and Conservancy continue GPL enforcement and compliance efforts
 
for software under the GPL, the GNU Lesser
 
Public License (LGPL) and other copyleft licenses.  In doing so, both organizations have
 
found that most violations stem from a few common mistakes that can be,
 
for the most part, easily avoided.  All copyleft advocates  hope to educate the community of
 
commercial distributors, redistributors, and resellers on how to avoid
 
violations in the first place, and to respond adequately and appropriately
 
when a violation occurs.
 

	
 
\chapter{Best Practices to Avoid Common Violations}
 
\label{best-practices}
 

	
 
Unlike highly permissive licenses (such as the ISC license), which
 
typically only require preservation of copyright notices, licensees face many
 
important requirements from the GPL.  These requirements are
 
carefully designed to uphold certain values and standards of the software
 
freedom community.  While the GPL's requirements may appear initially
 
freedom community.  While the GPL's requirements may initially appear
 
counter-intuitive to those more familiar with proprietary software
 
licenses, by comparison, its terms are in fact clear and quite favorable to
 
licensees.  Indeed, the GPL's terms actually simplify compliance when
 
violations occur.
 

	
 
GPL violations occur (or, are compounded) most often when companies lack sound
 
practices for the incorporation of GPL'd components into their
 
internal development environment.  This section introduces some best
 
practices for software tool selection, integration and distribution,
 
inspired by and congruent with software freedom methodologies.  Companies should
 
establish such practices before building a product based on GPL'd
 
software.\footnote{This document addresses compliance with GPLv2,
...
 
@@ -146,25 +146,25 @@ under the LGPL (e.g., the GNU C Library).  Sometimes, these programs have
 
been patched or slightly improved by direct modification of their sources,
 
resulting unequivocally in a derivative work.  Alongside these programs,
 
companies often distribute fully independent, proprietary programs,
 
developed from scratch, which are designed to run on the Free Software operating
 
system but do not combine with, link to, modify, derive from, or otherwise
 
create a combined work with
 
the GPL'd components.\footnote{However, these programs do often combine
 
  with LGPL'd libraries. This is discussed in detail in \S~\ref{lgpl}.}
 
In the latter case, where the work is unquestionably a separate work of
 
creative expression, no copyleft provisions are invoked.
 

	
 
Admittedly, a tiny
 
minority of situations which lie outside these two categories, and thus
 
minority of situations lie outside these two categories, and thus
 
do involve close questions about derivative and combined works.  Those
 
situations admittedly do require a highly
 
fact-dependent analysis and cannot be addressed in a general-purpose
 
document, anyway.
 

	
 
\medskip
 

	
 
Most companies accused of violations lack a basic understanding
 
of how to comply even in the former straightforward scenario.  This document
 
provides those companies with the fundamental and generally applicable prerequisite knowledge.
 
For answers to rarer and more complicated legal questions, such as whether
 
your software is a derivative or combined work of some copylefted software, consult
...
 
@@ -205,65 +205,65 @@ arrangement and management/legal oversight before the developers
 
incorporate the software.  By contrast, developers often obtain and
 
integrate Free Software without intervention nor oversight. That ease of acquisition, however,
 
does not mean the oversight is any less necessary.  Just as your legal
 
and/or management team negotiates terms for inclusion of any proprietary
 
software, they should gently facilitate all decisions to bring Free Software into your
 
product.
 

	
 
Simple, engineering-oriented rules help provide a stable foundation for
 
Free Software integration.  For example, simply ask your software developers to send an email to a
 
standard place describing each new Free Software component they add to the system,
 
and have them include a brief description of how they will incorporate it
 
into the product.  Further, make sure developers use a revision control
 
system (such as Git or Mercurial), and have
 
system (such as Git or Mercurial), and
 
store the upstream versions of all software in a ``vendor branch'' or
 
similar mechanism, whereby they can easily track and find the main version
 
of the software and, separately, any local changes.
 

	
 
Such procedures are best instituted at your project's launch.  Once 
 
chaotic and poorly-sourced development processes begin, cataloging the
 
presence of GPL'd components  becomes challenging.
 

	
 
Such a situation often requires use of a tool to ``catch up'' your knowledge
 
about what software your product includes.  Most commonly, companies choose
 
some software licensing scanning tool to inspect the codebase.  However,
 
there are few tools that are themselves Free Software.  Thus, GPL enforcers
 
usually recommend the GPL'd
 
\href{http://fossology.org/}{Fossology system}, which analyzes a
 
\href{http://fossology.org/}{FOSSology system}, which analyzes a
 
source code base and produces a list of Free Software licenses that may apply to
 
the code.  Fossology can help you build a catalog of the sources you have
 
the code.  FOSSology can help you build a catalog of the sources you have
 
already used to build your product.  You can then expand that into a more
 
structured inventory and process.
 

	
 
\section{Track Your Changes and Releases}
 

	
 
As explained in further detail below, the most important component of GPL
 
compliance is the one most often ignored: proper inclusion of CCS in all
 
distributions  of GPL'd
 
software.  To comply with GPL's CCS requirements, the distributor
 
\textit{must} always know precisely what sources generated a given binary
 
distribution.
 

	
 
In an unfortunately large number of our enforcement cases, the violating
 
company's engineering team had difficulty reconstructing the CCS
 
for binaries distributed by the company.  Here are three simple rules to
 
follow to decrease the likelihood of this occurrence:
 

	
 
\begin{itemize}
 

	
 
\item Ensure that your
 
developers are using revision control systems properly.
 

	
 
\item Have developers mark or ``tag'' the full source tree corresponding to
 
  builds distributed to customers
 
  builds distributed to customers.
 

	
 
\item Check that your developers store all parts of the software
 
development in the revision control system, including {\sc readme}s, build
 
scripts, engineers' notes, and documentation.
 
\end{itemize}
 

	
 
Your developers will benefit anyway from these rules.  Developers will be
 
happier in their jobs if their tools already track the precise version of
 
source that corresponds to any deployed binary.
 

	
 
\section{Avoid the ``Build Guru''}
 

	
...
 
@@ -501,38 +501,38 @@ code from us for a period of three years after our last shipment of this
 
product and/or spare parts therefor, which will be no earlier than
 
2011-08-01, on our website at
 
\verb0http://www.example.com/sources/productnum/0.
 
\end{quote}
 

	
 
\medskip
 

	
 
Under both GPLv2 and GPLv3, source offers must be accompanied by a copy of
 
the license itself, either electronically or in print, with every
 
distribution.
 
 
 
Finally, it is unacceptable to use option (b) merely because you do not have
 
Corresponding Source ready.  We find that some companies chose this option
 
Corresponding Source ready.  We find that some companies choose this option
 
because writing an offer is easy, but producing a source distribution as
 
an afterthought to a hasty development process is difficult.  The offer
 
for source does not exist as a stop-gap solution for companies rushing to
 
market with an out-of-compliance product.  If you ship an offer for source
 
with your product but cannot actually deliver \emph{immediately} on that
 
offer when your customers receive it, you should expect an enforcement
 
offer when your customers request it, you should expect an enforcement
 
action.
 

	
 
\subsection{Option (c): Noncommercial Offers}
 

	
 
As discussed in the last section, GPLv2~\S~3(c) and GPLv3~\S~6(c) apply
 
only to noncommercial use.  These options are not available to businesses
 
distributing GPL'd software.  Consequently, companies who redistribute
 
distributing GPL'd software.  Consequently, companies that redistribute
 
software packaged for them by an upstream vendor cannot merely pass along
 
the offer they received from the vendor; they must provide their own offer
 
or corresponding source to their distributees.  We talk in detail about
 
upstream software providers in \S~\ref{upstream}.
 

	
 
\subsection{Option 6(d) in GPLv3: Internet Distribution}
 

	
 
Under GPLv2, your formal provisioning options for Corresponding Source
 
ended with \S~3(c).  But even under GPLv2, pure Internet source
 
distribution was a common practice and generally considered to be
 
compliant.  GPLv2 mentions Internet-only distribution almost as aside in
 
the language, in text at the end of the section after the three
...
 
@@ -744,39 +744,39 @@ generalizations and do not all apply to every alleged violation.
 
\section{Understanding Who's Enforcing}
 
\label{compliance-understanding-whos-enforcing}
 
% FIXME-LATER: this text needs work.
 

	
 
Both  FSF and Conservancy has, as part their mission,  to spread software
 
freedom. When FSF or Conservancy
 
enforces GPL, the goal is to bring the violator back into compliance as
 
quickly as possible, and redress the damage caused by the violation.
 
That is FSF's steadfast position in a violation negotiation --- comply
 
with the license and respect freedom.
 

	
 
However, other entities who do not share the full ethos of software freedom
 
as institutionalized by FSF pursue GPL violations differently.  Oracle, a
 
as institutionalized by FSF and Conservancy pursue GPL violations differently.  Oracle, a
 
company that produces the GPL'd MySQL database, upon discovering GPL
 
violations typically negotiates a proprietary software license separately for
 
a fee.  While this practice is not one that FSF nor Conservancy would ever
 
consider undertaking or even endorsing, it is a legally way for copyright
 
consider undertaking or even endorsing, it is a legal way for copyright
 
holders to proceed.
 

	
 
Generally, GPL enforcers come in two varieties.  First, there are
 
Conservancy, FSF, and other ``community enforcers'', who primary seek the
 
Conservancy, FSF, and other ``community enforcers'', who primarily seek the
 
policy goals of GPL (software freedom), and see financial compensation as
 
ultimately secondary to those goals.  Second, there are ``for-profit
 
enforcers'' who use the GPL as a either a crippleware license, or sneakily
 
enforcers'' who use the GPL either as a crippleware license, or sneakily
 
induce infringement merely to gain proprietary licensing revenue.
 

	
 
Note that the latter model \textit{only} works for companies who hold 100\% of
 
Note that the latter model \textit{only} works for companies that hold 100\% of
 
the copyrights in the infringed work.  As such, multi-copyright-held works
 
are fully insulated from these tactics.
 

	
 

	
 
\section{Communication Is Key}
 

	
 
GPL violations are typically only escalated when a company ignores the
 
copyright holder's initial communication or fails to work toward timely
 
compliance.  Accused violators should respond very promptly to the
 
initial request.  As the process continues, violators should follow up weekly with the
 
copyright holders to make sure everyone agrees on targets and deadlines
 
for resolving the situation.
...
 
@@ -956,25 +956,25 @@ Therefore, you should introduce a due diligence process into your software
 
acquisition plans.  This is much like the software-oriented
 
recommendations we make in \S~\ref{best-practices}.  Implementing
 
practices to ensure that you are aware of what software is in your devices
 
can only improve your general business processes.  You should ask a clear
 
list of questions of all your upstream providers and make sure the answers
 
are complete and accurate.  The following are examples of questions you
 
should ask:
 
\begin{itemize}
 

	
 
\item What are all the licenses that cover the software in this device?
 

	
 
\item From which upstream vendors, be they companies or individuals, did
 
  \emph{you} receive your software from before distributing it to us?
 
  \emph{you} receive your software before distributing it to us?
 

	
 
\item What are your GPL compliance procedures?
 

	
 
\item If there is GPL'd software in your distribution, we will be
 
  redistributors of this GPL'd software.  What mechanisms do you have in
 
  place to aid us with compliance?
 

	
 
\item If we follow your recommended compliance procedures, will you
 
  formally indemnify us in case we are nonetheless found to be in
 
  violation of the GPL?
 

	
 
\end{itemize}
...
 
@@ -1053,14 +1053,14 @@ that allows them to associate versions of source with distributed
 
binaries, have a well-documented build process that anyone skilled in the
 
art can understand, and inform the lawyers when they bring in new
 
software.  Managers should build systems and procedures that keep everyone
 
on target.  With these practices in place, any organization can comply
 
with the GPL without serious effort, and receive the substantial benefits
 
of good citizenship in the software freedom community, and lots of great code
 
ready-made for their products.
 

	
 
\vfill
 

	
 
% LocalWords:  redistributors NeXT's Slashdot Welte gpl ISC embedders BusyBox
 
% LocalWords:  someone's downloadable subdirectory subdirectories filesystem
 
% LocalWords:  roadmap README upstream's Ravicher's Fossology readme CDs iPhone
 
% LocalWords:  roadmap README upstream's Ravicher's FOSSology readme CDs iPhone
 
% LocalWords:  makefiles violator's
enforcement-case-studies.tex
Show inline comments
...
 
@@ -113,25 +113,25 @@ 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
 
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
...
 
@@ -328,25 +328,25 @@ Finally, a GPL Compliance Officer inside Bortez was appointed to take
 
responsibility for all matters of GPL compliance inside the company.
 
Darvik 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 Darvik'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 who distribute GPL'd software do so in compliance, and at
 
  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.}
...
 
@@ -627,25 +627,25 @@ did so, and the violation was resolved.
 
  derivative works, 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
 
  whole is indeed a derivative work of a GPL'd program.
 
  a whole is indeed a derivative work 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.}
0 comments (0 inline, 0 general)