No subject

"The "Corresponding Source" for a work in object code form means all the
source code needed to generate, install, and (for an executable work) run
the object code and to modify the work, including scripts to control those
activities."

There is an exception to that broad definition of Corresponding Source.

"However, it does not include the work's System Libraries, or
general-purpose tools or generally available free programs which are used
unmodified in performing those activities but which are not part of the
work."

The limitation to the exception which some may overlook is: "which are not
part of the work."

The example which the license provides is helpful in clarifying.

"For example, Corresponding Source includes [...] the source code for
shared libraries and dynamically linked subprograms that the work is
specifically designed to require [...]."

The definition of Corresponding Source in object code form for GPL 3 and
AGPL 3 section 1 merely provides additional clarification beyond what had
been given as the definition in GPL 2 section 3.  "For an executable work,
complete source code means all the source code for all modules it
contains, plus any associated interface definition files, plus the scripts
used to control compilation and installation of the executable.  However,
as a special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary form)
with the major components (compiler, kernel, and so on) of the operating
system on which the executable runs, unless that component itself
accompanies the executable."

The difference for Corresponding Source between both GPL 2 and 3 on one
side and AGPL 3 on the other is that the license does not apply under GPL
2 or 3 unless the user already has a copy of the GPL 2 or 3 licensed
program which he is using.

Folk conceptions of the work as merely the base files of a program are
mistakenly under-inclusive and do not conform to how software functions in
relation to copyright law.  Many copyright lawyers lack sufficient
understanding of how to apply the definition of a work in copyright law to
software.  Copyright law gives little special treatment to software and
there have not  been enough court cases on the issue to guide lawyers
well.  See section 2 of my message to Aaron from 29 June, quoted further
below.

Programmers applying the GPL in good faith are routinely under-inclusive
in meeting their obligations to provide complete source code by omitting
unmodified third party modules to which they link.  Despite being a
license violation, such common under-inclusiveness results in little
practical harm to users because the omitted source code is generally
readily available.  Following the license terms is better than following
the crowd.

Aaron's previous mistake had been to give the opposite answer about the
form of the Corresponding Source applicable to remote network use under
AGPL 3.  He had not been making the mistake of copyright lawyers who do
not understand how copyright law applies to software.  He had merely
lacked experience answering some questions about how to apply AGPL 3.


1.2.1.  SPECIFIC APPLICATION TO KOHA.

For Koha, the "shared libraries and dynamically linked subprograms" are
the Perl modules used and their dependencies which are not included in a
minimal base Perl installation.  We should include the source code for
object code dependencies for which the Perl module is merely a wrapper. 
The FSF GPL FAQ treats the wrapper issue issue in a somewhat different
context, http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper , but the
answer given helps explain that the program which the wrapper wraps is
just as much a part of the work as the wrapper.

We should include Net::Z3950::ZOOM and the source code for Yaz for which
ZOOM is merely a wrapper.  We have no need to include the source code for
the Zebra server, because Yaz uses standard communication protocols and
provides a general purpose abstraction layer for the Z39.50 standard with
which other Z39.50 servers could be substituted for Zebra.

We should include DBI and the dependency which we currently require
DBD::mysql.  We have no need to include the source for MySQL server,
because DBI uses standard communication protocols and provides a general
purpose abstraction layer for the SQL standard with which other databases
could be substituted for MySQL.

For the inclusion of any third party module source code as part of the
Corresponding Source where the modules is under GPL 2 with the or later
version option, we should add a general license invocation statement that
as part of their inclusion in Koha we have upgraded the license of all
such programs to at least GPL 3 with an or later version option.  Such a
general license invocation statement should allow automating updating of
such third party modules for the Corresponding Source with minimal
trouble.


1.2.3.  AVOIDING AGPL 3 VIOLATIONS.

If we adopt AGPL 3 for Koha, including Perl modules and their dependencies
in the Corresponding Source is a burden which many may find unwelcome. 
Some may wish to take a narrower interpretation of the license obligation.
 When I suggested very generally what I thought we should include and
