[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