Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

AWS licenses it's client library as under the Apache License. (https://github.com/aws/aws-sdk-java/blob/master/LICENSE.txt) Doesn't that mean anyone can build an interoperable service? I can then benefit from other cloud providers implementing the same API. I don't need access to AWS' source code, I wasn't going to deploy a private cloud anyway. All I want is robust competition.


This has already happened to an extent. For example, there are bunch of API compatible implementations of s3, both oss and proprietary and most of them suggest you use the AWS sdk as a client.



Wow, that's wild to read. In comparison (and complete lack of contrast) to:

https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/am...


What the hell kind of comparison is that? You linked a human-doc-writer written documentation to auto-generated Java SDK documentation...


To me it's not related, the SDK is under the apache licence but it's just an implementation of the API, the API itself is not defined or under the copyright of that SDK.


Yeah, I think this is what Digital Ocean does? I believe the AWS S3 Python library works out of the box for DO.


I would guess that it doesn't work out that way. The Apache license has the patent clause, but it doesn't have a comparable "API copyright" clause. Though perhaps another consequence of an Oracle win is that we end up with an Apache3 license.


I don't follow. If someone can determine the API by referring to code released under the Apache licence, what copyrights could they be infringing by building a different implementation of the API using the Apache-licensed code as a reference?

For a copyright infringement to have taken place, there generally needs to be an unauthorised instance of recording or of duplication, of some copyrighted work.

I put generally as, I believe, precisely recreating someone else's photo can still count as an infringement of their copyrights, despite that you haven't copied the image itself in the usual sense of making duplicates. Singing someone else's song can also infringe on their copyrights over the song. I don't think this would apply here though.

(Disclaimer: I'm not a lawyer, I could well be missing something obvious.)


The same sort of API copyright that Oracle is trying to establish in this case.

How things actually shake out would depend a lot on the specifics of the Court's ruling, and I am not a lawyer either. But, if the court rules that Oracle owns a copyright to the Java APIs, and that this means they can prevent others from implementing their own versions of those APIs, and this right remains in effect even though they release a full implementation of them under GPLv2, then I can't see any particular reason to expect that things would work differently for Amazon's APIs and Apache2.


The difference is that the way Google used the APIs is not compatible with code use under the GPLv2 (in particular, they didn’t GPLv2 license it). If the original code implementing the APIs is Apache licensed however, you have a very free hand in changing the original code so you probably wouldn’t care about your working being considered a derivative of it. I’m not sure that absolves you categorically but it definitely sounds like a better position to be in.


But the API must be defined in the client library, and that has been released under an open source license.


They've given a license to use and extend the copy-written software, including its method signatures.


Oracle has done that, too. They release the full JDK under the GPL.

The law around these sorts of things can get pretty hair-splitty. My guess is that the situation here is that Amazon client libraries and OpenJDK are distributed with a license to create derivative works that are based on their respective products, but that these licenses do not necessarily grant a license to create a new thing that works the same out of whole cloth. Should Oracle win the case, that would seem to imply that the Court believes they do not. Alternatively, the fact that open source licenses do not appear to have even been brought up in the course of these hearings would perhaps imply that the existence of open source libraries that implement these APIs is legally irrelevant.


OpenJDK did not exist when Android was developed and initially released. Google did move to using it 2016 and may not have liability after that date.


Andriod was First released in Sept 2008,

OpenJDK was first released May 2007...


Perhaps more legally relevant, Android's first public beta dropped in late 2007. But still, technically after OpenJDK's release.


It's copyright, not copywrite

https://en.wiktionary.org/wiki/copywrite


Using a client is different than reimplementing compatible classes.


The idea is that a client generally contains a copy of the API (it's calling it so it should).

So you get a copy of the API with Apache license and are free to build your own implementation of it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: