Re: parse Alsup decision: any, all, some was Re: Oracle vs Google: APIs are copyright; appeal decision

[Thufir]

On 10/23/2014 05:13 AM, Kern Sibbald wrote:

On 14-10-23 06:49 AM, Ralph Corderoy wrote:

Hi Thufir,


My understanding is, and I know Luke disagrees violently,

I doubt he's the only one;  perhaps the others, like me, just can't be
bothered to entertain that an API can be copyrighted, and calling it an
SSO doesn't make it any more sensible.


is that SSO is a *useful* shorthand for API.

No shorthand is needed.  They are distinct concepts.  Both three letters
long.  :-)


Maybe this is already clear, but perhaps on should stress that API = 
"Interface specification or template" and SSO (in this case) = 
"copyrightable code" that implements the API.


The appeals court write about the SSO of an API.  So, no, I disagree 
with that interpretation, based on the usage by the appeals court, and 
that, when Alsup writes about the SSO of a computer program, I don't 
think he means the implementing code, but, literally, the Structure, 
Sequence and Organization of, in this case, the 37 Java API's.


If Alsup meant the implementing code, then he would've written that, 
instead of the SSO of the computer program.  In the contentious, 
inflammatory remark by Alsup, he was generalizing to any computer 
program, of course.  I think this was a deliberate choice on his part in 
considering the broader question of the purpose of copyright itself, 
because it's been suggested, since I think the beginning, that this case 
could go to the Supreme Court.


(Yes, Alsup does draw the conclusion that because the elements of the 
Java API are freely available (and I would contest that notion), this 
makes the SSO available to copied.  I don't take that at all to mean 
that the SSO is, or can be equated to, the implementing code. Google 
never said that it didn't copy the method signatures, but did maintain 
that the implementing code was farmed out.)


The wikipedia entry on SSO seems, to me, very even handed.


-Thufir

Re: parse Alsup decision: any, all, some was Re: Oracle vs Google: APIs are copyright; appeal decision

[Kern Sibbald]

On 14-10-23 06:49 AM, Ralph Corderoy wrote:

Hi Thufir,


My understanding is, and I know Luke disagrees violently,

I doubt he's the only one;  perhaps the others, like me, just can't be
bothered to entertain that an API can be copyrighted, and calling it an
SSO doesn't make it any more sensible.


is that SSO is a *useful* shorthand for API.

No shorthand is needed.  They are distinct concepts.  Both three letters
long.  :-)


Maybe this is already clear, but perhaps on should stress that API = 
"Interface specification or template" and SSO (in this case) = 
"copyrightable code" that implements the API.




Cheers, Ralph.

Re: parse Alsup decision: any, all, some was Re: Oracle vs Google: APIs are copyright; appeal decision

[lkcl .]

On Thu, Oct 23, 2014 at 12:33 AM, Robinson Tryon
 wrote:
> On Wed, Oct 22, 2014 at 12:11 AM, Neil Brown  wrote:
>> On 21 Oct 2014, at 18:26, Robinson Tryon  wrote:

> 1) Does the FSF believe that the SSO of a computer program should have
> no restrictions on its use?
>
> As Luke mentioned, the FSF would likely be in favor of unrestricted
> use of "function names, arguments, semantics, [and] error codes".

 not "in favour of" - actively working to do everything they can to
ensure access is unrestricted (just as it is expressely if verbiagely
described and permitted under the EU Copyright Directive of 2009).
the GNU project exists because of this belief and situation; the
rights that permitted them Dr Stallman to even *begin* the GNU project
are something that the FSF believes strongly should be granted to
everyone.

to do otherwise is completely hypocritical and is akin to starting a
revolution claiming to overthrow restrictions on free speech... and
then once winning saying "but i meant only _my_ speech should be
free".

 the fact that any GNU or GPL code may be re-engineered as a result is
entirely within the free (as in speech) rights of the individuals
deciding to make interoperable code.  in certain instances they'd have
to be off their heads or just very very rich, but it is within their
rights.

 in fact, under the laws enacted within European Member States as
instructed by the 2009 Copyright Directive, for the FSF (or anyone
else for that matter) to even *attempt* to restrict anyone from
creating interoperable code would get them into a whole boat-load of
trouble.

 in short, if the U.S. permits APIs to become copyrighted it's going
to be isolated in doing so and will end up butting heads with the E.U.
member states.

l.

Re: parse Alsup decision: any, all, some was Re: Oracle vs Google: APIs are copyright; appeal decision

[lkcl .]

On Thu, Oct 23, 2014 at 11:49 AM, Ralph Corderoy  wrote:
> Hi Thufir,
>
>> My understanding is, and I know Luke disagrees violently,

 ... i neither disagree nor do so with violence.  this statement has
made things unclear by being untrue.

> I doubt he's the only one;  perhaps the others, like me, just can't be
> bothered to entertain that an API can be copyrighted, and calling it an
> SSO doesn't make it any more sensible.
>
>> is that SSO is a *useful* shorthand for API.
>
> No shorthand is needed.  They are distinct concepts.  Both three letters
> long.  :-)

 :)

 my take on the original case (where SSO came up... in the 1970s?) is
that it was between two myopic ham-fisted giants fighting over a quail
farm, not caring if they killed the quails, crushed the eggs and
destroyed the farm itself for both themselves and their descendents in
the process.

 in other words it was two (otherwise highly educated in their field
of law) lay-people trying to get to grips with how software works;
they failed to educate themselves on even the most basic of software
concepts, inventing their own terminology in the process, and, being
so utterly clueless about software, have made it incredibly difficult
for anyone in the software industry to follow or discuss.

 regarding SSO and API: the ridiculous over-simplistic and general TLA
"SSO" as i understand it, it *very broadly* encompasses the concept of
what programmers understand APIs to be, and, unfortunately, covers a
hell of a lot more in a way that is completely unclear.

 by complete contrast, the language of the EU 2009 Copyright Directive
(very grateful to the fsfeurope team for bringing it up) is not only
clear but also uses terms with which both the computing industry *and*
lay-people can get to grips with [*1]

l.

[*1] if they are prepared to be gasping for mental breath at the end
of reading each section because of the lack of full-stops, that is.

Re: parse Alsup decision: any, all, some was Re: Oracle vs Google: APIs are copyright; appeal decision

[Ralph Corderoy]

Hi Thufir,

> My understanding is, and I know Luke disagrees violently,

I doubt he's the only one;  perhaps the others, like me, just can't be
bothered to entertain that an API can be copyrighted, and calling it an
SSO doesn't make it any more sensible.

> is that SSO is a *useful* shorthand for API.

No shorthand is needed.  They are distinct concepts.  Both three letters
long.  :-)

Cheers, Ralph.

Re: parse Alsup decision: any, all, some was Re: Oracle vs Google: APIs are copyright; appeal decision

[Robinson Tryon]

On Wed, Oct 22, 2014 at 12:11 AM, Neil Brown  wrote:
> On 21 Oct 2014, at 18:26, Robinson Tryon  wrote:
>
> I don't get the point of discussing the linguistic intricacies at the
> same time as discussing the legal points without pointing out up-front
> that the word choice is likely to be viewed as inflammatory.
>
>
> My recollection was that thufir did point out at the very beginning that
> s/he was using the words of the judgment, rather than his/her own choice of
> words:

I think part of the problem here is that we're not talking about a
multi-word quote, encased in quotation marks each time; we're talking
about a single verb "to steal," conjugated in multiple forms, and used
in several emails in a lengthy thread.

> "It's remarkable that the trial judge and the appeal judge use
> a word like stolen, and not "infringe" or other legal mumbo jumbo."

Here's that sentence with some more context:

---
' Though the trial court did add the caveat that it “does not hold that
the structure, sequence and organization of all computer programs may be
stolen,”...'

I cannot fathom why the FSF is on the side of letting API's get copied, I
mean stolen. Do they not see the result this would have on the GPL? Or,
do they see a larger issue? Or, do they just think that it's not
stealing? It's remarkable that the trial judge and the appeal judge use
a word like stolen, and not "infringe" or other legal mumbo jumbo.
---

The entire premise of the paragraph hinged on the verb, not on the
underlying question of whether the law was broken. You want to discuss
language choice in a ruling? Let's go ahead, but I find it confusing
to use the word choice of the judge when forming a statement like "I
cannot fathom why the FSF is on the side of letting API's get copied,
I mean stolen".

Also in a follow-up email: "The FSF is ok with, in the words of not
just the appeals court, but the original trial judge, stealing the SSO
of a computer program?"

Technically speaking, my understanding is that the FSF is in favor of
weak restrictions on API reuse that are *akin* to what the courts *may
have* meant when they used the word "stolen," but to #DEFINE the words
'stolen/stealing' for the purposes of this thread seems unnecessarily
complicated and potentially misleading when it's unclear whether or
not what happened in this case was ever classified as 'stealing'.

Much simpler is to just use two separate questions:

1) Does the FSF believe that the SSO of a computer program should have
no restrictions on its use?

As Luke mentioned, the FSF would likely be in favor of unrestricted
use of "function names, arguments, semantics, [and] error codes".

2) What did the trial judge and appeals court mean by the word
"stolen"? Was there any clarity on what types of use of SSO could be
classified as "stealing" ?

(good question; not sure I've read enough of the rulings to answer it :-)


Best,
--R

-- 
Robinson Tryon
QA Engineer - The Document Foundation
LibreOffice Community Outreach Herald
qu...@libreoffice.org

Re: parse Alsup decision: any, all, some was Re: Oracle vs Google: APIs are copyright; appeal decision

[Thufir]

n Wed, Oct 22, 2014 at 12:11 AM, Neil Brown  wrote:

>
> On 21 Oct 2014, at 18:26, Robinson Tryon 
> wrote:
>
>
> I don't get the point of discussing the linguistic intricacies at the
> same time as discussing the legal points without pointing out up-front
> that the word choice is likely to be viewed as inflammatory.
>
>
> My recollection was that thufir did point out at the very beginning that
> s/he was using the words of the judgment, rather than his/her own choice of
> words:
>
> "It's remarkable that the trial judge and the appeal judge use
> a word like stolen, and not "infringe" or other legal mumbo jumbo."
>
>
>
>
>
thanks for noting that, Neil.

Was Alsup intending to setup a straw-man argument?  I don't think so, I
think he was genuinely trying to answer that question.  I can only
speculate, but I'm guessing that he considered this possibility after
arriving at his decision and was then considering what the ramifications
would be.

It's more than ironic that the appeals court, to my mind, wrote a decision
which would actually protect open source, publicly available GPL software.

The only real-world consequences of upholding Alsup's reasoning would be
that any sufficiently popular GPL protected software will eventually get
the same treatment and end up under the ASL.  Theoretically, it could be
any software, and, theoretically, it could be made totally closed-source,
proprietary, but I don't see that happening.

My understanding is, and I know Luke disagrees violently, is that SSO is a
*useful* shorthand for API.  The appeals write about SSO in the context of
an API, that an API has a SSO.  No one, not the appeals court, not the
original Judge, Alsup, have ever suggested copyrighting an actual API.

I would ask and encourage not to consider the advisability of "copyrighting
an API," but:

what would've forced, or would force the next time, Google to have used the
GPL?


-Thufir

Re: parse Alsup decision: any, all, some was Re: Oracle vs Google: APIs are copyright; appeal decision

[Neil Brown]

On 21 Oct 2014, at 18:26, Robinson Tryon  wrote:
> 
> I don't get the point of discussing the linguistic intricacies at the
> same time as discussing the legal points without pointing out up-front
> that the word choice is likely to be viewed as inflammatory.

My recollection was that thufir did point out at the very beginning that s/he 
was using the words of the judgment, rather than his/her own choice of words:

"It's remarkable that the trial judge and the appeal judge use
a word like stolen, and not "infringe" or other legal mumbo jumbo."

Best wishes

Neil

__

Neil Brown
n...@neilzone.co.uk | http://neilzone.co.uk

Re: Oracle vs Google: APIs are copyright; appeal decision

[Thomas Charron]

On Sat, Oct 18, 2014 at 1:26 AM, thufir  wrote:

> However, to allow the SSO of any, and let's emphasize **any** computer
> program, to be stolen, and let's use the word stolen, that would be a
> dramatic shift.  Yes/no?
>
> If there's no way to enforce SSO under copyright, then any SSO can be
> **stolen** -- which is the word being used by the judges in this case.  the
> appeals court chose to write about the wider implications, so I'm adopting
> the language of first judge, and the appeals court, to use **any** and
> **stolen**.
>

  Here is where the crux of whatever point you are trying to make falls
apart.  SSO != the API.  The API is *PART* of SSO, but it is not, by
itself, the entirety of SSO.  For example, I may have a copyright on a book
with 10 chapters, with names A thru J.  If someone else makes a boot with
the same chapter names, did they step on my copyright?  Perhaps.  Did they
steal my book?  Obviously not.

  SSO is more then just the API.  Abstraction Filtration Comparison tests
have been used in trying to identify if something had indeed been stolen.
Your narrowly looking at one aspect.  You're also incorrectly making the
possibly blatant copy of a source file mean the same thing as
reimplementing an API.  They are DIFFERENT.

-- 
-- Thomas

Re: Oracle vs Google: APIs are copyright; appeal decision

[Thomas Charron]

On Tue, Oct 21, 2014 at 2:15 AM, thufir  wrote:

>
> Consider three outcomes from the upcoming SCOTUS trial:
>
> 1.)  The SSO of any computer program may be stolen.
> 2.)  The SSO of some computer program may be stolen.
> 3.)  The SSO of no computer program may be stolen.
>
> Only under the third outcome would Google have been forced to either
> obtain a license or to put Dalvik under the GPL.
>


  Option 4.  Google infringed on the copyrights, but did not steal the SSO
of the JVM.

-- 
-- Thomas

Re: parse Alsup decision: any, all, some was Re: Oracle vs Google: APIs are copyright; appeal decision

[Robinson Tryon]

