[License-discuss] [FTF-Legal] Reverse Engineering and Open Source Licenses
Reincke, Karsten
k.reincke at telekom.de
Fri Mar 6 09:09:56 UTC 2015
Dear Mr. Tilly;
On a first glance, your mail seems to be clear an reasonable. Unfortunately you are impeding the everyday work of those who want and must convince and support their companies, employees and colleagues to use free software compliantly. Let me explain, how your obstruction comes into being:
You delivered a summary classified as “the intended interpretation of the drafters”:
> If you distribute
> code that dynamically links to an LGPL library that is already
> present, you have not created a Combined Work. On the other hand if
> you distribute the library you will dynamically link to with your
> code, you *have* created a Combined Work. There is a grey area where
> you distribute both, but not at the same time.
The meaning(sic!) of this summary perfectly fits the conclusion of my – as you named it - “[…] try to reason […] out from the first principles”:
Following a strict analyses of the (LGPL-v2) licenses text itself, particularly of its §6, one gets a simple logical based rule:
'If you compliantly distribute a work containing portions of the Library, then you have to allow reverse engineering.'
Applying Modus Ponens onto this rule, from the fact, that you distribute a work containing portions of the Library compliantly, it directly and imperatively follows, that you have to allow reverse engineering. Applying Modus Tollens onto this rule, from the fact, that you do not allow reverse engineering, directly and imperatively follows, that you do not compliantly distribute the work containing portions of the Library.
The only open question for applying this rule in praxis is, what a work shall be, that contains portions of the Library. Fortunately, §5 of LGPL v2 delivers clear limits up to which sizes "the object file" of a "work using the library " which contains portions of the library "[...] is unrestricted, regardless of whether it is legally a derivative work".
So, the result of my – as you named it - “try to reason […] out from the first principles” is very similar to your summary: as long as you distribute an object file of the work using the library which contains less elements than the defined limits you are not obliged to allow reverse engineering, in all other cases you are. (For details an sub problems and conditions please see my complete text).
Why do I only say ‘very similar’ instead of ‘equal’. The problem with your summary is this: you do not talk about the license text! Your term “combined work” DOES NOT OCOUR in §6 of LGPL-v2. And this §6 is the only part of the license trying to regulate a necessary permission of reverse engineering. Unfortunately, you also do not link (derive) you paraphrase to (from) the license text. But without using the license text itself or strictly derived paraphrases of the license text, you are talking about your personal opinion. Or about the opinion of a group. This might be important. You might be important. But, we want the users of free software to respect the complete licenses, not the opinions of others concerning these licenses. So, for acting compliantly, there is one central rule: The license text first!!!
Thus, I cannot take your summary and implement a mandatory rule into our company by pointing out “Oh, in the community, there is the famous and well respected Mr. Ben Tilly who says, that if we do not distribute a combined work, than we need not to allow reverse engineering”. Everyone will directly ask me “Nice to hear from Mr. Tilly. But, please show me the corresponding line in the license text itself. Or deliver me at least a step by step analysis which derives this Tilly rule”. You see? There is a gap. The LGPL does not talk about combined works in the context of reverse engineering, neither directly, nor indirectly. Thus your summary does not help, to convince others, even if I fully agree with its' content.
Therefore, your answer is impeding my personal task and – as far as I can see - the wish of FSF to encourage and enable people and companies to use free software compliantly. Although our intended result is the same, you tries to discredit my complex analysis. This analysis is so complex, because it indeed starts by the first principles: the licenses text itself. But speaking about that issue with founding the statements on the license text itself, does not help.
What could you have done instead of this? For example, you could simply have answered:
“Oh my god! What a large document!! More than 20 pages for explaining one sentence!!! But indeed, this document delivers the missing link between the license text itself and the well known more generically formulated position of the FSF. And it delivers this link by reasoning the issue out from the first principles. Of course, it is a hassle, to read all this single steps. But it is good, to have such a step by step analysis.”
And in this case, I would have answered very briefly:
Oh yes, I fully agree with you. A hassle. Even sometimes, when I was writing it. But the meaning of a proof is, that it does the job once for all. Now, one can hint to a work instead of writing all these hassling lines by oneself. And yes, this is a next part of my 'giving back' to the community because I have received so many wonderful software.
Sincerely
Karsten Reincke
--
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: ftf-legal-bounces at fsfeurope.org [mailto:ftf-legal-
> bounces at fsfeurope.org] Im Auftrag von Ben Tilly
> Gesendet: Donnerstag, 5. März 2015 03:51
> An: License Discuss
> Cc: karen.copenhaver at gmail.com; ftf-legal at fsfeurope.org; Schwegler,
> Robert
> Betreff: Re: [FTF-Legal] [License-discuss] Reverse Engineering and
> Open Source Licenses
>
> Sorry, but this is a ridiculously heavyweight way of thinking about
> things. The problem with thinking in a heavyweight fashion is that it
> is easy to lose track of what is going on, and hard for anyone else to
> wade through it and point out the error. However I'll try.
>
> On page 6 you are arguing for a specific interpretation based on your
> claim that an alternate one would not achieve the aims of the drafters
> of the LGPL. But you set up a false dichotomy. There are other
> possible interpretations that you have not considered. And rather
> than trying to reason it out from first principles, it is better to
> just ask the source.
>
> The intended interpretation of the drafters is made clear at
> https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic. They
> distinguish by how the software is distributed. If you distribute
> code that dynamically links to an LGPL library that is already
> present, you have not created a Combined Work. On the other hand if
> you distribute the library you will dynamically link to with your
> code, you *have* created a Combined Work. There is a grey area where
> you distribute both, but not at the same time. My suspicion is that
> they would at that point distinguish based on whether or not you
> intend to link them.
>
> Before you argue against this interpretation, I remind you that your
> argument on page 6 rests on the expertise of the drafters of the
> license. In your words, "We know that the inventors of the GNU
> licenses and GNU software are very sophisticated experts." But if you
> accept them as experts, you are in no position to argue about what
> they say about how their own license is supposed to be interpreted.
>
> For the record, I am not a lawyer. This is not legal advice. And in
> common law countries, until a legal precedent is set, there is no way
> to tell whether the courts will interpret the license in the way that
> the drafters hope they will.
>
> On Wed, Mar 4, 2015 at 7:16 AM, Reincke, Karsten
> <k.reincke at telekom.de> wrote:
> > Dear Colleagues;
> >
> >
> >
> > In the past I was involved in some full discussions concerning the
> > issue ‘reverse engineering and open source licenses’. Although
> > personally esteeming and inspiring, such discussions sometimes
> became a bit explosive:
> > If – at least – the LGPL-v2 indeed requires to allow the reverse
> > engineering of those programs which use LGPL-v2 licensed components,
> > then companies are not able to protect these ‘private’ programs
> > against revealing the embedded business relevant secrets, even if
> they
> > do not distribute the corresponding source code. And – as far as I
> > know – at least some companies have therefore forbidden to link
> essential programs against the LGPL-v2.
> >
> >
> >
> > I have taken the view that this ‘rule of reverse engineering’ cannot
> > be applied in case of distributing dynamically linkable programs.
> By
> > arguing that way, I caused astonishment and dissents. But often, I
> > was also asked to note down my argumentation, because some of my
> > partners wanted to review it in detail. They had the hope to get a
> > solution for conflict of using open source software compliantly and
> > protecting their business relevant software.
> >
> >
> >
> > During the last two month, I had the pleasure to fulfill this
> request
> > by writing the corresponding article. Now, I am indeed sure that all
> > important open source licenses including the LGPL-v2 allow reverse
> > engineering only in case of distributing statically linked programs.
> > Moreover: I am definitely sure, that none of these open source
> > licenses requires to allow reverse engineering in case of
> distributing
> > dynamically linkable programs and that particularly even the LGPL-v2
> > does not require reverse engineering in case of distributing
> dynamically linkable programs.
> >
> >
> >
> > Unfortunately, the deduction of this position had to become more
> > complex than initially thought. But fortunately, it could preserve a
> > straight-forward argumentation: After having started with a
> linguistic
> > disambiguation and transposing the license statements into a logical
> > formula, it derives the results by using logic ways of inferring a
> > conclusion. And this method is applied for the LGPL-v2, for the
> > LGPL-v3, and for the other most important open source licenses.
> Hence,
> > for now, I – for myself - am indeed sure, that my argumentation is
> valid and mandatory.
> >
> >
> >
> > But subjective certainty is not enough. As long as we do not have a
> > legal decision, the best way to become sure is to invoke a
> discussion
> > (and a
> > consensus) by publishing the results. For that purpose, we decided,
> > not only to insert the analysis into the OSLiC, but to distribute
> that
> > chapter also as an autonomous article
> > (http://opensource.telekom.net/oslic/en/planning/results.html ).
> Thus,
> > it is also licensed under the der CC-BY-SA-3.0. So, feel free to use
> > it, to modify it, and/or to share it. The sources of the pdf are
> part
> > of the OSLiC repository (https://github.com/dtag-dbu/oslic/ ).
> >
> >
> >
> > We, Deutsche Telekom AG and I, Karsten Reincke, are indeed hoping to
> > having contributed something which simplifies the compliant use of
> > open source software.
> >
> >
> >
> > With best regards any many thanks for all the encouraging
> discussions
> > - especially to Mrs. Karen Copenhaven, Mr. Armin Taldur, and Mr.
> Claus
> > Peter Wiedemann Sincerely Your Karsten Reincke
> >
> >
> >
> > ---
> >
> > Deutsche Telekom Technik GmbH / Cloud Infrastructure
> >
> > Karsten Reincke, PMP®, Senior Expert Key Projects - Open Stack
> > Complexity- and Compliancemanagement
> >
> > [display complete signatur:
> > http://opensource.telekom.net/kreincke/kr-dtag-sign-en.txt ]
> >
> >
> >
> >
> > _______________________________________________
> > License-discuss mailing list
> > License-discuss at opensource.org
> > http://projects.opensource.org/cgi-bin/mailman/listinfo/license-
> discus
> > s
> >
> _______________________________________________
> FTF-Legal mailing list
> FTF-Legal at fsfeurope.org
> https://mail.fsfeurope.org/mailman/listinfo/ftf-legal
More information about the License-discuss
mailing list