% compliance-guide.tex                            -*- LaTeX -*-

\part{A Practical Guide to GPL Compliance}

\label{gpl-compliance-guide}

{\parindent 0in

This part is: \\

\begin{tabbing}

Copyright \= \copyright{} 2014 \= \hspace{.2in} Bradley M. Kuhn. \\

Copyright \> \copyright{} 2008 \> \hspace{.2in} Software Freedom Law Center. \\

\end{tabbing}

\vspace{1in}

\begin{center}

Authors of this part are: \\

Bradley M. Kuhn \\

Aaron Williamson \\

Karen M. Sandler \\

\vspace{1in}

Copy editors of this part include: \\

Martin Michlmayr

\vspace{3in}

The copyright holders of this part hereby grant the freedom to copy, modify,

convey, Adapt, and/or redistribute this work under the terms of the Creative

Commons Attribution Share Alike 4.0 International License.  A copy of that

license is available at

\verb=https://creativecommons.org/licenses/by-sa/4.0/legalcode=. 

\end{center}

}

\bigskip

\chapter*{Executive Summary}

This is a guide to effective compliance with the GNU General Public

License (GPL) and related licenses.  Copyleft advocates

usually seek to assist the community with

GPL compliance cooperatively.   This guide focuses on complying from the

start, so that readers can learn to avoid enforcement actions entirely, or, at

least, minimize  the negative impact when enforcement actions occur.

This guide  introduces and explains basic legal concepts related to the GPL and its

enforcement by copyright holders. It also outlines business practices and

methods that lead to better GPL compliance.  Finally, it recommends proper

post-violation responses to the concerns of copyright holders.

\chapter{Background}

Early GPL enforcement efforts began soon after the GPL was written by

Richard M.~Stallman (RMS) in 1989, and consisted of informal community efforts,

often in public Usenet discussions.\footnote{One example is the public

  outcry over NeXT's attempt to make the Objective-C front-end to GCC

  proprietary.  RMS, in fact, handled this enforcement action personally and

  the Objective-C front-end is still part of upstream GCC today.}  Over the next decade, the Free Software Foundation (FSF),

which holds copyrights in many GNU programs, was the only visible entity

actively enforcing its GPL'd copyrights on behalf of the software freedom

community.

FSF's enforcement

was generally a private process; the FSF contacted violators

confidentially and helped them to comply with the license.  Most

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.

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 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, avoidable mistakes.  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 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,

  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 invoking 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.  Those interested in this issue should study

  \tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related

      Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of

    this tutorial}.}

However, experienced  GPL enforcers find that few redistributors'

compliance challenges relate directly to combined work issues in copyleft.

Instead, the distributions of GPL'd

systems most often encountered typically consist of a full operating system

including components under the GPL (e.g., Linux, BusyBox) and components

under the LGPL (e.g., the GNU C Library).  Sometimes, these programs have

been patched or slightly improved by direct modification of their sources,

and thus the result is unequivocally a modified version.  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.

The core compliance issue faced, thus, in such a situation, is not an discussion of what is or is not a

combined, derivative, and/or modified version of the work, but rather, issues related to distribution and

conveyance of binary works based on GPL'd source, but without Complete,

Corresponding Source.  This tutorial therefore focuses primarily on that issue.

Admittedly, a tiny

minority of compliance situations relate to question of derivative,

combined, or modified versions of the work.  Those

situations are so rare, and the details from situation to situation differ

greatly.  Thus, such situations require a highly

fact-dependent analysis and cannot be addressed in a general-purpose

document such as this one.

\medskip

Most companies accused of violations lack a basic understanding

of how to comply even in the 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

with an attorney.\footnote{If you would like more information on the

  application of derivative works doctrine to software, a detailed legal

  discussion is presented in our colleague Dan Ravicher's article,

  \textit{Software Derivative Work: A Circuit Dependent Determination} and in

  \tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related

      Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of

    this tutorial}.}

This discussion thus assumes that you have already identified the

``work'' covered by the license, and that any components not under the GPL

(e.g., applications written entirely by your developers that merely happen

to run on a Linux-based operating system) distributed in conjunction with

those works are separate works within the meaning of copyright law and the GPL\@.  In

such a case, the GPL requires you to provide complete corresponding