asked Aaron for clarification on where we should draw the line between
what to include and what to exclude, he gave an expected answer.  The full
message is quoted further below.

Aaron answered:

"This is a difficult question, and I'm not sure the community has come to
a consensus on it, nor am I aware of any definitive statement on the
limits of this requirement by an authoritative source such as the FSF.  I
think you are right to read it fairly expansively, and that including the
source for required Perl modules is a good plan."

If we would follow the crowd of programmers applying license terms in good
faith but without due care, we would be setting ourself up for future
problems.  We should do what we can to avoid a problem where a new party
introduces a special modification of Koha and users of that version cannot
make the source code which they obtain function because of the use of a
particular Perl module which may be especially difficult to identify and
obtain.  We should avoid a problem in which the other party would able to
respond legitimately as follows.  "You did not include X for your version
so I should not need to include Y for mine."  We have already had such
problems in which we as a community had not been collectively consistent
about our treatment of the software name.  We should do whatever we
reasonably can to avoid similar problems in future.

We would have legal protections against those who would violate the
license despite our best efforts to help a violator understand the
advantages of cooperation.  However, we should set a good example to
others to ensure that others do not have a valid excuse for being
difficult about cooperating.


2.  ADDITIONAL CORRECTIONS FOR APPLYING AGPL 3.


2.1.  EQUIVALENT ACCESS TO PROGRAM AND CORRESPONDING SOURCE.

As the use is in object code form for a remote network user under AGPL 3,
the "equivalent access" provision of section 6 (d) would apply.  Limiting
the bandwidth for accessing the source code to a greater degree than the
limitation of the bandwidth of the program use for countries where network
connectivity is poor and extraordinarily expensive would not be allowed. 
This change corrects the answer given for limiting bandwidth as a remedy
to AGPL 3 objections given in section 3.1.1.3 of an earlier message of
mine in this thread at
http://lists.katipo.co.nz/pipermail/koha/2010-July/024391.html .

A provider of free source code hosting services with ample bandwidth, such
as http://www.gitorious.org/ and http://github.com/ , would be one option
for hosting the Corresponding Source.  Contracting Corresponding Source
hosting services with a Koha support company would be another option.  If
all the modifications of a particular installed version would be included
in the main Koha git repository, then the hosted git repository under the
direction of the party providing the installed version could merely be a
clone of the main repository with instructions on how to build the
particular installed version.


2.2.  ENFORCABILITY.

Aaron previously had answered that claims of substantive license violation
and action in bad faith could be made as a means of enforcing the intent
of AGPL 3 against a violator in the context of his previously mistaken
understanding applying Corresponding Source to AGPL 3.  See Aaron's
message from 2 June which I posted in
http://lists.katipo.co.nz/pipermail/koha/2010-July/024395.html .  In the
context of his current corrected answer about how Corresponding Source
applies to AGPL 3, there would be a much stronger claim to be made that
the license terms would be violated by the omission of part of the
Corresponding Source.  Both a strong claim of substantive license
violation and claim of action in bad faith would be available for
enforcing the license.


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783


---------------------------- Original Message ----------------------------
Subject: Re: Correspondence of Corresponding Source and derivative work   
   relationships
From:    "Aaron Williamson" <aaronw AT softwarefreedom.org>
Date:    Fri, July 2, 2010 18:42
To:      koha AT agogme.com
--------------------------------------------------------------------------

On 07/02/2010 02:06 PM, Thomas Dukleth wrote:
> You had already provided a sufficient suggestion for such a bandwidth
> problem by suggesting that those installing Koha could contract with an
> economically advantaged support company, from a place where network
> connectivity is more reasonably provisioned, to host the Corresponding
> Source on behalf of those responsible for a particular Koha installation.
> I suspect that some Koha support companies will be willing to offer a
> Corresponding Source hosting service for a minimal or token fee to those
> libraries which do not have an ongoing support contract otherwise.
> Operating costs would be kept low by automating the inclusion of any
> changes in the Corresponding Source.