On Tue, Oct 21, 2014 at 10:06 AM, thufir  wrote:
> On 14-10-21 09:24 AM, Robinson Tryon wrote:
>>>
>>> >  So, now, for any GPL licensed program I can think
>>> >of, it's now possible, by Alsup's reasoning, to steal the SSO.
>>
>> On the crudest of linguistic levels, I guess that one could say that,
>> but I think that in this context the phrase "to steal" is rather
>> misleading.
>
> The appeals court not only echo Alsup's language choice, but write that, to
> apply his reasoning to other software, it's hard to come to any other
> conclusion.  Yes, I deliberately chose inflammatory language, exactly
> because it was so interesting.

Choosing to *discuss* particulars of a language choice is interesting.
I don't get the point of discussing the linguistic intricacies at the
same time as discussing the legal points without pointing out up-front
that the word choice is likely to be viewed as inflammatory.
Otherwise, you're just going to confuse some people, and annoy a bunch
more.

But perhaps that was the intended point.

--R

-- 
Robinson Tryon
QA Engineer - The Document Foundation
LibreOffice Community Outreach Herald
qu...@libreoffice.org

Re: parse Alsup decision: any, all, some was Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-21 09:24 AM, Robinson Tryon wrote:

>  So, now, for any GPL licensed program I can think
>of, it's now possible, by Alsup's reasoning, to steal the SSO.

On the crudest of linguistic levels, I guess that one could say that,
but I think that in this context the phrase "to steal" is rather
misleading.


The appeals court not only echo Alsup's language choice, but write that, 
to apply his reasoning to other software, it's hard to come to any other 
conclusion.  Yes, I deliberately chose inflammatory language, exactly 
because it was so interesting.



-Thufir

Re: parse Alsup decision: any, all, some was Re: Oracle vs Google: APIs are copyright; appeal decision

[Robinson Tryon]

On Mon, Oct 20, 2014 at 1:47 PM, thufir  wrote:
> On 14-10-20 01:18 AM, Robinson Tryon wrote:
>> I can see how on a cursory examination one might read "it does not
>> hold that SSO of all programs may be stolen", and be confused that it
>> implies "some SSO may be stolen", but the next sentence states that
>> (in the court's view) the elements in question were free for all under
>> the Copyright Act (which I interpret to mean: not copyright-eligible).
>
> Interesting, I think that the above quote is from the decision by the
> original trial judge, Alsup?

Ayup,
https://www.eff.org/files/alsup_api_ruling.pdf

> 'Though the trial court did add the caveat that it “does not hold that the
> structure, sequence and organization of all computer programs may be
> stolen,” Copyrightability Decision, 872 F. Supp. 2d at 1002, it is hard to
> see how its method of operation analysis could lead to any other
> conclusion.'  page 42, appeals court decision
>
> Maybe the appeals court has it wrong, and Alsup's logic doesn't apply to
> *all* computer programs, but just to libre software.  Only libre software
> makes the "particular elements" (method signatures, etc,) "freely available"
> to be copied *verbatim*.

If method signatures (and other "particular elements") are deemed to
be non-copyrightable, then I'd assume that such a ruling would apply
to any code that is accessible to the public, whether Free Software or
not. (Admittedly, Free Software probably makes up the largest subset
of such works)

>  So, now, for any GPL licensed program I can think
> of, it's now possible, by Alsup's reasoning, to steal the SSO.

On the crudest of linguistic levels, I guess that one could say that,
but I think that in this context the phrase "to steal" is rather
misleading.

Alsup writes:

---
To accept Oracle’s claim would be to allow anyone to copyright one
version of code to carry out a system of commands and thereby bar all
others from writing their own different versions to carry out all or
part of the same commands.
---

Perhaps one could use contract law or other mechanisms to prevent the
creation of such 'different versions', but I believe that Alsup's
insinuation is that copyrights are not as laterally restrictive as
Oracle would like them to be, and cannot be used in a blanket fashion
to prohibit all reuse of SSO.


-- 
Robinson Tryon
QA Engineer - The Document Foundation
LibreOffice Community Outreach Herald
qu...@libreoffice.org

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-20 07:20 AM, Luke Kenneth Casson Leighton wrote:

  please read this, which is written by bradley kuhn of the FSF:

  
https://www.fsf.org/blogs/community/who-ever-thought-apis-were-copyrightable-anyway

  in it he*EXPLICITLY STATES*, and i quote:

  "The whole idea of a clean-room implementation of something centers
around the idea that the APIs aren't copyrighted. GNU itself depends
on the fact that Unix's APIs weren't copyrighted; just the code that
AT&T wrote to implement Unix was."


Was GNU a clean-room implementation of Unix?  Was the Unix API unique 
and creative?  If the answers are "no, yes, yes" then ya got me:  I 
give.  Not because I'm wrong, but because, to justify what was done 
years ago, the FSF, as an organization, would be unable to reverse 
course and will never budge on this issue to protect that legacy.  Which 
is unfortunate.  In that case, I would suggest to you that you're 
cutting off your nose to spite your face.



-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-20 07:29 AM, Thomas Charron wrote:
On Sun, Oct 19, 2014 at 3:44 PM, thufir > wrote:



Google found a work-around to remove the GPL, in certain
circumstances, of certain types of code, if, and it's a big if,
they ultimately prevail.  Since Google, or someone, will
eventually come along, copy all that declaring code, verbatim,
farm out the implementing code, and slap the ASL license on the
result, why use the GPL at all?


  So, your basic argument is..  Don't use the GPL since people can see 
your code...  ?


--
-- Thomas



There are three possible outcomes from the SCOTUS:

1.)  The SSO of any computer program may be stolen.
2.)  The SSO of some computer program may be stolen.
3.)  The SSO of no computer program may be stolen.

As pointed out to me, Alsup writes: "...the particular elements 
replicated by Google were free for all to use under the Copyright 
Act..." to arrive at his conclusion that it does not hold that the SSO 
of any computer program may be stolen.  The appeals court replies, 
effectively, that the reasoning Alsup applies to the case, were it 
applied to other computer programs, would allow for the SSO to any 
computer program to be stolen.


In theory, the appeals court is reading Alsup's decision correctly. As a 
practical matter, however, only the SSO to some computer programs would 
be green-lit for getting stolen:  libre software. Only libre software 
makes the code directly available for verbatim copying.


My basic argument is:  consider the repercussions to these three 
possibilities.



-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-20 07:20 AM, Luke Kenneth Casson Leighton wrote:

Google found a work-around to remove the GPL,

  no they did_not_  find a "work-around to remove the GPL".  they are
NOT the copyright holders of the code that was completely clean-room
re-implemented, therefore they have NO LEGAL BASIS for REMOVING any
license UNDER ANY circumstances.





Are saying that Google couldn't remove the ASL from Harmony, which was 
incorporated into Dalvik?  Ok, I'll agree with that; I don't agree that 
Google did everything else in a clean-room.  It's notable that they 
don't make such defense in their appeal to the SCOTUS.



-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-20 07:20 AM, Luke Kenneth Casson Leighton wrote:
[...]

Google found a work-around to remove the GPL,
  no they did _not_ find a "work-around to remove the GPL".  they are
NOT the copyright holders of the code that was completely clean-room
re-implemented, therefore they have NO LEGAL BASIS for REMOVING any
license UNDER ANY circumstances.


"...Google concedes that it copied portions of Oracle’s declaring source 
code verbatim." p 39


Are you claiming that the implementing code was done in a clean-room?  
Keep in mind the 9 lines which were, apparently, copy/pasted.  Even if 
the methods were done in a clean-room, which was never claimed by 
Google, the appeals court, again and again, points out that reverse 
engineering would've been ok.


Only if you define clean-room in an unusual way.  Please point to a 
single document in this legal case, anywhere, where Google makes a 
clean-room defense -- because, again, the appeals court goes out of its 
way to point out that reverse engineering would've been ok.





  only companies such as google can be sufficiently pathologically
insane as to *remotely* consider (hypocritically because they did not
also do the same for the linux kernel itself) re-duplicating such
enormous codebases.


I would suggest to you that the cost differential between 
reverse-engineering and what Google did here is sufficient to be a 
tipping point.  You can take the opposing view, and you might be right, 
but that's the crux of my argument.




  "The whole idea of a clean-room implementation of something centers
around the idea that the APIs aren't copyrighted. GNU itself depends
on the fact that Unix's APIs weren't copyrighted; just the code that
AT&T wrote to implement Unix was."


Google did not do a clean-room implementation of OpenJDK.  If you can 
point to Google ever, and I mean ever, making such a claim in any legal 
filing I'll concede all points and drop the topic. Certainly, they took 
from Harmony, which *was* a clean-room implementation, but that doesn't 
make Dalvik a clean-room implementation.




  is that now clear enough?  have i repeated it enough times in enough
ways as to make it clear as to why the FSF, and you, and any software
engineer, should be deeply concerned at even the remotest slightest
possibility of APIs becoming copyrightable material through
application of case-law precedent?

l.


I read everything you wrote carefully, and, no, you don't address the 
actual topic which I raise precisely because of tangents about clean-rooms.


This has nothing to do with clean-rooms, except that this was an option 
which Google didn't take.  Or, if they did take this option, they never 
made such a defense at trial.  Nowhere in their appeal to the SCOTUS do 
Google ever claim to have reverse engineered, nor to have made a 
clean-room implementation.  Certainly, they *discuss* reverse 
engineering, but don't claim to have actually reverse engineered.  Since 
they never make such a claim, there's not really anything quote from 
their appeal to the SCOTUS in this context.


Perhaps someone can point me to where, in the trial, Google claimed to 
have done this in a clean room?  Or in any legal filing?  I would be 
very interested in such a quote.




-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[Florian Weimer]

* Kern Sibbald:

> I am not taking any side, but could you be more specific on your
> comment "the result this would have on the GPL"?

If copyright protection does not seep through APIs, you can link your
proprietary software against a library licensed under the GPL, and you
would only have to obey the GPL terms for the library (i.e., not your
proprietary application).  Essentially, this would turn the GPL into
the LGPL, which is clearly against the FSF's interests (because they
view the LGPL as the lesser license of the two).

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-20 07:29 AM, Thomas Charron wrote:
On Sun, Oct 19, 2014 at 3:44 PM, thufir > wrote:



Google found a work-around to remove the GPL, in certain
circumstances, of certain types of code, if, and it's a big if,
they ultimately prevail.  Since Google, or someone, will
eventually come along, copy all that declaring code, verbatim,
farm out the implementing code, and slap the ASL license on the
result, why use the GPL at all?


  So, your basic argument is..  Don't use the GPL since people can see 
your code...  ?




Consider three outcomes from the upcoming SCOTUS trial:

1.)  The SSO of any computer program may be stolen.
2.)  The SSO of some computer program may be stolen.
3.)  The SSO of no computer program may be stolen.

Only under the third outcome would Google have been forced to either 
obtain a license or to put Dalvik under the GPL.



-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-20 07:20 AM, Luke Kenneth Casson Leighton wrote:

  no they did_not_  find a "work-around to remove the GPL".  they are
NOT the copyright holders of the code that was completely clean-room
re-implemented, therefore they have NO LEGAL BASIS for REMOVING any
license UNDER ANY circumstances.


If you can point to a single sentence in any legal filing by Google 
where they claim to have done this in a clean-room I'll concede all 
points and drop the topic.  That was not part of their defense at all.



-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[Thomas Charron]

On Sun, Oct 19, 2014 at 3:44 PM, thufir  wrote:

>
> Google found a work-around to remove the GPL, in certain circumstances, of
> certain types of code, if, and it's a big if, they ultimately prevail.
> Since Google, or someone, will eventually come along, copy all that
> declaring code, verbatim, farm out the implementing code, and slap the ASL
> license on the result, why use the GPL at all?
>

  So, your basic argument is..  Don't use the GPL since people can see your
code...  ?

-- 
-- Thomas

parse Alsup decision: any, all, some was Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-20 01:18 AM, Robinson Tryon wrote:

---
CONCLUSION
This order does not hold that Java API packages are free for all to
use without license.It does not hold that the structure, sequence and
organization of all computer programs may be stolen. Rather, it holds
on the specific facts of this case, the particular elements replicated
by Google were free for all to use under the Copyright Act
---

I can see how on a cursory examination one might read "it does not
hold that SSO of all programs may be stolen", and be confused that it
implies "some SSO may be stolen", but the next sentence states that
(in the court's view) the elements in question were free for all under
the Copyright Act (which I interpret to mean: not copyright-eligible).


Interesting, I think that the above quote is from the decision by the 
original trial judge, Alsup?


'Though the trial court did add the caveat that it “does not hold that 
the structure, sequence and organization of all computer programs may be 
stolen,” Copyrightability Decision, 872 F. Supp. 2d at 1002, it is hard 
to see how its method of operation analysis could lead to any other 
conclusion.'  page 42, appeals court decision


Maybe the appeals court has it wrong, and Alsup's logic doesn't apply to 
*all* computer programs, but just to libre software.  Only libre 
software makes the "particular elements" (method signatures, etc,) 
"freely available" to be copied *verbatim*.  So, now, for any GPL 
licensed program I can think of, it's now possible, by Alsup's 
reasoning, to steal the SSO.  Whether Alsup's reasoning applies to *all* 
computer programs, or just publicly available, GPL licensed programs 
isn't quite clear to me.  I think his reasoning only applies to libre 
software where the actual code is publicly available.



-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[Robinson Tryon]

On Mon, Oct 20, 2014 at 5:46 AM, Kern Sibbald  wrote:
> Yes I meant and wrote API but my smat
> rt phone "corrected" and I failed to notice -- sorry.

:-)

Sartre said that Hell is other people, but only because they didn't
have phones with auto-correct back in his day.

-- 
Robinson Tryon
QA Engineer - The Document Foundation
LibreOffice Community Outreach Herald
qu...@libreoffice.org

Re: Oracle vs Google: APIs are copyright; appeal decision

[Kern Sibbald]

Yes I meant and wrote API but my smat
rt phone "corrected" and I failed to notice -- sorry.


Sent from my Samsung Galaxy S5.


 Original message 
From: Robinson Tryon  
Date:20/10/2014  06:18  (GMT-03:00) 
To: thufir  
Cc: Kern Sibbald , GPL Violations 
 
Subject: Re: Oracle vs Google: APIs are copyright; appeal decision 

