Authored by: DBLR on Saturday, April 21 2012 @ 01:48 PM EDT

This is good news.



---



"Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is

a well-armed lamb contesting the vote."

Benjamin Franklin.



[ Reply to This | # ]



Authored by: DBLR on Saturday, April 21 2012 @ 01:50 PM EDT

Place Off Topic subject maters here.



---



"Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is

a well-armed lamb contesting the vote."

Benjamin Franklin.



[ Reply to This | # ]



Authored by: Anonymous on Saturday, April 21 2012 @ 01:50 PM EDT



Otherwise APIs are just what they always were, stuff programmers use to

communicate with stuff that other programmers have already done.

[ Reply to This | # ]



Authored by: DBLR on Saturday, April 21 2012 @ 01:51 PM EDT

If needed



---



"Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is

a well-armed lamb contesting the vote."

Benjamin Franklin.



[ Reply to This | # ]



Authored by: DBLR on Saturday, April 21 2012 @ 01:52 PM EDT

###



---



"Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is

a well-armed lamb contesting the vote."

Benjamin Franklin.



[ Reply to This | # ]



Authored by: Anonymous on Saturday, April 21 2012 @ 01:58 PM EDT

They appear in the GPLed version of Java, don't they?

[ Reply to This | # ]



Authored by: mossc on Saturday, April 21 2012 @ 02:12 PM EDT

As part of "Oracle Unbreakable Linux" Oracle has released the JAVA

APIs with gnu classpath. The only permission they have to do this is the GPL

license.



I am fairly certain that the GPL would not allow this legal action and remain in

compliance.



Google should be able to rely on this as permission from ORACLE.



I think a issue in common with the TSG saga is The SCO Group and Oracle seem to

think that when they buy a product, company or distribution channel, that they

can disregard all obligations by either entity and assume all rights.



Chuck [ Reply to This | # ]



Authored by: tknarr on Saturday, April 21 2012 @ 02:18 PM EDT

You don't have to do exact copies, e.g., you could use science.sqrt() as your method rather than math.sqrt() I'd note that when the judge says this, he's wrong by definition. The name "science.sqrt" isn't "math.sqrt", and by the rules of Java refers to a different function. The unqualified names, "sqrt", may be the same, but they have to be fully-qualified to be usable and the fully-qualified names are different. Go look up http://www.groklaw.org/ and see if it's the same site as http://www.groklaw.net/ to see an example of this. They're both "groklaw", right? No they aren't, because the TLD qualifies the name "groklaw" and www.groklaw.org is a different fully-qualified domain name than www.groklaw.net. The two may both be called "groklaw" in part, but that doesn't make them the same name and you can't go to www.groklaw.org and find yourself at www.groklaw.net. [ Reply to This | # ]



Authored by: Anonymous on Saturday, April 21 2012 @ 02:19 PM EDT

Put your comes transcripts here! Please use Plain Old Text to make copying easier for PJ!



P.S. I know someone said anons should not make a canonical section, but I'm working on some transcripts for PJ the section does not exist! [ Reply to This | # ]



Authored by: Anonymous on Saturday, April 21 2012 @ 02:20 PM EDT

If indeed as indicated by Google that The fully-qualified names are the organization. Then what is "Structure" and "Sequence" in the context of APIs? An example would be very helpful. From my limited programming (mainly Visual Basic), I do not see how one can code with an aim for compatibility and in the process, employ a different Structure or Organization of APIs. For "Organization", it may be the case but still, it's a stretch. [ Reply to This | # ]



Authored by: naka on Saturday, April 21 2012 @ 02:23 PM EDT

Well, relief doesn't really come until all the decisions and then appeals are finished I suppose, but I'm so glad that it's Judge Alsup deciding this and not the jury. There are some fairly abstract and nuanced ideas and interpretations of the law in play and it would be tough to get a jury up to speed. JA will be able to ask questions and have a better idea of when the answers are evasive than a lay-person. Kudos to Judge Alsup for owning the decision now that he is (hopefully) starting to understand what is happening here. [ Reply to This | # ]



Authored by: sproggit on Saturday, April 21 2012 @ 02:52 PM EDT

Way (way, *way*) back in February 2005, PJ wrote an article in analysis of orders from the Honorable Dale A. Kimball in the case between SCO and IBM. In her article, PJ quoted from a Groklaw contributor, Marbux - who, IIRC, is a retired lawyer.



Here's a snippet of that article:-

"Viewed through that lens, here's my own interpretation of what Judge Kimball is saying, stripped of legalese and the shroud of impartiality that judges have to wear:



"IBM, you got my attention and I'm all over this case now. But we're going to do it my way. Don't worry, IBM. The briefs have convinced me that you are going to win this case, so I'm going to help you win. Our main task is to work together to create a record that has the best possible chance of standing up on appeal. People appeal my rulings all the time, but I'm pretty good at predicting how the Tenth Circuit will rule and I don't get reversed very often. I'm in charge, so listen very carefully to what I say.



I'm not going to sit back and let the lawyers run the show. This is a case I'm going to actively manage from here on out. Here are my ground rules for the winner and the loser.



SCO, your case is absurd, and you're trying to swim up a waterfall. You made your bed; now you have to sleep in it. Your motion to get rid of the counterclaims is denied and off my desk. I'm not worried about getting reversed on that subject."

As it happens, we were all partially wrong on that one, and Judge Kimball's decisions were, in part, reversed. The panel of appeals judges decided that Judge Kimball had erred in deciding that one aspect of SCO's case could be decided as a matter of law, finding instead that it needed a jury trial. And as the full record shows, SCO lost in Court and in spectacular style.



I have no legal expertise on which to base this hunch - it's just a gut reaction really, but I echo PJ's sentiment when she states that this is a very significant development for the case.



That gut reaction suggests to me that Judge Alsup has watched the initial days of the trial and has realised that the BSF/Oracle strategy is to play fast and loose, to perform some fancy footwork and to create enough confusion and doubt in the minds of the jurors that they fall back on "Well, I suppose..."



As in, "Well, I suppose that Oracle must know what they're talking about and this is a huge trial and it all sounds very technical and important and it's their stuff after all and even though I may not understand this, surely they wouldn't sue Google unless there really was something wrong? Surely there's no smoke without fire?"



I wonder if the good Judge hasn't seen to the heart of this ploy and thought,



"Not so fast, Oracle. I see what you're up to here, and I won't have you bamboozle this jury just to get the win. They may not understand the niceties of copyrights and patents, but I do. We'll do this properly, if you don't mind..."



I confess I am very much looking forward to the transcripts of Monday's day in court, and the reaction of BSF/Oracle to this development... [ Reply to This | # ]



Authored by: Anonymous on Saturday, April 21 2012 @ 02:56 PM EDT

If the judge is doing this determination, what is left in the copyright phase? The 9 lines of code donated1 to sun/oracle?



1: This is my understanding of the TimSort() testimony, please correct me if I'm wrong. [ Reply to This | # ]



Authored by: kawabago on Saturday, April 21 2012 @ 03:40 PM EDT

Judges have already decided that API's are not eligible for

copyright protection because they are necessary elements to inter-operate with

the API. They become facts not expression

in this context.

[ Reply to This | # ]



Authored by: Anonymous on Saturday, April 21 2012 @ 03:43 PM EDT

"I'll say. Imagine if, in a truly karmic result of bringing this

litigation, Oracle loses not only most of the asserted patents but has to GPLv2

the APIs."



That won't happen. The APIs are already freely usable by anybody, there is no

need for a license. (Unless the good Judge decides he wants to crash the U.S.

software industry into an iceberg worthy of the Titanic).



Besides, it already happened, in the sense that OpenJDK contains all of the APIs

in question and is already available under the GPL, with a linking exception for

the class libraries. [ Reply to This | # ]



Authored by: Anonymous on Saturday, April 21 2012 @ 03:46 PM EDT

I commented a couple of days ago that the judge would rule on this in a summary judgment. No way was he going to let the copyright go to the jury once he realized what was what. As for Java and the GPL, the Java APIs are NOT under the GPL. If you look at the license you will see that Java is under the GPL but the APIs under under what is commonly known as the Classpath exception. What this means is that anyone can write code that uses the APIs and their code does not have to abide by the GPL. Without this provision almost no one would use Java. The implications of the exception on the API are not straightforward since they are packaged together with the implementation. However, Joshua Bloch did a great job in illustrating why this isn't important since the APIs aren't copyrightable in the first place. [ Reply to This | # ]



Authored by: Ian Al on Saturday, April 21 2012 @ 03:52 PM EDT

The thing in question is the Java API Specification. This is an instruction

manual for writing Java software. It is not source code.



The names listed in the Specification are the names used in programs and in

function libraries so that the library code can be added to the class file along

with the program code.



As Oracle explain, providing function code in libraries means the programmer

does not have to reinvent regularly used code like the code for doing math.



The way that function code is selected from the library is that the programmer

uses the same text label for the function within the syntax of the computer

language that the library and compiler use to pick out the actual function code

from the library.



The SSO in the Specification is a factual listing of where in the various

library packages the relevant named function code can be found. It is a

directory which is precisely constrained by the way the libraries were written.

The SSO in the Specification cannot be patented because it is a book.



The SSO is the SSO of the libraries and is not new creative expression put into

the Specification. Even if the Specification came first as an abstract idea, it

is modified so that it reflects what is actually and finally coded into the

libraries.



The SSO in the libraries cannot be patented because the libraries are math...

no, because the libraries are a collection of components and not a machine,

process, transformation or method. A selection or organisation is not patentable

subject matter under the act. SSO is not an invention.



Anyone writing replacement libraries intended for use by Java programmers *must*

duplicate the SSO of the original libraries or else the libraries will not

function when the programmer attempts to access them; i.e. it is a functional

requirement of replacement libraries.



The SSO creative expression is not written into the Specification: it is written

into the libraries and reported like a dictionary or a schedule in the

Specification. The Specification is entirely and completely derived from the

library expression.



As such, the SSO in the Specification is the recording in abstract idea terms of

the function and disposition of the actual code in the libraries.



---

Regards

Ian Al

Software Patents: It's the disclosed functions in the patent, stupid! [ Reply to This | # ]



Authored by: jbb on Saturday, April 21 2012 @ 03:57 PM EDT

Google is using Harmony which is under a permissive Apache-2 license. They choose not to use the GPL version of this code. Despite what some people might say, the GPL and Apache-2 don't mix well. If Oracle's novel theory about API copyrights prevails then the GPL versions of the APIs won't help Google. If Google were forced to switch to a GPL version then all the downstream manufacturers would be forced to GPL their code which I assume they do not want to do. I was disappointed that Google went with a permissive open-source license rather than a free software license (the GPL) for this layer of Android but I think it was understandable. I'm sure Google discussed licensing issues with potential manufacturers. I imagine using a Free Software license was ruled out early on. Perfect is the enemy of good. ---

Our job is to remind ourselves that there are more contexts than the one were in now  the one that we think is reality.

-- Alan Kay [ Reply to This | # ]



Authored by: Anonymous on Saturday, April 21 2012 @ 03:57 PM EDT

Oracle's Java implementation is based on the OpenJDK which is GPLv2, so

yes the Java API could be licensed as GPLv2. Oracle, of course, as the

copyright holders, may license Java any other way they want. Companies

that don't want to use the copyleft OpenJDK would need to license Java.



Google didn't like the GPL licensing because it would require handset

manufacturers to open-source their modification to the code. Google

didn't want to pay Sun for a commercial license, either (or, as Google

claim, Sun were dragging their feet during the negotiations). Google

couldn't use any clean-room open-source implementation of Java because

Sun wanted to specifically restrict implementations on mobile handsets,

and so had the field-of-use restriction on the TCK, which is required

if you want to call your implementation "Java".



So Google went ahead and found a loophole. They wouldn't call their

implementation Java (eschewing the need for the TCK), and they'd use an

inferior, yet passable virtual machine that could run Java (Dalvik).

Trying to do as little as possible while still circumventing Sun's

restrictions, Google did not provide their own implementation of the

Java language at all (it appears from the descriptions here as if

Google re-implemented the Java language - they didn't), i.e. they

didn't write a Java compiler. What they did do was have developers use

the standard Sun Java compiler (or any other), and then translate the

compiled code to a format that could run on their VM. In the process,

Google has fragmented Java.



Oracle, in their frustration, realized what Google had done: replaced

as few pieces of possible, but just enough to bypass their licensing or

the GPL, and tried to sue Google over whatever it is they did. Just as

Google found an apparent loophole, so is Oracle trying to find a crack

in the armor. The tactics Oracle is using may or may not be effective.

They may or may not have legal merit - IANAL. But it has to be clear:

Oracle isn't trying to make a philosophical or general argument here.

They're simply trying to nail Google for the schtick they've pulled.



The legal arguments are, of course, very interesting, but I don't

understand the Google bias here. Google pulled a schtick on Oracle, and

now Oracle fights back. It's simply two corporations using the court as

another battleground.



The legal ramifications that the ruling may have on copyrights,

patents, etc., is, of course fascinating. But there are no good guys

and bad guys here. Only two fierce warriors. [ Reply to This | # ]



Authored by: Anonymous on Saturday, April 21 2012 @ 04:00 PM EDT

I really liked that Google came back to ask Joshua about the Java 7 vote. Java 7 was stalled for years over the dispute with the Apache Software Foundation regarding the Java TCK. Several JCP members were willing to support the ASF and vote "No" on the specification. However, once Oracle and IBM signed their deal with regard to IBM moving from Apache Harmony to OpenJDK the writing was on the wall. The ASF had no recourse except to resign from the JCP. Several other JCP members who would have voted "No" also resigned and were replaced by Oracle, so it is no great surprise. Stephen Colebourne documented these events extremely well in his blog in 2011. [ Reply to This | # ]



Apache - Authored by: Anonymous on Saturday, April 21 2012 @ 04:58 PM EDT Shocked! - Authored by: Anonymous on Monday, April 23 2012 @ 12:28 AM EDT

- Authored by: Anonymous on Saturday, April 21 2012 @ 04:58 PM EDT

Authored by: Anonymous on Saturday, April 21 2012 @ 04:44 PM EDT

A. You could add two numbers, but couldn't do any I/O. E.g.,

the simplest program, the first program you write is "Hello

world". This isn't doable without an I/O API.



Firstly - if Oracle wins, then they will have shown that you

can't trust them. In just the way that we don't trust

Microsoft. And once you can't trust a company or a person,

every interaction with them carries that baggage, and

whenever you have the opportunity to avoid dependency on

them you think about it. The consequence is that Java will

only be used when it's necessary and unavoidable.



Secondly - if Oracle win, then the I/O library and all

others become unusable by FOSS advocates. And we'll have to

write our own set of APIs and split the language base

between those that use the Oracle standard and those that

use the FOSS libraries; there can be no dependency on any

Oracle libraries/APIs.



Neatly accomplishing exactly what Oracle claim to want to

avoid. Anyone would think they want the language to die. [ Reply to This | # ]



Authored by: Anonymous on Saturday, April 21 2012 @ 04:52 PM EDT

Be careful what you wish for.



Every time that I write a program in Linux I use, at least,

two APIs which were included in GPLed packages. One for the

system calls and one for calls to gcc run time library(s).



I don't release my programs under GPL and it is legal and

proper because the people who wrote gcc or Linux have never

claimed copyrights of the APIs; unlike Oracle they play fair.



If the judge will accept Oracle's idea of copyrights to API

then plenty of people will be very afraid to write programs

on Linux or use gcc. The big winner will be Microsoft.



Not Good.



(And I thank Google for fighting against this idea, hard.) [ Reply to This | # ]



Authored by: Anonymous on Saturday, April 21 2012 @ 04:55 PM EDT

OK, this is the 9th Circuit. So, that's good. But I still get the feeling that

this just creates an appeal and won't be settled for a long time to come.

[ Reply to This | # ]



Authored by: Anonymous on Saturday, April 21 2012 @ 05:45 PM EDT

As I understand it, copyright can only be used to protect

creative content. APIs and classpaths are not creative

content, they are a rigidly enforced referencing convention

which code cannot deviate from for compatibility reasons.

Hence they are not creative but rather part of the Java

language's structure.



In addition, fair use of copyrighted material allows the use

of limited copying of names for functions, variables,

classpaths and comments for reference purposes.



If this fair use wasn't permitted, it would be possible for

the Coca Cola company to sue the publisher of any negative

article using the name "Coca Cola" for copyright

infringement and so stifle free speech. Similarly the

publishers of a street map of New York, and the New York

telephone directory would be able to charge a copyright free

from anybody who used the name of a street or a person taken

from their publications in any written communications.



This would be total madness - even worse than the patent

madness we have now. [ Reply to This | # ]



Authored by: Anonymous on Saturday, April 21 2012 @ 05:49 PM EDT

One of the topics getting discussed here is Sun releasing openJDK under GPL with

the classpath exception. The argument goes 'If only dalvik was under GPL and

derived from openJDK not Harmony then Oracle could not complain, since this is

expressly permitted under the GPL...'. That argument is probably a dead end.



Lets try another argument:



1. openJDK contains all the APIs being argued about.

2. Each method in a java language API has either public, private, protected,

package access restrictions. All non-private methods can be used in inheritance

 if a method is public or protected in a non-final regular class or a public

interface then it is volunteering itself for inheritance/implementation when it

is consumed by a programmer using the API.

3. In a java program during inheritance the full signature of the method is used

to identify the method being overridden.

4. The licence of openJDK explicitly says that programs making use of it don't

need to be GPL.



/*license gpl+cpe*/

package foo.bar;

public class APIclass {

public int add(int, a, int b) { //GPL+CPE

return a+b;

}

}





/*license creative-commons-do-whatever*/

package mypackage;

import foo.bar;

class MyClass extends APIclass {

public int add(int x, int y) { //API method signature reproduced but no-longer

under GPL

System.out.println("adding " x + ", " + y);

return super(x,y);

}

}





API

foo.bar.APIclass

public int add(int, a, int b)

...



So in normal use of a publicly facing API covered by GPL+CPE it is possible to

extract the method signature and sidestep the GPL+CPE. There is nothing

nefarious about it. Repeat this step for every public/protected method and then

extract just the method signatures from your own subclasses and you get the

public/protected API as a list. This process will produce a big API that may

exactly match the ordering in the openJDK source  but is under no copyright 

certainly not GPL-CPE



Lets look at private API methods that are not intended/cannot be consumed by

normal regular use. Well first of all these are part of the implementation so

are not usually part of the public API that would be given to a programmer but

there are several corner cases in java where someone re-implementing an API for

comparability reasons would also clone private method signatures (for example

where the class might be interrogated at runtime using 'reflection' and

everything marked private becomes public). Well we could get the private APIs

using reflection but IMO that is not clear-cut legal. Instead there is a simple

way: simply take the openJDK source, locate the private methods you want to

copy, change private to public and save the changes  the code is still under

GPL, how can it not be? Now inherit the method in your own non-GPL class and

extract the method signature from your own non-GPL code. The same procedure can

be used to extract signatures from classes marked final which otherwise can't

be inherited.





An alternative weaker argument can be made that the the public/protected method

signatures in the openJDK source are directly analogous to the header files in

c. Google have previously been accused of taking the headers from GPLed c/c++

source-code and rewriting the code so that is no longer covered by the GPL but

still has the original header files  this is done for interoperability with

existing code. Now this might leave bad taste in the mouth but is it legal? Well

according to the people who drew up the GPL it is perfectly fine:



<i>In an email Richard Stallman says 'I've talked with our lawyer about

one specific issue that you raised: that of using simple material from header

files. Someone recently made the claim that including a header file always makes

a derivative work. That's not the FSF's view. Our view is that just using

structure definitions, typedefs, enumeration constants, macros with simple

bodies, etc., is NOT enough to make a derivative work. It would take a

substantial amount of code (coming from inline functions or macros with

substantial bodies) to do that.' This should help end the recent FUD about the

Android 'clean headers.'</i>

http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.html



By publishing their APIs under GPL+CPE Sun/Oracle have placed any

public/protected API contained in openJDK non-copywritable when presented as a

list with no source-code attached. Since the API can derived legally in at least

three ways:



By simply inheriting the class into your own code, overriding the method and

then running grep over your own code.



Using reflection to list available packages and methods from your own program

running on openJDK  do Oracle claim to own the output of your programs when

running on their own fully free and open-source GPL+CPE openJDK ?!



By analogy  the GPL does not extend to header files in c  according to the

authors of the GPL. Method signatures declared public/protected may be

equivalent to header files in c.



Conclusion: It is trivial to write legally permitted non-GPL code, using no

non-GPL Oracle API documentation, only the openJDK source code for reference,

that results in a list of Oracles precious API as a document.



R [ Reply to This | # ]



Authored by: SilverWave on Saturday, April 21 2012 @ 06:03 PM EDT

Nelson Muntz is a fictional character and bully from the animated TV series The

Simpsons. ... Simpson. He is best identified by his signature laugh

("HA-Haw!").



---

RMS: The 4 Freedoms

0 run the program for any purpose

1 study the source code and change it

2 make copies and distribute them

3 publish modified versions



[ Reply to This | # ]



Authored by: webster on Saturday, April 21 2012 @ 09:25 PM EDT

.



It's about time. Oracle ought to move for a mistrial. They have been trying to

convince the Jury that some aspect of API's is copyrightable AND that there is

infringement of such copyrightable API's. There is hardly any disagreement on

the rest of the "facts" of this case. Now they have to proceed

without knowing what the Judge will decide about this issue. It is a lot of

wasted time. Oracle: "If API's are copyrightable, consider this; if they

are not, never mind." Without this issue there is little for the jury to

do other than listen to stipulations. Since they have been listening to this

API-"design" mumbo-jumbo, Oracle can argue that the issue's

disappearance hurts their credibility.



Judge Alsup will decide more mindful of legal and industry precedence. The

presumption is against copyrighting API's. The GPL and the Harmony license may

also preclude the API copyright issue.



There is little for the jury to decide. There is no wilfull infringement if

this case sets a new precedent. How can Google infringe by a rule that didn't

exist yet. And then the licenses ...



API's appear to be clips of code that one can precisely invoke in a language to

do powerful and flexible things. The API's derive from ancestral coders passing

on and enhancing functionality. They are basic to making the circuits in the

computer behave in an anticipated matter. It is code below the source

programming level but above the brutal binary level. It keeps everyone from

having to reinvent the wheel in every language. Use the old stuff unless you

see an improvement. Copyrighting these clips is little more advanced than

copyrighting words or letters or yes/no, or ... numbers, like 0 or 1.



~webster~



. [ Reply to This | # ]



Authored by: Anonymous on Saturday, April 21 2012 @ 10:01 PM EDT

Do I understand this correctly...

While employed at Google:

Bloch copied code from Timsort

Bloch donated code to Java

Bloch used part of same code at Google



This is the ONLY code that Oracle is said was copied by Google?

...or am I missing something [ Reply to This | # ]



Authored by: Anonymous on Saturday, April 21 2012 @ 10:06 PM EDT

The Judge declaring he would be the one to decide if API's are

indeed Copyrightable is the best thing to happen for Google

this week!

Here's a case that might have some important information for

Judge Alsop's Copyrightability issues:

Lexmark Intl v. Static Control Components

https://w2.eff.org/legal/cases/Lexmark_v_Static_Control/2004102

6_Ruling.pdf



Let's just hope Judge Alsop decides correctly, so Google

doesn't have to appeal his ruling, that it took this appellate

court to overturn!



Why aren't all the Java API's deemed copyrightable by Oracle.

Same function/purpose as any other API's in the Java

programming language? So why only these 37 API's published in

the Specifications. Is that the only place they remain under

copyright according to their claims or is it that it's the only

place these API's can be seen to be published with a copyright

notice anywhere in Java? Why didn't Google post the Oracle

Copyright Notices in Android then? Maybe because these 37 API's

are not so special or different from all the rest of the Java

API assets taken out of context by Boes from the Copyrightable

Specifications rather than in their implementable form?



http://www.infoq.com/news/2006/11/open-source-java



Great information from Tim Bray (Sun/Oracle 2006) speaking to

InfoQ, when Java was Open Sourced:

""we have to ensure that users of Java don't have to worry

about getting claims that by using Java they're infringing a

patent held by any of the contributors to Java (including Sun);

so we have to prevent anyone, whether by accident or on

purpose, from contributing code to Java and then being able to

launch claims against people who use it.""



And another interesting Tim Bray quote for you:

""The GPL doesn't require that bytecode classes using a GPLd

java.lang.Object be licensed under the GPL as well. That's

because neither the bytecode nor the source code using it are

derivative works of java.lang.Object, as all that ever ends up

in them are interface names and constants, and those remain the

same, regardless of the license of the java.lang.Object class.

Those symbols are standardised through the JCP, and published

as specifications. They are necessary for interoperability.

Therefore, the symbol names and constant values can not be

claimed as original works by a GPLd java.lang.Object, and

accordingly don't meet the bar for copyrightability.""



The judge needs to run the tests for "copyrightability"

himself, without Oracle or Google's input. So it's decided

based on what's legally copyrightable instead of what Oracle

wishes was copyrightable!



If.... Oracle's "API's are Copyrightable" claims are court

stamped and approved, then Oracle can use this "Come On" pitch

sales ruse to force you to pay for what even they say is FREE

to Use... the Java Programming Language. It's like as if Oracle

is putting out some magnificently delectable Banquet dinner for

FREE. But... then make you pay the equivalent price of every

item on the table, for the plate and utensils to eat it with!



[ Reply to This | # ]



Authored by: Anonymous on Saturday, April 21 2012 @ 10:47 PM EDT

Bloch explained that regex was borrowed from Java. Now we just need some

explanation about how string formatting was borrowed from C and how a lot of the

math functions were borrowed from other languages as well.

[ Reply to This | # ]



Authored by: Khym Chanur on Sunday, April 22 2012 @ 02:04 AM EDT

Doesn't it have to go this way? That is, isn't whether or not APIs are copyrightable a matter of law, which makes it something the judge has to decide? ---

Give a man a match, and he'll be warm for a minute, but set him on fire, and he'll be warm for the rest of his life. (Paraphrased from Terry Pratchett) [ Reply to This | # ]



Authored by: Anonymous on Sunday, April 22 2012 @ 03:42 AM EDT

Perhaps more a question for the techies, but what happens if Sun is granted a

controlling copyright on these APIs. Does they mean they would have a

controlling copyright on those data structures and algorithms, regardless of

the implementation language?



Let us consider the example of a book. I cannot write my Barry Cotter novel

about a teenager sorcerer if it is a simply variation of another well-known

series by Ms J K Rowling. Can I implement a C++ API that sorts a sequence of

numbers stored in a sequential container without violating the copyrighted

Java container API. Or rather, can I provide a complete package of data

structures and algorithms, much as every computer language supplies out-

the-box?



It is bad enough that we are facing the current trend to patent the 'words in

our dictionary', but at least pattens expire after 'only' a few decades.

Copyright essentially locks these things away for ever, given the trend of

extending copyright lifetimes each time certain culturally sensitive works are

approaching the end of their existent copyright terms.



I cannot see victory for Oracle as anything less than the end of the ability to



practice software in USA. In practice I suspect software businesses would

continue, but trading in the knowledge that they could be shut down by

lawsuit at a moments notice, which is a pretty strong incentive to move

elsewhere, were there not so many paying customers over here. It would

become a thoroughly toxic market though, and probably lose many of its top

talents. [ Reply to This | # ]



Authored by: s65_sean on Sunday, April 22 2012 @ 07:56 AM EDT

I questioned Mark's statement in the previous article that oracle had released

the java programming language under the GPL. I never received a reply pointing

to any proof of this GPL'ing of the java language ever happening. Here in this

article PJ repeats that statement.



Does anyone have a link or citation to support the statement that the java

programming language was released under the GPL?



The only thing related to java that I am aware of that Oracle (Sun) has released

under the GPL is the OpenJDK, which is not the java language. it is an open

source version of a set of java related programming tools, but it is not the

java language itself. [ Reply to This | # ]



Authored by: Anonymous on Sunday, April 22 2012 @ 07:57 AM EDT

Oracle talks A lot about the fragmentation of Java Android/Google has created.



But if you think about it they have just created a new very large alternative

Java Programing language ecosystem. And it is big as there is probably more

lines written targeting Android each day than there are targeting Java ME/SE/EE.

So eventually it should overtake these other forms of Java in total lines

written to date etc. This is probably what scares Oracle the most.



But I would argue that it actually reduces fragmentation because there is likely

to be only one main Mobile platform version that uses the Java Language and this

is going to be Android/Delvik (note Java ME is just a toy version of Java and

you can't run a mobile platform on it).



So because Google has done such a good job so far on Android there is no need

for anyone to further fragment Java with every phone maker trying to make

different versions etc. The only real effect is that instead of Oracle holding

all the Java cards we have some real competition now. So right now it is only

Oracle that is fighting to further fragment Java and hurt the language in

general.



Michael [ Reply to This | # ]



Authored by: IMANAL_TOO on Sunday, April 22 2012 @ 08:15 AM EDT

Here is one example of interfaces in programming, public methods in programming.



Leading-Edge Java

Design Principles from Design Patterns

A Conversation with Erich Gamma, Part III

by Bill Venners

June 6, 2005 [...]



In this third installment, Gamma discusses two design principles highlighted in the GoF book: program to an interface, not an implementation, and favor object composition over class inheritance.



Program to an interface, not an implementation



Bill Venners: In the introduction of the GoF book, you mention two principles of reusable object-oriented design. The first principle is: "Program to an interface, not an implementation." What's that really mean, and why do it?



Erich Gamma: This principle is really about dependency relationships which have to be carefully managed in a large app. It's easy to add a dependency on a class. It's almost too easy; just add an import statement and modern Java development tools like Eclipse even write this statement for you. Interestingly the inverse isn't that easy and getting rid of an unwanted dependency can be real refactoring work or even worse, block you from reusing the code in another context. For this reason you have to develop with open eyes when it comes to introducing dependencies. This principle tells us that depending on an interface is often beneficial.



Bill Venners: Why?



Erich Gamma:Once you depend on interfaces only, you're decoupled from the implementation. That means the implementation can vary, and that's a healthy dependency relationship. For example, for testing purposes you can replace a heavy database implementation with a lighter-weight mock implementation. Fortunately, with today's refactoring support you no longer have to come up with an interface up front. You can distill an interface from a concrete class once you have the full insights into a problem. The intended interface is just one 'extract interface' refactoring away.



So this approach gives you flexibility, but it also separates the really valuable part, the design, from the implementation, which allows clients to be decoupled from the implementation. One question is whether you should always use a Java interfaces for that. An abstract class is good as well. In fact, an abstract class gives you more flexibility when it comes to evolution. You can add new behavior without breaking clients. The article goes on, still, I have a difficulty seeing the difference between a public method in a class and an API as is discussed in the Oracle vs Google case.



Maybe there is one, but I don't know what it would be. Maybe someone can enlighten me.







---

______

IMANAL





. [ Reply to This | # ]



Authored by: Anonymous on Sunday, April 22 2012 @ 08:18 AM EDT

I am not sure if I actually understand this:

A developer can donate Code to Java (like J. Bloch

maybe)presuming Java is GPL, Free and open source. The

donation is taken into the Java code base, Oracle/Sun

whoever, says: "thank you great contribution". And then

later down the road that same developer gets sued by Oracle

for using his own code that he donated to GPL-Java?



Is that really the way GPL-Opensource Java works? Or am I

missing something?



How many Non-Oracle/Sun authors donated their own code to

the GPL'd Java codebase?



How much of Java was written by Authors outside of

Sun/Oracle? Are they all going to be coerced now by

Oracle/Sun to pay for and license back their own

contributions to the Java Codebase?



Is that really how Opensource and GPL-Java works?



Is it just me thinking that this is fraud or am I wrong

that, just missing some key point?

[ Reply to This | # ]



Authored by: Anonymous on Sunday, April 22 2012 @ 12:07 PM EDT

I think the real problem for the court here is that the term "API" is jargon more than meaning. Without the experience of being an experienced programmer, it's very hard to understand the variety of ways and levels at which the term can correctly apply. Instead of using this meaningless-to-laymen jargon, expand the definition to focus on the important part. Application Programming Interface. The point that needs to be made in court is that an API is simply an "interface" between software components. "interface" is a word which in general usage has precisely the same flexibility as API does in programming usage. Drop the jargon abbreviation - speak English and get to the core of the matter. [ Reply to This | # ]



Authored by: mcinsand on Sunday, April 22 2012 @ 03:33 PM EDT

Although some wiser, calmer heads here have been cautiously optimistic, I'm a

bit more confident. Judge Alsup has been steadly, carefully avoiding any

decisions that would pave the way for an appeal. Although it's been

frustrating, things like giving Oracle upmteen chances with the damages

estimates would give Oracle a decidedly uphill battle in appealing any ruling.

Given the Judge's cautious nature, I don't think he would rule on API copyrights

without a solid, concrete, well-documented legal basis. If the API's were

copyrightable, then the way Sun/Oracle GPL'd the language itself would create

gray areas for a jury to be required.



If he's ruling, then I think we have a great chance of uncorking something in

celebration soon! [ Reply to This | # ]



optimism - Authored by: jvillain on Sunday, April 22 2012 @ 11:13 PM EDT

Authored by: sproggit on Sunday, April 22 2012 @ 04:12 PM EDT

Reading through the testimony from Leo Cizek, there's an interesting exchange

where he is being questioned by Counsel for Oracle:-



Oracle: What was discussed regarding Android licensing Java?



Leo Cizek: Which of the two JME technologies would be most appropriate.



Oracle: Where was this meeting held?



Leo Cizek: All 3 meetings were held at Google's headquarters.



Oracle: Who attended meeting two?



Leo Cizek: Me and Vineet Gupta.



Oracle: And for Google?



Leo Cizek: Andy Rubin, Brian Swetland, [missed one attendee for Google].



Oracle: What was discussed?



Leo Cizek: Further discussions of Open Source licensing, regarding whether Sun

would [ missed ], and did Google need a JCL.



Oracle: And the third meeting, in December 2005, who attended that?



Leo Cizek: For Sun: Vineet Gupta, Alan Brenner, and me. For Google: Andy Rubin,

Brian Swetland, and Borenstein.



Oracle: Why was Brenner there?



Leo Cizek: He led a large part of the discussion regarding [trying to] convince

Andy Rubin to 1) use Sun's technology (CDC), and 2) not use Open Source for

licensing.





It's that bit right at the end of my excerpt that caught my eye: Mr Cizek

clearly states that one of the Oracle deputation to Google went along

specifically to try and persuade Google to "not use Open Source for

licensing".



Well, duh... if *Oracle* felt that this was something that they needed to

*persuade* Google over, then doesn't it follow that *Oracle* felt that Google

could not be *compelled* to ignore an Open Source approach???



I am not sure how well this would have been picked up by the jury, but it reads

like another foot-gun moment for BSF. [ Reply to This | # ]



Authored by: Anonymous on Sunday, April 22 2012 @ 04:46 PM EDT

"When determining "substantial similarity" what is Oracle

comparing?" is the question Mark asked.



He then started talking about APIs.



I think at this point Mark took a left turn and inadvertently fell through

Oracles looking glass.



I think the answer is actually much simpler.



They are comparing Androids Book to their Book.



That Book is the API Specification, that is the English Language Descriptions of

the APIs

(cf. Day 3 of the ..Challenged Item 6)



The confusion I think arises as to what's what and the question of which comes

first. Let's see if I can articulate that.



If I write a phone book, you expect that phone book to be arranged like all

phone books, alphabetically, by surname, forename, street address/zip code.



But I'm not like you, I'm an artist, I am very creative and I work very hard.



I instead order it by the second digit in your post/zip-code as the first order,

and the third letter in your surname as the second order, after that fall where

they may.



That is covered by copyright doctrine.



That is, my choice of selection, structure and arrangement is most definitely

creative (albeit useless as a phone book)



(I believe doctrine states it is Arrangement rather than Organisation, but

seeing as it has become such, at least in discussion here, I shall refer to it

as SSO from here on)



I am entitled to (thin) copyright protection in that SSO.



You may not, without my permission/license, produce a phone book with the same

SSO.



Oracle is pointing at it's Book, and saying look, we 'designed this', it is

complex, it is interesting, it is creative, it is (unlike my phone book), a work

of art for programmers, it is creative, we are entitled to protection for the

SSO as well as the English Language expressive content.



They then say, if it is so, such that our SSO is protected, then it follows that

after Google read our specification, they copied our SSO into their source code

(the 37 Apis), and therefore their source code is a derivative work, regardless

of its being an independent implementation. Their declarations are an identical

copy of our SSO.





I've been getting irritated through this discourse about Oracles wilful misuse

of the terms "API", and "API Specification", frankly the

diversion into the GPL made me want to scream. So much that I could only find

myself writing odd humour (I did the "Groklaw to be taken down" and

law.corporate.due_diligence() API Implementation, posts)



But the GPL thing made me stop and ask how do you go about dispelling something

that is offered up as confusing and something that appears to be a struggle to

understand even for technical people? And this is it.



Oracle are saying that their Book has a unique and creative SSO and everything

follows from there.



All the discourse around here starts at the declarations and implementations and

looks out, this is a function, this is a class, this is an interface, this is a

package, the API Specification is just the documentation for the stuff we've

just said.



It leads to the raging discussion "what is an API?". I even fell into

the trap of trying to provide an example of an API for OddOrEven, my post went

wrong and bugstomper beat me to the repost with a much better articulation.



But if you look at it the other way up, from Oracles position, it doesn't

matter a jot what an API is, or even what's in it, or whether its free to use or

GPL or open, or where the boundary is between API and Language or what the

various licenses permit, say or don't say.



SSO is the only thing that counts. It is not the APIs and their SSO, it is only

the SSO, all else follows from there.



It explains why in the list of Challenged items (again cf. Day 3 of the ....)

Item 1 The 37 APIs, and Item 4 the Declarations in the 37APIs are identical

symbol for symbol are called out separately, and yet in the not in contention we

see 2) Names of any particular element, despite all of these being basically the

same thing from a technical point of view.



(IANAL) Google can try all the estoppel, de-minimis, functional, merger they

want, but that's only pandering to the illusion and nibbling at the edges, they

are talking about code and Oracle aren't (TBF we haven't heard Googles side

yet)



It seems to me that if instead Google show that the code came first, that the

Book comes from the code, that the SSO is a consequence of and falls out of the

code, then the Book is just a Book and the SSO is '(in/ac)cidental' and no more

than just a happy result of using javadoc, then the whole SSO argument goes out

the window, and we stay exactly where we are. Your source code is protected,

Your book is protected, your binary is protected. Doesn't it?



Is it that? Or did I just muddy the water even further? [ Reply to This | # ]



Authored by: Anonymous on Sunday, April 22 2012 @ 07:51 PM EDT

I hope Google's lawyers point out that API's have been around

for over half a century, and no one has tried to copyright

them before. [ Reply to This | # ]



Authored by: Anonymous on Sunday, April 22 2012 @ 08:07 PM EDT



For quite some time now, Pl/Sql has been the de-facto language for programming

using an Oracle database.



Oracle Pl/Sql is based on Ada, it says so in Appendix C of the Oracle 11g Pl/Sql

Reference Manual, and has said so in the version of the manual that has

accompanied each major database release back to Oracle 8 at least. If memory

serves me correctly, it goes back to Oracle 6. It might even go back further

than that.



The Ada 83 Language Reference Manual is copyright the US Government

(http://archive.adaic.com/standards/83lrm/html/lrm-01.html#1), which is not

surprising as they paid quite a lot to get the language developed in the first

place.



So - does this mean that Oracle copied the Ada APIs when they created Pl/Sql,

and if so, was a licence necessary, and did they obtain one??



Are they guilty of themselves doing exactly what they accuse Google of??



I'm sure that plenty of your readers with better memories and legal minds than

mine will know the history and details.



Keep up the good work



Regards [ Reply to This | # ]



Authored by: LouS on Sunday, April 22 2012 @ 09:34 PM EDT

In order for something to be copyrighted it must be fixed in some tangible form. But an API has no tangible form - it is an abstract idea. What confuses people is that there are several entities related to an API the do have fixed tangible forms. There can be an implementation of an API, which is copyrightable source or binary (or byte) code. But there can be many different implementations of the same API, so the implementation is not the API There can be documentation of an API which is copyrightable human- language text, aimed at either the user or the implementer of the API. (Documentation aimed at the implementer is often called a "specification".) But there can be many different documents describing the same API, so the documentation is not the API. Consider the words "Gee" and "Haw" which were commands used to tell a plow horse to turn left and right respectively. (You might consider these a "Application Plowing Interface :) The fact that Gee means turn left and Haw means turn right are abstract facts, separate from the fact that these meanings are listed in some document or that horses are trained to respond that way. There is no way to patent the meanings of Gee and Haw because theses meanings have no fixed form, [IANAL so take the above with a grain (at least) of salt.] [ Reply to This | # ]



Authored by: Anonymous on Sunday, April 22 2012 @ 11:24 PM EDT

The last comment is totally bogus. The aforementioned APis are already

made available under GPLv2 in OpenJDK. The question is why GOogle

have not derived their implementation from this?? [ Reply to This | # ]



Authored by: Anonymous on Monday, April 23 2012 @ 03:46 AM EDT

The API's might not be copyrightable, however the implementation of the API's can be copyrighted and hence can fall under the GPL. Given that OpenJDK also distribute an implementation of the API's, OpenJDK can therefore be GPL'ed. [ Reply to This | # ]



Authored by: vadim on Monday, April 23 2012 @ 05:44 AM EDT

It is very disturbing to see that when discussing copyrightability of API people seems to forget about the other side of copyright equation : Promotion of Progress of Science and useful Arts. The U.S. Constitution says: To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries So the question is If we allow copyrights on API are we promoting Progress of Science and useful Arts? IMO the obvious answer is NO. On the contrary this will open the potential of miriads of new lawsuits. In will have an enormous chilling effect on industry. [ Reply to This | # ]



Authored by: Anonymous on Monday, April 23 2012 @ 07:05 AM EDT

Considering this article about the judge taking the copyright issue was during day 4, and the next day (day 5), there was apparently some doubt on the issue, how certain are we that he will rule on this issue rather than allow the jury to? It seems possibly dangerous to allow a jury to rule on an issue like this unless they are given very clear instructions and information on the current law. They are probably confused... http://www.gr oklaw.net/article.php? story=20120420210807212 Judge Alsup: I am understanding that there is a cloud over Apache (Harmony). What is the nature of that (cloud)? Google: The fight was over Apache wanting to say that Harmony is Java. They wanted that right. Sun didn't want to give Apache that. (It's the) same with Android. "If you don't want to call it Java, fine." Everyone knew who was using what APIs. Google: "The copyright claim is a little crazy." Google: "None of the engineers talked about that" [an API copyright]. Google: "None of the business people ever talked about that." Judge Alsup: That's what you argue. Even if you are right will let the decision on SSO go to the jury. [Not clear to me that Judge Alsup has made a decision on this or is just mulling it out loud.] Judge Alsup: What is the comparison made against? Judge Alsup: What is the copyrighted work? [ Reply to This | # ]



Authored by: Winter on Monday, April 23 2012 @ 07:42 AM EDT

German Heise reports the rejection of Oracle patent 5,966,702 is overturned (I have difficulty getting at the page). It is valid again: Reexamination of US5,966,702 Rob ---

Some say the sun rises in the east, some say it rises in the west; the truth lies probably somewhere in between. [ Reply to This | # ]



Authored by: Anonymous on Monday, April 23 2012 @ 08:18 AM EDT

Authored by: lwoggardner on Monday, April 23 2012 @ 08:41 AM EDT

Is this a way to define the API? Source code contains the API, Code (implementation) and Comments (both describing the API and the code)

API documentation (Javadoc) is the API + Comments (the ones describing the API)

Bytecode is the API + Code We know that the source code is copyrightable, and the bytecode is copyrightable, but this question is whether the API on its own is copyrightable.

So if we look at what is common between the bytecode and the javadoc then the API as a whole would be... the package namespace (being an unordered list of classes) the class hierarchy (inheritance relationships) the unordered list of instance and class variables (name and type) for a class the unordered list of methods defined for a class, a method being a name, return type, and ordered list of parameters (name,type) If Judge Alsup determines that as a whole is copyrightable then the Dalvik source and bytecode would likely be considered derivative works of that API. Oracle have given that API away under GPL+CE. The Classpath exception would not apply here (since not about linking other modules) so a remedy for Google would be to GPL2 Dalvik. What is the value to Google of the permissiveness of Apache 2 over GPL2?, or does Oracle's past actions in respect of Harmony mean that the chance to monetize that difference has come and gone? [ Reply to This | # ]



Possible definition of "the API" - Authored by: Anonymous on Monday, April 23 2012 @ 10:14 AM EDT

Authored by: Anonymous on Monday, April 23 2012 @ 09:49 AM EDT

This article in the news pick is simply wrong. In fact if your GPL+CE jdk is

derived from openJDK you can get a special TCK. Red Hat have already done this

with icedTea. Its what caused the Apache Harmony fallout since Harmony was not a

derivative. Its not fair or pretty but java is 100% free under GPL+CP - stop

spreading FUD. (Interestingly it is possible to use the 'Reflection Mechanism'

to extract the full jav API copyright free from openJDK or icedTea - so please

don't spread FUD on this issue it is important and could even win the case for

Google - hopefully)



"The Java IP Story

http://dirkriehle.com/2011/06/30/the-java-ip-story/



2) If you dont care about the Java label, you can forgo certification.

However, without the certification, you dont get a license to the software

patents buried in the OpenJDK code. Thus, any patent owner who happens not to

like you might decide to sue your customers who will turn back on you and will

find you without patent defense"



This story is mis-information and FUD please look here instead for a more

accurate take:

http://www.infoq.com/news/2008/06/icedtea_tck



"the IcedTea Project reached an important milestone - The latest OpenJDK

binary included in Fedora 9 (x86 and x86_64) passes the rigorous Java Test

Compatibility Kit (TCK). This means that it provides all the required Java APIs

and behaves like any other Java SE 6 implementation - in keeping with the

portability goal of the Java platform.



The IcedTea project is not subject to the same licensing issues as Apache

Harmony, as Sun has provided a special version of the TCK license that is

targeted to any Java implementation that is a derivative of OpenJDK; something

that Apache Harmony cannot claim."



Please do not be helping spread FUD that damages our own case against Oracle.





[ Reply to This | # ]