Actually, my colleague Bradley suggested a concrete and much more practical
solution -- you could just put the modified source up on Gitorious or a
similar
hosting provider.  It's free, easy, and high-bandwidth.

> I think that we should include all Perl modules used by Koha and the
> source code for any dependencies used by them which are not part of a base
> Perl distribution.  Some Perl modules used are merely Perl wrappers or
> special purpose Perl APIs to programs written in C.
>
> Others may claim that anything which can be obtained as a package in the
> large number of packages available for a GNU/Linux distribution such as
> Debian is a part of the "System Libraries, or general-purpose tools or
> generally available free programs which are used unmodified" and thus
> exempt from inclusion in the Corresponding Source.  In contrast, I think
> that the license seems to define the exemption as a relatively small set
> of minimally essential components for any operating system which would
> never be expansive enough to be every Debian package.
>
> Q.  Where do we draw a practical distinction about what should be included
> in the Corresponding Source with particular reference to what is and what
> is not exempt from the guidance provided for object code form?

This is a difficult question, and I'm not sure the community has come to a
consensus on it, nor am I aware of any definitive statement on the limits of
this requirement by an authoritative source such as the FSF.  I think you are
right to read it fairly expansively, and that including the source for
required
Perl modules is a good plan.

Aaron


---------------------------- Original Message ----------------------------
Subject: Re: Correspondence of Corresponding Source and derivative work   
  relationships
From:    "Thomas Dukleth" <koha AT agogme.com>
Date:    Fri, July 2, 2010 18:06
To:      "Aaron Williamson" <aaronw AT softwarefreedom.org>
--------------------------------------------------------------------------

Aaron,

Thank you greatly for thinking enough about the issue to come to  a
consistent conclusion.  I am sorry that I had not reached my own corrected
analysis about source code only form earlier.  Lack of sleep had kept me
from thinking sufficiently broadly about  the issue of source code only
form.

The questions which I had posed at the beginning of the week were merely
intended to help us come to a consistent conclusion and should now be set
aside.

I have one question posed at the end of this message which we had not
reached before your present conclusion about AGPL 3 specific obligations.


1.  YOUR SOLUTION TO POOR NETWORK CONNECTIVITY.

As the use is in object code form for a remote network user under AGPL 3,
the "equivalent access" provision of section 6 (d) would apply.  Limiting
the bandwidth for accessing the source code to a greater degree than the
limitation of the bandwidth of the program use for countries where network
connectivity is poor and extraordinarily expensive would not be allowed.

You had already provided a sufficient suggestion for such a bandwidth
problem by suggesting that those installing Koha could contract with an
economically advantaged support company, from a place where network
connectivity is more reasonably provisioned, to host the Corresponding
Source on behalf of those responsible for a particular Koha installation. 
I suspect that some Koha support companies will be willing to offer a
Corresponding Source hosting service for a minimal or token fee to those
libraries which do not have an ongoing support contract otherwise. 
Operating costs would be kept low by automating the inclusion of any
changes in the Corresponding Source.


2.  FOLLOWING OBJECT CODE FORM.

Following the correct guidance (or definition as you might put it more
strongly) included in the license under the definition of Corresponding
Source in object code form requires some consideration.

I think that we should include all Perl modules used by Koha and the
source code for any dependencies used by them which are not part of a base
Perl distribution.  Some Perl modules used are merely Perl wrappers or
special purpose Perl APIs to programs written in C.

Others may claim that anything which can be obtained as a package in the
large number of packages available for a GNU/Linux distribution such as
Debian is a part of the "System Libraries, or general-purpose tools or
generally available free programs which are used unmodified" and thus
exempt from inclusion in the Corresponding Source.  In contrast, I think
that the license seems to define the exemption as a relatively small set
of minimally essential components for any operating system which would
never be expansive enough to be every Debian package.

Q.  Where do we draw a practical distinction about what should be included
in the Corresponding Source with particular reference to what is and what
is not exempt from the guidance provided for object code form?


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783


---------------------------- Original Message ----------------------------
Subject: Re: Correspondence of Corresponding Source and derivative work   
   relationships
From:    "Aaron Williamson" <aaronw AT softwarefreedom.org>
Date:    Fri, July 2, 2010 15:34
To:      koha AT agogme.com
--------------------------------------------------------------------------

Thomas,

I think you're way too far down the rabbit hole, and consequently I don't
think
it will be helpful for me to address your questions as you lay them out in
your
email.  Hence, I'm going to provide an answer to what I believe is the
substance
of your question, and if I'm mistaken, you can lead me back in the right
direction.

First, you are correct in your self-correction that the distinction
between the
Corresponding Source of a source code-form work and the Corresponding
Source of
an object code-form work is explicit in the text of the license, and does not
derive from its interpretive history.  Moreover, I believe that the
distinction
is meaningful -- there would be no reason to define Corresponding Source
differently for object- and source-form distributions if the "work"
referred to
was the same thing (i.e., the specific program at issue plus anything it
links
to, etc.).  I believe still that if I distribute a GPLv3 work in source
code or
modified source code form, I have fulfilled my requirement to provide
Corresponding Source even if I did not provide source for libraries which are
explicitly #include'd by that source code.  This is not because the work in
source code form is not derivative of those libraries, but because the
license
has explicitly limited the definition of "Corresponding Source."

Second, you are correct that the back-of-the-envelope interpretation of
the AGPL
I gave when last we spoke was misguided.  I believe I said something like:
"The
AGPL only requires you to make any sort of distribution when a user interacts
with the Program over a network.  When you distribute, you distribute source.
The Corresponding Source for a distribution of source code is that source
code,
so you don't have to include dependencies."

Does that sound about right?  I acknowledge that this interpretation is
deficient in a couple of ways, but not because of any fundamental interaction
between the "scope of the work" under copyright law and under the GPL. 
Rather,
it ignores that the Remote Network Interaction section explicitly refers
to the
Corresponding Source of the Program with which the user is interacting. 
Unless
my computer science degree fails me, I believe that Program (even if
written in
an interpreted language such as Perl) will always be in object code form
as the
user interacts with it.  Hence, the Corresponding Source will be the
Corresponding Source for an object code work.

As I see it, this addresses your concern regarding interpretive
consistency but
does not help with your original problem of onerous source distribution
requirements placed on African libraries with very low bandwidth.

Am I missing anything?

Aaron


[...]



---------------------------- Original Message ----------------------------
Subject: Re: Correspondence of Corresponding Source and derivative work   
  relationships
From:    "Thomas Dukleth" <koha AT agogme.com>
Date:    Fri, July 2, 2010 06:31
To:      "Aaron Williamson" <aaronw AT softwarefreedom.org>
--------------------------------------------------------------------------

Aaron,

Please note a correction in my explanation for the questions from my
message of three days ago quoted further below.

I had mistakenly suggested that the FSF practise of deference to source
code only conveyance is merely a practical courtesy in not requiring the
inclusion of unmodified third party modules.  I still think that you seem
to be reading an interpretation into the license for source code only
conveyance which does not match the special condition of AGPL 3
obligations.

In contrast to my own mistaken suggestion, I explained the issue best when
I identified the fact that outside of the special conditions of AGPL 3 a
source code only work conveyed may be non-functional or incomplete.  The
GPL cannot generally require that a broken source code only conveyance be
fixed or that missing features be added.  The 'correspondence' for the
'Corresponding Source' in a source code only conveyance need not be
anything more than whatever source code happens to have been conveyed.

As I explained in section 1.1.2 of my message from three days ago, the
following difference is important for AGPL 3.

"The GPL allows the conveyance of a non-functioning program or merely part
of a program and hence the Corresponding Source need only match the
non-functional or incomplete program conveyed.  Use of a program over a
network under AGPL 3 necessarily implies that the program is functional
enough to use and is as complete as the provided use.  Consequently, the
Corresponding Source [for AGPL 3 specific obligations] must be a complete
functional work which may imply some of the concern which had motivated
the guidance provided in the definition of Corresponding Source for object
code."