On Sun, Oct 19, 2014 at 3:44 PM, thufir  wrote:
> On 14-10-19 09:13 AM, Kern Sibbald wrote:
>
> Thanks for your response. I don't want to take sides yet because I don't yet
> fully understand the case. If Google copied copyrighted code in  violation
> of the licence they have a problem.
> For the GPL IANAL but the  licence permits copying the code provided that
> the copyright is maintained thus though  not explicit it is clear to me any
> GPLed APL can be copied.

APL -> API (right?)

(Watch those initialisms, folks. This conversation is already abstruse
enough ;-)

> I think this exactly hits the nail on the head:  "...provided that the
> copyright is maintained."  By changing the license from GPL to ASL (or,
> theoretically, closed-source), I don't consider that ok.

We often wave our hands regarding licenses and copyright, but I think
the question being debating here is not whether one has *changed* the
license or *maintained* copyright, but whether that content is
*eligible* for copyright protection in the first place.

> "...Google conceded that it copied it  [the declaring code] verbatim," page
> 27.
>
> This is something which only FOSS is vulnerable to, because the declaring
> code is there to be copied.

When you say 'vulnerable', are you talking about the vulnerability of
the original library code to being copied, or the vulnerability of the
rewritten API-compatible second library to a copyright lawsuit?

> The
> implication that it's then possible to, literally, copy the API verbatim (p
> 27), not for the purpose of compatibility, but to cash in on the popularity
> of the original (p 51), without trying to figure out the original (p 48), is
> huge.

Doesn't compatibility pretty much boil down to 'cashing in' (so to
speak) on the popularity of the original?

To put it another way, all of the various import filters we have in
LibreOffice are useful precisely because people have created documents
in those formats (whether in a program designed by the original author
of the format, or a competing program). If there was zero popularity
of the format, then nobody would have files written in it, and nobody
would have a need for an import filter.

If you have a bunch of people who have written Java programs, and who
know how to write Java code, why would one create a different
programming language for a new mobile phone OS if Java would work
quite well for the purpose?

> Again, this only applies to FOSS, and would allow anyone to steal an
> API (p 42).  Stolen, the word used not just by the first trial, but also by
> the appeals court.  Note that there's no dissenting opinion from the appeals
> court.

The only time the appeals court used the word 'stolen' was in a quote
from the first trial, so I don't think that counts as 'used by the
appeals court'. The district court used the terms 'steal' and 'stolen'
once each. Here are the uses in context:

---
Everyone agrees that no one can copy line-for-line someone else’s
copyrighted computer program. When the line-by-line listings are
different, however, some copyright owners have nonetheless accused
others of stealing the “structure, sequence and organization” of the
copyrighted work.
---

---
CONCLUSION
This order does not hold that Java API packages are free for all to
use without license.It does not hold that the structure, sequence and
organization of all computer programs may be stolen. Rather, it holds
on the specific facts of this case, the particular elements replicated
by Google were free for all to use under the Copyright Act
---

I can see how on a cursory examination one might read "it does not
hold that SSO of all programs may be stolen", and be confused that it
implies "some SSO may be stolen", but the next sentence states that
(in the court's view) the elements in question were free for all under
the Copyright Act (which I interpret to mean: not copyright-eligible).

Perhaps it would have scanned better had it read "It does not hold
that SSO of *any* programs may be stolen" ?

> Google found a work-around to remove the GPL, in certain circumstances, of
> certain types of code, if, and it's a big if, they ultimately prevail.

As a copyright license, the GPL can only cover copyright-eligible
code. So if the code isn't copyright-eligible, then it's not really
being *removed*, right? I don't know much about past precedent, so I
don't know if th

Re: Oracle vs Google: APIs are copyright; appeal decision

[Robinson Tryon]

On Sun, Oct 19, 2014 at 3:44 PM, thufir  wrote:
> On 14-10-19 09:13 AM, Kern Sibbald wrote:
>
> Thanks for your response. I don't want to take sides yet because I don't yet
> fully understand the case. If Google copied copyrighted code in  violation
> of the licence they have a problem.
> For the GPL IANAL but the  licence permits copying the code provided that
> the copyright is maintained thus though  not explicit it is clear to me any
> GPLed APL can be copied.

APL -> API (right?)

(Watch those initialisms, folks. This conversation is already abstruse
enough ;-)

> I think this exactly hits the nail on the head:  "...provided that the
> copyright is maintained."  By changing the license from GPL to ASL (or,
> theoretically, closed-source), I don't consider that ok.

We often wave our hands regarding licenses and copyright, but I think
the question being debating here is not whether one has *changed* the
license or *maintained* copyright, but whether that content is
*eligible* for copyright protection in the first place.

> "...Google conceded that it copied it  [the declaring code] verbatim," page
> 27.
>
> This is something which only FOSS is vulnerable to, because the declaring
> code is there to be copied.

When you say 'vulnerable', are you talking about the vulnerability of
the original library code to being copied, or the vulnerability of the
rewritten API-compatible second library to a copyright lawsuit?

> The
> implication that it's then possible to, literally, copy the API verbatim (p
> 27), not for the purpose of compatibility, but to cash in on the popularity
> of the original (p 51), without trying to figure out the original (p 48), is
> huge.

Doesn't compatibility pretty much boil down to 'cashing in' (so to
speak) on the popularity of the original?

To put it another way, all of the various import filters we have in
LibreOffice are useful precisely because people have created documents
in those formats (whether in a program designed by the original author
of the format, or a competing program). If there was zero popularity
of the format, then nobody would have files written in it, and nobody
would have a need for an import filter.

If you have a bunch of people who have written Java programs, and who
know how to write Java code, why would one create a different
programming language for a new mobile phone OS if Java would work
quite well for the purpose?

> Again, this only applies to FOSS, and would allow anyone to steal an
> API (p 42).  Stolen, the word used not just by the first trial, but also by
> the appeals court.  Note that there's no dissenting opinion from the appeals
> court.

The only time the appeals court used the word 'stolen' was in a quote
from the first trial, so I don't think that counts as 'used by the
appeals court'. The district court used the terms 'steal' and 'stolen'
once each. Here are the uses in context:

---
Everyone agrees that no one can copy line-for-line someone else’s
copyrighted computer program. When the line-by-line listings are
different, however, some copyright owners have nonetheless accused
others of stealing the “structure, sequence and organization” of the
copyrighted work.
---

---
CONCLUSION
This order does not hold that Java API packages are free for all to
use without license.It does not hold that the structure, sequence and
organization of all computer programs may be stolen. Rather, it holds
on the specific facts of this case, the particular elements replicated
by Google were free for all to use under the Copyright Act
---

I can see how on a cursory examination one might read "it does not
hold that SSO of all programs may be stolen", and be confused that it
implies "some SSO may be stolen", but the next sentence states that
(in the court's view) the elements in question were free for all under
the Copyright Act (which I interpret to mean: not copyright-eligible).

Perhaps it would have scanned better had it read "It does not hold
that SSO of *any* programs may be stolen" ?

> Google found a work-around to remove the GPL, in certain circumstances, of
> certain types of code, if, and it's a big if, they ultimately prevail.

As a copyright license, the GPL can only cover copyright-eligible
code. So if the code isn't copyright-eligible, then it's not really
being *removed*, right? I don't know much about past precedent, so I
don't know if this ruling was seen as a change from previous rulings.

> Since Google, or someone, will eventually come along, copy all that
> declaring code, verbatim, farm out the implementing code, and slap the ASL
> license on the result, why use the GPL at all?

I guess one could use contract law instead of copyright law here to
try to effect a similar result to what copyleft provides, but what's
the legal problem with Google re-implementing libraries of code?

There are a number of people who promote copyleft as a useful
mechanism for ensuring software freedom for everyone (or at least
everyone with a computer and 

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-19 09:13 AM, Kern Sibbald wrote:
Thanks for your response. I don't want to take sides yet because I 
don't yet fully understand the case. If Google copied copyrighted code 
in  violation of the licence they have a problem.
For the GPL IANAL but the  licence permits copying the code provided 
that the copyright is maintained thus though  not explicit it is clear 
to me any GPLed APL can be copied.

Kern

Sent from my Samsung Galaxy S5



I think this exactly hits the nail on the head:  "...provided that the 
copyright is maintained."  By changing the license from GPL to ASL (or, 
theoretically, closed-source), I don't consider that ok. In the pdf, 
"verbatim" shows up nine times in the context of copying.  It's "novel" 
that they just copied the declaring code:


"...Google conceded that it copied it  [the declaring code] verbatim," 
page 27.


This is something which only FOSS is vulnerable to, because the 
declaring code is there to be copied.  For proprietary code, there might 
be some documentation, but it wouldn't get copied verbatim in the same 
way.  The implication that it's then possible to, literally, copy the 
API verbatim (p 27), not for the purpose of compatibility, but to cash 
in on the popularity of the original (p 51), without trying to figure 
out the original (p 48), is huge. Again, this only applies to FOSS, and 
would allow anyone to steal an API (p 42).  Stolen, the word used not 
just by the first trial, but also by the appeals court.  Note that 
there's no dissenting opinion from the appeals court.


Google found a work-around to remove the GPL, in certain circumstances, 
of certain types of code, if, and it's a big if, they ultimately 
prevail.  Since Google, or someone, will eventually come along, copy all 
that declaring code, verbatim, farm out the implementing code, and slap 
the ASL license on the result, why use the GPL at all?



-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[lkcl .]

i received this from dr stallman today [not full message].  answer:
no, the FSF does *NOT* support the copyrighting of APIs and is
ACTIVELY opposed to the copyrighting of APIs.

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

>question: is the FSF accepting that APIs (Application Programming
>Interfaces) should become Copyright material, yes or no.

We oppose interface copyright and have always opposed it.
I founded an organization in 1990, the League for Programming Freedom,
to fight against user interface copyright, but we oppose
API copyright just the same.

Re: Oracle vs Google: APIs are copyright; appeal decision

[Kern Sibbald]

Thanks for your response. I don't want to take sides yet because I don't yet 
fully understand the case. If Google copied copyrighted code in  violation of 
the licence they have a problem. 
For the GPL IANAL but the  licence permits copying the code provided that the 
copyright is maintained thus though  not explicit it is clear to me any GPLed 
APL can be copied.
Kern

Sent from my Samsung Galaxy S5


 Original message 
From: thufir  
Date:18/10/2014  02:10  (GMT-03:00) 
To: legal@lists.gpl-violations.org 
Cc:  
Subject: Re: Oracle vs Google: APIs are copyright; appeal decision 

On 14-10-17 04:10 AM, Kern Sibbald wrote:
> I am not taking any side, but could you be more specific on your 
> comment "the result this would have on the GPL"?
>
> Thanks,
> Kern 

Please do take a side at some point, or take both sides, or your own side

The key phrase from Alsup, the trial judge, is that he writes "it does 
not hold":

''Though the trial court did add the caveat that it “does not hold that 
the structure, sequence and organization of all computer programs may be 
stolen,” Copyrightability Decision, 872 F. Supp. 2d at 1002, it is hard 
to see how its method of operation analysis could lead to any other 
conclusion.'

well, why not?  Why doesn't it hold that the wider implication is that 
the SSO of all programs may be stolen?

It's notable that the trial judge doesn't write "infringed" or "copied", 
he goes right to the word "stolen," which is so often mistakenly used in 
copyright.  Now, when joe public downloads a DVD, Hollywood wants to 
call that "stealing," but it's not -- and I have no doubt that Alsup is 
quite aware of the distinction.  Which makes his language choice, let's 
say, interesting.

When he writes "it does not hold" my take is that this is a slip. He 
arrived at his conclusion, and then considered the wider consequences 
were his decision to be applied elsewhere, and then, realizing what the 
potential result would be, wrote "it does not hold" exactly because of 
the potential implication.  Speculation on my part, but I put another 
negation on his negation -- it does hold.

Now, this is just one trial, but let's consider the wider implications.  
If the SCOTUS says, sure, go ahead and copy the SSO of any computer 
program, (not that they would phrase it like that), what are the 
implications?

In this case we're talking about OpenJDK.  OpenJDK is under the GPL.  
Well, now anyone can come along, copy the SSO and distribute without 
consideration of the GPL.  Wow, that's huge.

Even bigger than that, there's no copyright at all, or nothing 
enforceable, on SSO.

Please correct my reading of the appeals court decision.  I'm literally 
asking how others parse that excerpt from the appeals decision.


-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[Thufir]

On Sun, 19 Oct 2014 11:25:32 +0100, Ralph Corderoy wrote:


>> The FSF is ok with, in the words of not just the appeals court, but the
>> original trial judge, stealing the SSO of a computer program?
>
> Is it your view that an API defines the "structure, sequence and
> organization" of computer programs if they're implemented in a manner
> that isn't deliberately trying to be perverse?

Yes.  However, on page 37 they use the phrase "SSO of the Java API".  In
terms of an API "expiring" due to time or usage (or being forked?), they
say, no, that Scenes a Faire doesn't apply to Java.  Just because it's
widely adopted and is "standard, stock, or common to a topic" that there's
no copyright protection.

That being said, if you can diagram the decades over which a standard
evolved, I think that would be a convincing argument for a specific SSO to
a particular API.  Maybe Google just didn't argue this point well, or it's
a bad example and dbm.h would have a different result, which goes to the
larger question of intent.  Why copy, and the appeals court says Google
copied verbatim (p 10), a flawed API?  The intent wasn't to implement the
API but to ride the coat-tails of Java (page 51).

I think it starts and ends with intentions.


-Thufir

On Sun, Oct 19, 2014 at 3:25 AM, Ralph Corderoy 
wrote:

> Hi Thufir,
>
> > The FSF is ok with, in the words of not just the appeals court, but
> > the original trial judge, stealing the SSO of a computer program?
>
> Is it your view that an API defines the "structure, sequence and
> organization" of computer programs if they're implemented in a manner
> that isn't deliberately trying to be perverse?
>
> That seems wrong to me.  See the many key-value stores that descend from
> dbm.h over the decades.  The API has been the same in many cases, in
> order the new implementation be adopted by the old's users, but the
> new's implementation has been novel in order to give benefits over the
> old.
>
> (Please try and be succinct in answering;  I find the lengthy replies
> that rebut every paragraph are too much noise when all of our time is
> precious.)
>
> Cheers, Ralph.
>

Re: Oracle vs Google: APIs are copyright; appeal decision

[lkcl .]

On Sun, Oct 19, 2014 at 9:25 AM, thufir  wrote:
>
> On 14-10-17 08:52 AM, lkcl . wrote:
>
> one other thing: software libre developers would also be burdened with
> the additional task of issuing a LICENSE to use their API!  by
> default, copyright law DEMANDS that you, the copyright holder, issue a
> license.  if you do not issue a license then the default is that
> nobody may use the copyrighted work *without permission*.  you KNOW
> this.
>
>
> Pardon, I misread this paragraph in my previous reply.
>
> I would disagree with you about copyright and API burden.  To start with:

 i am sorry but i do not have time to go over absolutely every single
instance of confusion in your mind that is occurring, nor do i have
the time to find and read the original sources that you've copied a
few sections from without providing references.

 i'm going to have to leave it to other people to follow up on this topic.

l.

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-19 01:26 AM, lkcl . wrote:

On Sat, Oct 18, 2014 at 5:52 AM, thufir  wrote:

On 14-10-17 08:52 AM, lkcl . wrote:

  the reverse-engineering was at several different levels:


I think your missing a key point, which is that you reverse-engineered,
which is exactly exempt:

   you are correct in that the reverse-engineering *itself* is irrelevant.

  however if it is an *API* that has been reverse-engineered and that
API is considered to be *copyright material*.

  please ignore the fact that the material derived has been
reverse-engineered in samba, wine and many other software libre
applications.

  there is no link to reverse-engineering.

  it is the fact that the APIs which *have* been implemented [by a
means and method that HAPPENS* to be reverse-engineering] are,
through this dangerous precedent that will be used in case-law to make
ALL* APIs copyrighted material, that is the most dangerous
concern.

  is that clear where your confusion lies?

  is that clear enough now exactly what the issue is?

  l.


You've muddied the waters beyond all...something...at least for me. So I 
quoted everything.


Ok, make this concrete.  We're talking OpenJDK.  Let's ignore the GPL 
for the moment, and just consider copyright.  So, OpenJDK can be reverse 
engineered, resulting in ReverseEngineeredJDK, which can be completely 
proprietary.  You're concerned that the SSO of ReverseEngineeredJDK can 
be copyrighted?  Why are you concerned about that?


(Ignoring Apache Harmony, just because.)

(By SSO, I read that to be "API" by another name, at least that's my 
take.  Wikipedia has an entry:


http://en.wikipedia.org/wiki/Structure,_sequence_and_organization

which doesn't make it that much clearer, because the cases cited are 
sometimes called into question by the appeals court, but sometimes they 
quote those cases -- it's complex.)


What's the possible downside to ReverseEngineeredJDK being protected by 
copyright?  Or, rather the API/SSO of ReverseEngineeredJDK being 
protected by copyright.  it's certainly no worse than the fact that 
OpenJDK and its API/SSO itself being protected by copyright...


To go on a complete tangent, the interesting question, to my mind not 
directly addressed by the appeals court, is whether or not a fork of 
ReverseEngineeredJDK would be protected.  Is it required to reverse 
engineer the entire JDK just get the "good parts"?  But, those are 
tangential to the central issue:  what are the downsides to this 
decision, if not overturned, and if applied to other situations.


Or, my take, what are the downsides to overturning the appeals court!

Finally, while not stated by anyone, I think it's widely assumed that a 
trivial API, or SSO if you prefer, can't be "protected" by copyright.  
The fuzzy part is where to draw that line between an API that's not 
creative to one that is.  Which, I guess, is where the lawyers come in ;)




-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[Neil Brown]

On 18 Oct 2014, at 16:11, lkcl .  wrote:
> 
>> However, to allow the SSO
> 
> apologies i have no idea what an "S S O" is - it's not a common
> computing term that i've ever encountered in the past 38 years of
> working with computers.  would you mind providing a reference to this
> acronym?

For the sake of anyone else trying to follow this thread — and I had exactly 
the same question as Luke — I would take "SSO" to mean "structure, sequence and 
organization", which appear to be those parts (if parts is quite the right 
term) of a computer program seemingly at issue in the case under discussion.


