* Posts by jilocasin

80 posts • joined 20 Apr 2012

Page:

Judge green-lights Facebook, WhatsApp hacking lawsuit against spyware biz NSO, unleashing Zuck's lawyers

jilocasin
Meh

Bad analogy

Gun makers can be sued if they create a gun that injures the owners, as in it was defective. What they can't be sued for is if someone uses that gun to kill someone else. Much like Ford can't be sued when someone in an F-150 pickup truck drives drunk and kill someone, or Verizon can't be sued if someone orders 100 kilos of cocaine over their fios connection.

What the NSO group is being sued for, is not the fact that they wrote and sold software that one of their customers might have misused, but that they hacked into Facebook servers in order to help their customers. They maintained an active hand in the use of their software (so more software as a service). If they had simply sold some software to whomever and said "good luck", they wouldn't be in a California court being sued.

Sony reveals PlayStation 5 will offer heretical no-optical-disk option. And yes, it has an AMD CPU-GPU combo

jilocasin

Re: What's with the vertical consoles?

Never did see anything worth buying a PS4 for. Still playing PS2 & PS3 games here. If the PS5 is backwards compatible, then I might consider buying one.

Intel is offering more 14nm Skylake desktop processors, we repeat: More 14nm Skylake desktop processors

jilocasin
Facepalm

Re: Last paragraph of the article"

"They've proven they can reliably, steadily, consistently produce 7NM parts while Intel is still stuck in 10 14 NM land."

FTFY

Welcome to life in the Fossa lane: Ubuntu 20.04 let out of cage and Shuttleworth claims Canonical now 'commercially self sustaining'

jilocasin
Headmaster

Re: @ErroneousGiant - I still don't see the purpose of WSL

Actually you can ssh directly from the PowerShell prompt. Neither Putty nor WSL needed.

Chrome deploys deep-linking tech in latest browser build despite privacy concerns

jilocasin
Linux

It's there to allow Google to send more specific search results.

Currently the spec requires a web page author to create anchors on their web page. This new functionality will allow a 3rd party, in this case Google, to link to any portion of any existing page. If you have a page containing descriptions of all the albums of a group, say the Beetles, with a paragraph describing each album. If someone searched for 'Abby Road' this feature would allow Google to create a dynamic link that would take the user *directly* to the section on that album. Seems like a _great_ feature, right? Unfortunately it will let Google and other 3rd parties know more about what you are searching for. Hence the privacy issue.

I hope that clears things up.

In the red corner, Big Red, and in the blue corner... the rest of the tech industry

jilocasin
Boffin

Re: Not Just Re-Implementing

You might want to go back to the link I provided in an earlier response to the original ruling. It's well thought out. This appellate court, which has never seen anything that it didn't think shouldn't be patented/copyrighted the law be dammed, in a first, decided that API's and source code were the same thing. Since you can copyright source code you can copyright APIs. From there it overturned the original ruling and because the fair use question didn't need to be addressed in the original trial sent it back down for a ruling on that part.

The lower court then ruled, that if APIs were subject to copyright, then what Google did was the quintessential fair use of that API. Oracle appealed again to the same court and this time, completely misunderstanding what Google was trying to achieve, overturned the lower court again. The appellate court ruled that because Google could have used a different API (say, C, or Python, or FORTRAN, etc.) they didn't have to copy the existing Java API. Of course then it wouldn't have been interoperable. This just goes to show that the appellate court had no idea what interoperability means.

After the first ruling the supreme court decided not to jump into the matter, probably hoping that if it was ruled that interoperability was fair use of an API, it wouldn't cause too much damage and they could stay out if things. Unfortunately for Oracle, and perhaps fortunately for Google and the rest of us, the appellate court couldn't resist trying to impose their maximalist view of intellectual property forcing the supreme court's hand.

I hope that helps clear things up a bit.

jilocasin
Thumb Down

Re: @Pascal This was an eye-opener for me

I could say the same to you. The original judge made a well researched an documented ruling. This appellate court has a history of overstepping when it comes to allowing things to be locked up, first with patents and now with copyrights. The supreme court has overturned their overreach before and looks to do so again.

It isn't a matter of evil corporations, or which might be more evil than whom.

jilocasin
Angel

Re: Not Just Re-Implementing

Nope. Excepting for a couple of security files and a rangeCheck() function, which were accidentally copied by Google, all of the source code that implemented the API was in there legally. A large amount was Apache licensed Java source from the Harmony project. Some was written by Google's developers in house. Whether or not it was a copyright violation or covered under Fair Use is a separate question.

To a non-developer, a printed out API looks indistinguishable from source code. As the joke goes; "It's all geek to me." Oracle, and the appellate court, would have you believe that an API is source code for any of their arguments to make sense.