The fact that there is no guidance covering conveyance in source code only
form under AGPL 3 does not mean that similar guidance to guidance for
object code form would not be useful and appropriate.  The omission of
such guidance does not imply that absent guidance should not be applied as
appropriate.

Please answer the questions from my message quoted below with reference to
the emphasis on the difference identified above in Corresponding Source as
applied to AGPL 3.


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783


[...]



---------------------------- Original Message ----------------------------
Subject: Correspondence of Corresponding Source and derivative work     
relationships
From:    "Thomas Dukleth" <koha AT agogme.com>
Date:    Tue, June 29, 2010 22:03
To:      "Aaron Williamson" <aaronw AT softwarefreedom.org>
--------------------------------------------------------------------------

Aaron,

I have some remaining confusion about the requirements for conveying
Corresponding Source in the GPL.  Unexplained inconsistencies can result
in the failure of running code and also the failure of license
interpretation.  The confusion I have follows from your assertion that
Corresponding Source is different between  a work in object code form and
a work in source code form.

The inconsistencies are undermining my capacity to intelligibly explain
how GPL 3 or AGPL 3 would apply to Koha.  The best I have managed is try
to formulate a seemingly awkward explanation of the license which
corresponds to an affirmative answer to question Q.1.A., Corresponding
Source and Requirement Correspondence, further below.  However, I am more
inclined to believe that the correct answer is an affirmative answer to
question Q.1.B., Corresponding Source and Work Correspondence, further
below, which would contradict your assertion.

Your interpretation has led me into my muddle.  I hope that you can lead
me back out again.

I worry mostly about the integrity of the license to not be
self-contradictory in relation to copyright law.  The possible scope for
evasion of the license intent is a lesser concern in this context than an
interpretive problem which might undermine the license meaning more
generally.  The greatest hazard within the scope for evasion of license
intent which may follow from a self-contradictory interpretation of the
license risks undermining the source code obligation of those conveying
GPL programs in object code.

Please remember that my presumption of what constitutes a derivative work
in relation to software under copyright law matches what I have understood
the FSF position to be, as it has been explained over the years in
relation to examples involving object code.  I have presumed that source
code and object code forms of a work had significant parity in relation to
merely being a different embodiment of the work.  The goal of the GPL is
well understood to ensure that the user can exercise his rights, in part
by ensuring access to the source code of a GPL program.  The practical
exercise of other user rights under the GPL follow from access to the
source code.

You identified an FSF practise of giving deference, with respect to the
issue of including third party modules in the Corresponding Source, when a
GPL program has been conveyed to the user in source code form only. 
Reasonable deference to the virtues of those conveying source code as the
sole means of conveyance may be a helpful FSF practise.  Such a
deferential practise would be better than attempting be overly strict with
those conveying in source code only form.  Source code only conveyance
serves the intent of the license especially well and those who have who
convey in source code only form may be worthy of some deference for having
started ahead of others who convey in object code form.

There is a danger in attempting to treat the FSF practise of deference as
anything more than a special courtesy for good will in license
enforcement.  Great care should be taken to avoid reading a basis of
practise into a part of the license where the distinction cannot be fully
supported without violating copyright law.  Any valid interpretation of a
valid copyright license should conform to copyright law as it would be
interpreted by the courts if there would ever be a dispute on the issue in
which the license is challenged.


1.  QUESTIONS.

1.1.  CORRESPONDING SOURCE CORRESPONDENCE.

Q.1.  What is Corresponding Source intended to 'correspond to' in GPL 3?

Copyright law determines the scope of a work.  The source code of a work
is thus fixed by copyright law independent of whatever form, source or
compiled, in which a work may be usually conveyed.

Copyright licenses might impose disparate requirements to comply with the
license in disparate conditions which all conform to the objective of the
license.  License terms may guide the user in the correct application of
copyright law but must not contradict copyright law.


