[License-discuss] [FTF-Legal] Reverse Engineering and Open Source Licenses

Reincke, Karsten k.reincke at telekom.de
Mon Mar 9 16:18:23 UTC 2015


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.

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. 

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:

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.” 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).

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.

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. 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.

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.

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.

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 ]


>  -----Ursprüngliche Nachricht-----
>  Von: license-discuss-bounces at opensource.org [mailto:license-discuss-
>  bounces at opensource.org] Im Auftrag von Ben Tilly
>  Gesendet: Freitag, 6. März 2015 19:29
>  An: License Discuss
>  Betreff: Re: [License-discuss] [FTF-Legal] Reverse Engineering and
>  Open Source Licenses
>  
>  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-
>  discus
>  > s
>  _______________________________________________
>  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