I was thinking the same thing. At the time Google was the unsung hero defending our rights. Now Google won't let you subscribe to podcasts in their app unless you turn on location history storage, like those two things are actually mutually exclusive.
It's unbelievable that Oracle is still pursuing this, despite the obvious consequences _for its own survival_. Their main product copied APIs and even the SQL language itself.
> Now Google won't let you subscribe to podcasts in their app unless you turn on location history storage, like those two things are actually mutually exclusive.
Have they made any statement on why that? I don't use their podcast app, but that's particularly egregious.
I've seen similar stuff with Android Auto/Google Assistant requiring Web & Location History; but I gave them a bit more benefit of the doubt because that data could be used for needed context to answer voice queries, and I could see them not wanting to create special cases that did not use those permissions for business reasons.
Their main product copied APIs and even the SQL language itself.
This is a really interesting point. Presumably IBM owns the copyright on SQL ("SEQUEL"); is there anything that prevents them from suing Oracle (and everyone else) for royalties?
> At the time Google was the unsung hero defending our rights. Now Google won't let you subscribe to podcasts in their app unless you turn on location history storage, like those two things are actually mutually exclusive.
Okay, so you don't like how their podcast app works, but how does this violate your rights?
Luckily, Java is fully open source now, with OpenJDK. I concur though with never using proprietary languages (which is a part of me not using C#--of course, that is now also open source, but C# is still kinda bad on Linux afaik).
Edit: _sigh_ The downvotes without any reason hurt. See [1]. Since OpenJDK is GPL v2, and since TCK tests have been open sourced and Java EE given to Eclipse, I would call the Java ecosystem fully open source. Feel free to correct me if I'm wrong of course.
OpenJDK is an open source implementation of the Java API. However the question here is about the openness of the Java API itself, not any particular implementation of it. Google already uses a totally separate implementation which is different from both Oracle Java AND OpenJDK.
Unfortunately, the scope of the case is broader than proprietary languages. It doesn't matter what language you use---if you copy an API (including, IANAL-but-I-assume, recapitulating that API in an entirely different language), you're at risk. This covers a plethora of use-cases.
what about instruction "signatures"? i.e. the machine instruction sets? every compiler is potentially performing millions of counts of copyright and or license violations on a large scale?
What is a proprietary language to you? Java? Then you will have a hard time using many languages since it is open source and copyrighted by its owner like many languages.
But regardless of what language you use, this legal precedent is saying if you, for example, copy Twitter's RESTful API to create your own messaging service where all the existing Twitter clients can change a few constants and adopt you as a target, Twitter could sue. That's not something ISO protects against (unless there's an international standard for asymmetric message services you can design against).
I suspect that the implementation of any API would come under the shadow of this ruling. For instance, replacing a proprietary product with an open-source variant that has the same API would also be illegal or subject to licensing fees.
In my opinion, this will be bigger than proprietary languages and cover drop-in replacements for pretty much any proprietary code, thus providing yet another way to lock customers into a particular product.
As someone who has recently tried Rust and uses Java in his day job, why do you think that Rust is the obvious successor? Wouldn't C# be a better fit for people looking to leave Java?
I agree that C# would be a better fit. In terms of this ruling, I don't think the language really matters. Re-implementing any API that is copyrighted will be a problem no matter what the language.
In terms of re-implementing the language, I believe that C# is just as free as Rust in this regard; it can be done without fear of a lawsuit.
Java was also unique in that Sun was only charging licensing fees for mobile implementations, providing motivation for Google to build their own implementation of the language. With mobile devices being as high powered as they are, I don't think that model makes sense anymore.
I really hate this view of the world. I'm a developer, not a "C++ developer" or a "Java developer". I write code in C++, Java, C#, Python, Matlab, Rust, and other languages.
My current project has me working primarily in a mix of C++ and Java, and I would love nothing more than to rewrite the whole thing in Rust. Sadly, I did my job too well the first time around, and it's hard to justify a full rewrite of a codebase that already works.
B. What about Scala? Would you say Scala is a "good fit" for people leaving Java because it's also built on top of the JVM? Or would it be a "bad fit" because the idioms and functional-nature of Scala are vastly different than Java? Or how about Kotlin?
I'm not thinking about "successor" in terms of "Java-specific" design patterns. I'm thinking successor in terms of - can Rust, with concurrency as a first-class-citizen and C-like perf with a safer programming model, replace Java for many of the "higher-level" applications that would've typically been written in Java?
Google starting to hit the presses about this probably means they realize they are fucked. This is an attempt to steer public opinion in their favor in order to influence either the outcome or start the discussion about mitigation for the expected outcome.
That's entirely possible, but it's also not super-great if this precedent stands. APIs have generally been understood to be a tool for communicating between layers, not a work of art that are themselves copyrightable and proprietary. It throws sand in the gears of cross-system integration if a company can get you on their copyright ownership of an API (especially since in the US, copyright is assumed and one is not required to file formally for it).
I don’t know how they could steer the relevant public opinion any more in their favor--is there anyone in the industry who doesn’t work in Oracle’s exec suite who thinks this is anything but an incredibly stupid and destructive precedent?
> Google positions a decision in favor of Oracle as a disaster for all developers.
That's a bit of hyperbole, because it requires a company to sacrifice developer good will (if it has any, unlike Oracle) to claim ownership/copying.
Also, where they reasonably can, people need to stop building on tech owned by companies they despise. Of course this is not reasonable in many cases, but for me, I won't use Graal and will actively tell others not to because it's easy not to. I don't have a problem w/ Google or FB like many others on here, but if you did, not using Go or React is probably unreasonable, but not using Google Cloud might be reasonable.
Also, we need to start holding privileged developers accountable for their chosen employer. I'm not talking about the underprivileged intern, I'm talking about the Oracle engineer that continues to work there at this time. If it's on your resume of late, I won't hire you. I also might not accept your PR if you are employed there.
I'm not sure how your clarification addresses MBlume's concern.
A mass culture of "If you have X on your resume, I won't hire you" puts pressure on people who have X to stay in the space where X is true rather than try to exit it. It could put pressure on incoming software engineers to not join X, but if X's perks are good enough, will it? I'm reminded of the fact that undocumented immigrants in the US rose after the beginnings of tightened border security during the "war on drugs"---if the flow back and forth is easy, people flow back and forth. But if the flow is blocked, people will tend to stay where they are (or, worse, migrate to where the perks are better...).
Sorry, I was unclear and didn't address the concern specifically. I meant it is still overall what I would want even with that downside. Granted I recognize that there will likely be no observable effect to such a limited, hard-line stance on these principles, but that's the case with many other principled choices too. I wouldn't suggest it if it was hard or unreasonable.
That's ridiculous self-serving high-horse grade-a bullshit. You've chosen a single feature among countless other's and decided to give it disproportional weight and treat it as a perfect predictor.
> You've chosen a single feature among countless other's and decided to give it disproportional weight and treat it as a perfect predictor.
Not true. It's not a predictor of anything and I never claimed it was. I said that is a feature that is a disqualifier, especially in the current market of employer/employee choice. There are many other features like this too, including the attitude presented by your comment.
I love it how you clearly use your position at the company to make yourself feel in control. Like a mod on this site. Hey fucktard, you're not interviewing the guy you just replied. He's not interested in your disqualifications for hiring. In fact, I'd say you're a low-level middle-management paper pusher who does nothing useful for the company, and are replaceable with no ramp-up.
The attitude is a negative one, towards an idiot shithead. Trust me, with an attitude like yours, no one good would choose to work for you. When picking good resources, that are good for your team, you are competing for them - they're not competing for you. Seriously, you're like a meter maid on a powertrip. Clown.
It is true that GraalVM has a proprietary version too, that AFAIK has extra features, but the open source version is impressive on its own.
What developers really need to do is to stop building on platforms based on how much they like a company. Stop treating companies like sports teams. Your feelings for a company are completely irrelevant because its culture can always change, or it can be sold to the highest bidder.
Things that matter much more:
1. Is it Open Source? This is important for having control. E.g. no matter what Oracle does next, there is now a community dedicated to maintaining and improving OpenJDK and in fact OpenJDK has cool features that Oracle’s Java does not, like a cool new low latency GC contributed by Red Hat.
2. Does it have an ecosystem around it?
GraalVM is new, but it piggybacks on Java’s ecosystem and Java is huge. In fact that’s also why Google piggybacked on Java too.
Speaking of which, I’m not defending Oracle’s lawsuit, I think they did it because they are greedy bastards, however the elephant in the room is that Google fragmented the Java ecosystem.
It is 2019 and Android’s SDK still does not support Java 8’s bytecode.
So how is Google any more special than Microsoft and what they did with Java (J++) back in the day? I don’t see a difference. And now the Java ecosystem can’t move on to Java 8 due to Android.
We have a huge double standard. Back in the day when Sun sued Microsoft people cheered for Sun.
The problems will come when it is claimed that some other thing is really just an API, and also subject to this ruling.
Is public inheritance and interface implementation no longer allowed in Java? I can think of several ways to duplicate parts of the Java API. I don’t see how courts will draw a legal distinction.
> The problems will come when it is claimed that some other thing is really just an API, and also subject to this ruling.
This is not so simple. The court ruled only about a particular case that concerns an API under the "traditional" definition (the only thing we used to call API until not long ago) -- an API that is actual code -- and not other things that some are calling APIs, such as protocols (so-called REST "APIs"). One cannot simply claim that the ruling applies to other kinds of things, like protocols, regardless of whether programmers think they are similar or even "essentially the same." For example, in the US programs are protected by copyright but not patents while algorithms are protected by patents but not copyright. I imagine that at least part of the reason for this distinction can be found here: https://www.law.cornell.edu/uscode/text/17/102
(a) Copyright protection subsists... in original works of authorship fixed in any tangible medium of expression...
(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.
A program (and an API) are some text "fixed in a tangible medium of expression" while an algorithm (and a protocol) are an idea described in some text (although the description text itself may be copyrighted; an algorithm book, including the pseudocode of the algorithms, is copyrighted, but the algorithms themselves are not). Ideas can be covered by patents, not copyright.
> Is public inheritance and interface implementation no longer allowed in Java?
Leaving aside the fact that Java is 100% open source and the license explicitly allows this kind of use (and in a non-viral way thanks to "the classpath exception")[1], your question is similar to, if a recording is copyrighted, is listening to it no longer allowed? One can make fair use of copyrighted works. This would not only apply to subtyping or calling APIs, which, like listening to music, is obviously their intended use but even -- and this is implied in the discussed ruling -- copying them and implementing them in order to enable third-party interoperability (the court ruled that in this particular case Google did not make fair use of the APIs[2])
This seems dangerous to anyone reverse engineering an API to, say, port it to another language or runtime. Is the Win32 API copyrighted? If so, is the ReactOS project in danger? Is Haiku?
Second, companies don't sue you just to make a point or to show they're right; success is never guaranteed, and corporate lawsuits are expensive -- not only in direct monetary cost but in PR costs as well. Companies use lawsuits when there's actual serious damage done to them which they want to recuperate, or to prevent such imminent danger of serious damage.
If you cause serious damage you should expect to be sued regardless of whether you did something wrong or not, and even if you do something wrong but don't cause serious damage, chances of a lawsuit are low[1]. So while certain things may certainly increase your exposure, what puts you in danger is the harm you do more than the rules you break.
Projects that mimic or port the Windows API would be in danger -- whether now or before the lawsuit under discussion -- when they can cause serious damage to MS.
[1]: This may be different for trademark violations; I think trademarks require vigilant defense or they could be lost.
I like open source, and I don't like how patents and proprietary software has made the life of the developer difficult, but to be fully honest I don't like java either, I would really prefer to see languages like C++ thrive instead of java, especially today with the new iterations of C++.
I just don't understand what makes java more appealing than C++. I guess the garbage collector? I just wish python was just in the same league of performance of java...
fully virtual (C++'s being mixed is a blessing and a curse), portable (C/C++ depends on architecture details) high performance compared to other high level languages - with less of C++'s complexity arising from "you don't pay for what you don't use", standard packaging (JARs, WARs or maven-like stuff) + standard compiler, relatively standard options for building, a broad set of largely compatible application servers.
It's the fastest and most mature platform for its level of complexity around (namely, less than C++), C# is a close and viable second and outshines it in some ways - and can be thought of as a descendant in some ways, if you squint a little bit (of Microsoft Java).
Anyone else irked by the keyboard shortcut analogy Google's lawyers keep using? It clearly didn't help them last time they used it. I think if I was a judge I would feel … insulted by such an obvious oversimplification. And the result is both vaccuous and debatable. Keyboard shortcuts aren't perfectly consistent, many people don't actually use them very much anyway, and many more people wouldn't care if they were different between different "computers" (?!) because they only use one and feel lost in the other kinds anyway. Surely Google's team of lawyers, in the space of nine years, can find a better source for analogies here…
The evidence suggests that they can’t come up with a better analogy. Perhaps there are legal principles at play that prevent them from using something seemingly better. They are smart people. I think a better a question or observation would be, “What prevents them from using X as an analogy?”. Or maybe the case isn’t so clear cut in favor of Google that its lawyers have to traverse a minefield of legal traps and this is the best they can come up with.
Google should just do what Microsoft did with dotnet. Fork their Java projects, change method names from lowercase to uppercase then give it a new name.
Oh, sorry. I guess I've woken up in a magical parallel universe where Microsoft didn't just spend the better part of the past decade extracting billions of dollars every year from Android phone manufacturers.
So here's a question: supposing APIs become copyrightable, doesn't that imply there also must be a way to license API implementations, including issuing free and open licenses?
So although the idea of copyrighting an API strikes me as generally stupid and it could clearly be problematic for some developers in the short term, surely this isn't really that much of a hassle in the long term? People will just explicitly state whether or not they want to allow others to implement their API?
I don't really consider that an improvement, but neither does it seem all that disastrous.
I'm also curious how this will affect the geography of software development. Since the SCOTUS' jurisdiction only covers the US but there are international copyright treaties, will this decision affect development outside the US?
In theory, the market will adapt to track this layer of copyright, but the short-term shock effect is large. Since nobody's assumed APIs are copyrightable 'til now, nobody's been keeping track. So every API currently in use is under threat (especially since in the US, you don't have to file a copyright claim to have copyright; if you can just prove your API came first and there's reason to believe the younger API was familiar with your own, you can claim statutory damages, IIUC).
It'll be exciting to see how many of Oracle's APIs are 100% derivative of some software released under Copyleft licenses... ;)
The thing if that API compatibility is huge when it comes to migrating from one service to another. If an open source project can't reimplement an API then it means that it's way harder to migrate from a proprietary solution to an open one.
As APIs (at least those the court ruled on) are code, it appears they are licensed along with the rest of the code. Java's APIs would, therefore, be dually licensed under either a commercial license or an open-source license (Android originally complied with neither; I believe it now complies with the open-source license).
This is similar to what AWS recently did with providing MongoDB interface with its DocumentDB offering.
If Oracle wins, it logically goes then AWS would not be allowed to provide MongoDB interface to DocumentDB.
If I think back in time, Java was just reference implementation of the API. Sun JDK VM being one implementation of it, OpenJDK being the other. By that extension, Google wrote its own VM for it, that worked on mobile phone OS.
Let's say Oracle gets everything they want. What impact would this have on the legality of certain programming practices in commercial settings like inheritance and the wrapper pattern?
80 comments
[ 4.9 ms ] story [ 171 ms ] threadIt's unbelievable that Oracle is still pursuing this, despite the obvious consequences _for its own survival_. Their main product copied APIs and even the SQL language itself.
I use BeyondPod, so I wasn't aware Google had any offering in this space.
https://support.google.com/googleplaymusic/answer/6343833?hl...
They also apparently have a standalone podcast app:
https://play.google.com/store/apps/details?id=com.google.and...
https://www.androidcentral.com/google-listen-officially-dead
Have they made any statement on why that? I don't use their podcast app, but that's particularly egregious.
I've seen similar stuff with Android Auto/Google Assistant requiring Web & Location History; but I gave them a bit more benefit of the doubt because that data could be used for needed context to answer voice queries, and I could see them not wanting to create special cases that did not use those permissions for business reasons.
This is a really interesting point. Presumably IBM owns the copyright on SQL ("SEQUEL"); is there anything that prevents them from suing Oracle (and everyone else) for royalties?
Oracle probably has a good couple parents that are absolutely essential to IBM or that would have already happened. MAD works.
Okay, so you don't like how their podcast app works, but how does this violate your rights?
Edit: _sigh_ The downvotes without any reason hurt. See [1]. Since OpenJDK is GPL v2, and since TCK tests have been open sourced and Java EE given to Eclipse, I would call the Java ecosystem fully open source. Feel free to correct me if I'm wrong of course.
[1] https://openjdk.java.net/legal/gplv2+ce.html
We're not talking about re-implementing the JDK/JRE spec; the author mentioned he/she wants to use only open source languages...
In my opinion, this will be bigger than proprietary languages and cover drop-in replacements for pretty much any proprietary code, thus providing yet another way to lock customers into a particular product.
In terms of re-implementing the language, I believe that C# is just as free as Rust in this regard; it can be done without fear of a lawsuit.
https://arstechnica.com/information-technology/2009/07/micro...
Java was also unique in that Sun was only charging licensing fees for mobile implementations, providing motivation for Google to build their own implementation of the language. With mobile devices being as high powered as they are, I don't think that model makes sense anymore.
A Java programmer would be so confused by Rust.
My current project has me working primarily in a mix of C++ and Java, and I would love nothing more than to rewrite the whole thing in Rust. Sadly, I did my job too well the first time around, and it's hard to justify a full rewrite of a codebase that already works.
(Or I guess you could write Scala in a non-functional, Java-y way, but that would defeat the purpose of using Scala...).
B. What about Scala? Would you say Scala is a "good fit" for people leaving Java because it's also built on top of the JVM? Or would it be a "bad fit" because the idioms and functional-nature of Scala are vastly different than Java? Or how about Kotlin?
I'm not thinking about "successor" in terms of "Java-specific" design patterns. I'm thinking successor in terms of - can Rust, with concurrency as a first-class-citizen and C-like perf with a safer programming model, replace Java for many of the "higher-level" applications that would've typically been written in Java?
What is so ironic is Oracle was completely built off of re-using an API. It was an API owned by IBM.
Few companies existence is completely built off of using someone else's API.
But then the irony for Oracle to bring this lawsuit.
What other company the size or Oracle was built on an API?
That's a bit of hyperbole, because it requires a company to sacrifice developer good will (if it has any, unlike Oracle) to claim ownership/copying.
Also, where they reasonably can, people need to stop building on tech owned by companies they despise. Of course this is not reasonable in many cases, but for me, I won't use Graal and will actively tell others not to because it's easy not to. I don't have a problem w/ Google or FB like many others on here, but if you did, not using Go or React is probably unreasonable, but not using Google Cloud might be reasonable.
Also, we need to start holding privileged developers accountable for their chosen employer. I'm not talking about the underprivileged intern, I'm talking about the Oracle engineer that continues to work there at this time. If it's on your resume of late, I won't hire you. I also might not accept your PR if you are employed there.
Then they can't leave. I'm not sure that's what you want.
It is, my statement is about industry-wide stigma henceforth, not specific literal effects on existing employees.
A mass culture of "If you have X on your resume, I won't hire you" puts pressure on people who have X to stay in the space where X is true rather than try to exit it. It could put pressure on incoming software engineers to not join X, but if X's perks are good enough, will it? I'm reminded of the fact that undocumented immigrants in the US rose after the beginnings of tightened border security during the "war on drugs"---if the flow back and forth is easy, people flow back and forth. But if the flow is blocked, people will tend to stay where they are (or, worse, migrate to where the perks are better...).
That's a little ridiculous.
Thank you for saving good employees from a bad boss.
An assumption at best. Those of us that have the leverage to choose our employers can be judged by that choice.
Not true. It's not a predictor of anything and I never claimed it was. I said that is a feature that is a disqualifier, especially in the current market of employer/employee choice. There are many other features like this too, including the attitude presented by your comment.
The attitude is a negative one, towards an idiot shithead. Trust me, with an attitude like yours, no one good would choose to work for you. When picking good resources, that are good for your team, you are competing for them - they're not competing for you. Seriously, you're like a meter maid on a powertrip. Clown.
It is true that GraalVM has a proprietary version too, that AFAIK has extra features, but the open source version is impressive on its own.
What developers really need to do is to stop building on platforms based on how much they like a company. Stop treating companies like sports teams. Your feelings for a company are completely irrelevant because its culture can always change, or it can be sold to the highest bidder.
Things that matter much more:
1. Is it Open Source? This is important for having control. E.g. no matter what Oracle does next, there is now a community dedicated to maintaining and improving OpenJDK and in fact OpenJDK has cool features that Oracle’s Java does not, like a cool new low latency GC contributed by Red Hat.
2. Does it have an ecosystem around it?
GraalVM is new, but it piggybacks on Java’s ecosystem and Java is huge. In fact that’s also why Google piggybacked on Java too.
Speaking of which, I’m not defending Oracle’s lawsuit, I think they did it because they are greedy bastards, however the elephant in the room is that Google fragmented the Java ecosystem.
It is 2019 and Android’s SDK still does not support Java 8’s bytecode.
So how is Google any more special than Microsoft and what they did with Java (J++) back in the day? I don’t see a difference. And now the Java ecosystem can’t move on to Java 8 due to Android.
We have a huge double standard. Back in the day when Sun sued Microsoft people cheered for Sun.
And who told you these (or any other) people are looking forward to be hired by you?
How about we attach an "industry wide stigma" (sic) on you for proposing something so inane and inconsiderate?
Maybe if you get fired under such pressure on your employer and can't find a job you'd reconsider how nice "blacklisting" of the type you propose is?
Is public inheritance and interface implementation no longer allowed in Java? I can think of several ways to duplicate parts of the Java API. I don’t see how courts will draw a legal distinction.
> The problems will come when it is claimed that some other thing is really just an API, and also subject to this ruling.
This is not so simple. The court ruled only about a particular case that concerns an API under the "traditional" definition (the only thing we used to call API until not long ago) -- an API that is actual code -- and not other things that some are calling APIs, such as protocols (so-called REST "APIs"). One cannot simply claim that the ruling applies to other kinds of things, like protocols, regardless of whether programmers think they are similar or even "essentially the same." For example, in the US programs are protected by copyright but not patents while algorithms are protected by patents but not copyright. I imagine that at least part of the reason for this distinction can be found here: https://www.law.cornell.edu/uscode/text/17/102
(a) Copyright protection subsists... in original works of authorship fixed in any tangible medium of expression...
(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.
A program (and an API) are some text "fixed in a tangible medium of expression" while an algorithm (and a protocol) are an idea described in some text (although the description text itself may be copyrighted; an algorithm book, including the pseudocode of the algorithms, is copyrighted, but the algorithms themselves are not). Ideas can be covered by patents, not copyright.
> Is public inheritance and interface implementation no longer allowed in Java?
Leaving aside the fact that Java is 100% open source and the license explicitly allows this kind of use (and in a non-viral way thanks to "the classpath exception")[1], your question is similar to, if a recording is copyrighted, is listening to it no longer allowed? One can make fair use of copyrighted works. This would not only apply to subtyping or calling APIs, which, like listening to music, is obviously their intended use but even -- and this is implied in the discussed ruling -- copying them and implementing them in order to enable third-party interoperability (the court ruled that in this particular case Google did not make fair use of the APIs[2])
[1]: http://openjdk.java.net/legal/gplv2+ce.html
[2]: https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google...
But this case would be a very significant precedent...
Second, companies don't sue you just to make a point or to show they're right; success is never guaranteed, and corporate lawsuits are expensive -- not only in direct monetary cost but in PR costs as well. Companies use lawsuits when there's actual serious damage done to them which they want to recuperate, or to prevent such imminent danger of serious damage.
If you cause serious damage you should expect to be sued regardless of whether you did something wrong or not, and even if you do something wrong but don't cause serious damage, chances of a lawsuit are low[1]. So while certain things may certainly increase your exposure, what puts you in danger is the harm you do more than the rules you break.
Projects that mimic or port the Windows API would be in danger -- whether now or before the lawsuit under discussion -- when they can cause serious damage to MS.
[1]: This may be different for trademark violations; I think trademarks require vigilant defense or they could be lost.
I just don't understand what makes java more appealing than C++. I guess the garbage collector? I just wish python was just in the same league of performance of java...
It's the fastest and most mature platform for its level of complexity around (namely, less than C++), C# is a close and viable second and outshines it in some ways - and can be thought of as a descendant in some ways, if you squint a little bit (of Microsoft Java).
How many have used copy and paste? Hopefully all of them.
* https://www.computerworld.com/article/2475440/android/micros...
See: https://raw.githubusercontent.com/dotnet/corefx/master/PATEN...
So although the idea of copyrighting an API strikes me as generally stupid and it could clearly be problematic for some developers in the short term, surely this isn't really that much of a hassle in the long term? People will just explicitly state whether or not they want to allow others to implement their API?
I don't really consider that an improvement, but neither does it seem all that disastrous.
I'm also curious how this will affect the geography of software development. Since the SCOTUS' jurisdiction only covers the US but there are international copyright treaties, will this decision affect development outside the US?
It'll be exciting to see how many of Oracle's APIs are 100% derivative of some software released under Copyleft licenses... ;)
If Oracle wins, it logically goes then AWS would not be allowed to provide MongoDB interface to DocumentDB.
If I think back in time, Java was just reference implementation of the API. Sun JDK VM being one implementation of it, OpenJDK being the other. By that extension, Google wrote its own VM for it, that worked on mobile phone OS.