[Koha] Proposal To Switch Koha's License to GPLv3 and AGPLv3 or AGPLv3
Thomas Dukleth
kohalist at agogme.com
Fri Jul 2 19:27:39 NZST 2010
[This is the third of about three messages which I had intended to send in
early June reporting on the current state of my seeking answers from the
SFLC about copyright licensing of Koha. The effects of chronic lack of
sleep required me to stop attempting to draft the second message for the
schedule which I had originally intended. I delayed sending the original
contents of this message to keep the chronology of events to which the
messages refer clear.]
Quoted further below is correspondence between Aaron Williamson at
Software Freedom Law Center (SFLC) and myself over derivative works as
applied to software generally and source code conveyance obligations under
GPL and AGPL 3 specifically. There are four messages. I have yet to have
a reply to the two most recent messages.
[The text of the messages is quoted exactly except that I changed the form
of quotation marks which Aaron had used in quoting from the license. In
the exact form of his reply, there had been no distinction between his
quotation of the license text and his quotation from my earlier message.
There is some point at which I had used the wrong word in my first message
which was not a misspelling. I would correct that mistake but I do not
remember where it is now.]
1. DERIVATIVE WORKS IN RELATION TO SOFTWARE.
In the first message which I sent to Aaron about derivative works I
provided an explanation of how derivative works function in relation to
software. Unfortunately, in my effort to be brief I oversimplified the
issue to a degree which I should not have done for the present discussion.
I have privately shared a very complete and lengthy explanation of
derivative works in the context of software and various licenses. I spare
the list such a complete and lengthy explanation of derivative works at
the present time.
Please understand that my explanation given in section 1 of the oldest
message, from 27 May, quoted further below is an oversimplification. I
corrected that oversimplification for an important issue of discussion on
telephone with Aaron and in section 2 of the 29 June message quoted
further below.
2. SPECIALLY RESERVED RIGHT TO BE WRONG.
When I spoke to Aaron on telephone, after he had sent the message quoted
further below from 2 June, he specifically reserved the right to be wrong.
He explained that he had done some original research in answering in
which he did not have full confidence, as he had not had the opportunity
to discuss the issue with others at SFLC.
I explained to Aaron that he should always reserve the right to be wrong
as I always do. However, I seldom make it a special point to identify
the fact that I have reserved that right.
I believe that Aaron had meant to reserve the right to be wrong in the
special context of the justification for why Koha does not need to include
MySQL in the Corresponding Source. Aside from a modest muddle at the
edges, I have no concern about the MySQL non-issue.
I think that the issue for which Aaron should have specially reserved the
right to be wrong is the issue for Aaron's claim that Koha does not need
to include unmodified third party Perl modules in the Corresponding Source
under AGPL 3.
2.1. MYSQL NON-ISSUE.
During the course of my meeting with Aaron in late May I had
misinterpreted the key reason which he had given or at least intended to
give for why Koha need not be understood to be partly a derivative work of
MySQL. Koha uses DBI::Perl to access MySQL. DBI::Perl is an abstraction
which allows substituting another database other than MySQL. Koha has
some MySQL specific code for which a Postgres alternative should be
provided, however, it is not substantive enough to be of much concern for
license compatibility.
If the Koha community upgrades the Koha license to GPL 3 or AGPL 3, Oracle
will not be pursuing the Koha community to obtain a special MySQL license
to use an GPL 3 or AGPL 3 Koha with GPL 2 only. MySQL AB had pursued
proprietary closed source software companies requiring them to obtain a
proprietary license to MySQL merely for using MySQL as a database with
MySQL specific calls. MySQL AB had asserted that without a special
proprietary license mere use of MySQL created a derivative work which
required abiding by the particular version of the GPL used by MySQL at the
time.
2.2. PERL MODULES ISSUE.
I think that at least for conveying the Corresponding Source under AGPL 3
we are required or should be required to include Perl modules. Aaron has
given a different interpretation of the license.
Aaron has stated that the source code only conveyance of Koha does not
require including unmodified third party modules under AGPL 3 specific
terms. He has stated that unmodified third party modules would only be
required if Koha would be conveyed in object code form. I think that
Aaron is mistaken.
Aaron cites what he interprets as the distinctive definition of
Corresponding Source for justification.
GPL 2 section 3 gives distinctive definition of the source code for an
executable work.
GPL 3 and AGPL 3 section 1 also gives a distinctive definition for the
Corresponding Source for a work in object code form. That definition is
followed by a definition of the Corresponding Source for the source in
object code form. "The Corresponding Source for a work in source code
form is that same work."
I do not read the lack of a definition for Corresponding Source in GPL 2
or the definition provided in GPL 3 and AGPL 3 as any more informative.
Both the absence and presence of a definition seem to be a tautology such
as 'the source code of X is the source code of X' or the 'Corresponding
Source is the Corresponding Source'.
Guidance is provided for understanding what should be considered part of a
work for object code form about which people may be confused. AGPL 3
seems to me to introduce a need for comparable guidance for source code
form because its specific obligations are only operative when a program is
sufficiently functional and complete to have remote network users.
Whether or not guidance is present in the license, the definition of a
work is the same irrespective of the form in which it is embodied. The
definition of a work comes from copyright law and court interpretation,
but not from a copyright license.
I provide an awkward alternative in my message from 29 June further below.
The consequence which I describe below for Aaron's assertion to be
correct is that the license would not be meaningful in a vitally important
respect.
I think that the confusion over the issue of including third party
modules, which have not been modified directly, in a source code only
conveyance under AGPL 3 is not really that AGPL 3 is untested as MJ has
raised as an objection. I suspect that the nuances of AGPL 3 are merely
unfamiliar to SFLC because they have yet to have sufficient need to
examine the nuances closely. I doubt that SFLC has yet undertaken any
enforcement action over 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: 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
---------------------------- Original Message ----------------------------
Subject: Re: Questions about upgrading Koha to AGPL 3 or GPL 3
From: "Aaron Williamson" <aaronw AT softwarefreedom.org>
Date: Wed, June 2, 2010 22:10
To: koha AT agogme.com
--------------------------------------------------------------------------
On 05/27/2010 10:48 AM, Thomas Dukleth wrote:
> 1.1. DERIVATIVE WORK RELATIONSHIPS.
>
> Functional calls to a program invoke a derivative work relationship to the
> called program as a dependency of the calling program. The test which I
> have used is whether the work as a whole would function if one would
> remove a particular dependency.
I think that this is too broad a definition of a derivative work, and is
inconsistent with the FSF's traditional interpretation of the GPL. Your test
would yield results that contradiction to FSF's historical interpretation.
For
example, when a program interacts with another program via fork and exec
calls,
the FSF generally considers them to be separate programs.[1] And when a
program
interacts with another program via standard interprocess communication or
network protocols, the FSF has usually considered the programs to be separate
works.[2] So I think your test is too rigid.
If we accept this interpretation (and since the FSF has been espousing it for
years, we would be in good company), then it is a simple matter to declare
MySQL
and Koha separate works without damning Koha to rampant exploitation.
Though if
you took away MySQL Koha would not function, Koha runs in a separate process
from MySQL and interacts with it via standard protocols (i.e. Perl's DBI and
Unix sockets or TCP/IP). However, if someone were to heavily modify Koha to
give it a nonstandard interface allowing it to access all of Koha's
internals,
and then create a "separate" proprietary application that interacted with
this
interface, they would run afoul of FSF's interpretation that
"communication of
the [proprietary] component with a [] GPL'ed component via a rich,
non-standard
IPC or network interface that gives all the same functionality normally
given by
static or dynamic linking." Moreover, I think an effort to circumvent the
license in this way would evince clear bad faith and would be unlikely to
sway a
judge.
[1] See http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
[2] C.f. http://www.fsf.org/licensing/compliancelab.html
> 3. EXTENT OF CORRESPONDING SOURCE.
>
> When you had to depart yesterday we were in the midst of discussing
> obligations under the license in terms of what constitutes the
> 'Corresponding Source' for the obligation to provide the 'Corresponding
> Source'.
>
> Are the unmodified Perl modules and their dependencies which are
> distributed independently from Koha part of Koha, when considered as a
> work as a whole?
Considering AGPLv3 specifically, I think you avoid this issue because no
non-source form of Koha is ever conveyed. If Koha could be compiled into
binary
form, then the source for the Perl modules, etc., would be a required
component
of the Corresponding Source. However, since Koha is only ever *conveyed* in
source form, they are clearly not a part of the Corresponding Source:
"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."
[snip]
"The Corresponding Source for a work in source code form is that same work."
The result is the same under GPLv2 -- the complete corresponding source is
only
defined to include third-party libraries, etc., when the work is
distributed in
object code form.
--
Aaron Williamson
Counsel
Software Freedom Law Center
1995 Broadway, 17th Fl.
New York, NY 10023
(212) 461-1911 direct
(212) 580-0898 fax
www.softwarefreedom.org
---------------------------- Original Message ----------------------------
Subject: Re: Questions about upgrading Koha to AGPL 3 or GPL 3
From: "Thomas Dukleth" <koha AT agogme.com>
Date: Thu, May 27, 2010 14:48
To: "Aaron Williamson" <aaronw AT softwarefreedom.org>
--------------------------------------------------------------------------
Aaron,
I had read the paper about maintaining permissively licensed code within
GPL works previously after hearing it discussed in a SFLC oggcast. Thank
you for the link.
1. HOW DERIVATIVE WORKS APPLY TO SOFTWARE.
Throughout my thinking about how copyright law applies to software I have
taken a software dependency to generally imply a derivative work
relationship to that dependency.
Please explain where I may be mistaken.
1.1. DERIVATIVE WORK RELATIONSHIPS.
Functional calls to a program invoke a derivative work relationship to the
called program as a dependency of the calling program. The test which I
have used is whether the work as a whole would function if one would
remove a particular dependency.
The relationship is then analogous to the analysis one might give 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 and the book
would not have the same meaning intended in organising the various parts
if a section would be omitted.
Given the rigid linear manner in which program control is generally coded,
omitting a dependency would usually be liable to cause the entire program
to fail.
1.2. MERE DATA LINKING.
Functional calls are very different from mere data linking.
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.
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 hyperlink
and the electronic version with a hyperlink 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.
There is no functional dependency which would necessarily cause program
failure if a data link would be omitted.
1.3. FSF INTERPRETATION.
As far as I have understood, such an interpretation of how the derivative
works concept in copyright law applies to software is the interpretation
which FSF has always advocated and the correct interpretation.
The precise application of the principle for the obligation to provide
Corresponding Source may not always be clear when the user suffers no
harm. The user has little incentive to complain when the user can easily
obtain the Corresponding Source for unmodified dependencies of a program
independently from the conveyance of the source code for base program
which the user is using and which depends upon those independently
available dependencies.
2. QUESTION ABOUT MYSQL.
Please ask Eben Moglen or whomever may be well informed about the history
of the matter whether an express dependency on another program such as
MySQL, which is not modified directly, necessarily establishes a
derivative work relationship to that other program as MySQL AB had claimed
repeatedly.
Koha is not a modification of MySQL directly, however, every program which
uses some MySQL specific SQL not generalised in a database independent
manner may be thought of as extending the functionality of MySQL.
Remember that the general principle is that we want the license to work
for everyone and not have someone add an API or different user interface
at some programming layer apart from Koha and not follow the license for
Koha if relying upon Koha exclusively for some functionality.
This question is not merely an issue about what is reasonable between
different free software communities when everyone has some common
understanding of the spirit of the license and mistakes over details have
no effective consequence. This is an issue where there are companies
which are less well behaved than any company in the business of serving
libraries with books and other information media would ever behave. I
expect that Koha will at some future time include code which may be
considered useful outside the domain of libraries. We will want the
license to be respected for the benefit of the users in every activity to
which the code may be applied.
3. EXTENT OF CORRESPONDING SOURCE.
When you had to depart yesterday we were in the midst of discussing
obligations under the license in terms of what constitutes the
'Corresponding Source' for the obligation to provide the 'Corresponding
Source'.
Are the unmodified Perl modules and their dependencies which are
distributed independently from Koha part of Koha, when considered as a
work as a whole?
[The specific issue of MySQL is raised in the section above.]
While the widest interpretation of the work as whole may impose some
burden of compliance, there may be a safety of assurance of compliance in
a wide interpretation. Yet, we do not want any mere interpretation with
some margin for error, we want to know what is correct. We want to
respect the license and have others respect the license in the same
manner.
Some Perl module Koha dependencies are Perl hooks for C programs which
used in object form for which we would need to supply the source code.
Some Perl modules are express dependencies which are much more significant
than the case of MySQL dependency because there are no alternatives to
some Perl modules. Such Perl modules have no alternatives comparable to
Postgres as a possible alternative to MySQL.
I refer to the text of what I had given as question 5 repeated below.
"Q.5. What would constitute the 'Corresponding Source' for Koha in terms
of dependencies, which would necessarily be part of the work as a whole
for Koha, but which are widely distributed as works as whole in their own
right with no relation to Koha in most contexts?
[Clarity on how the work as a whole necessarily includes dependent works
which also have uses independent of the work as whole is needed. Some
direction about the scope of exceptions to Corresponding Source is needed
to help avoid improper overly broad or overly narrow misinterpretations.
'System Libraries' including any essential 'Major Component' of the
operating system are exceptions. The qualification "which are not part of
the work" limits the exception of "general-purpose tools or generally
available free programs which are used unmodified in performing those
[running and modification] activities but which are not part of the work".
Direction may merely reinforce the obvious but that direction would still
be helpful.
Perhaps Apache would be excluded from the Corresponding Source as a
generally available free program used to run a work designed to run on a
web server. Some may want to exclude MySQL even if it is the particular
database program expressly required. Some may want to exclude generally
available but expressly required Perl modules.
Certainly, copyright law governs what constitutes the work. The license
can specify exceptions to its requirements to allow the practical
realisation of its intent.
The Koha community needs guidance on understanding the intended exceptions
to avoid the temptation to misinterpret the scope of exceptions to
Corresponding Source in an overly broad manner for practical expediency.
On the other side, there may be a temptation to interpret the scope of
exceptions too narrowly and impose an unnecessary burden on compliance.
Significant misinterpretation may risk undermining the meaning of the
license which helps the community function within a legal framework.]"
Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY 10003
USA
http://www.agogme.com
+1 212-674-3783
More information about the Koha
mailing list