[License-discuss] Copyright on APIs

Sun Jul 7 08:23:19 UTC 2019

While I haven't closely followed the details of Oracle vs Google, purely
from a layman and business standpoint it seems clear that Google did create
Android / Dalvik exactly to be interoperable with Java. This means one can
run the same Java source code on either platform and the java.* namespace
offers the same packages and functionality. But importantly,
interoperability also goes the other way: Android was compatible with the
millions of developers familiar with Java syntax and standard libraries.

If I remember correctly, Oracle did find early on one function
implementation that had indeed been copy pasted from OpenJDK to Android.
But this was so minor (and obvious) it is not part of the issues decided in
higher courts.

henrik

On Mon, Jul 1, 2019 at 1:43 AM Pamela Chestek <pamela at chesteklegal.com>
wrote:

> The below is all well and good, also the law in the United States, and not
> at issue in Google v. Oracle. Google v. Oracle isn't about interoperability
> of devices or software. Android was not created to interface with Java or
> as a replacement for Java for those devices or programs running Java. The
> case is about whether it was lawful to copy portions of software to enhance
> the ease of development of software for an entirely different software
> ecosystem. I'm not expressing an opinion, simply pointing out that Google
> v. Oracle is a different factual situation than what everyone seems to be
> concerned about.
>
> Pam
>
> Pamela S. Chestek
> Chestek Legal
> PO Box 2492
> Raleigh, NC 27602
> 919-800-8033
> pamela at chesteklegal.com
> www.chesteklegal.com
>
> On 6/30/2019 5:51 PM, Lawrence Rosen wrote:
>
> 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-bounces at lists.opensource.org>
> <license-discuss-bounces at lists.opensource.org> *On Behalf Of *Patrice-Emmanuel
> Schmitz via License-discuss
> *Sent:* Sunday, June 30, 2019 1:13 PM
> *To:* Bruce Perens <bruce at perens.com> <bruce at perens.com>
> *Cc:* Patrice-Emmanuel Schmitz <pe.schmitz at googlemail.com>
> <pe.schmitz at googlemail.com>; license-discuss at 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 Directive
> 2009/24/EC
> <https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32009L0024&from=EN>
> )
>
> 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 <bruce at 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 at 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 <pamela at 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/license-review_lists.opensource.org/2019-April/004056.html
> <http://lists.opensource.org/pipermail/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 at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>
>
>
>
> --
>
> Patrice-Emmanuel Schmitz
> pe.schmitz at googlemail.com
> tel. + 32 478 50 40 65
>
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>
>
>
>
> --
>
> Patrice-Emmanuel Schmitz
> pe.schmitz at googlemail.com
> tel. + 32 478 50 40 65
>
> _______________________________________________
> License-discuss mailing listLicense-discuss at lists.opensource.orghttp://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>
>
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>

-- 
henrik.ingo at avoinelama.fi
+358-40-5697354        skype: henrik.ingo            irc: hingo
www.openlife.cc

My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190707/4fce8d5c/attachment-0001.html>