Thank you again Patrice-Emanuel, and thanks also to the EU for a much clearer
explanation of functional software interfaces ("APIs") than the brief but
equally relevant provision in 17 USC 102(b). I hope the US Supreme Court is as
clear in its decision in the Oracle v. Google case.
OSI should let "strong copyleft" die peacefully among the mistaken theories of
open source in any future licenses it approves. It is not a positive feature of
"software freedom."
Best, /Larry
From: License-discuss <license-discuss-boun...@lists.opensource.org> On Behalf
Of Patrice-Emmanuel Schmitz via License-discuss
Sent: Sunday, June 30, 2019 1:13 PM
To: Bruce Perens <br...@perens.com>
Cc: Patrice-Emmanuel Schmitz <pe.schm...@googlemail.com>;
license-discuss@lists.opensource.org
Subject: Re: [License-discuss] [License-review] Copyright on APIs
Hi Bruce,
This is explicit law if you read Recitals 10 and 15 of
<https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32009L0024&from=EN>
Directive 2009/24/EC)
At the contrary of "articles", recitals does not need to be transposed in
national law, as requested in the directive process.
However, they are part of EU law as well.
Recitals could not contradict articles (in such very hypothetical case they
would have poor binding value).
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.
This is just my opinion, since the Directive was not written originally with a
focus on open source, but the spirit looks clear.
The recitals are reproduced hereafter:
(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.
(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.
Le dim. 30 juin 2019 à 00:26, Bruce Perens <br...@perens.com
<mailto:br...@perens.com> > a écrit :
Is this a doctrine, or explicit law?
On Sat, Jun 29, 2019, 13:59 Patrice-Emmanuel Schmitz via License-discuss
<license-discuss@lists.opensource.org
<mailto:license-discuss@lists.opensource.org> > wrote:
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.
All the best,
Patrice-Emmanuel
Le sam. 29 juin 2019 à 15:08, Pamela Chestek <pam...@chesteklegal.com
<mailto:pam...@chesteklegal.com> > a écrit :
On 6/28/19 11:40 PM, Bruce Perens via License-discuss wrote:
Until now, the principle of copyleft has only been applied to literal code, not
APIs. The license 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. http://lists.opensource.org/pipermail/
<http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004056.html>
license-review_lists.opensource.org/2019-April/004056.html. The license also
makes this extension even if the legal system would not extend copyright (and
therefore copyleft) so far. During the license-review process some commentators
objected to this extension of the copyleft principle this far. However, the
license review committee does not believe that there was sufficient discussion
representing all points of view on the license-review list and so does not
reject the license for this reason. The license 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.
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.
So, it's a bad idea for us to in any way accept the application of API
copyright today.
If we actually get API copyrights enforced against us broadly, we would
obviously have to change our strategy. But until then, we shouldn't go there.
_______________________________________________
License-discuss mailing list
License-discuss@lists.opensource.org
<mailto:License-discuss@lists.opensource.org>
http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
--
Patrice-Emmanuel Schmitz
pe.schm...@googlemail.com <mailto:pe.schm...@googlemail.com>
tel. + 32 478 50 40 65
_______________________________________________
License-discuss mailing list
License-discuss@lists.opensource.org
<mailto:License-discuss@lists.opensource.org>
http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
--
Patrice-Emmanuel Schmitz
pe.schm...@googlemail.com <mailto:pe.schm...@googlemail.com>
tel. + 32 478 50 40 65
_______________________________________________
License-discuss mailing list
License-discuss@lists.opensource.org
http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