1.1.1.  CORRESPONDING SOURCE AND REQUIREMENT CORRESPONDENCE.

Q.1.A.  Is 'Corresponding' Source intended to 'correspond' to the 'scope
of the license requirement' to provide source code independent of the
scope of the work?

As an example of 'corresponding' to a requirement independent of the work,
some possible software license with a different objective than the GPL
might require a payment of $10 for object code conveyance and payment of
$100 for source code conveyance.  In this example, the 'scope of the
license requirement' 'corresponds' to the type of software conveyance
without impinging upon a domain specified by copyright law.

As another example, some possible software license with some similar but
much more limited objective to the GPL might require providing users only
the opportunity to obtain source code for data compression used in a
program for original object code conveyance and have no specific source
code requirement for original source code conveyance.  In this example
also, the 'scope of the license requirement' 'corresponds' to the type of
software conveyance without impinging upon a domain specified by copyright
law.


1.1.2.  CORRESPONDING SOURCE AND WORK CORRESPONDENCE.

Q.1.B. Is 'Corresponding' Source intended to 'correspond' to the 'scope of
the work' and thus the requirement to provide source code dependent upon
the scope of the work?

If 'Corresponding' Source 'corresponds' to the 'scope of the work', then a
requirement to convey the Corresponding Source must have the same scope
irrespective of whether the program has been conveyed to the user in
source or object code form.  The work is the work under copyright law and
the scope of the work cannot change by the form in which it is embodied.

Take the analysis given in the license of what constitutes Corresponding
Source for object code forms of a work.  Use that analysis to create the
source code form of the same work.  If that source code form of the work
is conveyed in source code form only, the Corresponding Source obligation
clearly cannot be diminished in such a case because the work is the same. 
Answering that works developed for source code distribution have a
categorically different relationship to third party modules is mistaken. 
Compilers for programming languages in which programs are usually conveyed
in source code form is one example of the falsity of a claim that object
code forms and source code forms generally relate to a work which is
substantially different.

The definition of Corresponding Source for source code form is merely a
tautology.  "The Corresponding Source for a work in source code form is
that same work."  I have supposed that the lack of equivalent guidance as
to the scope of Corresponding Source for a source code form of a work is
merely than the need for guidance arose in the context of object code form
conveyance where the is the hazard of a mismatch between the source code
offered and the object code conveyed.

AGPL 3 introduces an important difference for source code only conveyance.
 The GPL allows the conveyance of a non-functioning program or merely part
of a program and hence the Corresponding Source need only  match the
non-functional or incomplete program conveyed.  Use of a program over a
network under AGPL 3 necessarily implies that the program is functional
enough to use and is as complete as the provided use.  Consequently, the
Corresponding Source must be a complete functional work which may imply
some of the concern which had motivated the guidance provided in the
definition of Corresponding Source for object code.  Sadly drafting the
distinctive terms of AGPL 3 did not receive the same degree of scrutiny as
had been given to drafting GPL 3.

A diminutive folk conception of the scope of a work may be commonplace but
in a legal concept folk conceptions should be understood as insufficiently
precise.  Ultimately, we hope that laws reinforce our most fundamental
shared moral folk concepts.


1.2.  INCLUDE MEANING INCLUDE.

Q.2.  Does a 'program include' mean 'include within the scope of the work'?

Many programming languages use program 'include' functions to call module
dependencies.  Include functions are invoked variously with commands such
as 'use', 'include', and 'require'.  Such commands are very different from
fork or exec, and also very different from communication with a third
party program over a general purpose protocol.  Includes include another
program directly into the calling program irrespective of whether the
program is in source or object code form.  Includes function similarly to
linking when compiling programs.

Such 'include' relationships should mean that programs thus included are a
dependency of the calling work in a manner which makes them part of the
calling work.  Similarly the calling work is a derivative work of the
included work requiring license compatibility with the included work.

Given the license tautological definition of Corresponding Source for a
work in source code form, the license would not exclude 'included' modules
from a work in source code form.