The judge of the original case was fortunate enough to be able to write code himself, admittedly simple programs ( https://www.theverge.com/2017/10/19/16503076/oracle-vs-google-judge-william-alsup-interview-waymo-uber ). Here is a link to the original ruling ( https://www.eff.org/files/alsup_api_ruling.pdf ) it's clear and well written.

From pages 40-41 of the original ruling the judge wrote:

"In closing, it is important to step back and take in the breadth of Oracle’s claim. Of the 166 Java packages, 129 were not violated in any way. Of the 37 accused, 97 percent of the Android lines were new from Google and the remaining three percent were freely replicable under the merger and names doctrines. Oracle must resort, therefore, to claiming that it owns, by copyright, the exclusive right to any and all possible implementations of the taxonomy-like command structure for the 166 packages and/or any subpart thereof — even though it copyrighted only one implementation [emphasis mine]. 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. No holding has ever endorsed such a sweeping proposition."

I hope that help clear things up.

jilocasin
Happy

Re: Not Just Re-Implementing

That's called Re-Implementing the API.

If:

APIs are not copyrightable,

Then:

you can just copy and paste the code*.

That's what not copyrightable means.

*In this case code means the structure, names, function signatures, etc. Google wrote the source code themselves (or copied the Apache licensed Harmony code). Don't confuse API and source code with your loose use of the term "code". That's Oracle trying to muddy the waters.

jilocasin
WTF?

Re: Very different times...

Sorry to see you are still demonstrating your confusion between API's and source code from your posts on other articles on the same subject.

If the big cloud providers want to replicate the API by writing all their own source code more power to them. To do otherwise would be for nothing to be able to communicate with anything else. You won't be able to move your software from one operating system to another (no more compatible software without a costly re-write assuming you would even be allowed to do so). You wouldn't be able to get your data from one format to another (document formats are also an API). Want a different compiler or IDE for a computer language? Sorry, you can no longer re-implement the API in your world.

Google toyed with the idea of licensing Java ME, but it wasn't useful, they wanted to modify Java SE and Sun insisted that only Java ME could be used on mobile devices. So Google did what any self respecting software house did, they looked at the current resources available (like the Apache licensed Harmony project, and the fact that API's weren't covered by copyright) and set out to re-implement the language to suit their needs. Sun management was aware and even publicly encouraging of the effort, believing it would get more people interested in writing in Java. It wasn't until Oracle bought out Sun that this rediculous interpretation, and resulting lawsuit, came to be.

jilocasin
Facepalm

I don't think interoperability means what you think it does...

It has nothing to do with published vs. non-published. There are many levels of interoperability. In this case Google was trying to for interoperability with the Java language.

In the Samba case, some of the API would need to be replicated. All SMB compliant code would have to use the same data structures and the same keywords. What language you used to create/call those structures could be different.

The Google case is more like someone creating a compatible compiler. The Sun(Oracle), IBM, Apache, OpenJDK, and to a great extent Google have to re-implement the Java API in order to process Java source code. Using a different API would mean that it wouldn't be able to compile Java source code. Which is the whole point of the exercise.

You wrote; "But of course you user would need to adapt their code to use it..." In that you admit that if Google didn't do what they did, the result wouldn't have been interoperable. The whole point of interoperability is that the developer doesn't have to re-write their software to run on a different system, or to learn a new language to write it in. Programs written in PC-DOS ran just fine under MS-DOS. This isn't possible if PC-DOS didn't re-impliment the MS-DOS API.

IBM, Microsoft, a medley of others sing support for Google against Oracle in Supremes' Java API copyright case

jilocasin
Headmaster

Re: Is there anything

Then you are doing a terrible job of it. Since the supreme court granted certiorari, the status quo is that no one's ever been successfully found to have violated copyright re-implementing an API, cementing the widely understood belief that API's are unprotectable via copyright. The appellate decision in this case was the first to change that. Since it's currently under appeal, it's non-binding unless affirmed.

jilocasin
Facepalm

Re: Appellate decisions

The appellate's court ruling doesn't mean anything unless and until it is affirmed by the supreme court. That's what happens when the supreme court agrees to take a case. At this point the appellate decision isn't any more binding than that of the trial courts.

In my opinion isn't any type of a climb down. Just a differentiation of my opinion, vs that of the appellate or of your opinion.

The references to Harmony are important, because excepting the tiny amount of truly copied code, the vast majority of source code in this case was properly licensed. You keep confusing the 37 Java API packages with source code. Your quote: "We have already concluded that the declaring code and the SSO of the 37 Java API packages at issue are entitled to copyright protection." is once again taken from the appellate decision. Which means their validity in the current argument is suspect at best, bordering on worthless.

There was no need for a fair-use defense when Google copied the API. API's were widely understood (as mentioned by many previous cases on point though out this thread) to be beyond the bounds of copyright. They weren't trying to reverse engineer, it was public. They were re-implementing for compatibility.

Your arguments read like a case where your cousin publishes a web site declaring that you are the fastest sprinter alive. Other runners dispute your claim and the Guinness Book of Records says it will look into the matter. While others are quoting recorded track times of Usain Bolt claiming that he is the faster sprinter, referencing the times in the 2008, 2012, & 2016 Olympic medals, you just keep repeating that your cousin's website lists you as the fastest runner as if that settles that.

So what, if any cases can you cite to support your case (not including the appellate decision)?

jilocasin
Stop

Re: The idea/expression dichotomy doesn't eliminate copyright protection on software

So, is there anything you can cite, other than the appellate court decision, to back up your claim? Simply reiterating the decisions that are at issue, and that the supreme court is set to review, isn't terribly persuasive.

jilocasin
Meh

Re: You need to go back and reread the judgements in the case

Actually you really do need to brush up on your recent appellate decisions. Back in 2015 the 9th circuit (you know the one who's precedents the appellate court was supposed to be following) ruled ( https://www.eff.org/files/2015/10/09/yoga-copyright-opinion-ca9_0.pdf ):

BIKRAM’S YOGA COLLEGE OF INDIA, L.P.; BIKRAM CHOUDHURY, v. EVOLATION YOGA, LLC; MARK DROST; ZEFEA SAMSON (UNITED STATES DISTRICT COURT OF APPEALS FOR THE NINTH CIRCUIT 2015) ("Because copyright protection is limited to the expression of ideas, and does not extend to the ideas themselves, the Bikram Yoga Sequence is not a proper subject of copyright protection.").

There's no real split in the 9th. And the appellate decisions you reference clearly show that the court had no idea how an API differed from source code. This example is illustrative:

'Appellant Br. 50. Using the district court's "java.lang. Math.max" example, Oracle explains that the developers could have called it any number of things, including "Math. maximum" or "Arith.larger." This was not a situation where Oracle was selecting among preordained names and phrases to create its packages.6 As the district court recognized, moreover, "the Android method and class names could have been different from the names of their counterparts in Java and still have worked."'

While that is true, the result wouldn't be compatible with the Java language. What they are saying is that since Google could have used C, or FORTRAN, or Cobal, or something completely new, they are guilty of copyright infringement when they re-implemented Java.

Finally, since the supreme court granted certiorari it doesn't stand unless affirmed.

jilocasin
Facepalm

Re: Apache licenced harmony project

No, the the ranchCheck function and the security files were stipulated to and Google argued for a deminimus ruling. In other words it was such a small part of the code base it shouldn't really matter. If that was all it was, then at worse Google would have owed Oracle a small amount of money and no one would really care.

It's the API that's gotten everyone worked up. The issue is:

"Google’s use of the structure, sequence, and organization of 37 Java APIs."

Originally the court ruled that copyright was inapplicable to the APIs. Then being incorrectly overturned, ruled Googles use was fair. That was also overturned. Now the supreme court is taking a look at it.

jilocasin
FAIL

Re: Allowing copyrights on API's

Your constant references to the appellate decision doesn't make you right either. If it did, the supreme court wouldn't have accepted this case.

I have read the judgement of the appellate court as well as both of the original judgments that were wrongly overturned. It is my opinion, and that of Google as well as many of the amici, that the appellate court got it wrong. Now Google will have their chance to convince the court that the appellate is wrong again. It's been receiving regular bench slaps from the supreme court for misapplying patent law. Now it will get a chance to be bench slapped for misapplying copyright law.

Copyright applied to source code, it has never applied to an API.

Your final sentence is nonsensical:

"Google could have done the right thing from day 1, but they wanted to fragment the Java platform, but not play under the GPL."

Google didn't want to fragment the Java platform. They wanted developers to be able to use the Java language. They could have gotten a license from Sun to use Java ME, which is what Sun wanted them to do. Google correctly deduced that Java ME wasn't fit for purpose. By that point in time Sun had already released the specs, excepting the TCK. Apache was re-writing Java SE legally under the Harmony project. This was licensed under the Apache license, the GPL has nothing to do with anything. Google used the Java API, code from Apache Harmony, and code that they wrote themselves. This included a new bytecode format and a new run time. They never called their platform Java nor claimed it was compatible.

jilocasin
Facepalm

Re: Microsoft violated the license they had signed with Sun

You can't in the sense of an enforceable copyright based license. I can license the right to breath air and you can agree to it, if you are dumb enough.

Sun didn't open source Java until 1.5, The Microsoft/Sun suit was based on 1.2. It also governed the fact that Microsoft was calling their version Java without being fully compatible, something their license with Sun prohibited.

See ( https://www.cnet.com/news/sun-microsoft-settle-java-suit/ ):

"Java is a software technology that allows a program to run on a multitude of computers without having to be rewritten for each one. Sun sued Microsoft for $35 million in 1997, saying Microsoft breached its contract by trying to extend Java so it would work differently, and presumably better, on Windows computers. Consequently, one of Sun's main arguments in the case was that Microsoft wrongfully advertised that its products were Java-compatible because, in Sun's eyes, they were not. Those changes broke the universality of Java, Sun argued."

As noted at the time, it wasn't a copyright issue, but a trademark and license issue. Microsoft settled the case for about $20 million and agreed to stop using their version of Java.

The judgments in this case, written by the appellate court, confused source code and API. The points cited don't apply to APIs. The original judge & jury were correct, and the appellate court misapplied the law and existing precedent to reach their decision. Now the supreme court has agreed to take the case, over Oracle's objection, to hopefully reverse this travesty.

jilocasin
WTF?

Re: Plagarism protection for source.

Actually you can and it's not just for API's.

API's are like the legend of a map, the index in a card catalog, the symbols used to create diagrams. None are subject to copyright.

Any particular maps can be protected, but using blue for water, tan for sand, and white for ice with north at the top isn't.

Putting books A-C in one drawer, D-G in another, etc. isn't, But the books themselves maybe.

Using an oval for beginning a process, a rectangle for a step, a diamond for a decision isn't protectable. A particular flowchart created with those symbols might be.

You really need to go back and reread the included text of the law. Nothing says anything about:

"...just not in the same of substantially similar words."

It says that regardless of all those things listed under (a), it doesn't get copyright protection if it's an idea, procedure, process, system, method of operation, concept, principle, or discovery. The API isn't an implantation, it's a standard that you have to adhere to (see previous) to allow various pieces of software to inter-operate.

It's like copyrighting the English language. You can create copyrighted works using the English language, but the language itself, isn't copyrightable, even if you copy the whole thing.

jilocasin
Headmaster

Re: Why not let idiotic orgs let their APIs slide into obscurity via failing to license freely?

Yes and no.

Yes - Google did copy some Java copyrighted code. Mostly legally from the Apache licensed Harmony project. A wee little bit by mistake.

No - That isn't what this case is about. It's about the unlicensed Java API that Google replicated to be compatible with the Java language so that developers wouldn't have to learn a whole new language to start writing software for Android devices.

jilocasin
FAIL

Re: Allowing copyrights on API's

No, I think I've gotten it right. There is no danger if API's aren't protected by copyright. Quite the contrary. You are still confusing source code and API's. You are, and always were, free to write your own software implementing any API and license it however you like. You can copy the MS DOS API with your own source code and call it DR DOS (it was done). That's how programs written for Microsoft DOS could run under DR DOS.

The OpenZFS authors could ship a substitute kernel that adheres to the previous Linux kernel API (as long as they wrote the software that implements it themselves) and add a symbol, any symbol they want to it. No one is stopping them. It was part of the API, but it isn't anymore, and the kernel developers are under no obligation to keep it around just for the non GPLv2 people to keep using.

You claim to know the difference between the interface and the implementation. Your problem seems to be that you refuse to accept that the interfaces aren't subject to protection (nor should they be) and so it doesn't matter if Google copied a single interface, or all of them. It's still perfectly legal. To argue otherwise is to threaten software development as a field.

jilocasin
Facepalm

Re: An API is not a triviality

MS didn't 'cough up cash to Sun in 2001 for the same reason'.

Microsoft violated the license they had signed with Sun. The license they signed said that the version of Java Microsoft wrote would be functionally identical to the one Sun and other Java JVM makers wrote. It wasn't, as Microsoft was trying to make their Java Windows only and leverage their large Windows developer base. Google never signed a license with Oracle. They didn't need to. The old Sun vs. Microsoft case had nothing to do with API's.

As mentioned elsewhere API's are a "method or procedure" and not subject to copyright.

jilocasin
FAIL

Re: War over API

Hmmm... so much fail it's hard to know where to start.

1) Google knowingly copied code from the Harmony project. That code is licensed under the Apache license, so that was perfectly legal to do. Google re-implemented the Java API. The API is unprotectable by definition, so also perfectly legal.

2) Google is not now claiming fair use because it is an API, they are telling the appellate court that if you are going to misapply the law and make API's subject to copyright (something that never was and still technically isn't) then re-implementing one for interoperability is the quintessential fair use.

