[License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com

Wed Sep 11 04:00:10 UTC 2013

Hi Til:

Thanks very much for this thoughtful analysis.  Are you planning to post to the ftf list as well?

G.
On Sep 10, 2013, at 10:24 AM, Till Jaeger <jaeger at jbb.de> wrote:

> Dear list,
> 
> Bradley and Larry have asked me to share my view as a European lawyer on the
> question if linking of software components (necessarily) results in a
> "derivative work" as understood by the GPL. In a nutshell, my thoughts are
> the following (a more comprehensive overview can be found at
> http://www.ifross.org/Druckfassung/Ziffer%202.pdf, unfortunately in German
> only):
> 
> 1.
> As far as I know there is no relevant case law on the question of what may
> be considered a "derivative work" under European copyright law for software.
> 
> European software copyright law has been harmonized
> (http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:111:0016:01:EN:HTML)
> since 1991.
> 
> In my opinion "derivative work" in software law should have a different
> meaning than in other fields of copyright law.
> 
> Software is typically interacting with other software, and dependencies
> (e.g. an application running on an operating system) do not necessarily mean
> that two components form a derivative work.
> 
> 2.
> GPLv3 refers to copyright law ('To “modify” a work means to copy from or
> adapt all or part of the work in a fashion requiring copyright permission,
> other than the making of an exact copy') whereas GPLv2 might be interpreted
> in a way that the understanding of "derivative work" is broader. In this
> regard the GPLv2 seems to be a bit contradictory to me. On the one hand it
> defines 'a "work based on the Program"'as  “either the Program or any
> derivative work under copyright law", on the other hand sec. 2 contains a
> more detailed explanation of what the term "derivative work" is supposed to
> mean within the scope of the GPLv2 ("If identifiable sections of that work
> are not derived from the Program, and can be reasonably considered
> independent and separate works in themselves, then this License, and its
> terms, do not apply to those sections when you distribute them as separate
> works."). Apparently, a computer program which is _not_ derived from GPL
> code has nonetheless to be licensed under the GPLv2 when the original GPL
> code and the program are not distributed "as separate works".
> 
> If you do not want to ignore that language you have to find a meaningful
> interpretation for this sentence in sec. 2 of the GPLv2. To me, it makes
> sense to understand "distribute them as separate work" as a formal
> criterion, i.e. distributing one binary blob makes it "one work" instead of
> two or more "separate works". Of course, other interpretations are possible.
> 
> 3.
> I think it is very difficult to predict how the European Court of Justice
> (ECJ) would interpret the phrase "adaptation, arrangement and any other
> alteration of a computer program" as used in Article 4.1 (b) of the
> Directive 2009/24/EC.
> 
> The only hint you may find is Article 6 which says that decompilation is
> allowed under certain circumstances to "achieve the interoperability of an
> independently created computer program with other programs". There is a
> definition of interoperability in recital 10: 'The parts of the program
> which provide for such interconnection and interaction between elements of
> software and hardware are generally known as "interfaces". This functional
> interconnection and interaction is generally known as "interoperability";
> such interoperability can be defined as the ability to exchange information
> and mutually to use the information which has been exchanged. '
> 
> Therefore, my understanding of the directive is that software, that is
> independently created and exchanges information with other software through
> an interface, is independent software and not a derivative work.
> 
> However, it is unclear which kinds of interfaces fall within the scope of
> the directive. The text is from 1991 when Java and other object oriented
> programming was not known at that time (or not as common as it is today).
> 
> 4.
> If linked software should be considered a derivative work (under the
> GPLv2 and GPLv3) is truly difficult to judge. With regard to the
> aforementioned criteria I come to the following conclusions:
> 
> a)
> From the perspective of copyright law the way how two parts of a program
> interact _technically_ with each other may provide an indication about the
> derivative work question. However, the technical fact by itself that two
> components are linked with each other does not necessarily lead to the
> conclusion that the combination is or is not a derivative work.
> 
> b)
> If a developer modifies an existing program and puts the added code in a
> library instead of the existing files the code in the library would still be
> a derivative work. A modified program is a modified program, and one might
> not circumvent this legal effect just by moving code into a library.
> 
> However, the situation might be different if an independently created
> application uses an existing standard library. You could argue
> that the application uses the interface of the library, and linking is just
> a matter of interoperability, which seems convincing to me. But you might
> also consider that there is a widely accepted opinion that linking results
> regularly in creating a derivative work under the GPL, and accordingly a
> customary business practice has been brought into existence.
> 
> c)
> The situation might be different in the case of statically linked libraries.
> If you agree with the interpretation of the GPLv2 I proposed above, the
> program and the statically linked library are not distributed "as separate
> works" and therefore the copyleft applies.
> 
> 5.
> The situation is far from being clear. I do not claim to have the
> "right" answer to the question on hand. But I think that we need more
> exchange between lawyers and software engineers for developing our view on
> the issue of linking, an issue courts will have to deal with one day.
> 
> Best regards,
> 
> Till
> 
> --
> Dr. Till Jaeger
> Certified Copyright and Media Law Attorney
> 
> 
> JBB Rechtsanwälte
> Jaschinski Biere Brexl Partnerschaft
> Christinenstraße 18/19 | 10119 Berlin
> Tel. +49.30.443 765 0  |  Fax +49.30.443 765 22
> Sitz der Gesellschaft: Berlin | Registergericht AG Charlottenburg | PR 609 B
> www.jbb.de
> 
> 
> 
> 
> Am 29.08.2013 22:33, schrieb Bradley M. Kuhn:
>> Larry, I will be more direct since you aren't getting my subtle hints.  If
>> you think I've misquoted Till and am somehow damaging his professional
>> reputation, then just say that, simply, to Till, and give him the source, and
>> I'm sure Till will take the matter up with me if he agrees with you.
>> 
>> Larry, I think what you're actually doing is wasting Till's valuable time.
>> 
>> Till, just in case you do want to see it, without having to search around, the
>> email where I referenced you is at:
>> http://projects.opensource.org/pipermail/license-discuss/2013-August/001181.html
>> 
>> The specific text that I wrote that mentions you is:
>>>> BTW, if you are interested in how the European lawyers view this question,
>>>> I refer you to an excellent talk by Till Jaeger at FOSDEM 2013:
>>>> http://www.faif.us/cast/2013/mar/26/0x39/
>> 
>> As you can see, Larry, I didn't, as you claim, represent that Till supported
>> any of my positions.
>> 
>> Till, thanks again for giving that excellent talk on our track at FOSDEM 2013!
>> I'm truly sorry that you've been dragged in to this conversation, and I had
>> no idea that sharing the audio of your useful talk with others would cause
>> these sorts of unsolicited emails from Larry.
>> 
>>   -- bkuhn
>> .
>> 
> _______________________________________________
> License-discuss mailing list
> License-discuss at opensource.org
> http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss