<div dir="ltr">Dear Till<div>Thank you for this - excellent - analysis.</div><div>You wrote:</div><div><p class="" style="margin-bottom:12pt">The only hint you may find
is Article 6 which says that <span style="background-color:yellow">decompilation
is<br>
allowed under certain circumstances to "achieve the interoperability of an<br>
independently created computer program with other programs".</span></p>

<p class="" style="margin:0in 0in 12pt 0.5in">Written in 1991, the Directive considered decompilation only, based on
the assumption that source code was not communicated to the licensee. The case
of free/open source software looks different because the licensee has
legitimately an access to the source code (no decompilation is needed).
However, this is indeed without importance in my understanding: the idea is that the
legitimate licensee of a software program (received as object code only or as
object + source in the case of FOSS) has the right to inspect and reuse this
code with the purpose “to achieve interoperability”  </p>

<p class="" style="margin-bottom:12pt">There is a definition of
interoperability in recital 10: 'The parts of the program<br>
which provide for such interconnection and interaction between elements of<br>
software and hardware are generally known as "interfaces". This
functional<br>
interconnection and interaction is generally known as
"interoperability";<br>
such interoperability can be defined as the ability to exchange information<br>
and mutually to use the information which has been exchanged. '<br>
<br>
<span style="background-color:yellow">Therefore, my
understanding of the directive is that software, that is<br>
independently created and exchanges information with other software through<br>
an interface, is independent software and not a derivative work.</span></p>

<p class="" style="margin:0in 0in 12pt 0.5in">This is also my own understanding. But it means that linking software
for interoperability (= for exchanging information) makes no derivatives and that
the way of linking (statically producing a single binary or dynamic at runtime)
is just a technical modality without substantial importance regarding
copyright.</p>

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