3) Yes. You can use the Google API, any of their many API's, however you like, they aren't protectable by copyright (seeing a pattern here?).

4) Google can't use the Java API in violation of the terms set by the Java license, because you can't license an API.

5) Google can control/license how other's use Google Maps, or any other Google service. If you wanted to re-implement the Google Maps API so that yours or someone else's product could call your map service, that currently calls Google Maps, without having to be rewritten that's perfectly legal.

So to sum up, you don't seem to have any idea what an API is, or what it's used for.

I hope the above helps.

jilocasin
WTF?

Re: Translating hardware to software, plug compatible is *not* the equivalent of a API.

No, API's don't fall under copyright by virtue of being published in books. Here's the relevant section of the law ( https://www.copyright.gov/title17/92chap1.html#102 ):

102. Subject matter of copyright: In general (28)

(a) Copyright protection subsists, in accordance with this title, in original works of authorship fixed in any tangible medium of expression, now known or later developed, from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device. Works of authorship include the following categories:

(1) literary works;

(2) musical works, including any accompanying words;

(3) dramatic works, including any accompanying music;

(4) pantomimes and choreographic works;

(5) pictorial, graphic, and sculptural works;

(6) motion pictures and other audiovisual works;

(7) sound recordings; and

(8) architectural works.

(b) In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work. [emphasis mine].

