[License-discuss] [FTF-Legal] Reverse Engineering and Open Source Licenses
Ben Tilly
btilly at gmail.com
Fri Mar 6 18:28:31 UTC 2015
There is a significant problem with the abbreviated version that you
wish I had said. I believe your analysis is wrong when you concluded
that dynamic linking is enough to escape the reverse engineering
provision. It would therefore be a lie for me to say something like,
"But indeed, this document delivers the missing link between the
license text itself and the well known more generically formulated
position of the FSF."
Now I know you are frustrated with me. You believe that you've found
good reason to believe that using LGPL software is safer than others
believe. You want more people to use free software. You think I am
impeding that.
However the frustration goes both ways. I think it is a bad thing to
convince people to use free software in ways that the authors of said
software think is non-compliant. People choose to use the LGPL as a
strategy to push others to make free software. If their goal was
simple to make their software widely used, they would have used a less
restrictive license. That they purposefully didn't do. I believe
that you do them a serious disservice when you encourage other people
to disregard the author's wishes. I further believe that convenience
is not a sufficient reason to do so.
What is their intent? You argue that they intended to allow dynamic
linking. However the FAQ put out by the organization which drafted
the license in question says that they didn't intend that. You
complain that I didn't quote the license itself to make my point. So
let me fix that by quoting the preamble of the LGPL v2:
"When a program is linked with a library, whether statically or using
a shared library, the combination of the two is legally speaking a
combined work, a derivative of the original library. The ordinary
General Public License therefore permits such linking only if the
entire combination fits its criteria of freedom. The Lesser General
Public License permits more lax criteria for linking other code with
the library. "
Clearly their belief, AS STATED IN THE LICENSE, is that dynamic
linking suffices to make a combined work. Furthermore their actual
intent goes farther. The belief of the FSF is, as stated at
https://www.gnu.org/philosophy/shouldbefree.html, is that all software
should be free, and non-free software is evil. They can't actually
make this happen, so they have instead decided to maximize how much
free software there is. All of their activities, including licenses
and software, are strategies to that end.
Please digest that. The FSF uses the LGPL strategically when they
think it will result in more organizations being pushed to create free
software than the GPL would. That is their explicit goal. Until you
understand that, you will never understand their intent. (As, indeed,
you did not on page 6 of your paper.)
Why, then, would they say in their FAQ that you are not restricted by
the license if you distribute an application that dynamically links to
a library already on the user's machine? I explained that in a
different email. Under US copyright law, you can develop, compile,
and distribute a dynamically linked application without ever doing
anything restricted by copyright law. Therefore there is no need to
accept a copyright license to do so. You only need to accept that
license if you distribute the LGPL library. The LGPL v2 and that FAQ
were written by people who were familiar with US law and not (at the
time) with international law. (That is one of the things that v3 was
trying to fix.)
So where do we stand?
1. On page 6 you reasoned that their intent could not be to restrict
all dynamic linking because it would lead to ridiculous consequences.
But those ridiculous consequences are, in fact, their openly stated
goal.
2. The drafters explained, both in the license and in their FAQ, that
they intended to cover dynamic linking.
3. I have explained an apparent discrepancy between what their FAQ
says and what is in the license.
My background is in mathematics. I well know what it is like to have
an apparently solid proof fall apart at a key step. I have sympathy
with the temptation to believe in the proof, even though you have a
gap. I know the temptation to hold on to it even when confronted with
contrary evidence.
But it is important to face reality as it is, and not as we would wish
it to be. And reality is that the drafters of the LGPL intended to
allow you to dynamically link to LGPL libraries only if you are
willing to allow others to attempt reverse engineering your code. And
their license did as much to achieve that goal as they thought they
could under US law.
On Fri, Mar 6, 2015 at 1:09 AM, Reincke, Karsten <k.reincke at telekom.de> wrote:
> 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
> _______________________________________________
> License-discuss mailing list
> License-discuss at opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
More information about the License-discuss
mailing list