Big News: Supreme Court To Hear Google v. Oracle Case About API And Copyright
from the this-is-important dept
Some big news out of the Supreme Court this morning, as it has agreed to hear the appeal in the never-ending Oracle v. Google lawsuit regarding whether or not copyright applies to APIs (the case is now captioned as Google v. Oracle, since it was Google asking the Supreme Court to hear the appeal). We've been covering the case and all its permutations for many years now, and it's notable that the Supreme Court is going to consider both of the questions that Google petitioned over. Specifically:
1. Whether copyright protection extends to a software interface.
2. Whether, as the jury found, petitioner’s use of a software interface in the context of creating a new computer program constitutes fair use.
As you may recall, the Supreme Court refused to hear Google's appeal back in 2015, which was just focused on the first question above, regarding whether or not an API was copyright-eligible. So it's quite interesting to see that it will now review that question. As you may recall, after the Supreme Court refused to review that point, the case went back to the district court where Google's use of some of the Java API was deemed to be fair use, which was a funky sort of way for the jury to recognize that there never should have been copyright on the API in the first place.
To me, as I always point out in this case, the key element will be getting the Supreme Court to recognize that an API is not software. Oracle and its supporters keep trying to insist that an API and executable code are one and the same, and I worry that the Supreme Court will not fully understand the differences, though I am sure that there will be compelling amici briefs trying to explain this point to them.
You never can tell how the Supreme Court will come down on these issues. The court has been tragically bad on copyright over the past few decades (with a few exceptions). But it's also repeatedly smacked down bad rulings from the Federal Circuit, which is where this case is coming from. So perhaps that additional skepticism over CAFC's nutty interpretation of the law will help them review this issue carefully.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: android, api, copyright, fair use, java, supreme court
Companies: google, oracle
Reader Comments
Subscribe: RSS
View by: Time | Thread
"You never can tell how the Supreme Court will come down on these issues."
The fact that it is so unpredictable, really makes me question anyone who says "show me the law." Cheap cop-out.
Laws are made purposely broken. See: Lobbyist
It is the only way they work for High Court, Low Court and Kangaroo Court.
[ link to this | view in chronology ]
Re:
anarchist?
[ link to this | view in chronology ]
Will the Supremes Understand Copyright?
Hard to say, and Mike is right to say they might not get it. But I want to do a shout out for a Professor I once had who is now one of them: Justice Breyer. He's written many times on the subject (and had many other commentators disagree with him) but I claim he does "get it." A speech he gave is quoted at https://babel.hathitrust.org/cgi/pt?id=mdp.39015039064657&view=1up&seq=106, with particular focus on technology/software toward the bottom of page 101. It was a while ago, and his views may well have evolved, but this speech is well worth reading. For amusement, the very next speaker at this event (whose article I will not bother to read) is there on behalf of Elsevier.
[ link to this | view in chronology ]
Re: Will the Supremes Understand Copyright?
I agree. Breyer is frequently correct on copyright law. At the same time, Ginsburg is frequently wrong. So, to some extent those two cancel each other out.
[ link to this | view in chronology ]
Re: Will the Supremes Understand Copyright?
"If you work by analogy, you'd better be cerrtain that you have the right analogy, based on the particular economic conditions". "Take the area, for example, of scholarly libraries. The case for protection there is very weak. Why? Well, scholarly material will likely be produced without any protection".
The person from Elsevier spoke right after a federal judge arguing there should be no copyright at all on scholarly journals! He must have fainted.
Not to be outdone, the very next year Elsevier escalated the serials crisis, increasing the speed of price hikes by 300 %. "Prices have risen faster than inflation since the 1970's, and four times faster since 1986". https://dash.harvard.edu/bitstream/handle/1/4728931/suber_univactions.htm?sequence=1
[ link to this | view in chronology ]
Really hope that someone at Google has them use the contract analogy for an API. That would be something judges and lawyers could understand.
The API is like a contract between the user application and the software library. It specifies how the two interact with each other, but does NOT specify how they actually perform the contracted activities.
[ link to this | view in chronology ]
Re:
Analogies are a bad way to explain things and they can muddy the waters even further.
I would hope the scotus would have staff on hand to explain things, how could they not?
[ link to this | view in chronology ]
Re: There's no need for an 'analogy'...
Analogies are not needed if it's truly recognised what this is about, which seems to be a problem for many:
The difference between the use of language, and the rules that govern it.
An API is simply an ADDITIONAL set of rules (that may be more subjective) governing how language is used for greater consistency. A set of rules governing how to apply the English language as 'Yodaspeak' would be an 'API'. Since such rules are completely functional, and used to enable creative expression, they are as unsuitable for copyright protection as any other rules of grammar/content.
Just because you can create a language, and have many subjective rules governing it, does not make either of them suitable for copyright protection in themselves: whether it's speech or computer code makes no difference.
[ link to this | view in chronology ]
Re:
Or use a car analogy. Most people understand cars.
An API is like the bolts that connect a steering wheel to the steering column. Oracle is claiming that because they used a different size and shape of bolts than anyone else, it would violate their copyrights for anyone to use anything but their steering wheels or steering wheels they have approved in their cars, even if non-approved steering wheels will fit.
[ link to this | view in chronology ]
Re: Re:
An API would be more like the convention that turning the steering wheel counter-clockwise makes the car turn left and turning it clockwise makes the car turn right. Oracle is arguing that since they made one kind of steering mechanism that responds to the steering wheel that way, any steering mechanism that responds to a steering wheel the same way automatically infringes on Oracle's mechanism.
[ link to this | view in chronology ]
Re: Re: Re:
I own the patent on round steering wheels, pay up.
[ link to this | view in chronology ]
Re:
An API has no inherent "consideration". API's can be user extended, and typically are without constraint. They are completely unlike a contract. Please don't use law terms you don't understand.
[ link to this | view in chronology ]
Re:
It's such a good analogy that the specification of inputs and outputs in an API is often referred to as a contract.
[ link to this | view in chronology ]
Re: Re:
The Story of the Shibboleth.
[ link to this | view in chronology ]
Re: Re: Re:
If you are suggesting I used that phrase to try to exclude non-technical people, that couldn't be further from the truth. I tried to find an accurate phrase that a non-programmer could understand. If you have a better suggestion, I'm all ears. If I had wanted to employ a shibboleth, I would have called it a method signature, which is the most correct term but I assume means nothing to anyone not in the field, and might even be somewhat confusing to a programmer who is not familiar with Java.
If you meant something else, perhaps you could elaborate.
[ link to this | view in chronology ]
Re: Re: Re: Re:
I gave you a link to a very old story. That ancient story belongs to the common culture. Make of it whatever you will.
Although I myself think, you ought listen very carefully…
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
Reminds me of Trump. "I don't stand by anything."
To what? Your vague reference to an old story and refusal to explain what you mean by it? Why should anyone listen carefully to that? It seems to me you're trying to appear wise by being cryptic, but it comes across more as not really having anything to say.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
Have a nice day.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re:
Thanks, you too.
[ link to this | view in chronology ]
Know what's a really good non-software API? Mail.
I put a lot of information in a package, and put an address on it. That address tells the carrier to get it to this country, then this state, this town, street, and address.
If it were a copywritable API, then I could do the above for the USPS, but if I went to FedEx, they'd tell me they don't understand that address. But they can deliver to a GPS coordinate!
But DHL can't use the street address, and FedEx already is using GPS coordinates so they can't deliver via that mechanism, so you have to pre-coordinate with your receiver to give them turn by turn directions from the nearest DHL facility so they can get to the correct house without using a copywritten method.
[ link to this | view in chronology ]
Re:
I see your point but many will confuse the "what do we do" with the "how do we do it" in your analogy. There are many much better analogies for APIs such as restaurant menus.
[ link to this | view in chronology ]
The nature of the way digital mechanisms functions really demonstrate the absurdity of the very concept of copyright.
[ link to this | view in chronology ]
I think an API is most easily described as the instructions describing how to write other instructions.
Therefore they should be either a subset of the "series of mental steps" category that is not eligible for patent or copyright or a "list of facts" also not eligible for patent or copyright.
[ link to this | view in chronology ]
Re:
That makes sense if you are a developer who already understands what an API is. That will make no sense to a supreme court judge with no previous idea what an API is.
[ link to this | view in chronology ]
Re: Re:
Yes, part of the problem -- and the one that Oracle's lawyers have exploited throughout this process, is that to a totally untrained eye, an API spec looks equally as incomprehensible as executable code... and thus they pretend the two are identical.
[ link to this | view in chronology ]
Re: Re: Re: Interface != Implementation
I can't imagine that a court filing would get very far without correct and specific details in the correct and specific LANGUAGE using the correct and specific TERMS in the correct and specific SYNTAX in the correct and specific locations on the correct and specific form in the correct and specific order with the correct and specific fees in a correct and timely manner lodged with the correct clerk of the correct and specific court.
https://www.youtube.com/watch?v=9t3B-ssC5j0
[ link to this | view in chronology ]
Re: Re: Re: Re: Interface != Implementation
Assuming tongue in mouth ala Monte Python, what makes you think the Supreme's (with apologies to Dianna Ross and the Primettes) can understand the specifics? I mean, for example, if you network doesn't connect is it a hardware or software issue? How do you tell? If your software doesn't work, is it bad software, or an OS incompatibility, or is your system infested with some malware? If you want to query a website about something specific, to you just use CNTRL f in the browser or an API setup to do that king of query.
You might, and I think I know that the API isn't a part of the website, but a way to interact with it that doesn't include a browser. Is it software on its own or a part of the websites software. It might be software as it is a set of code, but it is not executable code and it merely points to those parts of the output of executable code that one is interested in. How hard is that to comprehend?
Well, what took your network down, hardware, software, the ISP failing, something you did, but didn't know you did, something else (I have found at times that something else applies)? How are some lawyers gonna splain that to some egocentric lawyers sitting on a bench set above all other benches?
[ link to this | view in chronology ]
Re: Re: Re:
"an API spec looks equally as incomprehensible as executable code"
The API may be and often is indistinguishable from source code. Sometimes the only difference between a web page describing the source, and the actual source is a little formatting. (Perls POD system does this)
Binary code is not consistent even on the same machine derived from the same source code. (different compiler options make different binary code) Any expectation that copyright applies to binary code is irrational.
To say that the API can't be copyrighted, is like saying the header files in a C program can't be copyrighted. People on the side of Google complain that it is like copyrighting a table of contents. Well, you CAN copyright a table of contents.
Really an API is actually more like a trademark than either a copyright or a patent. It defines a programmatic namespace that is claimed by the author. Technically you probably could trademark an API. It defines a unique piece of information specific to the authors business which is used to identify work.
The issue is that the neither USPTO or the Copyright Office have any interest in serving the software community. You've been through the copyright process. You know what joke they are.
Programmers are getting shafted when it comes to intellectual property rights. API copyrights are a good thing for programmers. It will result in a lot more work, and a lot more upward mobility for individual programmers. Yes there are problems. But for programmers, API copyright is a good thing.
[ link to this | view in chronology ]
Re: Re: Re: Re:
As a programmer, I can tell you, you're full of shit.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
As a programmer whose written an API, Oracle is right. API copyrights are a good thing.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
[Asserts facts not in evidence]
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
Until you need to use one. It's not A problem till it's YOUR problem.
[ link to this | view in chronology ]
Re: Re: Re: Re:
Only for programmers hoping to get an API in use and then extort customers with copyright demands. The majority of programmers are users of APIs, and so would benefit from them being clearly not copyrightable.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
Copyright issues in large companies like google or oracle are completely different matter than in your average startup. Startups are taking risks that large companies simply cannot take. Any indication of copyright problems in large companies when your product is being sold by millions of units and you'll have copyright trolls trying to extract billions from your operation. Large companies simply cannot afford any problems with this area.
Small companies never have this problem, since the worst that can happen is that the ceo goes to jail and company is bankcrupt. But copyright trolls dont bother with small entities since there isn't enough money in the bank to pay whatever the trolls want for the effort.
I have no idea who inside google thuoght it is good idea to clone java apis. After they broke the negotiations for the java licenses, their operation become extreamly lucrative target for copyright trolls.
[ link to this | view in chronology ]
Re:
"I think an API is most easily described as the instructions describing how to write other instructions."
Nope. there's no "how-to" in an API. An API specifies a collection of contracts, i.e., declarations of interfaces. Each signature, i.e., specification of an API element, declares the obligations that each party, the client and the API element, must meet in order for interactions to complete successfully. Amusingly in the context of our current news universe, the API declares a set of quid quo pros without direction as to how either party will meet its obligations. How-to is relevant to the implementation layer - not the contracts (signatures of interfaces) that constitute the API collection.
[ link to this | view in chronology ]
Re: Re:
If you can't see how it is a set of instructions I suggest you not get a developer job.
[ link to this | view in chronology ]
Re: Re: Re:
Here is the Java Math class definition, where in that description is there any instruction on how to implement any code. Notes on requirements of an implementation are not instructions in the sense of computer instructions. Also, what in that class definition is new or original, considering the history of computer programming and mathematics.
That class is no more than an enumeration of standard maths functions, with some notes to guide implementation. It also informs programmers and compilers of available functions.
[ link to this | view in chronology ]
Re: Re: Re: Re:
where in that description is there any instruction on how to implement any code
"static double E"
It is exactly instructions on the proper syntax to implement a static double decimal number closest to the constant e by putting in E as the symbol in the code. It is a fact, not a copyrightable element.
Notes on requirements of an implementation are not instructions in the sense of computer instructions.
They are instructions to the developer not the computer.
what in that class definition is new or original, considering the history of computer programming and mathematics
To be honest I learned java at my University (got an A) along with several other languages and I do not know how much any one is original over the others. I did like try { } though. It turned what was intended to be giant programming assignments into 3 liners.
That class is no more than an enumeration of standard maths functions, with some notes to guide implementation. It also informs programmers and compilers of available functions.
That is true. It is very instructional for students to look at that list of facts describing the Java programming language.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
How did you manage that if you are confusing API specification with implementation.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
You could put that class into an API if it's not already in one. I didn't know this was stupid gotcha garbage.
Here is an API:
http://spec.openapis.org/oas/v3.0.2
It also contains information similar to that class.
Specifically:
type format Comments
integer int32 signed 32 bits
integer int64 signed 64 bits (a.k.a long)
number float
number double
string
string byte base64 encoded characters
string binary any sequence of octets
boolean
string date As defined by full-date - [RFC3339]
string date-time As defined by date-time - [RFC3339]
string password A hint to UIs to obscure input.
The rest of it is also largely facts about the API. I stand by my original statement.
[ link to this | view in chronology ]
Re:
Grab an old style hard wired telephone.
The API is the phone jack. It specifies the physical connection required, and the voltages and current supplied. It DOES NOT specify the actual implementation for the phone itself.
So you can have an old style phone that can plug into the jack and operate with the phone system.
So you can have a wireless phone that also plugs into the same jack and uses a radio transmitter/receiver to a remote unit. And this also works with the phone system.
So you can have an answering machine that will pick up on a phone call, send out a message, and record an incoming message. And this also works with the phone system.
...
[ link to this | view in chronology ]
Re: Re:
Actually the phone jack is OSI layer 1, (physical layer) and has nothing at all to do with software. If you are going to make up analogies, please stay away from already established tech namespace.
Thanks
[ link to this | view in chronology ]
Re: Re: Re:
It's an analogy...
[ link to this | view in chronology ]
Re: Re: Re:
Analogies are a bad way to explain things.
[ link to this | view in chronology ]
Re: Re: Re: Re:
Explaining something with an analogy is like feeding dog food to a cat.
More seriously, some commentary on analogies:
https://www.copyblogger.com/persuasive-analogies/
https://betterexplained.com/articles/le arning-to-learn-embrace-analogies/
And there's tons more of course. If you have any writings about why analogies should be avoided or are "a bad way to explain things" I'd be interested to see it.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
An analogy is typically used when there is insufficient time and/or interest in learning details of whatever the topic is, shortcuts are taken (analogy) in order to explain complex things. The next time that person encounters a similar but different situation, they will stumped again.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
Sometimes. But if time or interest does not permit going into details, you have a few options:
It seems obvious to me that the second one is the best option, and I see no problem with analogy as a teaching method, if used well. And that is not the only use for analogy - it can be used to introduce a concept and then followed up with more rigorous detail.
That is not an issue of teaching with analogy. If the person isn't capable of figuring things out on their own, they will be stumped in a new situation if they have been taught about a different one in detail or not.
[ link to this | view in chronology ]
If APIs are afforded copyright, does that mean every application developer will have to choose a different name for each command their app makes public? For example, one would have to replace the command "open" with some other word? How would all these different ways of doing the same thing be cataloged for licensing purposes? This is really stupid - lets do it! LOL not.
[ link to this | view in chronology ]
Re:
Well, I already tried this approach and now I have 500 functions that are completetly unique. There are some problems getting people to learn the new menu structure, but once they manage to learn it, it works like blender for creating 3d models.
[ link to this | view in chronology ]
Re: Re:
I'm back in a silo again
Out where IP is a pain
Where the copyright barons feed
On the lowly startup weed
Back in the silo again
[ link to this | view in chronology ]
Technology for technologists.
I wound up with some very serious technological problems here at home. I am not a technologist by training or or avocation, though I do understand some of it. Some issues were resolved, others are outstanding. The point is what I went through to resolve those issues would likely be beyond most people.
When it comes to technology, and understanding, I have little hope that any of the Supreme's will, OK, let's say it, compute. There is that one judge, William H. Alsup that learned to code, in this very case in fact, in order to improve his understanding of what was going on. I have little expectation that any of the Supreme's will either comprehend what he did, or do so for themselves. I think they tend to see themselves above, and in their point of view above whatever the intricacies of nuance that exist, and see themselves as merely arbitrators of law. How closed minded of them. There is a real world out here, and it is changing fast, and faster. For the Supreme's to keep up, they are going to have to change as well. Not just their mindset, but their understanding of the real world, as it changes.
[ link to this | view in chronology ]
Re: Technology for technologists.
The Supreme Court seems to like to tell the Federal Circuit to stop throwing away their IP precedents and do their job right.
I think there is room for optimism they will do that again but obviously it could go either way.
[ link to this | view in chronology ]
Re: Technology for technologists.
Part of the reason for Alsup's learning some of Java is that he already did know how to script and write code a bit. And from other tech-orientated cases, it is clear he has a scientific mind, and willing to learn and understand things in order to apply the law.
It is all too often true that others seem to think that a properly-formed argument is the way to go, and hang reality-based evidence that doesn't fit into the normal (and sometimes questionable) ideas of what conventional legal evidence is.
[ link to this | view in chronology ]
Re: Technology for technologists.
There is that one judge, William H. Alsup that learned to code, in this very case in fact, in order to improve his understanding of what was going on.
This is not entirely accurate. Alsup already knew how to code. He just didn't know Java, so he taught himself how to code in Java to better understand the specifics.
[ link to this | view in chronology ]
Re: Re: Technology for technologists.
That honestly just leaves him coming out looking even better than I'd pictured him before now, as I can only imagine how many judges would assume that since they already know one way to do the job in question the knowledge would accurately translate to the other way on trial and saved themselves the 'unnecessary' work.
[ link to this | view in chronology ]
Re: Re: Re: Technology for technologists.
I already see the Federalist Society adding "Has never ever tried to write or read source code of a computer program" to their requirements for a job of judge.
[ link to this | view in chronology ]
Oracle doesn't understand their own business
Winning this case would be one of the worst things that could happen to Oracle. By owning the API, they have hegemonic control of the direction of one of the most prevalent programming languages on the planet. If they win and force everyone to only use their subscription licen$ed versions of Java, then people will move to alternatives. I work at a company with hundreds of developers who have mainly use java for 20 years, but if Oracle wins this case, I have no doubt that we would take steps to migrate to different languages.
[ link to this | view in chronology ]
Re: Oracle doesn't understand their own business
Concidering Oracle's new license requirements for java shops, I am a bit surprised that your shop has not starting considering migrating. Oracle licensing comes off as a cluster fuck...
[ link to this | view in chronology ]
Re: Re: Oracle doesn't understand their own business
I wonder what oracle plans to do with all the still valid sun licenses the thousands or millions of university students technically have. Part of the course actually WAS about the licenses because organizations like the RIAA or MPAA paid the university to put more IP in the curriculum after some students made a large search/index project on the dorms intranet that served almost solely infringing material as part of their senior engineering project.
The students had to take down their project. More IP instruction was included in the curriculum. No one got sued.
[ link to this | view in chronology ]
Re: Re: Oracle doesn't understand their own business
We're moving to non-oracle java implementations. But if they win this case and those non-oracle implementations get shut down...
[ link to this | view in chronology ]
Re: Re: Re: Oracle doesn't understand their own business
You have to pay whatever Oracle demands until you have everything re-written into some other language.
[ link to this | view in chronology ]
Re: Re: Re: Re: Oracle doesn't understand their own business
where did the idea come rom that companies need to offer their technology without compensation to anyone who wants to use it?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Oracle doesn't understand their own business
Straw man. The idea is that since an API specification is nothing more than instructions on how systems are to interact, they shouldn't be copyrightable. Any company basing its business on creating, copyrighting, and then selling rights to an API is probably extremely stupid by the way, since the way APIs gain value is by being widely adopted.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Oracle doesn't understand their own busi
Normal application developers using an API do not need to copy the api definitions. What they do instead is just use the api. I.e. they use part of (already licensed) software package, and find the header files from it. You usually get the license to use the api together with the purchase of the software module that you're using.
Whatever google is doing with oracle's software is something completely different. They're building competing platform that tries to enter the java market. Obviously this activity can have separate (and more expensive) licensing than what ordinary application developers need to use.
Note that both cases here, the people who use the sofware, need to obtain valid licenses to use the api definitions.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Oracle doesn't understand their own
There you have a misunderstanding, Google is not using Oracle software, but rather implementing their own version of Java that is API compatible with Java. Oracle wants Google to pay them for not using their software.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Oracle doesn't understand their
The api definitions are part of oracle software. QED.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Oracle doesn't understand th
but not afforded copyright
I thought one of, if not the top, reasons for using java is the interoperability/portability characteristics. By demanding royalties on the api, they are shooting their product in the foot.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Oracle doesn't understand their own
We're talking about implementing the API, as Google did, not using an implementation of the API as most programmers do. And it's impossible to implement the API without copying it. Let's say the API defines this method:
public void doSomething(String anInput);In order to implement that API, your code must contain:
public void doSomething(String anInput){ // your implementation }Software is executable code. API definitions are not executable.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Oracle doesn't understand their
There's no good reason for implementing an API to be allowed. Especially for internal apis like java standard libraries. Java standard libraries are sitting inside java software bundle. It's not external api which is needed to communicate with other pieces of software, instead both the application developers and libraries are part of the java community. Both sides of the interface are owned and maintained by oracle. There's no reason for other companies to mess with that api whatsoever.
Of course google is part of the java community when they use oracle's java environment to develop the android software. Google is obviously disappointed that the language they chose for the basis of their android software wasn't as cheap as they originally estimated. But that's life.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Oracle doesn't understand th
Everyone but the gatekeepers is better off if there is competition. With multiple Java implementations, everyone has an incentive to make theirs better. If Oracle has a monopoly on it, well we've seen how they run their database business. You can expect skyrocketing prices to use Java, and the language will be run into the ground in very short order if Oracle wins this thing. Google is already all in on Kotlin, and I wonder if that would even have gotten off the ground if it were not for this lawsuit. It's a massive foot shooting by Oracle that will make sure nobody wants anything to do with Java because it will just be too risky.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Oracle doesn't understan
I think you underestimate the amount of money and effort it takes to make something like java popular. The investment is in billions of dollars. Which means sun and oracle has actually spent that money to make java popular among programmers and users.
Now that oracle paid the money, they need to get something in return. It's well established principle that if you give out money, you need to get something in return. What they get was ownership in the java platform and community. Owners are in unique position to decide who is allowed to use that work. If they decide that google is not allowed to use it, then by their ownership, google is not allowed to touch the technology.
So this is why oracle is allowed to place a bill of 9 billion to google for their unauthorized use of java platform and community.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Oracle doesn't under
One reason Java is so popular is that Google picked it for Android. I believe most of the devices running Java are Android devices. If Google had believed that Sun could impose per-device license costs for creating their own JVM, they never would have picked Java. Now that Oracle is attempting to do so, they're moving to Kotlin. So how is that working out?
If they win this case, yes. And as I said, that would be the death knell for Java. Oracle will almost immediately behead the goose (whatever the quality of eggs it has been laying). Google and anyone else with any sense will drop Java like a hot potato, and then Oracle will wonder why nobody is using Java any more.
The question is, what happens to the wider software development world? Don't bother answering, I already know what you think.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Oracle doesn't u
Here's a crazy theory:
1) sun/oracle wanted to kill java years ago
2) android made their maintainance burden 10 years longer than expected
3) the end run of programming languages is not profitable, it just eats money and effort
4) so oracle wants to get paid for the additional effort they need to do
5) google is obvious candidate from where they can get the money needed
6) so they sued google for copyright infrigement
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Oracle doesn
You're right, that is crazy, because Sun or Oracle could have decided to stop supporting Java any time they wanted to. There is no law requiring ongoing support.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Oracle d
Large projects might have some additional requirements related to not breaking
the competition or the world. These rules somehow prevent the next world war 3.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Orac
So - make java apis copyrightable or its the end of the world as we know it .... do you feel fine?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
I think you misconstructed the argument a little. Large projects have large number of people relying on the services provided. When this is the case, any changes to the service level will be felt by large group of people. When these
people collectively try to react to the changes they see, these people might together cause large amount of damage to the services of companies that need to handle the fallout.
This argumentation has nothing to do with java copyrights. It just questions the premise that sun/oracle would be free to stop supporting java any time they liked. This clearly isn't the case.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
I didn't say there wouldn't be any consequences, I just said they could do it if they wanted to. Ford decided to cancel almost all their cars in North America. In the same way, Oracle could cancel Java (unless there are contracts I'm not aware of).
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Oracle doesn
A useful timeline of the initial relationship between Sun/Oracle and Google can be found on pp. 6-14 oof the CAFC’s 2014 decision in Oracle v. Google. It also succinctly provides a description of the actions by Google that led to the claim and ultimate finding of copyright infringement.
[ link to this | view in chronology ]
Re: Re: Re: Re: Oracle doesn't understand their own business
Are we witnessing the death of java?
Who in their right mind would choose such a language these days.
[ link to this | view in chronology ]
Forget that silly SCOTUS, Masnick's opinion is all that matters.
[ link to this | view in chronology ]
Electrical sockets and water faucets
APIs are no more software than electrical sockets are electricity, or water faucets are water.
Just because it's called a "software API" doesn't mean it's made out of software.
Will somebody please explain this to the court?
How do I file a amicus curiae brief on this?
[ link to this | view in chronology ]
FAQ How to friend SCOTUS [was Re: Electrical...]
“How to friend SCOTUS” is a frequently asked question (FAQ).
Unfortunately, most of the FAQ-level answers which are readily available on the 'net seem to be pitched towards attorneys. Accordingly, the best answer to this FAQ for regular, non-lawyer folks seems to be “go get an attorney.”
The SCOTUS interface is not user-friendly for non-privileged users.
[ link to this | view in chronology ]
Re: FAQ How to friend SCOTUS [was Re: Electrical...]
Who owns the scotus api ?
[ link to this | view in chronology ]
Re: Re: FAQ How to friend SCOTUS [was Re: Electrical...]
Is the question, “Who pwns the scotus api ?” ?
Perhaps maybe someone somewhere knows some |-|4|<0rz.
[ link to this | view in chronology ]
Re: Re: FAQ How to friend SCOTUS [was Re: Electrical...]
That would be the Caledonians.
[ link to this | view in chronology ]
Re: Re: FAQ How to friend SCOTUS [was Re: Electrical...]
"Who owns the scotus api?"
The RNC.
[ link to this | view in chronology ]
The U.S. must take Monroe Doctrine now.
Allahu Akbar!
The U.S. must take Monroe Doctrine now.
The U.S. must withdraw American Forces from all Foreign Countries now.
Stop America's doing its all wars now!
The U.S. must return to the gold standard now!
The U.S. must adopt the gold standard again now!
The U.S. must decrease its military-budget to 100-billion-dollar per year now.
Or, the U.S. must decrease its military-budget to 1% of its GDP now.
I love American99% and the U.S.
Germany and Japan must loosen Germany's and Japan's monetary policies now!
Germany and Japan must stimulate Germany's and Japan's domestic demands now!
Japan and Germany must issue a lot of construction bond now!
Japan and Germany must reduce Germany's and Japan's taxes now!
The U.S. must tighten its monetary policy now!
As a result, Dollar value will rise!
The U.S. will have trade surplus!
Japan and Germany are evil empires.
Islamists' true enemies are Japan, Germany, FRB, Top1%, Wall Street, American Military Industry and DOD!
Japan is the country which has been promoting Globalization!!!
Allahu Akbar!
American Revolutionary War!
We American 99% have the 2nd amendment!
American Revolutionary War!
Japan's Ministry of Economy, Trade and Industry (METI) and Japanese-bureaucrats are the main largest promoters of FTA.
Wall-Street, American-top1%, American-Military-Industry are colluding with Japan and Japan's Ministry of Economy, Trade and Industry (METI).
US DOD, Japan and Germany are enemies of American99%.
US DOD, Japan and Germany are enemies of mankind.
[ link to this | view in chronology ]
Re: The U.S. must take Monroe Doctrine now.
Looks like you’re having a stroke bro. I’d say call 911 but the damage has already been done.
[ link to this | view in chronology ]
API analogies
API stands for "Application Programming Interface".
The Java math classes are a good way to explain what a Java API is: it's a collection of names of functions (also known as methods), such as sin, cos, tan, including how to call those functions (function call signatures, specifying the objects involved which in this case are numeric types), as well as constants like pi.
The crucial thing is an API is those lines which specify only the interface. Those lines do not tell anyone how to implement any of these functions. They only list the input and output of each function, plus any constants you might need to use them. The purpose of the API is to act as a contract which tells software how to interact with a piece of software.
One analogy to an API might be the shape of an electrical socket. This specifies what can plugged in, but does not specify how the generator makes electricty, and does not specify how the appliance uses that electricity. These interfaces are standard so many devices can interact safely, and people can choose what they plug together freely. Like an API, an electrical socket is merely an agreement about how things will connect.
Another analogy is that an API is like a menu in a restaurant. It lists the things you can choose, but doesn't specify the exact recipe that will be used to fulfill your order. Like an API, a menu lists certain things but leaves the implementation up to the creators behind the scenes.
Another analogy is that an API is like the steering wheel and dashboard in a car. Many cars can share a similar appearance of their controls, so that drivers can use many cars. This is a feature. Like an API, the design of a car's controls is used to interact with a machine, but on its own it is not the machine, it is merely the way to control that machine.
Allowing copyright on electrical socket design would not promote safety or interoperability. Allowing copyright on menus would not help people order food and would not help restaurants clearly specify what was on offer. Allowing copyright on dashboards would not help people learn or use cars. Allowing copyright on APIs would not improve the safety, security, or interoperability of software.
[ link to this | view in chronology ]
Interesting how many here are self-professed experts about APIs. What is particularly interesting is that nowhere have any of them indicated that they have reviewed and are intimately familiar with the specific APIs at issue in this lawsuit. You would think that surely someone wanting to weigh in on this matter would try and secure a copy of the contested work(s) that by law had to be registered with the Copyright Office, with copies being filed with the application for registration, before the lawsuit was even filed.
[ link to this | view in chronology ]
Re: secure a copy of the contested work(s)
There is still plenty of space available below here for those details to be supplied to assist this conversation.
The floor is yours. We are happy for you to furnish the room.
[ link to this | view in chronology ]
Re: Re: secure a copy of the contested work(s)
I am not one of those waxing poetic on APIs. Seems to me it is incumbent upon them to secure and review the actual APIs at issue if they want to speak with any actual authority. Until then their opinions are missing an important element...knowledge of the actual facts.
[ link to this | view in chronology ]
Re: Re: Re: secure a copy of the contested work(s)
I looked and did not find any claims of expert in the above comments, maybe I need new glasses.
[ link to this | view in chronology ]
Re:
Install Java and a development environment for it, and you can browse the APIs at your leisure.
The API is not the implementation, i.e. Java Swing API defines the a GUI for Java programs, and has to be implemented differently on every supported operating system. Indeed in porting Java to a new OS requires implementing various APIs so that Java programs see the windowing system, file system, networking etc. through the same set of functions despite difference in operating system implementation details.
[ link to this | view in chronology ]
Re:
Interesting how many here are self-professed experts about APIs. What is particularly interesting is that nowhere have any of them indicated that they have reviewed and are intimately familiar with the specific APIs at issue in this lawsuit.
What makes you say that? In my case, you're assumption is incorrect. I am familiar with the API in question -- as was Judge Alsup who found it non-copyrightable.
Beyond that, though, the rest of your comment is nonsense meant to confuse and distort. One need not read the entirety of the phone book in Feist to understand that phone numbers (even made up ones) are not copyright-eligible. Yet, I imagine that you were sitting on the sidelines whining that no one had read the entire phone book?
[ link to this | view in chronology ]
Re: Re:
Perhaps you should have jumped in and shared your intimate knowledge instead of sitting by the sidelines while persons obviously not familiar with the APIs argued with, and sometimes insulted, each other.
[ link to this | view in chronology ]
Tero Pulkinnen losing his shit in 3, 2, 1...
[ link to this | view in chronology ]
Re:
you actually browsed to my web page, examined it far enough to see the copyright notice? Good job. Next time you can try the tool too.
[ link to this | view in chronology ]
Re: Re:
Hook, line, and fucking sinker.
I browsed your webpage to know that nobody would pay you ad space to let it on London buses.
[ link to this | view in chronology ]
Re: Re: Re:
So your refusal to even look at my API is based on the fact that it isn't yet the most popular project on the planet? After this refusal, do you wonder that google needs to do illegal copyright infringement actions to get past this block? If they need the "this is the most popular programming language and environment on the planet" -bit to get past your refusal to look at the project?
If you keep refusing projects based on bullshit rules without even looking at the quality and performance of the project, do you really wonder when companies that absolutely must get to your sphere, are doing illegal actions to get it done?
[ link to this | view in chronology ]
Re: Re: Re: Re:
So far, what you write on this site is a reason not to use your software, especially as Blender has a well established development team behind it, and they listen to their users.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
This proves my point. Simply being available for customer service on this site makes you refuse the software. This proves the "bullshit" part, i.e. your reasons
to refuse finished and working software is based on something that takes heavy actions to overcome. Basically you're requiring software authors to do illegal actions to get past your biases.
Correct action is NOT to make the action legal by allowing copying of api definitions. Proper action that resolves this problem is for large sections of end users and programmers to update their criteria of how they choose to use software.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
Formal and informal standards, which include APIs and some menus, like file menus for a reason. They make software much more useable because the applications use a standard language. If you want to use obscure names for standard operations because you think you need unique names, do not be surprised when people decide not to learn your invented language.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re:
They're by definition not standard operations, because cloning the existing operations would be copyright infringements.
Instead, the operations are completely unique concepts. If one of the operations are available in other environments, the combined api is not, i.e. if other environments decide to implement the same operations, then it's just one label that is equivalent. Not all 500 of them. And even if you scramble the order of the api definitions, you wont find the same concepts available in other environments.
This "unique concepts" is what copyright law assumes that authors will do. They don't care about external interfaces, but the internal concepts for all different software systems need to be unique.
Note that there still exists some commonality between the software systems. Many of the projects use opengl which provides some commonality between projects. But if the software is properly developed, it implements completely unique concepts which are not available anywhere else.
Basically if you make a feature list of your software, that feature list need to be completely unique, not found anywhere else in the world.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re:
Basically if you make a feature list of your software, that feature list need to be completely unique
So your product makes 3D images? I'm sorry, that feature already exists in commercial software. Guess that makes your product illegal!
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re:
Feature list o any significant sotware includes more than one item.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
here's example of what a feature like might look like:
http://tpgames.org/Feature_list.txt
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
And I've seen all those items before on other imaging software.
Your product is illegal, fam.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
Good luck with your lawsuit against the author of that drivel.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
You insisted all the features of your software are unique.
That claim has been proven otherwise. Really, the biggest cost this means for me is I don't use the software so pathetically supported you think two London buses is all it takes to catapult yourself into software superstardom.
You could always try and sue.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
Your proof fails for the following reasons:
1) types called ML, P or BM are not available in other works
2) the external interface of modules in my software are based on types mentioned in (1)
3) these types in (1) limit the allowed implementation code in compile time
Thus both the api definitions and the implementation code is completely unique.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re:
Pray tell, how do you do 3d modelling without being able to create squares,cubes, cylinders etc, ; allowing them to moved into position, rotated and scaled referencing a 3 axis coordinate system and combined with the boolean operation of union, difference and intersection. Those are all part of the expected feature list of 3d software aimed at creating art, along with the mesh based operations for sculpting models.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re:
You're obviously allowed to listen your customer demands. If tthey all demand the same stuff, of course it's allowed to implement them. But when you do your market research, every customer will also give different set of important features. Their requests are not going to be the same, recardless of how you do your market research.
You market research just isn't allowed to be examining competitor products and cloning them.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re:
"They're by definition not standard operations, because cloning the existing operations would be copyright infringements."
You mean operations like "open", "close", "read", "write", "print" are not standard commands users would want to do no matter what software they were using? Do you own stock in a company that sells thesaurus?
Can you imagine if they demanded every typewriter used a different keyboard layout ... (because intellectual property of course).
No one would learn to type or they would only use one brand, but this most definitely promotes the useful arts and sciences now doesn't it?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re:
We obviously didn't use those operations or any other common menu structures.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
And that is a good reason for people to avoid your software, that is they manage to navigate your site to discover what you are offering.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
And the alternative is some software that does copyright infringement of the user interface design?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
Where are the lawsuits alleging infringement over standard menus? Indeed such menus are promulgated as part of standards for a programmers targetting a platform to follow. Even Apple failed to establish copyright over the concepts of a WIMP interface, (which they stole from Xerox).\
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
The Kazaa lawsuit, i.e. MGM Studios, Inc. v. Grokster, Ltd. had pirated elements visible in the user interface of their p2p software.
Similar issues in Metallica, et al. v. Napster, Inc.
also A&M Records, Inc. v. Napster, Inc.
All these are essentially displaying menu items where the underlying content is copyright infringement.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
I see that you use the maximalist view of infringement, where the slightest association with infringement is itself infringement.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
That view is needed whenever you try to create a system that needs to be legal for end users to use.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re:
They already do this. While they don't scramble the order of the keys, the exact millimeter dimensions of the keys and location of each key in the keypad are highly confidental secrets of the keyboard manufacturers, and the exact dimensions of the keypads must not match in competing keyboards. Similarly the companies are competing who can create a keyboard where the mechanism is accurate and lasts long time.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
Highly confidential secrets that anyone who cared to know could measure?
Citation needed. But not expected.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
Yeah, but this kind of reverse engineering of competitor products is illegal.
This is the main reason why cheap chinese knockoffs of original products are being confiscated at the country borders etc.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
Nope.
'Reverse engineering has traditionally been a legal method of acquiring trade secrets under certain conditions. The product must be acquired through “fair and honest means.” Trade secrets cannot be protected through these basic purchasing means. An example of this is buying a product on the open market. The Restatement of Unfair Competition states that “The owner of a trade secret does not have an exclusive right to possession or use of the secret information. Protection is available only against a wrongful acquisition, use, or disclosure of the trade secret.”'
https://ghbintellect.com/is-reverse-engineering-legal/
"It’s perfectly legal for your competitors to reverse-engineer your product in order to copy it. The minute an unpatented product is sold in the marketplace, it is no longer considered a trade secret. "
https://www.asme.org/topics-resources/content/trade-secrets-101
"A lock purchaser's own reverse-engineering of his own lock, and subsequent publication of the serial number-key code correlation, is an example of the independent invention and reverse engineering expressly allowed by trade secret doctrine."
https://casetext.com/case/chicago-lock-co-v-fanberg
No it isn't, because 1) reverse engineering is perfectly legal and 2) even if it weren't, there's no way customs officials could tell by looking that a knock off was created by reverse engineering. A much more likely reason for confiscation is trademark violation: trying to pass off a fake as the real thing.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
Obviously the crooks will put a custom label to the product while it's being imported to the country, and then change the label before it is sold to customer expecting the real thing. The only way customs official knows it's being passed as the real thing is to compare the designs and check if there's enough copied details to fool average customer. If it fools average customer of the origin of the product, then it's clear sign that illegal reverse engineering practises was used.
I can remember (from news tidbits) two separate instances. One was curtains where the topic was copied using carbon copy from a book that contained photos of paintings.
another instance was nike's shoes where they ordered similar looking striped shoes from chinese manufacturer and sold it without mentioning nike's trademarks, but similarity anyway made it illegal.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
I guess you decided to just ignore all the references I provided, including the US Supreme Court, indicating that reverse engineering is perfectly legal in the US?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
You're supposed to use cases from all around the world, not just in your tiny bubble called USA.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
This is a US blog, focusing on US issues, with a story about a lawsuit between two US companies in a US court. If you want to discuss laws in some other country, go find a story about that. Also nice try at deflecting but you fail.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
An when you put content to the web, you need to follow laws of all the countries where it is available.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
Wrong again. You need to follow laws where you have some kind of presence - such as employees or servers. I assure you Techdirt does not and does not need to follow the laws of places such as Turkey or Thailand.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re:
Oh, and not only wrong, but yet another attempt to deflect or distract since it has nothing to do with your (also wrong) claims about intellectual property.
[ link to this | view in chronology ]
Re: Re: Re: Re:
So your refusal to even look at my API is based on the fact that it isn't yet the most popular project on the planet?
It's based on the fact that I'm not in the industry where 3D modeling, animation, or game engines would be remotely relevant to my current work.
If you Open Source a men's toilet no amount of government legislation will let you force women to start using it.
Go pound sand for your mansion.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
"If you Open Source a men's toilet no amount of government legislation will let you force women to start using it."
A lack of adequate restroom facilities for women will.
[ link to this | view in chronology ]
An API is a compendium of importable namespace.
when you say:
#include "Foo"
use Foo ;
require module.foo ;
What you are doing is bringing a predefined set of symbols into the memory where the current piece of code is running. In other words, combining two namespaces. From a physics standpoint, a "namespace" is just a descriptor of the unique piece of entropy where some information exists. All intellectual property can therefore be regarded as having a "namespace", in that the ability to evaluate it at all dictates that some entropy exists.
The question that should follow is: "is a namespace a protectable thing in intellectual property law?". Well, it isn't just one namespace, but it is a "compendium" of namespaces. Compendiums are copyrightable.
The next question should be: "are namespaces reservable for exclusive use in intellectual property law". And the answer to that is: "Yes", trademarks are namespaces. Trademarks are reservable for exclusive use.
The copyright office does a crap job of dealing with software. The USPTO is worse. There needs to be a place for independent programmers can preserve their rights in the intellectual property sphere. To date, neither the Copyright Office, or the USPTO provide a good system for doing that. Which is to say the law is now at least 40 years behind reality.
There needs to be a lawful recognition of software I.P. that makes sense both legally and in software. It doesn't exist. If Oracle wins, it compels the Copyright office to do something different. This is a good thing.
It will break backwards compatibility if Oracle wins. But a lot of that backwards compatibility out there is propping up bad architectures that need to go the way of the dodo bird. If Oracle wins there will be a mad dash for API namespace, like there was with .COM domain names. There will be a lot of stupidity, but there will also be some good to come out of it.
Consideration should be given to the fact that this case may all just a put-on, and Google is wailing "Don't throw me in that briar patch!". Both of these companies have massive back catalogs of software API's.
[ link to this | view in chronology ]
Re: An API is a compendium of importable namespace.
The worse thing to happen to software would be a massive expansion of copyright, as that would result in software islands, where if you use Windows, you cannot exchange data with Mac or Linux users. It would also mean that Microsoft can ensure they are the only company that can write windows programs, and charge whatever they want for continues use, as it would be impossible to migrate your files to a different platform..
[ link to this | view in chronology ]
Re: Re: An API is a compendium of importable namespace.
This is already the case. Your horror is the current reality. A default windows bmp file is very difficult to open and manipulate in linux/mac systems.
Executables are even worse. Windows executable works very badly in linux systems, you need to deal with whole another level of dll hell before you have any chance of running executables on different systems. Basically its so difficult that none of the users are willing to spend the time to make it happen.
[ link to this | view in chronology ]
Re: Re: Re: An API is a compendium of importable namespace.
What? bmp files are trivial to deal with in Linux (I have no experience with mac, though iOS can display them fine when I transfer). At least a couple of the most common distributions include bmp editing software by default, but there are plenty of programs you can install if you don't already have one.
Actually, just checked the editor Ubuntu includes, and it works on OS x and iOS as well, so macs also shouldn't have any problems.
[ link to this | view in chronology ]
Re: Re: Re: An API is a compendium of importable namespace.
"A default windows bmp file is very difficult to open and manipulate in linux/mac systems."
"Windows executable works very badly in linux systems"
[ link to this | view in chronology ]
Re: Re: An API is a compendium of importable namespace.
"if you use Windows, you cannot exchange data with Mac or Linux users"
This is not correct.
[ link to this | view in chronology ]
Re: Re: Re: An API is a compendium of importable namespace.
I've yet to witness "tp" make even a single factual statement when it comes to the subject of copyright.
[ link to this | view in chronology ]
Re: Re: Re: Re: An API is a compendium of importable namespace.
I responded to the ac
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: An API is a compendium of importable namespa
I meant to anyway
[ link to this | view in chronology ]
Re: Re: Re: Re: An API is a compendium of importable namespace.
He thinks the government is mandatorily obliged to furnish him with a mansion.
I've yet to witness Tero "Meshpage" Pulkinnen make even a single factual statement when it comes to anything.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: An API is a compendium of importable namespa
Oh, that's what "tp" stands for?
"Toilet Paper" seemed more fitting, given the quality (such as it is) of his deluded ranting.
[ link to this | view in chronology ]
Re: An API is a compendium of importable namespace.
"Compendiums are copyrightable"
Is a cookbook considered to be a compendium?
A cookbook is afforded copyright on the presentation of the recipes and not the contents of same. That is, you are not afforded copyright on the actual recipe where measurements, etc are provided.
Do you have additional info to add?
[ link to this | view in chronology ]
Re: Re: An API is a compendium of importable namespace.
An API is the presentation of the functions, not the functions. The whole point of an an API, is to provide a uniform interface that doesn't change as the underlying code changes.
When you say "black box" what you are talking about is the API. Indeed programmers use the world "publish" when they create an API. You "publish" an API so that users can use the code, without having to understand the underlying functions.
A cookbook might list cheese, but it doesn't tell you anything about making different kinds of cheeses. An API lists a function, but does not tell you how the underlying code is dispatched, which considering polymorphism, could be as many different ways as there are cheeses.
There is an interesting post on soylentnews.org about this that is getting some reasoned debate.
[ link to this | view in chronology ]
Re: Re: Re: An API is a compendium of importable namespace.
So, you did not answer the questions
[ link to this | view in chronology ]
Re: An API is a compendium of importable namespace.
"The next question should be: "are namespaces reservable for exclusive use in intellectual property law". And the answer to that is: "Yes", trademarks are namespaces. Trademarks are reservable for exclusive use. "
[ link to this | view in chronology ]
good analagy
suppose you have a friend named John who is good at math and you ask him to multiply 10 times 5 for you. Your friend is a bit weird and will only answer if you ask him in this form "please multiple first number by seconds number". if you forget to say please he will not answer, if you say what is firstnumber times second number he will not answer. only if you say exactly "please multiple first number by seconds number" will he respond with the correct answer. that question is the API.
There are my ways for your friend to determine the answer. he could for example do the calculation in his head. or he might get a paper and pencil and write out the steps. or he might type it into a calculator, or he my call his elementary school teach and ask for the answer. none of these things are part of the API.
now suppose Bill is also good at math and you would like his help instead because well you just don't like John that much. what oracle is saying is that you are not allowed to ask Bill "please multiple first number by seconds number".
[ link to this | view in chronology ]