An API is a "...procedure, process, system, method of operation..." and so categorically excluded from copyright protection regardless of how it was recorded, in a book or in anything else for that matter.

Fair-Use, compilations, none of that applies as a matter of law. It's just that this particular appellate court (with a history of rewriting law and getting smacked down by the supreme court) overrode the correctly descided lower court, twice, to rule otherwise.

jilocasin
Meh

Re: Why not let idiotic orgs let their APIs slide into obscurity via failing to license freely?

Actually it is. You wrote that copyright doesn't exist in trivialities. It also doesn't exist in methods or procedures.

To use your example:

American dogs are trained with American English words that mean the same thing to the dog.

German dogs are trained with German words that mean the same thing to the dog.

Java uses a particular API to call functions that perform math operations.

C uses a particular API to call functions that perform math operations.

Java API == American dog training

C API == German dog training

See?

jilocasin
Boffin

Re: Why not let idiotic orgs let their APIs slide into obscurity via failing to license freely?

Um, no, no, and no.

Allowing copyrights on API's would do absolutely nothing in the OpenZFS case. They already have access to the API. Heck, they already have access to all the source code, it's open and public. What the GPL doesn't let them do is distribute the combination of GPLv2 kernel and non GPLv2 OpenZFS. It is perfectly legal for any user to use the two in combination. Many people do. The recent fracas was caused by the fact that the kernel team stopped exporting a kernel symbol that OpenZFS was using. There wasn't any GPL code using it, and so they removed it. If you want the Linux kernel to stay in sync with your non-GPL'd code, that's on you.