source (CCS)\footnote{For more on CCS,  see

\tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related

      Licenses}'s Section on GPLv2~\S2 and GPLv3~\S1.}{\S~\ref{GPLv2s2} and \S~\ref{GPLv3s1} of

    this tutorial}.}

for the GPL'd components and your modifications thereto, but not

for independent proprietary applications.  The procedures described in

this document address this typical scenario.

\section{Monitor Software Acquisition}

Software engineers deserve the freedom to innovate and import useful

software components to improve products.  However, along with that

freedom should come rules and reporting procedures to make sure that you

are aware of what software that you include with your product.

The most typical response to an initial enforcement action is: ``We

didn't know there was GPL'd stuff in there''.  This answer indicates

failure in the software acquisition and procurement process.  Integration

of third-party proprietary software typically requires a formal

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

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

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

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

% comprehensive-gpl-guide.tex                                    -*- LaTeX -*-

%

% Toplevel file to build the entire book.

\documentclass[10pt, letterpaper, openany, oneside]{book}

% I'm somewhat convinced that this book would be better formatted using

%  the memoir class :

%    http://www.ctan.org/pkg/memoir

%   http://mirror.unl.edu/ctan/macros/latex/contrib/memoir/memman.pdf

% For the moment, I've thrown in fancychap because I don't have time to

% research memoir.

\usepackage{hyperref}

\usepackage{enumerate}

\usepackage[Conny]{fncychap}

\usepackage[dvips]{graphicx}

\usepackage[verbose, twoside, dvips,

              paperwidth=8.5in, paperheight=11in,

              left=1in, right=1in, top=1.25in, bottom=.75in,

           ]{geometry}

\newcommand{\tutorialpartsplit}[2]{#2}

%\input{no-numbers-on-table-of-contents}

\begin{document}

\pagestyle{plain}

\pagenumbering{roman}

\frontmatter

\begin{titlepage}

\begin{center}

{\Huge

{\sc Copyleft and the  \\

GNU General Public License:

\vspace{.25in}

A Comprehensive Tutorial

}}

\vfill

{\parindent 0in

\begin{tabbing}

Copyright \= \copyright{} 2003--2007 \hspace{1.mm} \=  \kill

Copyright \> \copyright{} 2014 \>  Bradley M. Kuhn. \\

Copyright \> \copyright{} 2014 \>  Anthony K. Sebro, Jr. \\

Copyright \> \copyright{} 2008 \>  Software Freedom Law Center. \\

\end{tabbing}

\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}.

Each part of this book, except the appendix, is separately under this same

license, but copyrighted by different entities at different times.  Each part

therefore also contains its own copyright and licensing notice.  The notice

above is for the entire work, and includes the full copyright and licensing

details, except for the appendix.

Since the appendix includes copies of the texts of various licenses published

by FSF, and they are all licensed under the license, ``Everyone is permitted

to copy and distribute verbatim copies of this license document, but changing

it is not allowed.''.  However, those who seek to make modified versions of

those licenses should note the

\href{https://www.gnu.org/licenses/gpl-faq.html#ModifyGPL}{explanation given in the GPL FAQ}.

\vfill

Patches are welcome to this material.  Sources can be found in the Git

repository at: \url{https://gitorious.org/gpl-compliance-tools/tutorial/}

}

\end{center}

\end{titlepage}

\tableofcontents

\chapter{Preface}

This tutorial is the culmination of nearly a decade of studying and writing

about software freedom licensing and the GPL\@.  Each part of this tutorial

is a course unto itself, educating the reader on a myriad of topics from the

deep details of the GPLv2 and GPLv3, common business models in the copyleft

licensing area (both the friendly and unfriendly kind), best practices for

compliance with the GPL, for engineers, managers, and lawyers, as well as

real-world case studies of GPL enforcement matters.

It is unlikely that all the information herein is necessary to learn all at

once, and therefore this tutorial likely serves best as a reference book.

The material herein has been used as the basis for numerous live tutorials

and discussion groups since 2002, and the materials have been periodically

updated.   They likely stand on their own as excellent reference material.

However, if you are reading these course materials without attending a live

tutorial session, please note that this material is merely a summary of the

highlights of the various CLE and other tutorial courses based on this

material.  Please be aware that during the actual courses, class discussion

and presentation supplements this printed curriculum.  Simply reading this

material is \textbf{not an equivalent} for attending a course.

\mainmatter

\input{gpl-lgpl}

\input{compliance-guide}

\input{enforcement-case-studies}

\appendix

\input{license-texts}

\end{document}

%      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}

\end{tabbing}

\vspace{1in}

\begin{center}

Authors of this part are: \\

Bradley M. Kuhn \\

John Sullivan

\vspace{3in}

Copy editors of this part include: \\

Martin Michlmayr

\vspace{3in}

The copyright holders hereby grant the freedom to copy, modify, convey,

Adapt, and/or redistribute this work under the terms of the Creative Commons

Attribution Share Alike 4.0 International License.  A copy of that license is

available at \verb=https://creativecommons.org/licenses/by-sa/4.0/legalcode=.

\end{center}

}

