Aaron Williamson at Software Freedom Law Center (SFLC) has reached a consistent conclusion about the Corresponding Source for AGPL 3. Our correspondence is quoted further below. [I had previously posted the oldest two messages in this set which I include within this message for continuity. Messages are copied exactly except for my correction of a usage mistake in which I have substituted 'automating' for the originally mistaken use of 'automation'.] Each of us had to correct an earlier mistake in our analysis to see the issue clearly. As I have stated previously, the difficulty is not that AGPL 3 is new and untested as MJ Ray argues. The difficulty had been that AGPL 3 is sufficiently new that SFLC has lacked the familiarity of experience to already have well thought out answers to some questions about applying AGPL 3. 1. SOURCE CODE OBLIGATIONS FOR GPL 2, GPL 3, AND AGPL 3. The AGPL 3 specific obligations are the obligations to remote network users of a program under AGPL 3. All other license obligations under AGPL 3 are obligations common to GPL 3. 1.1. GPL SOURCE CODE OBLIGATIONS. I use GPL 3 terminology but the conditions apply equally well to GPL 2. While the base files for Koha only exist in source code form, for any conveyance of them outside of AGPL 3 specific obligations where there is no remote network user, the Corresponding Source is nothing more than whatever source code has actually been conveyed. The Corresponding Source in such a circumstance is as much or as little source code as is conveyed to the user. If an incomplete or non-functional version of the code is conveyed under such a circumstance there is no license obligation to convey a complete or functional version. Such a circumstance is the circumstance which we always have now under GPL 2 and would always have if we would adopt GPL 3 as the license for Koha. Such a circumstance is also the circumstance which we would have if we would adopt AGPL 3 as the license for Koha and the party to whom the source code would be conveyed would happen not to be a remote network user of the program. My previous mistake had been not to take source code only conveyance under GPL 3 to its logical conclusion. 1.2. AGPL 3 SOURCE CODE OBLIGATIONS. The Corresponding Source under AGPL 3 is considered to be object code form for the purposes of the license obligations when a user uses a program remotely over the network. All functional uses of software are object code form. Corresponding Source is only source code form when the user is using a particular version for which he already has the source code. The significant consequence of the fact that the object code form applies is that the Corresponding Source in object code form includes unmodified third party modules. The license definition of Corresponding Source is not increasing the scope of the work which constitutes the program. The license definition of Corresponding Source merely provides correct guidance for object code form in conformity with a reasonable and correct interpretation of how copyright law should be applied to software in determining the scope of the work. There is a similar definition of source code in executable form in GPL 2 section 3.
From the definition in GPL 3 and AGPL 3 section 1:
"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