Neil

__

Neil Brown
n...@neilzone.co.uk | http://neilzone.co.uk

Re: Oracle vs Google: APIs are copyright; appeal decision

[Ralph Corderoy]

Hi Thufir,

> The FSF is ok with, in the words of not just the appeals court, but
> the original trial judge, stealing the SSO of a computer program?

Is it your view that an API defines the "structure, sequence and
organization" of computer programs if they're implemented in a manner
that isn't deliberately trying to be perverse?

That seems wrong to me.  See the many key-value stores that descend from
dbm.h over the decades.  The API has been the same in many cases, in
order the new implementation be adopted by the old's users, but the
new's implementation has been novel in order to give benefits over the
old.

(Please try and be succinct in answering;  I find the lengthy replies
that rebut every paragraph are too much noise when all of our time is
precious.)

Cheers, Ralph.

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-19 01:57 AM, lkcl . wrote:

On Sun, Oct 19, 2014 at 9:48 AM, thufir  wrote:

On 14-10-19 01:26 AM, lkcl . wrote:

On Sat, Oct 18, 2014 at 5:52 AM, thufir  wrote:

On 14-10-17 08:52 AM, lkcl . wrote:

   the reverse-engineering was at several different levels:


I think your missing a key point, which is that you reverse-engineered,
which is exactly exempt:

you are correct in that the reverse-engineering *itself* is irrelevant.

   however if it is an *API* that has been reverse-engineered and that
API is considered to be *copyright material*.

   please ignore the fact that the material derived has been
reverse-engineered in samba, wine and many other software libre
applications.

   there is no link to reverse-engineering.

   it is the fact that the APIs which *have* been implemented [by a
means and method that HAPPENS* to be reverse-engineering] are,
through this dangerous precedent that will be used in case-law to make
ALL* APIs copyrighted material, that is the most dangerous
concern.

   is that clear where your confusion lies?

   is that clear enough now exactly what the issue is?

   l.


You've muddied the waters beyond all...something...at least for me. So I
quoted everything.

Ok, make this concrete.  We're talking OpenJDK.  Let's ignore the GPL for
the moment, and just consider copyright.  So, OpenJDK can be reverse
engineered, resulting in ReverseEngineeredJDK, which can be completely
proprietary.  You're concerned that the SSO of ReverseEngineeredJDK can be
copyrighted?

  i'm not in the slightest bit interested in Structure, Sequence and
Organisation.  the only thing i care about is that APIs remain
uncopyrightable.


Well, neither the appeals court nor the trial judge wrote anything about 
API's themselves being copyrightable, that I'm aware of.  So that 
specific question isn't addressed, at least not directly, by any 
decision I know of.  Neither do I see a practical way, even if API's 
were copyrightable, to put a copyright "on" an API.



   Why are you concerned about that?

  please do not make assumptions about what i am concerned about: if
you would like to know my concerns please ask.


Well, you wrote "...that is the most dangerous concern," which I read to 
be your concern.  Yes, I was asking what your concerns were, or rather, 
why.  I made no assumptions, I was replying to your words about the most 
dangerous concern.  There's no assumption that it's your concern, that's 
the implication of what's written.  Anyhow.



  > Finally, while not stated by anyone, I think it's widely assumed that a

trivial API, or SSO if you prefer,

  no i do not.  and any confusion or attempt to call SSO "APIs" is
flat-out wrong.  APIs are *NOT* the same as a program's structure,
sequence or organisation. please stop doing it.


Fair enough; there was at least one person unfamiliar with the SSO 
terminology from the appeals court.  While it doesn't seem a far-off 
comparison, at least in the context of this specific appeals court 
decision, fair enough.



can't be "protected" by copyright.  The
fuzzy part is where to draw that line between an API that's not creative to
one that is.  Which, I guess, is where the lawyers come in ;)

  exactly.  and once one court case defines it as being for example
"37" APIs, then case law will permit *ALL* APIs comprising a number of
function calls at 37 or above to be copyrighted.

  once that happens then the nightmare scenario that i outlined in the
first post becomes a reality.

  ok _enough_ hawat, i have to get on with other matters.

  l.


That's not how it works, that 37 would now be some magic number.  In 
fact, the appeals court directly addressed this topic, writing:


"Given the court’s findings that the SSO is original and creative, and 
that the declaring code could have been written and organized in any 
number of ways and still have achieved the same functions..."


page 45

meaning that, at trial, it would be required to establish that the SSO 
is original and creative.


Well, anyhow, I wanted to know what the FSF thought of this decision, 
specifically, beyond the statements on the website.  There seems a 
disconnect between what the appeals court actually wrote and the 
response from the FSF.  Most of the what I've read in the press repeats 
this idea that suddenly API's are copyrighted, or that it's somehow not 
possible to use Wine, or along these lines, which isn't at all how I 
read the decision by the appeals court.


I wouldn't expect everyone to read this decision, but I was curious 
about it and thought this would be a good place to discuss the appeals 
court decision; hence the subject title.  I'd like the FSF to reconsider 
its position on the ramifications of this lawsuit, I think that the FSF 
has it backwards.


Unfortunately, this discussion went nowhere.  Reverse engineering was 
brought up, then dropped.  Why it was even raised is unclear to me; 
apparently, it was a red herring.




-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[lkcl .]

On Sat, Oct 18, 2014 at 5:52 AM, thufir  wrote:
> On 14-10-17 08:52 AM, lkcl . wrote:
>
>  the reverse-engineering was at several different levels:
>
>
> I think your missing a key point, which is that you reverse-engineered,
> which is exactly exempt:

  you are correct in that the reverse-engineering *itself* is irrelevant.

 however if it is an *API* that has been reverse-engineered and that
API is considered to be *copyright material*.

 please ignore the fact that the material derived has been
reverse-engineered in samba, wine and many other software libre
applications.

 there is no link to reverse-engineering.

 it is the fact that the APIs which *have* been implemented [by a
means and method that HAPPENS* to be reverse-engineering] are,
through this dangerous precedent that will be used in case-law to make
ALL* APIs copyrighted material, that is the most dangerous
concern.

 is that clear where your confusion lies?

 is that clear enough now exactly what the issue is?

 l.

Re: Oracle vs Google: APIs are copyright; appeal decision

[lkcl .]

On Sun, Oct 19, 2014 at 9:48 AM, thufir  wrote:
> On 14-10-19 01:26 AM, lkcl . wrote:
>>
>> On Sat, Oct 18, 2014 at 5:52 AM, thufir  wrote:
>>>
>>> On 14-10-17 08:52 AM, lkcl . wrote:
>>>
>>>   the reverse-engineering was at several different levels:
>>>
>>>
>>> I think your missing a key point, which is that you reverse-engineered,
>>> which is exactly exempt:
>>
>>you are correct in that the reverse-engineering *itself* is irrelevant.
>>
>>   however if it is an *API* that has been reverse-engineered and that
>> API is considered to be *copyright material*.
>>
>>   please ignore the fact that the material derived has been
>> reverse-engineered in samba, wine and many other software libre
>> applications.
>>
>>   there is no link to reverse-engineering.
>>
>>   it is the fact that the APIs which *have* been implemented [by a
>> means and method that HAPPENS* to be reverse-engineering] are,
>> through this dangerous precedent that will be used in case-law to make
>> ALL* APIs copyrighted material, that is the most dangerous
>> concern.
>>
>>   is that clear where your confusion lies?
>>
>>   is that clear enough now exactly what the issue is?
>>
>>   l.
>
>
> You've muddied the waters beyond all...something...at least for me. So I
> quoted everything.
>
> Ok, make this concrete.  We're talking OpenJDK.  Let's ignore the GPL for
> the moment, and just consider copyright.  So, OpenJDK can be reverse
> engineered, resulting in ReverseEngineeredJDK, which can be completely
> proprietary.  You're concerned that the SSO of ReverseEngineeredJDK can be
> copyrighted?

 i'm not in the slightest bit interested in Structure, Sequence and
Organisation.  the only thing i care about is that APIs remain
uncopyrightable.

>   Why are you concerned about that?

 please do not make assumptions about what i am concerned about: if
you would like to know my concerns please ask.

 > Finally, while not stated by anyone, I think it's widely assumed that a
> trivial API, or SSO if you prefer,

 no i do not.  and any confusion or attempt to call SSO "APIs" is
flat-out wrong.  APIs are *NOT* the same as a program's structure,
sequence or organisation. please stop doing it.

> can't be "protected" by copyright.  The
> fuzzy part is where to draw that line between an API that's not creative to
> one that is.  Which, I guess, is where the lawyers come in ;)

 exactly.  and once one court case defines it as being for example
"37" APIs, then case law will permit *ALL* APIs comprising a number of
function calls at 37 or above to be copyrighted.

 once that happens then the nightmare scenario that i outlined in the
first post becomes a reality.

 ok _enough_ hawat, i have to get on with other matters.

 l.

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-17 03:52 AM, Luke Kenneth Casson Leighton wrote:


  let's look for example at the microsoft NT Domains and Exchange 5.5
network traffic that i reverse-engineered (for zero monetary reward)
over a three year period in 1997-1999 and in 2001/2005 respectively.

  the reverse-engineering was at several different levels:


I don't understand why you're bringing up reverse-engineering. Google 
never claimed to have reverse-engineered anything in this trial.  Where, 
and I mean this sincerely, do you get the idea that reverse engineering 
is at all applicable?


Please reference:


'As the former Register of Copyrights of the United States pointed out 
in his brief amicus curiae, “[h]ad Google reverse engineered the 
programming packages to figure out the ideas and functionality of the 
original, and then created its own structure and its own literal code, 
Oracle would have no remedy under copyright whatsoever.”'


Which is directly from the appeals court.  This has nothing at all to do 
with reverse-engineering, except that, as noted, Google didn't reverse 
engineer anything.  Nor, in any filing, and I include the appeal to the 
SCOTUS, does Google claim to have reverse engineered anything.  If I'm 
incorrect, please point me to a document.  I might be right, I might be 
wrong.


