Changeset - 929f60c316d5
[Not reviewed]
0 1 0
Bradley Kuhn (bkuhn) - 10 years ago 2014-03-21 16:54:26
bkuhn@ebb.org
Wordsmith this paragraph
1 file changed with 4 insertions and 4 deletions:
0 comments (0 inline, 0 general)
compliance-guide.tex
Show inline comments
...
 
@@ -90,53 +90,53 @@ 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
 
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 are often caused or compounded by a failure to adopt sound
 
practices for the incorporation of GPL'd components into a company's
 
internal development environment.  In this section, we introduce some best
 
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.  We suggest companies
 
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,
 
  GPLv3, LGPLv2, and LGPLv3.  Advice on avoiding the most common
 
  errors differs little for compliance with these four licenses.
 
  \S~\ref{lgpl} discusses the key differences between GPL and LGPL
 
  compliance.}
 

	
 
\section{Evaluate License Applicability}
 
\label{derivative-works}
 
Political discussion about the GPL often centers around the ``copyleft''
 
requirements of the license.  Indeed, the license was designed primarily
 
to embody this licensing feature.  Most companies adding non-trivial
 
features (beyond mere porting and bug-fixing) to GPL'd software, and
 
thereby implicating these requirements, are already well aware of their
 
more complex obligations under the license.\footnote{There has been much legal
 
  discussion regarding copyleft and derivative works.  In practical
 
  reality, this issue is not relevant to the vast majority of companies
 
  distributing GPL'd software.}
 

	
 
However, in our experience with GPL enforcement, few redistributors'
 
compliance challenges relate directly to the copyleft provisions; this is
 
doubly true for most embedders.  Instead, the distributions of GPL'd
 
systems that we encounter typically consist of a full operating system
 
including components under the GPL (e.g., Linux, BusyBox) and components
0 comments (0 inline, 0 general)