[License-discuss] Copyright on APIs

Pamela Chestek pamela at chesteklegal.com
Sun Jun 30 22:12:05 UTC 2019


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>
> *On Behalf Of *Patrice-Emmanuel Schmitz via License-discuss
> *Sent:* Sunday, June 30, 2019 1:13 PM
> *To:* Bruce Perens <bruce at perens.com>
> *Cc:* Patrice-Emmanuel Schmitz <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
> <mailto: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
>     <mailto: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 <mailto: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
>             <mailto: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 <mailto:pe.schmitz at googlemail.com>
>         tel. + 32 478 50 40 65
>
>         _______________________________________________
>         License-discuss mailing list
>         License-discuss at lists.opensource.org
>         <mailto: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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190630/d49c1eea/attachment-0001.html>


More information about the License-discuss mailing list