I'm baffled as to why you believe this is related to reverse engineering 
-- the former Register of Copyrights is very clear that it's unrelated 
to reverse-engineering.  Do you disagree with that assessment by the 
former Register?  If so, what's your basis for such an assessment?


Where does this notion come from, that this case hinges on reverse 
engineering an API?




  a) the modifications (and significant and *necessary* technical
improvements) that microsoft had made to DCE/RPC.

  b) the implementation of NetBIOS over TCP and UDP

  c) the implementation of NetBIOS *services* over TCP and UDP (yes
there are such services: NetBIOS has the concept of "ports" just like
UDP and TCP, so there are several - undocumented - NetBIOS services).

  d) their extensions to the SMB protocol (which have a long and
chequered history going through IBM, Xenix, SCO and many other
contributors)

  e) their extensions to the LANMAN protocol (originally i believe by IBM)

  f) their implementations of around 15 to 20 *separate and distinct*
MSRPC services (such as winreg, lsass, NETLOGON, spoolss, srvsvc and
so on) each of which may be considered to be an API in their own right
(MSRPC aka DCE/RPC basically provides networked access to future-proof
extensible c style functions *as if* they were local APIs.  note the
key word "APIs" here)


yes, API, ok.  These were reverse engineered? If so, how is that at all 
relevant?



  g) their implementation of MAPI which had its own special RPC format
(it came from a 3rd party company that MS bought a long time ago, and
was originally sent over TCP/IP.  later it was proxied over an MSRPC
stream so gained authentication, encryption and so on.  kinda cool).

  all of these things can - and are - considered to be APIs.  they are
basically Remote Procedure Calls (APIs) where the data over-the-wire
is merely a marshalled format of the API.


And anyone could, and still can, reverse engineer any API.  The appeals 
court, as clearly as is possible, explains how to work-around copyright 
of an API:  reverse engineer it.



  the implementation of such RPC services comprises both an RPC layer
(a means to translate the APIs into a network stream) *AND* an actual
implementation of the APIs themselves.  the RPC "layer" merely divides
the API so that its caller is in one process (potentially even on
another computer over a network) and the calle is in another process.

  in fact, a case could be made that even JSONRPC services, XMPRPC
services, SOAP services (the basis of .NET inter-process
communication) - *ALL* of these would now become copyrightable APIs.
world-wide that's ENORMOUS.


Ok..."copyrightable API's", I'm with you.  For these API's, have they 
been reverse engineered?  I ask because that work-around exists.



  just for the microsoft reverse-engineering alone, under the new
ruling, all the efforts made by many people for *years* in pursuing
both the U.S. Dept of Justice and the EU Monopolies and Mergers
Commission, would be completely and utterly wasted.


You mean that the API's weren't reverse-engineered?  or that that the 
already were?  It's not clear, when you write "for the microsoft 
reverse-engineering" whether you mean for future or past 
reverse-engineering.


Because, again, if they were already reverse-engineered, and please do 
let me know whether you agree or not, the appeals court clearly states 
that it's ok to reverse engineer.



  you would no longer be permitted to work on or use Wine, because Wine
also contains implementations of the IDL files (the MSRPC services)
and nor of MSRPC.itself.


Why?  Wine is reverse-engineered, at least according to Wikipedia. You 
assert 

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-19 01:31 AM, lkcl . wrote:
[...]

nor do i have
the time to find and read the original sources that you've copied a
few sections from without providing references.


well, that's unfortunate, seeing as it was topic under discussion. In 
any event, it was an interesting discussion.  I still have no idea why 
the FSF is on the side of Google for this, though.  I say that because 
I'd like to see the FSF directly, and publicly, address, if nothing else:


'Though the trial court did add the caveat that it “does not hold that 
the structure, sequence and organization of all computer programs may be 
stolen,” Copyrightability Decision, 872 F. Supp. 2d at 1002, it is hard 
to see how its method of operation analysis could lead to any other 
conclusion.'


page 42, appeals court decision


The FSF is ok with, in the words of not just the appeals court, but the 
original trial judge, stealing the SSO of a computer program?


-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-17 08:52 AM, lkcl . wrote:

one other thing: software libre developers would also be burdened with
the additional task of issuing a LICENSE to use their API!  by
default, copyright law DEMANDS that you, the copyright holder, issue a
license.  if you do not issue a license then the default is that
nobody may use the copyrighted work*without permission*.  you KNOW
this.


Pardon, I misread this paragraph in my previous reply.

I would disagree with you about copyright and API burden.  To start with:

"Although Oracle owns the copyright on Java SE and the API packages, it 
offers three different licenses to those who want to make use of them. 
The first is the General Public License..."


So, the GPL is one option.  But your concern is the burden of issuing a 
license for an API.  I don't think so, because the appeals court writes:


'If we were to accept the district court’s suggestion that a computer 
program is uncopyrightable simply because it “carr[ies] out pre-assigned 
functions,” no computer program is protectable. That result contradicts 
Congress’s express intent to provide copyright protection to computer 
programs..."


and the fact that Sun never explicitly put a copyright on the API 
itself.  As a practical matter, how would that even be accomplished?


I think this concern misses the point of the definition to SSO:

http://en.wikipedia.org/wiki/Structure,_sequence_and_organization

It's about the, somewhat nebulous, totality of the API...?

In short, no, I disagree.  But, maybe.


-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[lkcl .]

On Thu, Oct 16, 2014 at 7:16 AM, thufir  wrote:
> On Sat, 10 May 2014 12:55:29 +0100, TJ wrote:
>
>> What are the potential ramifications of the U.S.A. appeals court
>> decision in Oracle Vs Google, that APIs are copyrightable and the only
>> question now is whether such use is fair-use?
>>
>> I'm wondering about the specific affect on a GPL licensed project that
>> re-implements an API, distributes their code under the GPL, and the
>> developers and downstream users exposure to a claim of copyright
>> infringement (of the API) for developing and using the F/OSS
>> implementation by the original API copyright holder?
>
>
> 'Though the trial court did add the caveat that it “does not hold that
> the structure, sequence and organization of all computer programs may be
> stolen,” Copyrightability Decision, 872 F. Supp. 2d at 1002, it is hard
> to see how its method of operation analysis could lead to any other
> conclusion.'
>
> the appeals court seems to have hit the nail on the head.
>
> I cannot fathom why the FSF is on the side of letting API's get copied, I
> mean stolen. Do they not see the result this would have on the GPL? Or,
> do they see a larger issue? Or, do they just think that it's not
> stealing? It's remarkable that the trial judge and the appeal judge use
> a word like stolen, and not "infringe" or other legal mumbo jumbo.

 let's look for example at the microsoft NT Domains and Exchange 5.5
network traffic that i reverse-engineered (for zero monetary reward)
over a three year period in 1997-1999 and in 2001/2005 respectively.

 the reverse-engineering was at several different levels:

 a) the modifications (and significant and *necessary* technical
improvements) that microsoft had made to DCE/RPC.

 b) the implementation of NetBIOS over TCP and UDP

 c) the implementation of NetBIOS *services* over TCP and UDP (yes
there are such services: NetBIOS has the concept of "ports" just like
UDP and TCP, so there are several - undocumented - NetBIOS services).

 d) their extensions to the SMB protocol (which have a long and
chequered history going through IBM, Xenix, SCO and many other
contributors)

 e) their extensions to the LANMAN protocol (originally i believe by IBM)

 f) their implementations of around 15 to 20 *separate and distinct*
MSRPC services (such as winreg, lsass, NETLOGON, spoolss, srvsvc and
so on) each of which may be considered to be an API in their own right
(MSRPC aka DCE/RPC basically provides networked access to future-proof
extensible c style functions *as if* they were local APIs.  note the
key word "APIs" here)

 g) their implementation of MAPI which had its own special RPC format
(it came from a 3rd party company that MS bought a long time ago, and
was originally sent over TCP/IP.  later it was proxied over an MSRPC
stream so gained authentication, encryption and so on.  kinda cool).

 all of these things can - and are - considered to be APIs.  they are
basically Remote Procedure Calls (APIs) where the data over-the-wire
is merely a marshalled format of the API.

 the implementation of such RPC services comprises both an RPC layer
(a means to translate the APIs into a network stream) *AND* an actual
implementation of the APIs themselves.  the RPC "layer" merely divides
the API so that its caller is in one process (potentially even on
another computer over a network) and the calle is in another process.

 in fact, a case could be made that even JSONRPC services, XMPRPC
services, SOAP services (the basis of .NET inter-process
communication) - *ALL* of these would now become copyrightable APIs.
world-wide that's ENORMOUS.

 just for the microsoft reverse-engineering alone, under the new
ruling, all the efforts made by many people for *years* in pursuing
both the U.S. Dept of Justice and the EU Monopolies and Mergers
Commission, would be completely and utterly wasted.

 you would no longer be permitted to work on or use Wine, because Wine
also contains implementations of the IDL files (the MSRPC services)
and nor of MSRPC.itself.

 you would no longer be permitted to work on or use Samba or any of
its services.

 you would no longer be permitted to utilise or work on the Firefox
Web Browser, because it has implemented a near-identical copy of the
Microsoft COM protocol named XPCOM (badly, it has to be said.  they
stupidly left out co-classes and this has caused a *severe* amount of
trouble for over a decade both internally as well as in the c++
community where gecko / xulrunner are used in 3rd party products).  to
implement a near-identical copy of XPCOM they *also* needed to
implement a similar system to DCE/RPC (MSRPC) but they left out the
networking, and many of the implementation details are different
***BUT*** the point is that at the API* level they have
*EXACTLY* the same functions as COM (minus, stupidly, co-classes).
they even implemented a Registry (because COM requires a registry, so
XPCOM also has one).

so DO YOU UNDERSTAND.  you would NO LONGER BE 

Re: Oracle vs Google: APIs are copyright; appeal decision

[Ian Stirling]

On 10/18/2014 06:26 AM, thufir wrote:
You absolutely will be permitted to work on on any API.  In the case 
of Firefox, since, I think, it's under the GPL, just release your code 
under the GPL.  If you're reverse engineering something, then, as the 
former Register writes, that gives an exemption.


Seems pretty clear, and no different from the current situation. 
Right?  Or, am I misunderstanding?


APIs are in general not very verbose.

There may be only one sensible way to express them, and it may be 
impossible to come up with a working
copy without something that either is literally identical to the vendors 
copy of the API code, or is so
similar that someone not skilled in the art of software would conclude 
that it's a mere copy, and not the

only possible embodiment of that API.

Yes, you can rename elements of structures and such - but that may not 
actually help.

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-17 09:36 AM, Ian Stirling wrote:


On 10/16/2014 07:16 AM, thufir wrote:


I cannot fathom why the FSF is on the side of letting API's get 
copied, I

mean stolen. Do they not see the result this would have on the GPL? Or,
do they see a larger issue? Or, do they just think that it's not
stealing? It's remarkable that the trial judge and the appeal judge use
a word like stolen, and not "infringe" or other legal mumbo jumbo.


If APIs can't be freely copied, then that means that it is essentially 
impossible to interoperate with systems without the vendors permission.


WINE is not legal.
Nor, is GCC compiling to target architectures where the vendor has not 
released information with a free licence but it's been reverse 
engineered.
Nor is Samba or any of the many filesystems that have been reverse 
engineered.





Your ignoring:

'As the former Register of Copyrights of the United States pointed out 
in his brief amicus curiae, “[h]ad Google reverse engineered the 
programming packages to figure out the ideas and functionality of the 
original, and then created its own structure and its own literal code, 
Oracle would have no remedy under copyright whatsoever.”'


Right there, the appeals court explains how to work around copyright.  
does that cover Wine?  GCC?


Since Wine and Apache Harmony are both reverse engineered, they're fine 
-- no different from yesterday, the sky isn't falling.


Presumably, since GCC and GCJ are under the GPL, I don't think it even 
matters.  However, in the context of API's, SSO and reverse engineering 
I'll ask:  are they reverse engineered?


I think it's moot because of reverse engineering.



-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-18 07:51 AM, lkcl . wrote:

On Fri, Oct 17, 2014 at 12:10 PM, Kern Sibbald  wrote:

>I am not taking any side, but could you be more specific on your comment
>"the result this would have on the GPL"?

  i do not believe that the GPL currently*explicitly*  states "any
**APIs*** implemented in the source code which is being licensed under
the GPL are available under the terms and conditions*of*  the GPL".


No, but we're talking about implications.  If anyone can come along, 
copy/paste method headers and the write their implementing code, well, 
that's a very weak sort copyright protection, right?  Or, do you say 
that it's fine to do so?


While Dalvik is at least under the ASL, it could just as easily be 
proprietary.  Now you've got a situation where method headers were 
copied, the implementing code farmed out, and no copyright protection.  
None.


to reiterate, this is in the context of copying, not of reverse engineering.



-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-18 08:11 AM, lkcl . wrote:

On Sat, Oct 18, 2014 at 6:26 AM, thufir  wrote:

On 14-10-17 03:52 AM, Luke Kenneth Casson Leighton wrote:

   you would no longer be permitted to utilise or work on the Firefox