% =====================================================================

% START OF SECOND DAY SEMINAR SECTION

% =====================================================================

\chapter*{Preface}

This one-day course presents the details of five different GPL

compliance cases handled by FSF's GPL Compliance Laboratory. Each case

offers unique insights into problems that can arise when the terms of

the GPL are not properly followed, and how diplomatic negotiation between

the violator and the copyright holder can yield positive results for

both parties.

Attendees should have successfully completely the course, a ``Detailed

Study and Analysis of the GPL and LGPL,'' as the material from that

course forms the building blocks for this material.

This course is of most interest to lawyers who have clients or

employers that deal with Free Software on a regular basis. However,

technical managers and executives whose businesses use or distribute

Free Software will also find the course very helpful.

\bigskip

These course materials are merely a summary of the highlights of the

course presented. Please be aware that during the actual GPL course, class

discussion supplements this printed curriculum. Simply reading it is

not equivalent to attending the course.

%FIXME-LATER: write these

%\chapter{Not All GPL Enforcement is Created Equal}

%\section{For-Profit Enforcement}

%\section{Community and Non-Profit Enforcement}

\chapter{Overview of Community Enforcement}

The GPL is a Free Software license with legal teeth. Unlike licenses like

the X11-style or various BSD licenses, the GPL (and by extension, the LGPL) is

designed to defend as well as grant freedom. We saw in the last course

that the GPL uses copyright law as a mechanism to grant all the key freedoms

essential in Free Software, but also to ensure that those freedoms

propagate throughout the distribution chain of the software.

\section{Termination Begins Enforcement}

As we have learned, the assurance that Free Software under the GPL remains

Free Software is accomplished through various terms of the GPL: \S 3 ensures

that binaries are always accompanied with source; \S 2 ensures that the

sources are adequate, complete and usable; \S 6 and \S 7 ensure that the

license of the software is always the GPL for everyone, and that no other

legal agreements or licenses trump the GPL. It is \S 4, however, that ensures

that the GPL can be enforced.

Thus, \S 4 is where we begin our discussion of GPL enforcement. This

clause is where the legal teeth of the license are rooted. As a copyright

license, the GPL governs only the activities governed by copyright law ---

copying, modifying and redistributing computer software. Unlike most

copyright licenses, the GPL gives wide grants of permission for engaging with

these activities. Such permissions continue, and all parties may exercise

them until such time as one party violates the terms of the GPL\@. At the

moment of such a violation (i.e., the engaging of copying, modifying or

redistributing in ways not permitted by the GPL) \S 4 is invoked. While other

parties may continue to operate under the GPL, the violating party loses their

rights.

Specifically, \S 4 terminates the violators' rights to continue

engaging in the permissions that are otherwise granted by the GPL\@.

Effectively, their rights revert to the copyright defaults ---

no permission is granted to copy, modify, nor redistribute the work.

Meanwhile, \S 5 points out that if the violator has no rights under

the GPL, they are prohibited by copyright law from engaging in the

activities of copying, modifying and distributing. They have lost

these rights because they have violated the GPL, and no other license

gives them permission to engage in these activities governed by copyright law.

\section{Ongoing Violations}

In conjunction with \S 4's termination of violators' rights, there is

one final industry fact added to the mix: rarely does one engage in a

single, solitary act of copying, distributing or modifying software.

Almost always, a violator will have legitimately acquired a copy of a

GPL'd program, either making modifications or not, and then begun

distributing that work. For example, the violator may have put the