1.3.  APPLICABILITY OF MODULE LICENSES.

Q.3.  Is the requirement to follow the copyright license for a third party
programming module different when the program incorporating the module is
conveyed in object code as distinct from source code only conveyance?

[For the purpose of this question, suppose that in the case of the source
code only conveyance alternative, a programming module is not conveyed but
has not been internally modified.  Such a supposition merely posits the
case in which you had suggested that third party modules do not need to be
conveyed to users even if the modules are clearly included as incorporated
within the functioning of the program.]

The GPL Wrapper FAQ question may address the issue the issue indirectly if
the wrapper part is ignored,
http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper .  However, the GPL
FAQ generally refers to linking implying examples from object code form if
there is a difference.


2.  HOW DERIVATIVE WORKS APPLY TO SOFTWARE.

I repeat my brief explanation of how derivative works apply to software
with a small clarification.  I have included a necessary exception which I
had omitted in my somewhat briefer simplified form.  The exception
explains how Koha need not include MySQL in the Corresponding Source.

In the interest of brevity, I do not present a fully nuanced set of
exceptions.  Exceptions addressing addressing parties creating some types
of modifications directly or acting under the direction or control of a
common party are excluded.  I also do not give an account of community
toleration of GPL licensed programs which may violate the GPL but which
otherwise advance community interests in a manner which could not be
advanced without violating the GPL.

I present an analogy to how copyright law is well understood in comparable
application to the copyright of books.


2.1.  DERIVATIVE WORK RELATIONSHIPS.

Functional calls to a program can invoke a derivative work relationship to
the called program as a dependency of the calling program.  Calls which
act upon the called program as an entirely separate process, or over a
standard communication protocol, or standard API: do not include the
called program within the calling program and thus do not invoke a
derivative work relationship to the called program.

The test which I have used for determining a derivative work relationship
is whether the work as a whole would function if a particular dependency
would be removed and would the dependency has not been called as part of a
derivative work relationship.  If a call is sufficiently generalised to
not exclusively require a particular dependency, then multiple alternative
dependencies may be substituted and no derivative work relationship to the
called program would be entailed.  Given the rigid linear manner in which
program control is generally coded, omitting a dependency for which no
alternative can be substituted would usually be liable to cause the entire
program to fail.

A program which calls a dependency without a generalised protocol, does
not call the dependency as an entirely separate process, and for which the
particular dependency has no readily substitutable alternative:
establishes a derivative work relationship to the called program.


2.1.1.  COMPARABLE CASE OF DERIVATIVE WORKS APPLYING TO BOOKS.

The relationship is analogous to the analysis one might give to a book
where some new wholly original material is contained within book which
also includes a collection of other works organised in some useful manner.
 Permission is need to include the other works in the book.  The book
would not have the same meaning intended in organising the various parts
if a section would be omitted.


2.2.  MERE DATA LINKING.

Functional calls are very different from mere data linking.  Mere data
linking does not establish a derivative work relationship.

An HTML hyperlink or other simple data link is an example of a mere data
link which does not necessarily establish a functional dependency on the
linked content by the program from which the link is being made.  If the
data resource to which a link is being made is unavailable, the program
would probably continue to function and the user would merely not have the
data from the particular resource.

There is no functional dependency which would necessarily cause program
failure if a data link would be omitted.


2.2.1.  COMPARABLE CASE OF MERE CITATION OF OTHER WORKS APPLYING TO BOOKS.

The analogous case for books is that of a bibliographic listing.  Books
may have HTML hyperlinks for bibliographic links if the book is presented
in electronic format.  However, both the paper version with no hyperlinks
and the electronic version with hyperlinks have the same functional
integrity.  The book containing the bibliographic listing would continue
to function correctly whether or not a work listed in the bibliography
would be available to the reader.


2.3.  FSF INTERPRETATION.

As far as I have understood, the interpretation given in this major
section for how the derivative works concept in copyright law applies to
software is the interpretation which FSF has always advocated and the
correct interpretation.

Please correct me if my understanding is mistaken.


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783