Web Browser, because it has implemented a near-identical copy of the
Microsoft COM protocol named XPCOM (badly, it has to be said.


That's not at all what the appeals court wrote.

  it may not explicitly be what was written, but what was explicitly
written is irrelevant. it's what's *implied* by what is written that
is important.


the appeals court explicitly writes:

'Though the trial court did add the caveat that it “does not hold that 
the structure, sequence and organization of all computer programs may be 
stolen,” Copyrightability Decision, 872 F. Supp. 2d at 1002, it is hard 
to see how its method of operation analysis could lead to any other 
conclusion.'


exactly because they're one step ahead of the argument you make, this is 
all about the ramifications.  They're not implying what the 
ramifications might or might not be, they're explicitly stating what 
they believe the ramifications to be.  We don't need to infer when the 
judges explicitly write about the larger ramifications.




  and, from what i gather everyone is saying, the crux of the matter is
that APIs are to become copyrightable material.

  due to the concept of case-law [precedent] i don't believe that the
judge may permit *only* 37 APIs to become copyrighted without also
setting a huge precedent of allowing *other people* to then quote the
exact same arguments and use this case as a reference.

  i believe this is what case law is all about?

  does that make it clear that this *REALLY IS* about copyrighting *ALL* APIs?


No, it doesn't make it clear at all because you're completely ignoring:

'As the former Register of Copyrights of the United States pointed out 
in his brief amicus curiae, “[h]ad Google reverse engineered the 
programming packages to figure out the ideas and functionality of the 
original, and then created its own structure and its own literal code, 
Oracle would have no remedy under copyright whatsoever.”'


The appeals court, right there, explicitly explains exactly how to 
work-around copyright:  reverse engineer the API's.


So, your concern that no one will be able to work on API's is unfounded 
-- provided that the API's are reverse engineered.  How is this any 
different than the current situation?


Correct me if I'm wrong, but, when working on an API, whether it's WINE 
or Apache Harmony, it's in the context of reverse engineering? Google 
doesn't claim to have reverse engineered anything, nor do they make the 
claim that they limited themselves to forking Apache Harmony.  Reading 
between the lines, they know that the copied so never claimed any 
exemption on that basis...sorta.


Except that their justifications for copying are all based on reverse 
engineering...confusing, to say the least.




Or, even better, hey why not just fork OpenJDK, trim it down, call it 
OpenJDKThe37APIsForPhones, and release it under the GPL?  That, to me, 
would've been the best solution -- Google went a different direction.




However, to allow the SSO

  apologies i have no idea what an "S S O" is - it's not a common
computing term that i've ever encountered in the past 38 years of
working with computers.  would you mind providing a reference to this
acronym?

l.


SSO is legal jargon:

http://en.wikipedia.org/wiki/Structure,_sequence_and_organization

I think, for the most part, it's safe to read "API" for "SSO" in the 
context of Google, Java, Android and Oracle -- at least, that's my take.


Keep in mind that Apache Harmony, so far as I understand, was exactly as 
described above:  a clean room, reverse engineered implementation of 
Java for the purposes of compatibility.  They hit every note that the 
appeals court asks.


I keep going back to purpose:

'Instead, Google chose to copy both the declaring code and the overall 
SSO of the 37 Java API packages at issue.'


to me, that says it all.  That's a strong statement that Google:

1.)  copied, they didn't reverse engineer
2.)  their purpose wasn't compatability
3.)  dalvik isn't compatible -- going by footnote 15, at least. Also, 
James Gosling.



Apache Harmony, quite notably, would've hit all three points where 
Google missed.  Now that OpenJDK is (mostly? completely?) under the GPL, 
there's not much point in Apache Harmony; it's been dead for a while.



I'm not subscribed to fsfeurope, so...will my reply to them bounce?




-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[lkcl .]

On Fri, Oct 17, 2014 at 12:10 PM, Kern Sibbald  wrote:
> I am not taking any side, but could you be more specific on your comment
> "the result this would have on the GPL"?

 i do not believe that the GPL currently *explicitly* states "any
**APIs*** implemented in the source code which is being licensed under
the GPL are available under the terms and conditions *of* the GPL".

 in other words, what oracle - and the court - have not realised is
that *unless* software licenses of the past - not just the GPL but
*all* software licenses - *specifically* have been designed with
enough foresight to explicitly state "yeah you can use the APIs in
this software" then it is necessary to go and ask permission of the
copyright holders.

in the case of the GPL on the linux kernel that is clearly flat-out impossible.

now there may be some cases where some software licenses (proprietary
ones usually) prevent and prohibit interacting with the software in
general such that the APIs (if there are any) are explicitly
prohibited *anyway* (by saying things like "you may not link against
this software") but actually reviewing that - world-wide - all
businesses, all end-users, all software suppliers... we're looking at
a _major_ amount of hassle.

l.

> Thanks,
> Kern
>
>
> On 14-10-16 02:16 AM, thufir wrote:
>>
>> On Sat, 10 May 2014 12:55:29 +0100, TJ wrote:
>>
>> > What are the potential ramifications of the U.S.A. appeals court
>> > decision in Oracle Vs Google, that APIs are copyrightable and the only
>> > question now is whether such use is fair-use?
>> >
>> > I'm wondering about the specific affect on a GPL licensed project that
>> > re-implements an API, distributes their code under the GPL, and the
>> > developers and downstream users exposure to a claim of copyright
>> > infringement (of the API) for developing and using the F/OSS
>> > implementation by the original API copyright holder?
>>
>>
>> 'Though the trial court did add the caveat that it “does not hold that
>> the structure, sequence and organization of all computer programs may be
>> stolen,” Copyrightability Decision, 872 F. Supp. 2d at 1002, it is hard
>> to see how its method of operation analysis could lead to any other
>> conclusion.'
>>
>> the appeals court seems to have hit the nail on the head.
>>
>> I cannot fathom why the FSF is on the side of letting API's get copied, I
>> mean stolen. Do they not see the result this would have on the GPL? Or,
>> do they see a larger issue? Or, do they just think that it's not
>> stealing? It's remarkable that the trial judge and the appeal judge use
>> a word like stolen, and not "infringe" or other legal mumbo jumbo.
>>
>>
>>
>>
>> -Thufir
>>
>
>

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-18 08:06 AM, lkcl . wrote:

On Sat, Oct 18, 2014 at 6:10 AM, thufir  wrote:


>In this case we're talking about OpenJDK.  OpenJDK is under the GPL.  Well,
>now anyone can come along, copy the SSO and distribute without consideration
>of the GPL.  Wow, that's huge.

  no not really.  if they implement an interoperable version, then so what?



They don't even claim to implement an interoperable version, to start with:

'Counsel did not identify any programs that use only the 37 API packages 
at issue, however, and did not attest that any such program would be 
useful. Nor did Google cite to any record evidence to support this claim.'


and, they never claimed to have reverse engineered the API, at least no 
where did I see Google ever make this claim.  Ever.  See:


'As the former Register of Copyrights of the United States pointed out 
in his brief amicus curiae, “[h]ad Google reverse engineered the 
programming packages to figure out the ideas and functionality of the 
original, and then created its own structure and its own literal code, 
Oracle would have no remedy under copyright whatsoever.”'


Google does claim that they "had" to implement the 37 API's, that's just 
circular reasoning:


'Indeed, given the record evidence that Google designed Android so that 
it would not be compatible with the Java platform, or the JVM 
specifically, we find Google’s interoperability argument confusing. 
While Google repeatedly cites to the district court’s finding that 
Google had to copy the packages so that an app written in Java could run 
on Android, it cites to no evidence in the record that any such app 
exists and points to no Java apps that either pre-dated or post-dated 
Android that could run on the Android platform. 15 The compatibility 
Google sought to foster was not with Oracle’s Java platform or with the 
JVM central to that platform.'


I think when the appeals court writes that Google's argument is 
confusing, that's just code for circular reasoning -- they're being 
polite, and giving Google an opportunity to make a non-confusing 
argument to the SCOTUS.


Again:

'The compatibility Google sought to foster was not with Oracle’s Java 
platform or with the JVM central to that platform.'


So, unfortunately, your what-if above doesn't even apply, there's no "so 
what".


Google seems to be making this compatibility argument, but it's a very 
weak sort of compatibility:


"And so all these Android phones are going to be incompatible." -James 
Gosling



This is my reading of the appeals court decision.


1.)  Dalvik isn't compatabile
2.)  Dalvik wasn't reverse engineered -- or at least, Google never makes 
that explicit claim



but Google's justifications are all about compatibility, which only 
applies in the case of reverse engineering.




-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[lkcl .]

