Dear Ben; During the last week, I thoroughly restudied the issues and especially your answers. Now I am going to integrate the discussions of the mailing lists into my article for having a better document than before. But at first let me complete our dispute for being able to generate adequate summaries:
(1) I welcome that we have at least one common viewpoint: the need of allowing reverse engineering is a consequence of the of target to preserve the freedom to update an LGPL licensed library wherever it is used. I am sorry for not having discussed the spirit of reverse engineering in the context of free software. I will add such a section. (2) I think, now I also got the details of your viewpoint: If someone distributes a dynamically linkable application without distributing the library at any point, then it is - as you assume - unclear whether he has also to allow reverse engineering. In your words: it is a grey area. But - as its' opposite - you claimed that distributing said application and library together triggers the copyright license provisions. (3) Based on these two alternatives you summarizes, that my "paper indicates that dynamic linking [totally] gets you out of trouble". You stated that my paper said that "distributing said application and library together does not trigger the copyright license provision". After having restudied all aspects let me clearly answer this: Whenever you distribute an LGPL licensed Library, you have to fully respect all requirements of the LGPL license. (Moreover, you have to respect the conditions even if you are only using it without distributing it.) This does not depend on the way you distribute it: you have to respect the rules regardless whether you distribute the LGPL-lib [a] as part of a statically linked app or [b] as part of a package containing the dynamically linkable app and the lib or [c] as only loosely 'linked' download offers or [d] as an isolated lib-package. This is because distributing a lib - as you wrote - "triggers the copyright license provision". I hope to get an 'exactly' again ;-) Then you asked me by hinting to section 6 and its phrase "combine or link" and to the definition of the preamble concerning a "combined work", whether I refuse to conclude that a combined work that uses dynamic linking is subject to the provisions of section 6? So, it is time to reply: First of all, no part of my article denies this viewpoint. Moreover, it implies the validity of your statement. I do not refuse it! Moreover, I (implicitly) postulate that also distributing a combined work that uses dynamic linking triggers the task to respect the rules of the LGPL. So, by accepting this fact, one of the two main questions is what the LGPL itself says. Accepting THAT you have to respect the rules does not anything about the meaning of the rule. I think that we will easily agree concerning the distribution of the library itself. You have to make known its use, you have to distribute the license text, you have to make accessible the source code of the library, especially if you have modified the lib, etc. etc. But that is not the topic of my article! So, I do not talk about the topic how to compliantly distribute an LGPL library. My article talks about the necessity to allow to reverse engineer the application using the lib. And because I presuppose the validity and responsibility of the LGPL, I analyze what the license text itself says, especially §6. But now we have closed the circle!! In the beginning of our discussion you said that my reading and analyzing of the §6 is "a ridiculously heavyweight way of thinking about things". Now, at the end, our total discussion confirmed me, that it is not: If you accept that you have to respect the license, then you have to read it exactly. And indeed, you can carve out, that §6 contains a condition (roughly) saying, that if you compliantly distribute a work using the library which contains portions of the lib, then you have to allow reverse engineering. And now one directly sees, that the trigger for this rule is the fact that you distribute a work containing portions of the lib. So, the next question is: does a dynamically linkable application contains portions of the lib? And the answer of the question depends on §5 of the LGPL: up to a specific size of such a dynamically linkable application it does not contain portions [even if factually it contains small portions]. Unfortunately, for carving out this argumentation exactly, one has to do a lot of work. I accept, that you do not want to read the article, at least not step by step. No problem! But, as an alternative, picking out some words from the license text without considering the syntactic, semantic, and logical structure of the sentences as whole does not deduce a valid statements about the license text. I regret for not having pointed out, that beside the license text itself there exist a tradition of understanding delivered by additional documents of the copyright holders which may become crucial in case of fighting a legal case. That's the argument of Eben Moglen: With respect to the legal context, the intention and the meaning of a license is not in the license text, it is in the copyright holders. I will add a delimitation into my article which clearly states, that I am talking about the text itself. But I do not regret to emphasize the meaning and the significance of license text itself, especially in its full complexity. Moreover, I think, that to weaken the license text itself by additional exegetical texts and statements damages the open source and free software movement. I believe in the force of the license texts. They have established the free and open source community. They are strong enough to do it in the future, too. Unfortunately, we have to read them in detail. So, I personally will furthermore focus on the 'pure' license text for using open source software compliantly. Primarily I focus on the license as it has been written (and secondly on some constraints of my legal environment.) And I know, that I am in good company: All the distributed free and open source licenses want that the distributed packages of free and open source software contain a copy of the license. So finally, the licensor (copyright holder) himself decided to distribute his conditions of use in form of a license text. Not in form of FAQs, mailing list comments, or anything. He selected the license text as his medium to communicate the rules he wants to be respected. That's why we have to consider the license text. -- Deutsche Telekom Technik GmbH / Infrastructure Cloud Karsten Reincke, PMP®, Senior Experte Key Projekte - Open Stack Komplexitäts- und Compliancemanagement [ komplette Signatur einblenden: http://opensource.telekom.net/kreincke/kr-dtag-sign-de.txt ] > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:license-discuss- > [email protected]] Im Auftrag von Ben Tilly > Gesendet: Montag, 9. März 2015 21:45 > An: License Discuss > Betreff: Re: [License-discuss] [FTF-Legal] Reverse Engineering and > Open Source Licenses > > I will respond inline this time because the conversation got > complicated. > > On Mon, Mar 9, 2015 at 9:18 AM, Reincke, Karsten > <[email protected]> wrote: > > Many thanks for your detailed description. Indeed, I am sorry that > we are reciprocally frustrated with us. > > But I do not want to give up. Let me first summarize – what we both > > accept (even if I until did not talk about it): > > > > The LGPL-v2 has been invented for strategic reasons. No doubt. This > > directly follows from the preamble. Licensing a library under the > > LGPL-v2 shall aim “[…] to encourage the widest possible use of a > > certain library, so that it becomes a de-facto standard”. Or the > “[…] permission to use a particular library in non-free programs > enables a greater number of people to use a large body of free > software.” > > But “although the Lesser General Public License is Less protective > of > > the users' freedom, it does ensure that the user of a program that > is > > linked with the Library has the freedom and the wherewithal to run > that program using a modified version of the Library”. > > That’s the base for the spirit, that in [many|all] cases reverse > > engineering of the work using the library must be allowed. > > Exactly. > > > We are divided over configuring the parameter [many|all]. You say: > The > > LGPL-v2 say ‘all’; I say, the license text say ‘many’. More exactly: > I > > say in case of separately distributing a dynamic linkable > application > > [which is not linked], the LGPL-v2 license text (sic!) does not > require to permit reverse engineering. You have vetoed. > > We have different understandings of where the disagreement is. > > Your paper indicates that dynamic linking gets you out of trouble. I > am saying that if you distribute both library and application > together, dynamic linking does not get you out of trouble. > > I have not said all. Specifically, I have pointed out that it is > permissible to distribute a dynamic linkable application if at no > point do you distribute the library. However I claim that > distributing said application and library together triggers the > copyright license provisions. Your paper said that it doesn't. Do > you agree with me that it doesn't in that case? > > As for separate distribution, I don't consider that guaranteed wrong. > I think it is a grey area. If you > distribute the application, and the library happens to be in an > archive that you maintain a mirror of, I think you should be OK. If > you've got a script that downloads and installs both in 2 separate > http requests, I don't see that the technicality should make it any > different than distributing together. In between there are a million > shades of grey. And I don't know where the line should be. > > > You are arguing for you position by correctly quoting a passage of > the > > preamble and then you refer to the FAQ and finally you conclude “The > > drafters explained, both in the license and in their FAQ, that they > > intended to cover dynamic linking”. With all due respect, I cannot > follow this way of concluding, based on two reasons: > > Really? Section 6 says "combine or link" and the preamble defines a > "combined work". From this you refuse to conclude that a combined > work that uses dynamic linking is subject to the provisions of section > 6? > > What more would it take for you to conclude that? > > > 1) You are quoting the preamble together with its hint that the “ > > General Public License therefore permits such linking only if the > > entire combination fits its criteria of freedom”. But you cannot > > conclude from this requirement of the GPL to maintain the freedom to > > the intended meaning, that the LGPL-v2 requires to permit reverse > engineering. The text you quoted explicitly says, that the “Lesser > General Public License permits more lax criteria for linking other > code with the library.” > > The "more lax criteria" is that you do not have to GPL your code. It > is not that dynamic linking is OK. > > Your argument here is of the form, "They meant to be permissive, so > they must be willing to let me have that cookie as well!" But in fact > the preamble defines a combined work. And section 6 on reverse > engineering says "combine or link". The only reasonable way to read > that is to believe that creating a combined work by using dynamic > linking is meant to trigger the reverse engineering permission. > > > You argumentation ignores that the LGPL-v2 explicitly speaks of a > work > > containing portions of the library (§6) and that it additionally > > states, that up to specific sizes of portions “the use of the object > > file [containing these portions] is unrestricted [sic!!!], > regardless of whether it is legally a derivative work[sic!!!]” (§5). > > I believe that the explicit section reflected the drafter's > understanding of what was legal. But they wanted it explicit so as > not to accidentally discourage allowed usage. > > > 2) But additionally, so you are arguing, the “[…] the drafters > > explained, both in the license and in their FAQ, that they intended > to > > cover dynamic linking”. Unfortunately this is not sufficient: As we > > learned by Eben Moglen, “the measure of the permission is the > > intention of the party giving a license”. The drafters of the > license > > are surely not the authors / copyright holders of all software > licensed under the LGPL-v2. The FAQ (which btw itself is a text) is at > most relevant for all those LGPL licensed software which is published > by its authors. You argumentation is over generalizing. > > I believe that Eben's quote is not entirely correct. And the > discrepancy can go both ways. > > If the licensor wants to give less permissions than they actually > said, a judge can say that they have to stick by what was said. > > If the licensor intended more than what they said, then copyright > passes to someone else, that new someone has to respect what was said > but does not have to be bound by the now unprovable intent. > > As for the FAQ itself, it is more relevant than you indicate. A large > amount of LGPL software is actually copyrighted by the FSF. Many > other people who use the LGPL look to the FSF for guidance as to the > meaning of the license. And judges are inclined to settle unclear > points by both intent and established usage. Which means that the FAQ > is a document that can be introduced to a court and may affect what > decision is handed down. > > No, it is not definitive about what will happen when precedent is set. > But it contains the legal > opinion from the people who drafted the license of what their license > means. > > > So in sum: > > > > First I do not understand why you feel free to highlight some > passages > > of the license text and to ignore other parts. Doing so let become > the > > license a hawker’s tray from which everyone can take what he needs. > > For any question you have to focus on the parts of the license that > address that question. When it comes to reverse engineering, section > 6 says that you cannot distribute a combined or linked application > without allowing reverse engineering. The preamble defines a combined > work. If you are distributing the library, this is more relevant than > trying to divine intent from a section on how much can can be included > in an object file without triggering the license provisions that could > require you to make your code LGPLed. > > > Second, I do not understand why the understanding of the one group > (of > > non software authors) is more important than the interpretation of > the > > other. Following the rule which has been often enough quoted in > these > > thread, it is the intention of author which decides, not the wishes > of the other people. > > More precisely it is the intend of the copyright owner. The FSF is > copyright owner for a lot of important LGPLed libraries. > > > This includes also that I have never and will never encourage other > > people to disregard the authors wishes. If there is an LGPL-v2 > > licensed piece of software and if its author has directly or > > indirectly stated that he requires the permission of reverse > > engineering without any restrictions, then every user has to fulfill > this condition, regardless whether the LGPL-v2 text itself does not. > > This is false. At least under US law. The whole point of a license > is that it gives you a path to having permission. Once you have > permission, it cannot be capriciously taken away. If the author later > wants to add requirements to it such as you need to stand on your > head, pay him a million dollars, or allow reverse engineering of other > software, the author is out of luck. > Permission has been given. > > > Please remind the difference between license and license text as I > > carved out in the answer to Eben Moglen: Mostly, I am talking about > > the license text, not about the license used in a real act of > licensing. > > Your discussion with Eben is on another mailing list. I have not seen > it. > > That said, are you aware that he is the person who wrote the LGPL v2? > And for a long time > was in charge of GPL enforcement for the FSF? If your opinion differs > substantially from his, that's good reason to believe that you are > wrong. > > > > > > With best regards > > KR > > > > -- > > Deutsche Telekom Technik GmbH / Infrastructure Cloud Karsten > Reincke, > > PMP®, Senior Experte Key Projekte - Open Stack Komplexitäts- und > > Compliancemanagement [ komplette Signatur einblenden: > > http://opensource.telekom.net/kreincke/kr-dtag-sign-de.txt ] > [previous discussion snipped] > _______________________________________________ > License-discuss mailing list > [email protected] > http://projects.opensource.org/cgi-bin/mailman/listinfo/license- > discuss _______________________________________________ License-discuss mailing list [email protected] http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