software in boxes and sold them at stores. Or perhaps the software

was put up for download on the Internet. Regardless of the delivery

mechanism, violators almost always are engaged in {\em ongoing\/}

violation of the GPL\@.

In fact, when we discover a GPL violation that occurred only once --- for

example, a user group who distributed copies of a GNU/Linux system without

source at one meeting --- we rarely pursue it with a high degree of

tenacity. In our minds, such a violation is an educational problem, and

unless the user group becomes a repeat offender (as it turns out, they

never do), we simply forward along a FAQ entry that best explains how user

groups can most easily comply with the GPL, and send them on their merry way.

It is only the cases of {\em ongoing\/} GPL violation that warrant our

active attention. We vehemently pursue those cases where dozens, hundreds

or thousands of customers are receiving software that is out of

compliance, and where the company continually offers for sale (or

distributes gratis as a demo) software distributions that include GPL'd

components out of compliance. Our goal is to maximize the impact of

enforcement and educate industries who are making such a mistake on a

large scale.

In addition, such ongoing violation shows that a particular company is

committed to a GPL'd product line. We are thrilled to learn that someone

is benefiting from Free Software, and we understand that sometimes they

become confused about the rules of the road. Rather than merely

giving us a postmortem to perform on a past mistake, an ongoing violation

gives us an active opportunity to educate a new contributor to the GPL'd

commons about proper procedures to contribute to the community.

Our central goal is not, in fact, to merely clear up a particular violation.

In fact, over time, we hope that our compliance lab will be out of

business. We seek to educate the businesses that engage in commerce

related to GPL'd software to obey the rules of the road and allow them to

operate freely under them. Just as a traffic officer would not revel in

reminding people which side of the road to drive on, so we do not revel in

violations. By contrast, we revel in the successes of educating an

ongoing violator about the GPL so that GPL compliance becomes a second-nature

matter, allowing that company to join the GPL ecosystem as a contributor.

\section{How are Violations Discovered?}

Our enforcement of the GPL is not a fund-raising effort; in fact, FSF's GPL

Compliance Lab runs at a loss (in other words, it is subsided by our

donors). Our violation reports come from volunteers, who have encountered,

in their business or personal life, a device or software product that

appears to contain GPL'd software. These reports are almost always sent

via email to $<$license-violation@fsf.org$>$.

Our first order of business, upon receiving such a report, is to seek

independent confirmation. When possible, we get a copy of the software

product. For example, if it is an offering that is downloadable from a

Web site, we download it and investigate ourselves. When it is not

possible for us to actually get a copy of the software, we ask the

reporter to go through the same process we would use in examining the

software.

By rough estimation, about 95\% of violations at this stage can be

confirmed by simple commands. Almost all violators have merely made an

error and have no nefarious intentions. They have made no attempt to

remove our copyright notices from the software. Thus, given the

third-party binary, {\tt tpb}, usually, a simple command (on a GNU/Linux

system) such as the following will find a Free Software copyright notice

and GPL reference:

\begin{quotation}

{\tt strings tpb | grep Copyright}

\end{quotation}

In other words, it is usually more than trivial to confirm that GPL'd

software is included.

Once we have confirmed that a violation has indeed occurred, we must then

determine whose copyright has been violated. Contrary to popular belief,

FSF does not have the power to enforce the GPL in all cases. Since the GPL

operates under copyright law, the powers of enforcement --- to seek

redress once \S 4 has been invoked --- lie with the copyright holder of

the software. FSF is one of the largest copyright holders in the world of

GPL'd software, but we are by no means the only one. Thus, we sometimes

discover that while GPL'd code is present in the software, there is no

software copyrighted by FSF present.

In cases where FSF does not hold copyright interest in the software, but

we have confirmed a violation, we contact the copyright holders of the

software, and encourage them to enforce the GPL\@. We offer our good offices

to help negotiate compliance on their behalf, and many times, we help as a

third party to settle such GPL violations. However, what we will describe

primarily in this course is FSF's first-hand experience enforcing its own

copyrights and the GPL\@.

\section{First Contact}

The Free Software community is built on a structure of voluntary

cooperation and mutual help. Our community has learned that cooperation

works best when you assume the best of others, and only change policy,

procedures and attitudes when some specific event or occurrence indicates