On Sat, Oct 18, 2014 at 6:26 AM, thufir  wrote:
> On 14-10-17 03:52 AM, Luke Kenneth Casson Leighton wrote:
>>
>>   you would no longer be permitted to utilise or work on the Firefox
>> Web Browser, because it has implemented a near-identical copy of the
>> Microsoft COM protocol named XPCOM (badly, it has to be said.
>
>
> That's not at all what the appeals court wrote.

 it may not explicitly be what was written, but what was explicitly
written is irrelevant. it's what's *implied* by what is written that
is important.

 and, from what i gather everyone is saying, the crux of the matter is
that APIs are to become copyrightable material.

 due to the concept of case-law [precedent] i don't believe that the
judge may permit *only* 37 APIs to become copyrighted without also
setting a huge precedent of allowing *other people* to then quote the
exact same arguments and use this case as a reference.

 i believe this is what case law is all about?

 does that make it clear that this *REALLY IS* about copyrighting *ALL* APIs?

> However, to allow the SSO

 apologies i have no idea what an "S S O" is - it's not a common
computing term that i've ever encountered in the past 38 years of
working with computers.  would you mind providing a reference to this
acronym?

l.

Re: Oracle vs Google: APIs are copyright; appeal decision

[lkcl .]

On Sat, Oct 18, 2014 at 6:10 AM, thufir  wrote:

> In this case we're talking about OpenJDK.  OpenJDK is under the GPL.  Well,
> now anyone can come along, copy the SSO and distribute without consideration
> of the GPL.  Wow, that's huge.

 no not really.  if they implement an interoperable version, then so what?

 in fact, google has already done that on a vast number of
pre-existing software libre packages (and earned a very dim reputation
in the software libre community as a result).

 for their own stupid reasons google stupidly made copies of at least
busybox, i believe they also made a copy of glibc and many many other
packages, *entirely* reimplementing them _just_ so that they could
satisfy pathetic whining companies who were  so scred of the
GPL when distributing android .[.. and then hypocritically *didn't*
re-implement the linux kernel, leaving massive numbers of
manufacturers with the false impression that android *and* the linux
kernel it runs on are both entirely Apache Licensed... but that is
another story ].

 anyway yes, google has *already* re-implemented a huge number of
GPL'd and LGPL'd APIs entirely as Apache-licensed software,  and
despite it being a hypocritical decision nobody has blinked because
they are perfectly within their legal rights to do so.

l.

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-17 08:52 AM, lkcl . wrote:

  the reverse-engineering was at several different levels:


I think your missing a key point, which is that you reverse-engineered, 
which is exactly exempt:


'Sec. 103(f) of the DMCA 
 (17 
U.S.C. § 1201 (f) 
) 
says that a person who is in legal possession of a program, is permitted 
to reverse-engineer and circumvent its protection if this is necessary 
in order to achieve "interoperability"...'


-wikipedia

never occured.  Granted, Harmony was an attempt at reverse engineering, 
but Dalvik is more than just Harmony.  Google has never disputed that 
they copied, in fact it never came up.


Google didn't reverse engineer.  While I appreciate your point, it's not 
directly relevant -- the analogy doesn't hold.  Nowhere in its legal 
filings did Google even claim to have reverse engineered anything.  Also 
from the appeals court:


"Oral Argument at 31:31. Counsel did not identify any programs that use 
only the 37 API packages at issue, however, and did not attest that any 
such program would be useful. Nor did Google cite to any record evidence 
to support this claim."


and, most damning:

'As the former Register of Copyrights of the United States pointed out 
in his brief amicus curiae, “[h]ad Google reverse engineered the 
programming packages to figure out the ideas and functionality of the 
original, and then created its own structure and its own literal code, 
Oracle would have no remedy under copyright whatsoever.”'



No, I've gotta say that, based on what I've read, this has absolutely 
nothing to do with reverse engineering; your analogy doesn't apply.



Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-17 04:10 AM, Kern Sibbald wrote:
I am not taking any side, but could you be more specific on your 
comment "the result this would have on the GPL"?


Thanks,
Kern 


Please do take a side at some point, or take both sides, or your own side

The key phrase from Alsup, the trial judge, is that he writes "it does 
not hold":


''Though the trial court did add the caveat that it “does not hold that 
the structure, sequence and organization of all computer programs may be 
stolen,” Copyrightability Decision, 872 F. Supp. 2d at 1002, it is hard 
to see how its method of operation analysis could lead to any other 
conclusion.'


well, why not?  Why doesn't it hold that the wider implication is that 
the SSO of all programs may be stolen?


It's notable that the trial judge doesn't write "infringed" or "copied", 
he goes right to the word "stolen," which is so often mistakenly used in 
copyright.  Now, when joe public downloads a DVD, Hollywood wants to 
call that "stealing," but it's not -- and I have no doubt that Alsup is 
quite aware of the distinction.  Which makes his language choice, let's 
say, interesting.


When he writes "it does not hold" my take is that this is a slip. He 
arrived at his conclusion, and then considered the wider consequences 
were his decision to be applied elsewhere, and then, realizing what the 
potential result would be, wrote "it does not hold" exactly because of 
the potential implication.  Speculation on my part, but I put another 
negation on his negation -- it does hold.


Now, this is just one trial, but let's consider the wider implications.  
If the SCOTUS says, sure, go ahead and copy the SSO of any computer 
program, (not that they would phrase it like that), what are the 
implications?


In this case we're talking about OpenJDK.  OpenJDK is under the GPL.  
Well, now anyone can come along, copy the SSO and distribute without 
consideration of the GPL.  Wow, that's huge.


Even bigger than that, there's no copyright at all, or nothing 
enforceable, on SSO.


Please correct my reading of the appeals court decision.  I'm literally 
asking how others parse that excerpt from the appeals decision.



-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On 14-10-17 03:52 AM, Luke Kenneth Casson Leighton wrote:

  you would no longer be permitted to utilise or work on the Firefox
Web Browser, because it has implemented a near-identical copy of the
Microsoft COM protocol named XPCOM (badly, it has to be said.


That's not at all what the appeals court wrote.  Footnote 15, in full:

'During oral argument, Google’s counsel stated that “a program written 
in the Java language can run on Android if it’s only using packages 
within the 37. So if I’m a developer and I have written a program, I’ve 
written it in Java, I can stick an Android header on it and it will run 
in Android because it is using the identical names of the classes, 
methods, and packages.” Oral Argument at 31:31. Counsel did not identify 
any programs that use only the 37 API packages at issue, however, and 
did not attest that any such program would be useful. Nor did Google 
cite to any record evidence to support this claim.'


Even if there's a useful program which only uses the 37 API packages at 
issue, and I'm not sure that there's a "useful" program like that, I 
don't know that it would change anything.  I've seen reference to jetty 
and i-jetty, but I think that just demonstrates that, no, a "useful" 
program will tend to use more than the 37 API's; it might use additional 
Android packages.


This really has nothing at all to do with reverse engineering:

'As the former Register of Copyrights of the United States pointed out 
in his brief amicus curiae, “[h]ad Google reverse engineered the 
programming packages to figure out the ideas and functionality of the 
original, and then created its own structure and its own literal code, 
Oracle would have no remedy under copyright whatsoever.”'


where the former Register, whomever that was, points out how reverse 
engineering works -- which I'm sure that the appeals court already 
knew.  In any event, there it is, it's a good quote.


You absolutely will be permitted to work on on any API.  In the case of 
Firefox, since, I think, it's under the GPL, just release your code 
under the GPL.  If you're reverse engineering something, then, as the 
former Register writes, that gives an exemption.


Seems pretty clear, and no different from the current situation. Right?  
Or, am I misunderstanding?


However, to allow the SSO of any, and let's emphasize **any** computer 
program, to be stolen, and let's use the word stolen, that would be a 
dramatic shift.  Yes/no?


If there's no way to enforce SSO under copyright, then any SSO can be 
**stolen** -- which is the word being used by the judges in this case.  
the appeals court chose to write about the wider implications, so I'm 
adopting the language of first judge, and the appeals court, to use 
**any** and **stolen**.




-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[Ian Stirling]

On 10/16/2014 07:16 AM, thufir wrote:


I cannot fathom why the FSF is on the side of letting API's get copied, I
mean stolen. Do they not see the result this would have on the GPL? Or,
do they see a larger issue? Or, do they just think that it's not
stealing? It's remarkable that the trial judge and the appeal judge use
a word like stolen, and not "infringe" or other legal mumbo jumbo.


If APIs can't be freely copied, then that means that it is essentially 
impossible to interoperate with systems without the vendors permission.


WINE is not legal.
Nor, is GCC compiling to target architectures where the vendor has not 
released information with a free licence but it's been reverse engineered.
Nor is Samba or any of the many filesystems that have been reverse 
engineered.

Re: Oracle vs Google: APIs are copyright; appeal decision

[Kern Sibbald]

I am not taking any side, but could you be more specific on your comment 
"the result this would have on the GPL"?


Thanks,
Kern

On 14-10-16 02:16 AM, thufir wrote:

On Sat, 10 May 2014 12:55:29 +0100, TJ wrote:

> What are the potential ramifications of the U.S.A. appeals court
> decision in Oracle Vs Google, that APIs are copyrightable and the only
> question now is whether such use is fair-use?
>
> I'm wondering about the specific affect on a GPL licensed project that
> re-implements an API, distributes their code under the GPL, and the
> developers and downstream users exposure to a claim of copyright
> infringement (of the API) for developing and using the F/OSS
> implementation by the original API copyright holder?


'Though the trial court did add the caveat that it “does not hold that
the structure, sequence and organization of all computer programs may be
stolen,” Copyrightability Decision, 872 F. Supp. 2d at 1002, it is hard
to see how its method of operation analysis could lead to any other
conclusion.'

the appeals court seems to have hit the nail on the head.

I cannot fathom why the FSF is on the side of letting API's get copied, I
mean stolen. Do they not see the result this would have on the GPL? Or,
do they see a larger issue? Or, do they just think that it's not
stealing? It's remarkable that the trial judge and the appeal judge use
a word like stolen, and not "infringe" or other legal mumbo jumbo.




-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision

[thufir]

On Sat, 10 May 2014 12:55:29 +0100, TJ wrote:

> What are the potential ramifications of the U.S.A. appeals court
> decision in Oracle Vs Google, that APIs are copyrightable and the only
> question now is whether such use is fair-use?
>
> I'm wondering about the specific affect on a GPL licensed project that
> re-implements an API, distributes their code under the GPL, and the
> developers and downstream users exposure to a claim of copyright
> infringement (of the API) for developing and using the F/OSS
> implementation by the original API copyright holder?


'Though the trial court did add the caveat that it “does not hold that
the structure, sequence and organization of all computer programs may be
stolen,” Copyrightability Decision, 872 F. Supp. 2d at 1002, it is hard
to see how its method of operation analysis could lead to any other
conclusion.'

the appeals court seems to have hit the nail on the head.

I cannot fathom why the FSF is on the side of letting API's get copied, I
mean stolen. Do they not see the result this would have on the GPL? Or,
do they see a larger issue? Or, do they just think that it's not
stealing? It's remarkable that the trial judge and the appeal judge use
a word like stolen, and not "infringe" or other legal mumbo jumbo.




-Thufir

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[Richard Fontana]

On Fri, May 16, 2014 at 01:17:09PM -0400, Joshua Gay wrote:
> I don't understand how these things work well enough to formulate my
> own opinion, but I've been hearing mixed opinions on precedent. Here
> is Jonathan Band's take on the matter of precedent,
> :
> 
> "1. The Federal Circuit’s decision is not binding precedent in any
> other case in any district court anywhere in the country. Because
> this case arose in the Ninth Circuit, the Federal Circuit was
> required to apply Ninth Circuit precedent. But its interpretation of
> Ninth Circuit precedent is not binding on district courts in the
> Ninth Circuit, or any other circuit. Thus, a district court in San
> Jose or Seattle is free to ignore the Federal Circuit’s
> misinterpretation of Sega v. Accolade and Sony v. Connectix."
> 
> "To be sure, other district courts may find the Federal Circuit’s
> reasoning to be persuasive, but it is not binding. And as these
> district courts dig into the Federal Circuit’s reasoning, they
> quickly will conclude that it is not that persuasive. The Federal
> Circuit certainly undermined its credibility with its assertion that
> Google and its amici believe that software should not be protectable
> under copyright. The Federal Circuit itself flatly contradicts this
> assertion when it observed that"

FWIW I believe what Jonathan says about precedent here is correct. 

 - RF

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[TJ]

On 16/05/14 18:17, Joshua Gay wrote:


I don't understand how these things work well enough to formulate my own
opinion, but I've been hearing mixed opinions on precedent. Here is
Jonathan Band's take on the matter of precedent,
:

"1. The Federal Circuit’s decision is not binding precedent in any other
case in any district court anywhere in the country. Because this case
arose in the Ninth Circuit, the Federal Circuit was required to apply
Ninth Circuit precedent. But its interpretation of Ninth Circuit
precedent is not binding on district courts in the Ninth Circuit, or any
other circuit. Thus, a district court in San Jose or Seattle is free to
ignore the Federal Circuit’s misinterpretation of Sega v. Accolade and
Sony v. Connectix."


Joshua, thank you. If that analysis proves correct it suggests that Google will 
ask for an en-banc hearing which might clarify things.

I'm working on obtaining some expert legal opinion as to the precise situation 
in the E.U./U.K. and I'll keep a close
eye on how things develop in the U.S.A. In the meantime I'm going to suspend my 
project until the legal landscape is clearer.

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[Joshua Gay]

On 05/16/2014 06:32 AM, TJ wrote:


But, unless I have misunderstood the lawyers (such as the EFF) who have
opined on the Oracle vs Google
appeal decision, the finding that the merger doctrine should be applied
to the time of the original creation, not
the time of alleged infringement, resulting in the fact that APIs can be
copyrighted is now precedent - unless overturned by an en-banc hearing
or appeal to the Supreme court.

>
> "Today's decision puts all of that at risk, potentially handing
> Oracle and others veto power over any developer who wants to create a
> compatible program." [0]

I don't understand how these things work well enough to formulate my own 
opinion, but I've been hearing mixed opinions on precedent. Here is 
Jonathan Band's take on the matter of precedent,

:

"1. The Federal Circuit’s decision is not binding precedent in any other 
case in any district court anywhere in the country. Because this case 
arose in the Ninth Circuit, the Federal Circuit was required to apply 
Ninth Circuit precedent. But its interpretation of Ninth Circuit 
precedent is not binding on district courts in the Ninth Circuit, or any 
other circuit. Thus, a district court in San Jose or Seattle is free to 
ignore the Federal Circuit’s misinterpretation of Sega v. Accolade and 
Sony v. Connectix."


"To be sure, other district courts may find the Federal Circuit’s 
reasoning to be persuasive, but it is not binding. And as these district 
courts dig into the Federal Circuit’s reasoning, they quickly will 
conclude that it is not that persuasive. The Federal Circuit certainly 
undermined its credibility with its assertion that Google and its amici 
believe that software should not be protectable under copyright. The 
Federal Circuit itself flatly contradicts this assertion when it 
observed that"

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[TJ]

On 15/05/14 20:58, Bradley M. Kuhn wrote:

[ I attempted to post a message similar to this on May 12th, but it never
   showed up in the archives nor did I get a copy back via the list as
   I usually do for my posts.  I'm posting again, so if the moderators
   just missed my previous email, please just delete that one and mod
   this one through instead.  Thanks! ]

I'd encourage people to not go off too far in speculating about the Oracle
v. Google case, and/or worrying about how it relates to GPL enforcement or
anything like that.  The case is remanded back to the lower court, and until
a new jury considers the fair use defense, there is not that much to say.
(IANAL and TINLA, of course.)


But, unless I have misunderstood the lawyers (such as the EFF) who have opined 
on the Oracle vs Google
appeal decision, the finding that the merger doctrine should be applied to the 
time of the original creation, not
the time of alleged infringement, resulting in the fact that APIs can be 
copyrighted is now precedent - unless overturned by an en-banc hearing or 
appeal to the Supreme court.

"Today's decision puts all of that at risk, potentially handing Oracle and others 
veto power over any developer who wants to create a compatible program." [0]

That's regardless of the outcome of a fair-use trial in the particular case.

I need to make a decision on whether to continue the work I'm currently engaged 
upon reimplementing a proprietary
API and protocol in a GPL v3 project, or to abandon it before I waste a couple 
of years creating something that cannot
be freely distributed.

[0] 
https://www.eff.org/deeplinks/2014/05/dangerous-ruling-oracle-v-google-federal-circuit-reverses-sensible-lower-court

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[Bradley M. Kuhn]

[ I attempted to post a message similar to this on May 12th, but it never
  showed up in the archives nor did I get a copy back via the list as
  I usually do for my posts.  I'm posting again, so if the moderators
  just missed my previous email, please just delete that one and mod
  this one through instead.  Thanks! ]

I'd encourage people to not go off too far in speculating about the Oracle
v. Google case, and/or worrying about how it relates to GPL enforcement or
anything like that.  The case is remanded back to the lower court, and until
a new jury considers the fair use defense, there is not that much to say.
(IANAL and TINLA, of course.)

But, I admit that I did in fact write a blog post and record and audcast
about the topic:
  http://ebb.org/bkuhn/blog/2014/05/10/oracle-google.html
  http://faif.us/cast/2014/may/13/0x44/

.. so maybe there is a *little* something to be said about it. :)

   -- bkuhn

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[TJ]

On 13/05/14 10:47, Neil Brown wrote:


I am afraid that I have not yet had a chance to get to grips with the Oracle v. 
Google case, but you might find the discussion before the High Court, and the 
Court of Appeal, in the SAS v. WPL case in the UK, to be of interest, along 
with the reference for the Court of Justice of the European Union, in 
interpreting the computer programs directive:

High Court: http://www.bailii.org/ew/cases/EWHC/Ch/2013/69.html
CJEU reference: 
http://curia.europa.eu/juris/document/document.jsf?docid=122362&doclang=EN
Court of Appeal:http://www.bailii.org/ew/cases/EWCA/Civ/2013/1482.html


Neil, those links are just what I was hoping for, so thank-you.

I wrote regarding Article 6 2.(c) and reverse-engineering:


In other words I read this as saying it is legal to use reverse-engineered 
interface specifications of a 'server'
in order to create a 'client', but not to create another 'server' 
implementation, nor to publish
documentation of the interface.


The EUCJ deals with this in paragraphs 60 and 61:

"60. As regards that latter condition, Article 6(2)(c) of Directive 91/250 relating to decompilation states that decompilation does not permit the information obtained through its application to be 
used for the development, production or marketing of a computer program substantially similar in its expression, or for any other act which infringes copyright."


61. It must therefore be held that the copyright in a computer program cannot be infringed where, as in the present case, the lawful acquirer of the licence did not have access to the source code of 
the computer program to which that licence relates, but merely studied, observed and tested that program in order to reproduce its functionality in a second program."



So the EUCJ is saying you cannot reverse-engineer a computer program in order to create a functionally compatible alternative, but you can create a functionally compatible alternative by studying the 
program's interaction with other programs, data files, users, other programs and other systems.


THE EUCJ didn't deal explicitly with API interfaces but on my reading it 
addressed it tangentially in its answers to Arnold J's questions 1 to 5 and 8 
to 9.

In the context of format of data files it said:


"43. In that context, it should be made clear that, if a third party were to procure the part of the source code or the object code relating to the programming language or to the format of data files 
used in a computer program, and if that party were to create, with the aid of that code, similar elements in its own computer program, that conduct would be liable to constitute partial reproduction 
within the meaning of Article 4(a) of Directive 91/250."



I take "liable to constitute partial reproduction" to mean, it would infringe.

In the context of discussing the use of the original program's user manual 
being used by the defendant as a specification for writing its alternative 
implementation, the court said:


"70. Consequently, in the light of the foregoing considerations, the answer to Questions 8 and 9 is that Article 2(a) of Directive 2001/29 must be interpreted as meaning that the reproduction, in a 
computer program or a user manual for that program, of certain elements described in the user manual for another computer program protected by copyright is capable of constituting an infringement of 
the copyright in the latter manual if—this being a matter for the national court to ascertain—that reproduction constitutes the expression of the intellectual creation of the author of the user manual 
for the computer program protected by copyright."



I parse that as saying that Program A and User Manual A have copyright protection if they are expressions of Author A's intellectual creation. That being the case, if Author B creates a (functionally 
compatible) Program B and/or a User Manual B based on a reading of User Manual A, then either or both of Program B and User Manual B may infringe on the copyright in User Manual A.


Arnold J interprets the EUCJ in the following terms in paragraph 16:


"In my judgment, the CJEU's answer to Questions 1-5 amounts to an endorsement of Pumfrey J's interpretation of Article 1(2) of the Software Directive. In short, copyright in a computer program does 
not protect either the programming language in which it is written or its interfaces (specifically, its data file formats) or its functionality from being copied. ..."



He goes into more detail in later paragraphs under the heading "SAS data file formats" and much of that is detailing that the plaintiff failed to raise amended issues early enough and therefore cannot 
do it now so avoids any detailed investigation in respect of data file formats.


He concludes that defendants did not infringe on the plaintiff's copyright in 
User Manual A but not for the obvious reason:


"53. I remain of the view that, for the reasons I gave in my first 

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[TJ]

On 14/05/14 04:24, Fernando Cassia wrote:

On Mon, May 12, 2014 at 1:44 PM, TJ  wrote:

It seems to impact reverse engineering too, since most black-box reverse
engineering techniques aim to observe the external interactions of an
executing binary and then write an interface specification (API) from which
a compatible implementation is written in a clean-room environment.


But you forget another way to get interoperability: justice and
regulators. Microsoft for instance was forced by regulators to open up
their networking protocols and APIs, as a result of which SAMBA can
implement compatible versions.


I do not forget - competition law forcing the sharing of otherwise 
(proprietary) copyright-protected information
is only useful where a single organisation has a dominant market position 
(monopoly) in a relevant market.

That is completely orthogonal to my questions about Copyright and doesn't help 
in the majority of instances
where someone would wish to publish an alternative implementation of some API.

It also doesn't help in the U.S.A. where there isn't the same regulatory 
oversight.


The documentation created as part of the EU settlement with Microsoft
helped us to make the Samba 4 Active Directory Compatible domain
controller code robust and reliable when interoperating with Microsoft
AD domain controllers.


That was a welcome outcome, but it took from 1998 to the end of 2007 to obtain the specifications under NDA, cost €1, and required the relentless pursuit of Microsoft by the EU commission through 
massive fines even after judgment and appeals.



Most other open protocols (ie TCPIP) are open by design (from the
start).  Maybe this ruling will have a positive impact: make people
weary of closed protocols and APIs that do not have an open source
implementation.

If this means more use of SIP and less use of Skype, all the better.


Agreed. It also calls to mind Cisco's behaviour over HSRP and VRRP.

The issue I've had in mind in bringing up this subject is how it affects open-source implementations. If it holds that APIs are copyright absent a fair-use judgment, then any existing open-source 
implementation of a (proprietary) copyrighted API could find itself threatened by a litigious API copyright owner, and as copyright terms are so much longer than patent it would effectively destroy 
any realistic prospect of alternative implementations surviving.



Yes, some surely will be hurt, ie WINE and ReactOS... but it's my
belief that they can challenge MSFT to open their APIs on competition
(antitrust) grounds...


I refer back to my earlier comments on the use of competition law.

I have been working on a GPL v3 implementation of a widely used proprietary 
protocol and had worked, until now, on
the assumption that APIs aren't copyrightable but after this appeals decision 
my primary concern has switched from
the technical challenges to the legal. I do not want to get to the end of what is a very time-intensive project which will probably total a couple of man-years only to discover that I am unable to 
legally publish my work.

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[Neil Brown]

On 12 May 2014, at 19:23, TJ  wrote:

>> Hi
>> Short version
>> In EU have already decided that api is not copyrighted. it was a trial a
>> company implement api/function of another program and program languaes. and
>> it is fair use and you have right reimplement.
> 
> My reading of directive 2009/24/EC contradicts your interpretation.
> ...
> 
> This text seems to carefully carve out "ideas and principles" that "underlie 
> its interfaces"
> as not being protected, but it doesn't say interfaces as expressions aren't 
> protected.

I am afraid that I have not yet had a chance to get to grips with the Oracle v. 
Google case, but you might find the discussion before the High Court, and the 
Court of Appeal, in the SAS v. WPL case in the UK, to be of interest, along 
with the reference for the Court of Justice of the European Union, in 
interpreting the computer programs directive:

High Court: http://www.bailii.org/ew/cases/EWHC/Ch/2013/69.html
CJEU reference: 
http://curia.europa.eu/juris/document/document.jsf?docid=122362&doclang=EN
Court of Appeal:http://www.bailii.org/ew/cases/EWCA/Civ/2013/1482.html

There is summary here: 

http://www.scl.org/site.aspx?i=ne34424

but, as with the case itself, “tortuous” is a fair description.



Enjoy :)


Neil

__

Neil Brown
n...@neilzone.co.uk | http://neilzone.co.uk







signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[TJ]

On 11/05/14 21:36, Magnus Olsen wrote:

Hi
Short version
In EU have already decided that api is not copyrighted. it was a trial a
company implement api/function of another program and program languaes. and
it is fair use and you have right reimplement.


My reading of directive 2009/24/EC contradicts your interpretation.

Article 1 2. says:

"Protection in accordance with this Directive shall apply to
the expression in any form of a computer program. Ideas and
principles which underlie any element of a computer program,
including those which underlie its interfaces, are not protected
by copyright under this Directive."

This text seems to carefully carve out "ideas and principles" that "underlie its 
interfaces"
as not being protected, but it doesn't say interfaces as expressions aren't 
protected.

I've not (yet) looked at the individual member states laws that implement the 
directive
but I doubt the wording will vary significantly from this.

Article 6 2.(c) prevents the use of interoperability interfaces deduced from 
inspecting the operation
of copyrighted works:

"to be used for the development, production or marketing of
a computer program substantially similar in its expression,
or for any other act which infringes copyright."

In other words I read this as saying it is legal to use reverse-engineered 
interface specifications of a 'server'
in order to create a 'client', but not to create another 'server' 
implementation, nor to publish
documentation of the interface.

In the Oracle vs Google situation an analogy would be that it is legal to 
observe the external
interfaces of the Java runtime (RT) library and Java virtual machine to create 
Java applications that
interface with the VM and RT, but not to create another JVM or RT 
implementation.

In the case of Apache Harmony its reimplementation of the Java Class Library 
API was based on the published
Sun SDK Specification and the associated license which permits reimplementation 
that fully reproduces the
specification and passes the TCK.

Google stripped back and modified parts of Harmony, which is the basis upon 
which Oracle's law-suit has succeeded, since without
permission via the SDK license Google had no other license to reimplement a 
reduced or changed API, if APIs are copyrightable as the appeals court has 
found.

In the case of an API that is published, it seems to me that creation of a 
competing implementation may be infringing
if the API documentation license restricts its use for that purpose, or, if the interface 
contains something other than "ideas and principles".

I'm currently working on a GPL v3 project that may be affected by this decision 
and the E.U./U.K. law.

Maybe Neil and Andrew can give their expert view on the current interpretation 
in the E.U./U.K. of this directive as it pertains
to 'interfaces' and pointers to any case law?

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[TJ]

On 11/05/14 17:14, Fernando Cassia wrote:

On Sat, May 10, 2014 at 8:55 AM, TJ  wrote:


>If in creating an interoperable project - let us imagine something akin to
>the Samba developers re-implementing the Microsoft SMB/CIFS and related
>protocols, or the WINE project's reimplementation of the Win32 APIs, or the
>OpenJDK project re-implementing the Java APIs - then the very fact that the
>law assumes that the APIs are copyrighted and a trial on fair-use is the
>only way to determine whether or not there is copyright infringement will
>have the effect of stopping most interoperability projects in their tracks.


When writing about things, it's generally a good idea to first know what
one is talking about.


The key phrase is "...let us imagine something akin to..."; I was giving 
examples of the type of project that (re)implements
a significant de-facto industry standard API to achieve interoperability. The 
same could apply to cloud services APIs being
re-implemented for cross-service portability as in, for example, Eucalyptus, 
OpenStack and CloudStack.

The appeals court decided that the trial court erred in pinpointing the time at 
which the creative expression occurred (the merger doctrine).

Until now it has been generally accepted in the development community that this 
would be the time at which the interoperable
alternative was created and this was the interpretation the trial court adopted.

The appeals court determined that is incorrect; the correct point in time is when the original expression occurred - in this case, when the Java developers at Sun designed the API. The upshot of that 
interpretation means that an interoperability project could not legally create an alternative implementation (in the U.S.A.) on the assumption that the API was not subject to copyright; the only way 
to determine legality would be for a trial and the fair-use defence before a Jury.


"Oracle also argues that the district court erred in invoking interoperability 
in its copyrightability analysis.
Specifically, Oracle argues that Google’s interoperability arguments are only 
relevant, if at all, to fair use
— not to the question of whether the API packages are copyrightable. We agree."

The appeal court further affirmed the trial court's 'scenes a fair' decision in respect of the specific defence Google raised using that doctrine. The EFF (and others) also raised this issue in their 
Amici Curiae briefs to the appeals court.


"On appeal, Google refers to scenes a faire concepts briefly, as do some amici, 
apparently contending that,
because programmers have become accustomed to and comfortable using the 
groupings in the Java API packages,
those groupings are so common place as to be indispensable to the expression of 
an acceptable programming
platform. As such, the argument goes, they are so associated with the “idea” of 
what the packages are
accomplishing that they should be treated as ideas rather than expression. See 
Br. of Amici Curiae Rackspace US, Inc.,
et al. at 19-22."
...
"Finally, Google’s reliance on the doctrine below and the amici reference to it here are premised on a fundamental misunderstanding of the doctrine. Like merger, the focus of the scenes a faire 
doctrine is on the circumstances
presented to the creator, not the copier. See Mitel, 124 F.3d at 1375 (finding error to the extent the trial court discussed “whether external factors such as market forces and efficiency 
considerations justified Iqtel’s copying of the command codes”). The court’s analytical focus must be upon the external factors that dictated Sun’s selection of classes, methods, and code

— not upon what Google encountered at the time it chose to copy those groupings and 
that code."


I see no reason why, on a literal reading of the appeal court's decision, the 
same reasoning will not be
applied to, for example, the command-line arguments of discrete binaries, 
network protocols in respect of the data structure
symbols and ordering, or 'standards' along the lines of POSIX/SUS.

It seems to impact reverse engineering too, since most black-box reverse engineering techniques aim to observe the external interactions of an executing binary and then write an interface 
specification (API) from which a compatible implementation is written in a clean-room environment.


Because copyright terms are so long it seems to me to have the potential to be 
far more disruptive than the U.S.A.'s Software Patent problems.

Even for interoperability developers outside the U.S.A. this has major 
implications if their software is likely to be imported into the U.S.A.; both 
for them and their users.

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[Bradley M. Kuhn]

TJ wrote:
> What are the potential ramifications of the U.S.A. appeals court decision
> in Oracle Vs Google, that APIs are copyrightable and the only question now
> is whether such use is fair-use?

I wrote a blog post on Saturday about this that might be of interest:
  http://ebb.org/bkuhn/blog/2014/05/10/oracle-google.html

> Could the lawyers amongst us provide some guidance especially as the
> decision may affect interpretation of API protection outside of the U.S.A.?

As I noted in my blog post, please note that lawyers don't have magic pixie
dust that they give them in law school to understand things.  The Courts are
discussing a matter of public policy.  I suggest that non-lawyers should have
a say in that too and we should listen to what non-lawyers have to say, too.


However, my TL;DR answer is that there is very little to conclude until
the fair use trial happens.  There are some interesting things in the ruling
to read and think about, but since it remands back to the lower court,
this isn't definitive precedent.

IANAL and TINLA.

   -- bkuhn

Re: Oracle vs Google: APIs are copyright; appeal decision ramifications?

[Fernando Cassia]

On Sat, May 10, 2014 at 8:55 AM, TJ  wrote:

> If in creating an interoperable project - let us imagine something akin to
> the Samba developers re-implementing the Microsoft SMB/CIFS and related
> protocols, or the WINE project's reimplementation of the Win32 APIs, or the
> OpenJDK project re-implementing the Java APIs - then the very fact that the
> law assumes that the APIs are copyrighted and a trial on fair-use is the
> only way to determine whether or not there is copyright infringement will
> have the effect of stopping most interoperability projects in their tracks.


When writing about things, it's generally a good idea to first know what
one is talking about.

OpenJDK is an ORACLE-sponsored project. Other firms contribute to it,
including Twitter, IBM, SAP, Apple, RedHat, and AMD.
In fact, Oracle has made OpenJDK 7 the reference implementation of Java7
and then for Java8 with OpenJDK 8 too. Oracle programmers contribute code
to OpenJDK and OpenJDK is the basis for the commercial and freeware builds
of Oracle JDK.

It's not a re-implementation, it's the official Open Source implementation
of Java.

See this to learn what OpenJDK is about, and the ecosystem around it
(including Oracle)
http://www.redhat.com/summit/2012/pdf/2012-DevDay-OpenJDK-Bhole.pdf‎

IBM Joins OpenJDK
http://www.sutor.com/c/2010/10/ibm-joins-the-openjdk-community/

SAP joins OpenJDK
http://scn.sap.com/community/open-source/blog/2011/07/14/sap-joins-openjdk

AMD and Oracle team up for Java GPU acceleration
http://scn.sap.com/community/open-source/blog/2011/07/14/sap-joins-openjdk

Apple and Oracle announce OpenJDK for Mac OS X
http://www.apple.com/pr/library/2010/11/12Oracle-and-Apple-Announce-OpenJDK
-Project-for-Mac-OS-X.html

Oracle makes OpenJDK the Java7 reference implementaiton
http://www.infoq.com/news/2011/06/openjdk-bylaws

Oracle open sources JavaFX 2.0 as OpenJFX under GPL license
http://openjdk.java.net/projects/openjfx/

Oracle open sources JavaFX 2.0 for iOS and Android
http://www.infoq.com/news/2013/02/javafx-ios-android

Oracle releases Nashorn, the next'generation Javascript engine for the
Java VM in Java8 and OpenJDK 8
http://www.dzone.com/links/all_about_oracle_nashorn_the_nextgeneration_javas.html

So your mixing of WINE (for which your reasoning has a point) with OpenJDK
is misguided and potential FUD...

FC
-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
Revolucionario
- George Orwell