The minimal code that Google copied was such a slight amount as to be a rounding error in the overall scheme of things. The rest was licensed under the Apache license as part of the Harmony project. That isn't what's at issue here. You seem to be confusing the API with the source code. The API describes the method (ex: int round(int a), java.Math.floor) and the source code implements it. Oracle is claiming that the API was never licensed under the Apache or any other license and so Google owes them oodles of money. It was never licensed because until this silly case it wasn't protectable by copyright.

I hope that clear things up a bit.

It's a no to ZFS in the Linux kernel from me, says Torvalds, points finger of blame at Oracle licensing

jilocasin
Linux

Re: I use ZFS with Linux - and so should you

That's a bit harsh, no?

It's not a matter of open source it's a matter of GPL. The kernel is licensed GPLv2. Everything that touches the kernel directly must also be licensed GPLv2. Linus has stated before that Linux is under no obligation to maintain compatibility with code that directly interacts with the kernel but is not maintained by the kernel team.

To quote Greg Kroah-Hartman ( https://lkml.org/lkml/2019/1/15/305):

"If you want to interact directly with Linux kernel

code in kernel-space, then you have to abide by it's license, which is

GPLv2". That's it. If you wish to use open source code by another

license, wonderful, I'm not telling you what you can, and can not do,

but please, do not violate the license of the code I contributed under

GPLv2.

So, no 'fuck off' and NVIDIA would, and has, gotten the same answer. License your code GPLv2, or in the case of hardware/drivers, open the documentation so that interested users can write drivers themselves. Otherwise it's on you to keep up with any changes in the kernel.

jilocasin
Headmaster

Re: The problem is not Oracle (for once)

While that is true, OpenZFS is based upon the code originally licensed under CCDL by (now) Oracle. So unless the entire OpenZFS code base has been completely rewritten in a clean-room without infringing on any existing ZFS patents, they can't relicense, or even dual license it without Oracle's blessing.

So you just can't get around Oracle's involvement in the process.

jilocasin
Holmes

Re: The problem is not Oracle (for once)

I don't think anyone in the *GPL* cult is complaining about ZFS' choice of license. There is nothing in the GPL that prevents a _user_ from using ZFS on their Linux system. Linus has reasonably stated that he isn't allowing anything in the Linux *kernel* that isn't licensed GPLv2. This is doubly so with a litigious company such as Oracle has shown itself to be. The kernel developers have stated publicly and repeatedly that they are under no obligation to maintain kernel level compatibility with anything that interacts with the kernel but isn't licensed/maintained by the kernel team.

If people want ZFS incorporated into the Linux kernel then it's up to Oracle to relicense it. Otherwise the ZFS devs will have to keep up with the kernel changes themselves.

jilocasin
Headmaster

Re: The problem is not Oracle (for once)

It's as much *caused* by the GPL as by the CDDL. It's all a matter of where you are standing.

If you are on ZFS island, then the problem is that the *GPL* isn't compatible with the CDDL that's the problem.

If you are on Linux land, then the problem is that the *CDDL* isn't compatible with the GPL that's the problem.

So in the end, what do you want to do? Run ZFS on Linux, or Linux on ZFS? Neither is going to happen without a compatible license. Linux can't really change license at this point, so the ball's in Oracle's court.

Reusing software 'interfaces' is fine, Google tells Supreme Court, pleads: Think of the devs

jilocasin
Coat

Re: You guys are wrong

Actually the interface (or API) was understood to be categorically excluded from copyright protection (as written about many times previously in this thread itself). Therefore you can't protect an API with any copyright license. So *anyone* can replicate an API regardless of what the creators of that API might have wanted. At least until this pigs breakfast of a ruling.

jilocasin
Meh

Re: @jilocasin There is *no* IP to take advantage of.

I am replying to correct myself. I was mistaken when I wrote:

"Your reference to a 'clean room version' is misplaced in this instance. That only applies to _patents_ NOT _copyrights_, the subject of this case."

Since there is no independent invention exception to patents, the above wouldn't apply. Which makes my other comment:

"confusing such simple concepts as patents and copyrights"

also inapplicable.

That being said, your insistence that: "Google's 'clean room' version wasn't clean and that's what damns them." is irrelevant as there was no such 'clean room' Google publicly acknowledged that they based their efforts on Apache's Project Harmony, which was licensed under the Apache license making what Google did perfectly legal, insofar as source code went. The API was never covered by copyright and technically (with the exception of a rogue appellate court) still isn't.

I apologize for any confusion I might have caused.

jilocasin
Facepalm

Re: Google's arguments fail

Let's see where do we start:

1) Who "own's" the java community is completely irrelevant to the case at hand.

2) They didn't, they claimed that implementation of the Java API was:

a) legal, it's an *unprotectable* API

b) required to be compatible with the Java *language*

3) Google's supposed history is also irrelevant, and their 'book scanning operation' was declared legal by the courts.

So about the only thing you've gotten correct/relevant in your post is that this case is a 'basic copyright issue'. An API is a method or system and so is categorically excluded from copyright protection.

See, that was simple.

jilocasin
Boffin

Re: @jilocasin There is *no* IP to take advantage of.

Sorry Ian,

I have read the facts and the case law since this farce's inception. There is a fundamental difference between *source code* and an *API*. It is only by conflating one for the other that any of the cases cited by either Oracle or the appellate court would be anywhere close to on point. Personally I don't believe source code should be copyrightable either, but that's neither here nor there.