that a change is necessary. We treat the process of GPL enforcement in

the same way. Our goal is to encourage violators to join the cooperative

community of software sharing, so we want to open our hand in friendship.

Therefore, once we have confirmed a violation, our first assumption is

that the violation is an oversight or otherwise a mistake due to confusion

about the terms of the license. We reach out to the violator and ask them

to work with us in a collaborative way to bring the product into

compliance. We have received the gamut of possible reactions to such

requests, and in this course, we examine four specific examples of such

compliance work.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Bortez: Modified GCC SDK}

In our first case study, we will consider Bortez, a company that

produces software and hardware toolkits to assist OEM vendors, makers

of consumer electronic devices.

\section{Facts}

One of Bortez's key products is a Software Development Kit (``SDK'')

designed to assist developers building software for a specific class of

consumer electronics devices.

FSF received a report that the SDK may be based on the GNU Compiler

Collection (which is an FSF-copyrighted collection of tools for software

development in C, C++ and other popular languages). FSF investigated the

claim, but was unable to confirm the violation. The violation reporter

was unresponsive to follow-up requests for more information.

Since FSF was unable to confirm the violation, we did not pursue it any

further. Bogus reports do happen, and we do not want to burden companies

with specious GPL violation complaints. FSF shelved the matter until

more evidence was discovered.

FSF was later able to confirm the violation when two additional reports

surfaced from other violation reporters, both of whom had used the SDK

professionally and noticed clear similarities to FSF's GNU GCC\@. FSF's

Compliance Engineer asked the reporters to run standard tests to confirm

the violation, and it was confirmed that Bortez's SDK was indeed a

modified version of GCC\@. Bortez had ported to Windows and added a number

of features, including support for a specific consumer device chipset and

additional features to aid in the linking process (``LP'') for those

specific devices. FSF explained the rights that the GPL afforded these

customers and pointed out, for example, that Bortez only needed to provide

source to those in possession of the binaries, and that the users may need

to request that source (if \S 3(b) was exercised). The violators

confirmed that such requests were not answered.

FSF brought the matter to the attention of Bortez, who immediately

escalated the matter to their attorneys. After a long negotiation,

Bortez acknowledged that their SDK was indeed a modified version of

% gpl-lgpl.tex                                                  -*- LaTeX -*-

%      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.

% FIXME-LATER: I should make a macro like the Texinfo @xref stuff for places

%      where I'm saying ``see section X in this tutorial'', so that the extra

%      verbiage isn't there in the HTML versions that I'll eventually do.

%      Maybe something like that already exists?  In the worst case, I could

%      adapt @xref from texinfo.texi for it.

\newcommand{\defn}[1]{\emph{#1}}

\part{Detailed Analysis of the GNU GPL and Related Licenses}

{\parindent 0in

\tutorialpartsplit{``Detailed Analysis of the GNU GPL and Related Licenses''}{This part} is: \\

\begin{tabbing}

Copyright \= \copyright{} 2003--2007 \hspace{.1mm} \=  \kill

Copyright \> \copyright{} 2014 \> Bradley M. Kuhn \\

Copyright \> \copyright{} 2014 \>  Anthony K. Sebro, Jr. \\

\end{tabbing}

\vspace{.3in}

\begin{center}

Authors of \tutorialpartsplit{``Detailed Analysis of the GNU GPL and Related Licenses''}{this part} are: \\

Free Software Foundation, Inc. \\

Bradley M. Kuhn \\

David ``Novalis'' Turner \\

Daniel B. Ravicher \\

Tony Sebro \\

John Sullivan

\vspace{.2in}

Copy editors of this part include: \\

Martin Michlmayr

\vspace{.2in}

The copyright holders of \tutorialpartsplit{``Detailed Analysis of the GNU GPL and Related Licenses''}{this part} hereby grant the freedom to copy, modify,

convey, Adapt, and/or redistribute this work under the terms of the Creative

Commons Attribution Share Alike 4.0 International License.  A copy of that

license is available at

\verb=https://creativecommons.org/licenses/by-sa/4.0/legalcode=.

\end{center}

}

\bigskip

\tutorialpartsplit{This tutorial}{This part of the tutorial} gives a

comprehensive explanation of the most popular Free Software copyright

license, the GNU General Public License (``GNU GPL'', or sometimes just

``GPL'') -- both version 2 (``GPLv2'') and version 3 (``GPLv3'') -- and

teaches lawyers, software developers, managers and business people how to use

the GPL (and GPL'd software) successfully both as a community-building

``Constitution'' for a software project, and to incorporate copylefted

software into a new Free Software business and in existing, successful

enterprises.

To successfully benefit from this part of the tutorial, readers should

have a general familiarity with software development processes.  A basic

understanding of how copyright law applies to software is also helpful.  The

tutorial is of most interest to lawyers, software developers and managers who

run or advise software businesses that modify and/or redistribute software

under the terms of the GNU GPL (or who wish to do so in the future), and those

who wish to make use of existing GPL'd software in their enterprise.

Upon completion of this part of the tutorial, successful readers can expect

to have learned the following:

\begin{itemize}

  \item The freedom-defending purpose of various terms in the GNU GPLv2 and GPLv3.

  \item The differences between GPLv2 and GPLv3.

  \item The redistribution options under the GPLv2 and GPLv3.

  \item The obligations when modifying GPLv2'd or GPLv3'd software.

  \item How to build a plan for proper and successful compliance with the GPL.

  \item The business advantages that the GPL provides.

  \item The most common business models used in conjunction with the GPL.

  \item How existing GPL'd software can be used in existing enterprises.

  \item The basics of LGPLv2.1 and LGPLv3, and how they

    differs from the GPLv2 and GPLv3, respectively.

  \item The basics to begin understanding the complexities regarding

    derivative and combined works of software.

\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% END OF ABSTRACTS SECTION

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% START OF DAY ONE COURSE

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{What Is Software Freedom?}

Study of the GNU General Public License (herein, abbreviated as \defn{GNU

  GPL} or just \defn{GPL}) must begin by first considering the broader world

of software freedom. The GPL was not created in a vacuum. Rather, it was

created to embody and defend a set of principles that were set forth at the

founding of the GNU project and the Free Software Foundation (FSF) -- the

preeminent organization that upholds, defends and promotes the philosophy of software

freedom. A prerequisite for understanding both of the popular versions

of the GPL

(GPLv2 and GPLv3) and their terms and conditions is a basic understanding of

the principles behind them.  The GPL family of licenses are unlike nearly all

other software licenses in that they are designed to defend and uphold these

principles.

\section{The Free Software Definition}

\label{Free Software Definition}

The Free Software Definition is set forth in full on FSF's website at

\verb0http://fsf.org/0 \verb0philosophy/free-sw.html0. This section presents

an abbreviated version that will focus on the parts that are most pertinent

to the GPL\@.

A particular program grants software freedom to a particular user if that

user is granted the following freedoms:

\begin{itemize}

\item The freedom to run the program, for any purpose.

\item The freedom to study how the program works, and modify it

\item The freedom to redistribute copies.

\item The freedom to distribute copies of  modified versions to others.

\end{itemize}

The focus on ``a particular user'' is particularly pertinent here.  It is not

uncommon for the same version of a specific program to grant these freedoms

to some subset of its user base, while others have none or only some of these

freedoms.  Section~\ref{Proprietary Relicensing} talks in detail about how

this can unfortunately happen even if a program is released under the GPL\@.

Many people refer to software that gives these freedoms as ``Open Source.''

Besides having a different political focus than those who call it Free

Software,\footnote{The political differences between the Free Software

  Movement and the Open Source Movement are documented on FSF's Web site at

  {\tt http://www.fsf.org/licensing/essays/free-software-for-freedom.html}.}

Those who call the software ``Open Source'' are often focused on a side

issue.  Specifically, user access to the source code of a program is a

prerequisite to make use of the freedom to modify.  However, the important

issue is what freedoms are granted in the license of that source code.

Software freedom is only complete when no restrictions are imposed on how

these freedoms are exercised.  Specifically, users and programmers can

exercise these freedoms noncommercially or commercially.  Licenses that grant

these freedoms for noncommercial activities but prohibit them for commercial

activities are considered non-free.  Even the Open Source Initiative

(\defn{OSI}) (the arbiter of what is considered ``Open Source'') also rules

such licenses not in fitting with its ``Open Source Definition''.

In general, software for which most or all of these freedoms are