Earlier quoted context omitted.
> [1]: I am willing to bet that very few people understand what the Oracle v. Google court case is all about, And what it was about?
First, we should separate the motivation for the lawsuit from the legal arguments. Corporations don't go to court to win legal arguments; they go to court to defend or promote their business. I) The motivation for the lawsuit was that at the time, Java's main revenue stream was licensing Java IP (either an actual implementation or the permission to implement the spec) for use in mobile devices. That was how Sun made…
Mysterious Android codebase commit
161–170 of 170 posts
Re: Mysterious Android codebase commit
#162Earlier quoted context omitted.
> [1]: I am willing to bet that very few people understand what the Oracle v. Google court case is all about, And what it was about?
First, we should separate the motivation for the lawsuit from the legal arguments. Corporations don't go to court to win legal arguments; they go to court to defend or promote their business. I) The motivation for the lawsuit was that at the time, Java's main revenue stream was licensing Java IP (either an actual implementation or the permission to implement the spec) for use in mobile devices. That was how Sun made…
Re: Mysterious Android codebase commit
#163Earlier quoted context omitted.
> [1]: I am willing to bet that very few people understand what the Oracle v. Google court case is all about, And what it was about?
First, we should separate the motivation for the lawsuit from the legal arguments. Corporations don't go to court to win legal arguments; they go to court to defend or promote their business. I) The motivation for the lawsuit was that at the time, Java's main revenue stream was licensing Java IP (either an actual implementation or the permission to implement the spec) for use in mobile devices. That was how Sun made…
> Google needed Java because developing a language ecosystem suitable for phone application takes years.
Google did not create a language 'eco system' from Java. They created an entirely new one. The only resemblance it has to Java is the fact that a few APIs look the same, and they presumably did this to help developers and phone manufacturers with familiarity and existing code. This is done every other day of the week in the software industry and presents no problem.
There is a fundamental comprehension problem about what the difference is between a set of APIs that a language uses, the language itself and its implementation.
> Anyway, Google claimed that APIs aren't copyrightable, but Oracle won that round.
The concept of APIs has been done and dusted before in the 80s and 90s and it will be again. If APIs are copywritable then there is no software industry. What's amusing is they they knew this was a problem because they had to build in a laughable fair use clause for interoperability. There is no situation where an API isn't used for interoperability and code reuse.
> First, it applies only to language-level APIs; not REST protocols, recently also referred to as APIs. This is not open to interpretation. Web "APIs" are not copyrightable for completely other reasons, reasons which are impossible
I think you need to re-read this back, carefully, and comprehend how utterly idiotic trying to separate 'web' APIs from 'other' APIs in terms of copywrite actually is. There is no difference and pigeon-holing this is plain laughable. The fact that you mention this shows that you, and probably Oracle, know what huge problems this causes. The whole argument is completely null and void and I'm afraid it very much is open for debate. Once again, we have legal people not knowing what they're talking about.
> Courts have ruled it legal to "violate" copyright for the purpose of creating components that are interoperable with the original. This means that if you implement an API in order to break vendor lockin, you're probably within your right to do so. However, that is not what Google did in this particular case (Android is not interoperable with Java, only very, very partially).
I'm afraid this is yet another piece of laughable misunderstanding and shows how shaky Oracle's legal case actually is. No one is under any obligation to implement a complete API. For example, there are many C standards and many implementations only implement a subset of a particular standard with a long list of caveats - and that's from compilers that claim to be C compatible. Implementing a subset of an API, taking code and compiling it on a new platform happens every other day of the week in software.
To attempt to claim that Google has no fair use argument because they didn't implement all of Java's APIs is completely laughable. There are a long list of exceptions going back decades that Google can use to completely invalidate this nonsense.
However, that's the big problem Oracle has. They have had to attempt to try and pigeon-hole what Google has used in Android as Java by jumping through a lot of nonsensical hoops.
> while it has been in Google's best interest to cause panic
There should quite rightly be panic. This means there is no software industry, and it goes way beyond Google and Oracle.
> It only applies to language-level APIs; it does not and cannot apply to web APIs and other protocols
This is complete tripe. It is impossible to pigeon-hole APIs in this manner because they exist at many different levels, and even this ridiculous definition still causes fundamental problems.
> Implementing an API is protected by the interoperability fair-use defense, even if Google's particular (and highly unusual) use isn't.
There is nothing unusual about what Google has done, but you would know that if you knew what you were talking about. Sadly, we have a lot of people, mostly legal, who simply don't.
As for what Google are doing with OpenJDK, I think it probably has more to do with tidying up their platform and multiple Android implementations more than anything else. Curiously, using OpenJDK and overriding core APIs with Classpath would also give them a pretty good example as to how ridiculous this whole thing is.
Re: Mysterious Android codebase commit
#164Earlier quoted context omitted.
> Still waiting an explanation about web API's not being a proper API. It's not that they're not APIs (you can call anything you want an API -- copyright law doesn't care what it's called), but because they don't have a fixed form. In order to copyright something you need it to be a particular fixed text (or image, or recording). There is no such text for web APIs. You can come up with multiple texts (or images) all…
> It's not that they're not APIs (you can call anything you want an API -- copyright law doesn't care what it's called), but because they don't have a fixed form. In order to copyright something you need it to be a particular fixed text (or image, or recording). There is no such text for web APIs. You can come up with multiple texts (or images) all describing the exact same API. That is not the case for "plain" APIs.…
You also can't label APIs as 'language level' either. It's ridiculous.
Re: Mysterious Android codebase commit
#165Earlier quoted context omitted.
> It's not that they're not APIs (you can call anything you want an API -- copyright law doesn't care what it's called), but because they don't have a fixed form. In order to copyright something you need it to be a particular fixed text (or image, or recording). There is no such text for web APIs. You can come up with multiple texts (or images) all describing the exact same API. That is not the case for "plain" APIs.…
Yes, it's utterly laughable. The sad thing is this isn't just him. This is actually what Oracle is arguing and the hoops they are jumping through to try and copywrite APIs for what they want but try and get around the very obvious problems. You also can't label APIs as 'language level' either. It's ridiculous.
Not at all. Oracle is arguing nothing regarding web APIs, and I'm arguing nothing about library APIs. My argument's and Oracle's do not overlap. Oracle is saying that library APIs are copyrightable, and I am saying that even if they are, web APIs cannot be.
> You also can't label APIs as 'language level' either. It's ridiculous.
You don't need to label APIs in any way (and what you find ridiculous has little bearing on the law). The relevant question to this particular discussion is whether what you're trying to copyright is a piece of text or not. A library API -- like all code -- is text. A web API isn't. If there's no fixed text to copyright, all other discussions are moot.
You could also claim that copyrighting code while not copyrighting algorithms is ridiculous because in your mind they are the same. However, as far as copyright is concerned, an algorithm can be described in many different words -- and therefore there is no fixed form to copyright -- while a piece of code is fixed, and therefore could potentially (and, in fact, is) be copyrighted.
Re: Mysterious Android codebase commit
#166Earlier quoted context omitted.
> Still waiting an explanation about web API's not being a proper API. It's not that they're not APIs (you can call anything you want an API -- copyright law doesn't care what it's called), but because they don't have a fixed form. In order to copyright something you need it to be a particular fixed text (or image, or recording). There is no such text for web APIs. You can come up with multiple texts (or images) all…
> It's not that they're not APIs (you can call anything you want an API -- copyright law doesn't care what it's called), but because they don't have a fixed form. In order to copyright something you need it to be a particular fixed text (or image, or recording). There is no such text for web APIs. You can come up with multiple texts (or images) all describing the exact same API. That is not the case for "plain" APIs.…
The question of how web services are defined is not material. The question is whether a "API" = "fixed text" or not. For library APIs, the answer is yes, for web APIs the answer is no.
Re: Mysterious Android codebase commit
#167Earlier quoted context omitted.
First, we should separate the motivation for the lawsuit from the legal arguments. Corporations don't go to court to win legal arguments; they go to court to defend or promote their business. I) The motivation for the lawsuit was that at the time, Java's main revenue stream was licensing Java IP (either an actual implementation or the permission to implement the spec) for use in mobile devices. That was how Sun made…
You have a few things ass backwards with a fundamental lack of technological knowledge on more than a few points (to put it mildly), which is not unusual for lawyers and won't be for Oracle either. > Google needed Java because developing a language ecosystem suitable for phone application takes years. Google did not create a language 'eco system' from Java. They created an entirely new one. The only resemblance it ha…
You may think this is the case and are entitled, of course, to your opinion, but:
> with a fundamental lack of technological knowledge on more than a few points (to put it mildly), which is not unusual for lawyers and won't be for Oracle either.
I am not a lawyer nor work for Oracle (or Google for that matter). Neither have I ever worked for Sun, Oracle or Google. However, I am a software developer and have been one for over twenty years. I have also collaborated with both Oracle and Google on OpenJDK (yes, Google has been collaborating with Oracle on OpenJDK throughout most of the court case, as much of Google's infrastructure is built upon OpenJDK).
> This is done every other day of the week in the software industry and presents no problem.
That's news to me, and I am quite familiar with the industry. I am not aware of many more cases where such a wholesale copying (without license compliance) of an API has taken place for reasons other than source/binary compatibility. There are a few (UNIX is a famous case, but that's been challenged in court already), but none recent. Again, regardless of how ridiculous, laughable or preposterous you think copyright law is, it most certainly does not apply to languages (like SQL or the Java language itself) nor to any other algorithm, protocol or API (as in web APIs) that does not have a fixed representation in text.
> I think you need to re-read this back, carefully, and comprehend how utterly idiotic trying to separate 'web' APIs from 'other' APIs in terms of copywrite actually is.
Again, the matter of whether you think this is idiotic or whether this really is has absolutely no relevance to the law. If I tell you a story it is not copyrightable; if I write the same story down, it is. If I record myself while telling you the story, it is also copyrightable. The same story, serving the same purpose may or may not be copyrighted depending on the very particular form it takes. You may think this is idiotic (although you may be persuaded otherwise if you studied the purpose of copyright vs other forms of legal IP protections), but that's how it's always been.
> I'm afraid this is yet another piece of laughable misunderstanding and shows how shaky Oracle's legal case actually is.
I don't know if you've noticed, but I'm not arguing Oracle's case. I think there are good arguments to copyright APIs and good arguments against, but I really -- in all honesty -- don't have a final opinion on the matter. You think Oracle's case is laughable -- fine. My point is that no matter if Oracle is right or wrong, from the perspective of copyright law a ruling on library APIs does not translate to web APIs regardless of how similar or even identical you believe they are. Copyright law is very specific about the forms protected works may take. If a work is a specific, fixed text it may be copyrighted (if it meets some other conditions); if not -- it may not.
> This means there is no software industry, and it goes way beyond Google and Oracle.
That's your opinion. However, the ruling does not apply to any API or protocol that is not recorded in fixed media, and interoperability has been accepted as a fair use defense before. I am not aware that the software industry is predicated on copying and re-implementing significant APIs (not a function here and there, which is definitely fair use) for purposes other than interoperability.
> Curiously, using OpenJDK and overriding core APIs with Classpath would also give them a pretty good example as to how ridiculous this whole thing is.
Maybe. I know that I and others wanted them to do this before the lawsuit ever happened, because everybody saw it coming (once Sun's fate was decided), but Google didn't listen. They preferred getting sued (which they had anticipated) over using GPL software.
Re: Mysterious Android codebase commit
#168Earlier quoted context omitted.
> It's not that they're not APIs (you can call anything you want an API -- copyright law doesn't care what it's called), but because they don't have a fixed form. In order to copyright something you need it to be a particular fixed text (or image, or recording). There is no such text for web APIs. You can come up with multiple texts (or images) all describing the exact same API. That is not the case for "plain" APIs.…
What piece of (substantial) text is replicated when you implement someone else's web API? If there isn't one then there is nothing to copyright. The question of how web services are defined is not material. The question is whether a "API" = "fixed text" or not. For library APIs, the answer is yes, for web APIs the answer is no.
Or perhaps you're just trolling
Re: Mysterious Android codebase commit
#169Earlier quoted context omitted.
> It's not that they're not APIs (you can call anything you want an API -- copyright law doesn't care what it's called), but because they don't have a fixed form. In order to copyright something you need it to be a particular fixed text (or image, or recording). There is no such text for web APIs. You can come up with multiple texts (or images) all describing the exact same API. That is not the case for "plain" APIs.…
What piece of (substantial) text is replicated when you implement someone else's web API? If there isn't one then there is nothing to copyright. The question of how web services are defined is not material. The question is whether a "API" = "fixed text" or not. For library APIs, the answer is yes, for web APIs the answer is no.
Re: Mysterious Android codebase commit
#170Earlier quoted context omitted.
What piece of (substantial) text is replicated when you implement someone else's web API? If there isn't one then there is nothing to copyright. The question of how web services are defined is not material. The question is whether a "API" = "fixed text" or not. For library APIs, the answer is yes, for web APIs the answer is no.
It is clear that you don't j=know what an API is if you say that a web API like Goole Maps or Beeminder is not a library API. Or perhaps you're just trolling
Just to make clear: I am not arguing that Java's APIs is copyrighted, just that there is good reason to see why -- from the perspective of copyright law -- the Google Maps API isn't, regardless of the status of the Java API. They could be absolutely identical from your perspective, and yet different enough from the law's perspective due to some minor detail that you -- but not the law -- may consider inconsequential.