An API is a method or process, it has to be the same for interoperability. As I quoted earlier, methods are expressedly excluded from copyright protection.

--------------------------------

An API:

int add(int a, int b)

---------------------------------

Some source code:

int add(int first, int second){

return first + second;

}

---------------------------------

int add(int a, int n){

int result = a;

if(n > 0){

for(int i=0;i<n;i++){

result = result + 1;

}

}

}

---------------------------------

The first isn't copywritable, either of the source code examples _could_ be protected by copyright. So a method isn't while a *particular expression* of that idea can be. Your reference to a 'clean room version' is misplaced in this instance. That only applies to _patents_ NOT _copyrights_, the subject of this case.

As to your remaining points;

Sun released three types of Java; Java EE, Java SE, Java ME. Sun had already released Java SE source code under various permissive licenses. Sun wanted mobile developers to use Java ME for mobile, Google rightly concluded that it wasn't fit for purpose. So Google based it's Android language on Apache's Harmony ( https://harmony.apache.org/ , https://en.wikipedia.org/wiki/Apache_Harmony ). As long as Google didn't call the result 'JAVA' that was perfectly legal. Lots of companies did the same. They threw out the portions they didn't want, added android specific bits and wrote their own bytecode and runtime. The result being a language that would be familiar to existing Java developers and would run on their new mobile device.

It's the same way that database developers can run *most* of the same SQL statements across different database systems. "SELECT * FROM table; " will work on any database that supports the SQL standard. Oracle, IBM, MySql, PostgreSQL, etc. How each database *implements* that statement in code may be different, but no one is allowed to monopolize the;

SELECT command followed by one or more fields, followed by FROM followed by the table, syntax.

Now having said all of that, Google did copy a very small amount of testing code that got released. Google argued that the amount, in light of the code base was allowed as it was 'de minimus'. But that's an entirely separate issue from whether or not API's should be allowed to be copyrighted.

You do yourself a disservice accusing me, or anyone for that matter, of down voting your posts. I'm not saying that this one shouldn't be down voted (lacking the understanding you accuse others of, confusing such simple concepts as patents and copyrights and making ad hominum attacks ;> ).

Hopefully you read things more closely yourself in the future.

jilocasin
Pint

Re: Google and Copyright

That would be the Authors Guild, Inc. v Google case ( https://en.wikipedia.org/wiki/Authors_Guild,_Inc._v._Google,_Inc. ).

The courts found that Google did *NOT* commit copyright infringement (there is no such thing as copyright _theft_) with it's Google Books search database. So, to answer your question, nope.

jilocasin
Boffin

Re: "There's a long history of API's being *outside* of the bounds of copyright"

If you insist:

17 U.S. Code § 102.Subject matter of copyright: In general ( https://www.law.cornell.edu/uscode/text/17/102#b ):

pay particular attention to section b:

"(b)In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work."

An API is a just such a 'system or method of operation'.

Then there's Baker v Shelden ( https://en.wikipedia.org/wiki/Baker_v._Selden ) back in 1879, where a system of accounting was ruled unprotectable by copyright. This came down from no less than the Supreme Court. His _book_ (a particular expression of the system) was copyrightable, but the system wasn't.

Then there's Bikram's Yoga College of India v. Evolution Yoga, LLC ( https://www.eff.org/files/2015/10/09/yoga-copyright-opinion-ca9_0.pdf ) in which the ninth circuit court held in 2015 that the sequence of poses was not the proper subject of copyright. This decision is important in two ways, first it provides a plethora of references to the various decisions underlying why an API isn't copyrightable including the previously mentioned Baker v Shelden. Second, the Federal court was _supposed_ to apply the rulings of the court where the case originated, which in this instance was the ninth circuit. Instead they chose to ignore precedence and rule that APIs are protectable by copyright.

As for your contention that AMD 'had a license' from Intel, that was for the use of their patents, not any copyrights (spoiler, there weren't any).

It's funny that you mention AWS. Do you know that Oracle has implemented Amazon's S3 API without permission (which is perfectly legal) ( https://arstechnica.com/tech-policy/2020/01/oracle-copied-amazons-api-was-that-copyright-infringement/ )? Oracle is claiming that it's OK because the Amazon SDK is licensed under the Apache license. But that's the *SDK* _not_ the API. Java's SE SDK was licensed under the GPL, but Oracle is arguing that license only apply's to the SDK, not the API.

Hmmmmm.......

jilocasin
Facepalm

There is *no* IP to take advantage of.

Apparently you are new here. There's a long history of API's being *outside* of the bounds of copyright. Going all the way back to x86 compatible CPUs. Oracle made a 'Hail Mary' play to try and squeeze a windfall from Google from their purchase of Java from Sun. They included a patent claim with the cynical goal of getting it before the one appeals court that never missed out on a chance to expand intellectual property, whether it made sense or not. The original judge came to a well documented opinion that API's aren't protectable, even going so far as to learn to code himself. When that was overturned and sent back to determine if it was 'fair use', the jury ruled that it was. Once again overturned, disregarding the jury's verdict in its belief that absolutely everything is patentable/copywritable. This particular court's already been _slapped_down_ by the Supreme Court for allowing patents on things that were clearly unpatentable. Hopefully they do the same again in this case.

Oracle and Google will fight in court over Java AGAIN and this time it's going to the Supremes

jilocasin
Boffin

Re: Why doesn't Alphabet just buy Oracle*

Sorry, but that's not what an API is. It has nothing to do with "documenting the code they mostly re-wrote"

If they re-wrote the headers as you put it it wouldn't have been compatible. The API is a collection of functional signatures [ex: int max(int a, int b)], structures, and groupings [ex: java.Math.*] that's it. So if they want to be compatible with Java and Java has a method with a signature; public static double floor(double a) then my floor function would have to match that to be compatible. I can't write a function called; public static double carpet(double a), or give it a different signature; public static int floor(long a) and expect it to remain compatible.

jilocasin
FAIL

Re: You've got to go into the weeds to understand.

LOL, seriously?

Apparently you don't really understand what an API is, do you?

The "the headers of the Java code and placed it in their own code... character per character" is called the API. It has to match, character for character or it wouldn't have been compatible. That's the whole point of having an API. It's not software, and it's not like a manual.

If my API has the following functions in a library called math (ex: java.Math):

int add(int a, int b)

int subtract(int a, int b)

int max(int a, int b)

int min(int a, int b)

int round(double a)

int ceil(double a)

int floor(double a)

Then your implementation (i.o.w. your source code) will have to match that exactly in order to be compatible. The above is what Google copied character for character. They wrote their own software, they didn't copy any of Sun's (well except for an accidental 9 lines) actual software.

Google didn't short-cut going to market they just used the industry standard practice of implementing the API of something they wanted to be compatible with (you know, like how Libre Office can read a Microsoft Excel file, or Excel could read a Lotus 1-2-3 file Or how your browser can connect to a web site, or your operating system (regardless of which) can read and write to your SSD).

It's Oracle's greed (and a particular Federal Appeals Court's intransigence) that has caused the world to suffer through endless court battles.

jilocasin
Pint

Almost

You can design all you like, but some things just aren't eligible for patent or copyright protection (crazy I know). API's are one of those things, like abstract ideas, or rules of nature.

At least they were, until Oracle decided to buy Sun and sue Google over them, and the random inclusion of a mostly irrelevant patent landed the appeal of their rightful loss into the hands of the "United States Court of Appeals for the Federal Circuit" [C.A.F.C.] otherwise known as the court that believes; all things are patentable, all uses require payment, and both the law and supreme court rulings are suggestions to be ignored. The Supreme Court has been taking a number of cases from the C.A.F.C. in order to reverse and otherwise try and smack some sense into them. Hopefully this is one such case.

jilocasin
Holmes

You've got to go into the weeds to understand.

Not quite. You will have to go a little further into the weeds to understand what was going on.

First, there was JAVA ME on clunky phones, then came Apple and the iPhone with it's third party app ecosystem and GUI that revolutionized phones at the time. Google didn't want to be shut out and so needed something to compete. It created (bought) Android and went about streamlining it as an OS that could compete with the iPhone.

In order to get a critical mass of developers who could write for this new OS, Google decided to base it on Java, since universities were churning our Java developers by the bucket load at that time. Now, at that time there were three versions of Java; Java EE (for enterprise and web servers), Java SE (for desktops), and Java ME (for mobile). Of the three the only one that was "open sourced" was Java SE. Anyone could write a compatible version (and by that I mean Java virtual machine there were several at the time) but in order to call it "Java" (and get a promise not to be sued over patents) it needed to pass a proprietary battery of tests. Included in this was a Use Restriction that said you couldn't use this product on mobile devices. About the only place Sun was getting any licensing revenue was from Java ME. The Apache Harmony version of Java runtime refused to accept that restriction and so was the only open source version that wasn't so encumbered. There was a lot of he said/she said between Sun and Google, but in the end Google took the Java API from Harmony, threw away those parts that it felt weren't suited to mobile, added parts that it thought were missing and created it's own runtime Dalvik. So, to make it clear, Android uses a Java SE compatible language that get compiled into a completely different (i.o.w. not Java) bytecode, on something that is not called Java.

Whether or not you think that's good/bad/fair or not, didn't really matter. Up until this case, it was well understood that API's weren't copyrightable. If they were we wouldn't have gotten IBM clones, multiple versions of BASIC, Linux, GNU software, or any two computer programs that weren't from the same company that could talk to each other. For those who actually understand these things it makes about as much sense as claiming that since I purchased the copyrights to William Shakespeare's works I can demand payment from anyone who dares write in iambic pentameter.

jilocasin
WTF?

Re: Oracle's Innovations??

Which unfortunately for Oracle couldn't have included an "IP" in API's, as until this case there wasn't any such thing.

jilocasin
Boffin

Re: Without any sign of a nod toward irony

Actually, no. Until this case API's (structure basically) were well understood to be uncopyrightable. Implementations could be copywritten but the API's themselves, not so much. So there was no such thing as "open sourced" API's.

An example of an API would be:

java.math.add

or

int add(int a, int b)

Actual implementation examples might include:

int add (int first, int second){

return first + second;

}

or

int add(int beginning, int ending){

int a = beginning;

int b = ending;

int result = a;

for(int i = 1; i == b; i++){

result = result + 1;

}

return result;

}

The only people that would be confused are those that either mistakenly, or intentionally confuse software for API's.

jilocasin
Headmaster

Almost.

Hate to nitpick but the Court of Appeals for the Federal Circuit is primarily the court of appeals for patents, *not* copyright cases. The original case had some patent elements and so got appealed to the Court of Appeals for the Federal Circuit.

GitLab reset --hard bad1dea: Biz U-turns, unbans office political chat, will vet customers

jilocasin
WTF?

SJW's muddying the waters.

The problem, as I see it, is that the SJW's (professional whiners, in other words) have so muddied the waters that people/companies have difficulties thinking straight. It's a matter of _what_ some company/group/person is *doing* and not _who_ they are that should be the deciding factor at the end of the day.

Shunning a person/group/company because they are; white, gay, republican, Jewish, etc. is wrong and lazy.

Shunning them because of what they do; cage small children, bomb civilians, shoot peaceful protesters, etc. is a morally sound thing to do.

SJW's, and modern _feminists_ in particular, are a terribly hypocritical lot. Willing to make sweeping racist and sexist generalizations against *other* groups in a rush to don the mantle of victimhood. In their world view they can not by definition be sexist, because they are women. As if all men are identical and can be judged as a group (wow, seems a little sexist to me). Heck, many of those that call themselves _feminists_ claim to speak for *all* women, and will even take the time to 'educate' a woman who doesn't realize that she's being oppressed. That of course assumes that they can even agree on what constitutes womanhood.

So yes, the EFF is correct when it states that making a choice to not take into account the morality of your customers is in fact making a choice, and not a good one at that. On the other hand, we as a society need to stop lending credence to the false narrative of victimhood and oppression promulgated by predominately first world professional victims. There is sexism in the world (take a look at women in Saudi Arabia and Ethiopia for example). There is racism and religious intolerance (for example the Rohinya's in Myanmar, and the Tibetan people in China). There is political unrest (such as the ongoing protests in Hong Kong). Closer to home, there are examples of LGBTQ youth getting thrown out of their homes, of churches and synagogues being vandalized, of people shot and killed by law enforcement for the simple crime of being non-white at the wrong place at the wrong time.

Offering to hold the door for a woman, isn't sexist. There isn't a great *patriarchal* conspiracy in films, books, music, and video games to oppress women. An artist refusing to create (whether it's a wedding cake, a painting, or a poem) for gay men isn't a sign of rampant LGBTQ discrimination. Refusing to teach creationism in the public schools, or drawing pictures of Mohammad, isn't religious intolerance. I believe we need to grow up, put on our 'big boy pants' and start acting like adults. Freedom means not just the ability to say/do what you want, but the tolerance to accept that other people don't share the same thoughts, values, ideals that you might. Hopefully we can still agree on the bigger issues.

Chef melts under heat, will 86 future deals with family-separating US immigration agencies

jilocasin
Facepalm

Re: Screw Chef

As opposed to the alternative?

Staying put and letting your children;

starve

be sexually abused

be killed by lawless gangs

be killed by lawless government agents

Pick any one (or all) of the above. Dragging your children across the desert to enter another, much safer, country sounds like the smartest thing a parent might do.

jilocasin
FAIL

Re: Go woke go broke

You are giving Chef too much credit. There is no 'Wokeness' to be found here, just cold hard accounting.

If you compare the initial response to this latest one, what's readily apparent is that other 'paying' customers were starting to get uncomfortable/complain. They were risking much more money from losing their 'other' customers over this than they stood to make continuing with this contract. They could care less about their employees complaints, those had been going on for a while and hadn't stopped them from signing. They sure as heck haven't gotten 'woke' to any extent.

jilocasin
Boffin

Re: Open source licenses and moral compass exclusions

For the most part they don't.

What this developer did (as was covered in the original piece) was to take down his repository. Anyone who had the code was free to keep using it under the terms of the open source license it was released under. What they couldn't do was get a copy from *his* repo. He was well within his rights to say in effect; "what ICE is doing is wrong, what Chef is doing is wrong supporting that, and I want to make it known that I *personally* don't agree with it.

The license is rather besides the point. He could have done the same thing under a suitable commercial license, although it would have been easier to include a morality clause in a commercial license.

Had Chef, as a competent commercial entity done the sensible thing, it would have been a non issue. Some smaller companies / independent developers would have noticed, but Chef's customers would have been fine. Unfortunately for Chef, while they took advantage of applicable open source code (good) they were too sloppy/lazy/cheap to host their own tool chain (bad). The effect being that when he 'closed' his repo, their product and their customer's installs, broke.

The fact that this served to magnify the point the developer was trying to make by calling attention to what he felt was a questionable contract was just icing on the cake. That Chef's employees and 'other' customers might feel the same, once they were made aware of it, if why Chef changed course.

You don't get points for doing the right thing only when all other options have been exhausted.

jilocasin
Pint

Re: "South America where the US govt has brought Freedom and Democracy(tm)"

As Churchill once said;

"Indeed it has been said that democracy is the worst form of Government except for all those other forms that have been tried from time to time.…"

jilocasin
Facepalm

Re: "don't enter the country illegally"

Once again, you aren't letting facts get in the way of your arguments. Mexico *isn't* legally a _safe_ country (no surprise there) and they would have had to walk all the way across the United States to get to Canada. According to your own logic, it would be illegal for them to apply for asylm in Canada having reached the 'safe country' of the United States first.

Page:

SUBSCRIBE TO OUR WEEKLY TECH NEWSLETTER

Biting the hand that feeds IT © 1998–2020