<div dir="ltr">Hi Bruce,<div>This is explicit law if you read <span style="font-family:Calibri,sans-serif;font-size:11pt">Recitals
10 and 15 of </span><span class="gmail-MsoHyperlink" style="font-family:Calibri,sans-serif;font-size:11pt;color:rgb(5,99,193);text-decoration-line:underline"><a href="https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32009L0024&from=EN" style="color:rgb(5,99,193)">Directive
2009/24/EC</a></span><span style="font-family:Calibri,sans-serif;font-size:11pt">)</span></div><div>At the contrary of "articles", recitals does not need to be transposed in national law, as requested in the directive process.</div><div>However, they are part of EU law as well.</div><div>Recitals could not contradict articles (in such very hypothetical case they would have poor binding value).</div><div>But in the case of Directive, there is no contradiction between recitals and articles and - in may opinion - these recitals would be used by the Court of Justice of the EU to interpret the Directive.</div><div>This is just my opinion, since the Directive was not written originally with a focus on open source, but the spirit looks clear.</div><div>The recitals are reproduced hereafter:</div><div><br></div><div> (10) The function of a computer program is to communicate
and work together with other components of a computer
system and with users and, for this purpose, a logical
and, where appropriate, physical interconnection and
interaction is required to permit all elements of
software and hardware to work with other software
and hardware and with users in all the ways in which
they are intended to function. 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. <br></div><div><br></div><div> (15) The unauthorised reproduction, translation, adaptation or
transformation of the form of the code in which a copy
of a computer program has been made available
constitutes an infringement of the exclusive rights of
the author. Nevertheless, circumstances may exist when
such a reproduction of the code and translation of its
form are indispensable to obtain the necessary information to achieve the interoperability of an independently created program with other programs. It has
therefore to be considered that, in these limited circumstances only, performance of the acts of reproduction
and translation by or on behalf of a person having a
right to use a copy of the program is legitimate and
compatible with fair practice and must therefore be
deemed not to require the authorisation of the rightholder. An objective of this exception is to make it
possible to connect all components of a computer
system, including those of different manufacturers, so
that they can work together. Such an exception to the
author's exclusive rights may not be used in a way which
prejudices the legitimate interests of the rightholder or
which conflicts with a normal exploitation of the
program. <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 30 juin 2019 à 00:26, Bruce Perens <<a href="mailto:bruce@perens.com">bruce@perens.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Is this a doctrine, or explicit law?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 29, 2019, 13:59 Patrice-Emmanuel Schmitz via License-discuss <<a href="mailto:license-discuss@lists.opensource.org" target="_blank">license-discuss@lists.opensource.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">As far the European law could be applicable, I just confirm that, for the purpose of interoperability between several components and when you are the legitimate owner or the legitimate licensee of these components, there is a copyright exception regarding their APIs. APIs escape to copyright , meaning also that no license may restrict their reproduction as soon the aim is to make the various components working together. By the way, regarding linking, this invalidates also the theory of strong copyleft, in my opinion.<div>All the best,</div><div>Patrice-Emmanuel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 29 juin 2019 à 15:08, Pamela Chestek <<a href="mailto:pamela@chesteklegal.com" rel="noreferrer" target="_blank">pamela@chesteklegal.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<br>
<div class="gmail-m_4035744437781305658m_720975723019406264gmail-m_8866525935254244560moz-cite-prefix">On 6/28/19 11:40 PM, Bruce Perens via
License-discuss wrote:<br>
</div>
<blockquote type="cite"><span class="gmail-m_4035744437781305658m_720975723019406264gmail-m_8866525935254244560gmail-im" style="color:rgb(80,0,80)">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><i>Until now, the principle of copyleft
has only been applied to literal code, not APIs. The <span class="gmail-m_4035744437781305658m_720975723019406264gmail-m_8866525935254244560gmail-il">license</span> submitter’s proposal is
for a copyleft effect that would apply to new
implementations of the API even when the underlying has
been written from scratch. <a class="gmail-m_4035744437781305658m_720975723019406264gmail-m_8866525935254244560gmail-m_-3438543155154543484gmail-m_-8747199028017241789moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004056.html" rel="noreferrer" target="_blank">http://lists.opensource.org/pipermail/<span class="gmail-m_4035744437781305658m_720975723019406264gmail-m_8866525935254244560gmail-il">license</span>-review_lists.opensource.org/2019-April/004056.html</a>.
The <span class="gmail-m_4035744437781305658m_720975723019406264gmail-m_8866525935254244560gmail-il">license</span> also makes this
extension even if the legal system would not extend
copyright (and therefore copyleft) so far. During the <span class="gmail-m_4035744437781305658m_720975723019406264gmail-m_8866525935254244560gmail-il">license</span>-review process some
commentators objected to this extension of the copyleft
principle this far. However, the <span class="gmail-m_4035744437781305658m_720975723019406264gmail-m_8866525935254244560gmail-il">license</span> review
committee does not believe that there was sufficient
discussion representing all points of view on the <span class="gmail-m_4035744437781305658m_720975723019406264gmail-m_8866525935254244560gmail-il">license</span>-review list and so does
not reject the <span class="gmail-m_4035744437781305658m_720975723019406264gmail-m_8866525935254244560gmail-il">license</span> for
this reason. The <span class="gmail-m_4035744437781305658m_720975723019406264gmail-m_8866525935254244560gmail-il">license</span> submitter
should also be aware that the OSI was a signatory on a
brief submitted to the U.S. Supreme Court advocating
against the copyrightability of APIs. APIs are also known
to be outside the scope of copyright under European law.
We are consequently uncomfortable endorsing an application
of copyright law to APIs in any form without further
discussion.</i></div>
</blockquote>
<div><br>
</div>
</span>
<div>The successful application of copyright to APIs would be a
disaster for Open Source software, in that we would no longer be
able to create Open versions of existing APIs or languages.
Consider that the GNU C compiler is the bootstrap tool of Open
Source. Now, consider what would have happened if copyright
protection had prevented independent implementations of the C
language.</div>
<div><br>
</div>
<div>So, it's a bad idea for us to in any way accept the
application of API copyright today.</div>
<div><br>
</div>
<div>If we actually <i>get </i>API copyrights enforced against us
broadly, we would obviously have to change our strategy. But
until then, we shouldn't go there.</div>
<span class="gmail-m_4035744437781305658m_720975723019406264gmail-m_8866525935254244560gmail-im" style="color:rgb(80,0,80)">
<div> </div>
</span></blockquote>
<br>
</div>
_______________________________________________<br>
License-discuss mailing list<br>
<a href="mailto:License-discuss@lists.opensource.org" rel="noreferrer" target="_blank">License-discuss@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org" rel="noreferrer noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_4035744437781305658m_720975723019406264gmail_signature">Patrice-Emmanuel Schmitz<br><a href="mailto:pe.schmitz@googlemail.com" rel="noreferrer" target="_blank">pe.schmitz@googlemail.com</a><br>tel. + 32 478 50 40 65</div>
_______________________________________________<br>
License-discuss mailing list<br>
<a href="mailto:License-discuss@lists.opensource.org" rel="noreferrer" target="_blank">License-discuss@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org" rel="noreferrer noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Patrice-Emmanuel Schmitz<br><a href="mailto:pe.schmitz@googlemail.com" target="_blank">pe.schmitz@googlemail.com</a><br>tel. + 32 478 50 40 65</div>