Supreme Court Asks White House To Weigh In On Copyrightability Of APIs
from the anyone-confident-that-this-white-house-understands-the-issue? dept
Back during an earlier round of the never-ending legal dispute between Oracle and Google concerning whether or not APIs can be covered by copyright the Supreme Court requested that the White House weigh in on its opinion -- leading then Solicitor General Donald Verrilli (formerly a top lawyer for the MPAA) to weigh in with what we argued was a painfully clueless brief. The underlying issue here, from the very beginning, revolves almost entirely around the simple point: do you actually understand what an API is? If you do -- and recognize that it's fundamentally different from executing software code -- then this is an easy case. An API is simply an instruction set -- a recipe of sorts -- for being able to interface with a particular program. And US copyright law is clear that copyright cannot apply to any "idea, procedure, process, system, method of operation, concept, principle, or discovery."
An API is easily covered by that designation, but because you have non-technical lawyers who can't understand the difference between software operating code (which is copyrightable) and an API (which is not) they argue that the two are virtually identical, and thus APIs should be covered by copyright. Tragically, that argument worked at the appeals court (it didn't work at the district court, where Judge Alsup already had some coding history and famously taught himself how to program in Java to better understand the facts of the case).
Now that the case is back on appeal to the Supreme Court, looking specifically at questions of fair use around the reuse of an API, the Supreme Court has (somewhat oddly) asked the White House to weigh in again. As part of its Monday orders it invited the White House to give its opinion on whether or not it should even hear the case (not yet on the actual merits of either side's case):
The Solicitor General is invited to file a brief in this case expressing the views of the United States.
Of course, there's a very different White House with a very different Solicitor General. Of course, I have no idea if the current Solicitor General's office knows anything about coding or knows why an API is not operating code, and it seems like a total crapshoot to expect the Solicitor General to have an informed opinion on this matter. So it's not entirely clear why the Supreme Court expects it will -- but now that it's asked, we should probably expect something from the White House on this issue. As has been noted in the past, when the Supreme Court does ask the Solicitor General to weigh in, it often has an impact on the case -- especially when the question is simply on whether or not the Supreme Court should hear the case in the first place. Given that, one hopes that the Solicitor General will support the petition to hear the case and revisit the CAFC's ongoing confusion over copyright law.
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: apis, copyright, interfaces, software, solicitor general, supreme court
Companies: google, oracle
Reader Comments
Subscribe: RSS
View by: Time | Thread
Here's hoping they can straighten this out and roll back bad copyright law. For a change.
[ link to this | view in chronology ]
If this goes the wrong way, I can see Microsoft and Apple licensing developers who develop programs for their systems, because they have to use the relevant API's. Net result those systems become closed off from free software.
[ link to this | view in chronology ]
Re:
Isn't what they do now, at least as far as the Xbox line of consoles and Apple's line of iEverything is concerned?
[ link to this | view in chronology ]
Re: Re:
Microsoft cuts out OSS support for device drivers too with the whole Driver Signing requirement where you have to pay Microsoft to put out a driver Windows will actually install. Doubly so for Secure Boot systems where you can't alter the kernel to allow unsigned drivers* without bricking the OS installation.
Most OSS projects can't afford to put out Microsoft's fee to do a Windows release of their driver. Of course this situation works out for Microsoft because broken hardware means greater chance of another OEM Windows license purchase. User has to buy replacement hardware, which means HW manufacturers have to pay again to develop drivers for their new HW. Which the manufacturer builds into the cost of the HW purchase. Sucks for the user because all it does is drive up the cost of computing, but works great for the industry forcing new purchases whenever Microsoft or the manufacturer decides to deprecate the old HW.
*: Technically there is a developer mode where windows can install a test-signing driver. (I.e. one signed during build by you.) But that requires rebuilding the driver yourself, creating a signing key, and enabling it on every boot. (Because Windows loves to disable the mode on reboot.)
[ link to this | view in chronology ]
Re: Re: Re:
Driver signing actually involves Microsoft doing some quality control work before signing a driver. I was thinking of application code, like LibreOffice etc, which rely on application Interfaces to Windows.
[ link to this | view in chronology ]
As the Trump regime wants to do whatever it can to ensure the few make as much money as possible whilst screwing over everyone else, the outcome of this, surely, is a foregone conclusion!
[ link to this | view in chronology ]
Re:
2020 is coming
[ link to this | view in chronology ]
Re:
Yeah, you are completely wrong, but go ahead, you do you.
[ link to this | view in chronology ]
Re: Re:
What was wrong about the post?
[ link to this | view in chronology ]
Never Underestimate the Venality of Shysters
I am dubious the Shyster in Chief will get it right, too much money in legal fees riding on the 'correct' interpretation.
[ link to this | view in chronology ]
Re: Never Underestimate the Venality of Shysters
There's no way Trump even knows what an API is. He won't be personally involved in preparing this brief. As the article notes, this is directed at the Solicitor General, Noel John Francisco.
I'm not aware of what background, if any, Francisco has in tech policy or copyright law. A look through his past cases and associations doesn't endear him to me, but that doesn't necessarily say anything about his views on this specific topic.
[ link to this | view in chronology ]
Re: Re: Never Underestimate the Venality of Shysters
If Fox News talks about an API,
Donald will probably tweet about an API.
lol, that would be funny
[ link to this | view in chronology ]
Why would they ask the Executive Branch (the supposed enforcers of the law) as opposed to the Legislative Branch who actually wrote the law and what their intentions were?
[ link to this | view in chronology ]
Re:
Now that's an excellent question.
[ link to this | view in chronology ]
Re: Re: Excellent answer to what you don't know, college boy:
Masnick doesn't understand why Court asks Administration instead of Legislature! SHEESH.
The Legislature has already acted to best of ability, now it's up Admin and Courts to try and figure out how can be applied. You don't ask the damn fools who created unclear law for MORE!
[ link to this | view in chronology ]
Re: Re: Re: Excellent answer to what you don't know, college boy
Hmm... so what's YOUR plan for having clear law made, if you take the legislature out of it?
[ link to this | view in chronology ]
Re: Re: Re: Re: Excellent answer to what you don't know, college
They have no plan other than setting the world on fire and watching it burn.
[ link to this | view in chronology ]
Re: Re: Re: Excellent answer to what you don't know, college boy
What makes you think the legislative branch wrote any part of any law? Seems they are just a rubber stamp to approve whatever the PAC tells to.
[ link to this | view in chronology ]
Re: Re: Re: Excellent answer to what you don't know, college boy
Aaaand you missed what is actually happening as usual..
The USC is asking the administration if the court should hear Googles motion to dismiss Oracles infringement suit.
If the law is unclear, who are the greater fools - those who wrote the law or those who made it law?
[ link to this | view in chronology ]
Re: Re: Re: Re: Excellent answer to what you don't know, college
Why does the judicial branch of government need to ask permission from the executive branch of government before they do their jobs?
[ link to this | view in chronology ]
Re: Re: Re: Excellent answer to what you don't know, college boy
Hey blue, horizontal rules are on sale today!
We're overstocked! They need to go, go, go!
[ link to this | view in chronology ]
Re: Re:
Legal representation of the USG before the Supreme Court is through the Office of the Solicitor General, which in turn is a part of the Department of Justice, an executive agency.
[ link to this | view in chronology ]
Re: Re: Re:
I thought this case was between Oracle and Google.
[ link to this | view in chronology ]
Re:
Because getting Congress to agree on anything is impossible.
[ link to this | view in chronology ]
“Reads bio”
Survey says: what’s your price oracle.
Company you keep.
[ link to this | view in chronology ]
Might I suggest sending him and his staff and solicitor letters and having his someone read them telling him and them that they make money by being as widespread as possible and will personally benefit them and his election?
Plus he can’t read so we have the advantage.
[ link to this | view in chronology ]
No, if MM understood what API is, he'd support copyright.
Recipe. Sheesh. Clearly word chosen from vague grasp, and then hedged "of sorts".
API is THE center of creativity, just doesn't look impressive to masnicks who've never actually written code. (That means more than HTML, which is not much more than the frequently used term "script".)
All access to whatever functions is through API, from OS calls to custom in a program. Programs are designed as re-usable general purpose modules (often to excess, but another topic). You almost cannot have (any more) a program so simple that it's not best organized as sub-routines.
Google's intent was to make use of all Oracle's (Sun's) code without having to pay for it, when easily could have and avoided years of litigation! -- So, its own stupidity is a second reason I want 'em to PAY until hurts.
But of course Masnick is STILL rabid on this: it might cost Google (vastly more NOW than if had licensed), AND he always views any licensing as unwarranted draconian control by way of mythical "intellectual property".
In fact, licensing is best practical way to ensure consistent streamlined design in software, not the "throw in every idea" school, besides that those who put in the work and money to think through and test the design are due rewards.
[ link to this | view in chronology ]
Re: No, if MM understood what API is, he'd support copyright.
And where did you get your Comp Sci degree?
[ link to this | view in chronology ]
Re: Re: No, if MM understood what API is, he'd support copyright
Doesn't have one, or so it seems.
[ link to this | view in chronology ]
Re: Re: No, if MM understood what API is, he'd support copyright
He has no idea what he's talking about. Any real developer knows the APIs aren't the code.
[ link to this | view in chronology ]
Re: Re: Re: No, if MM understood what API is, he'd support copyr
Any real legal expert knows that copyright applies all the text content, including the code, the api or comments. You can't twist the scope of copyright simply because you think some text content is more worthy of protection than some other piece.
[ link to this | view in chronology ]
Re: Re: Re: Re: No, if MM understood what API is, he'd support c
Literally explained in this article why that is completely false. There are lots of things that are completely uncopyrightable and examples have already been given both in the article and in the comments. Like it or not some text content IS more worth of protection than some other pieces.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: No, if MM understood what API is, he'd suppo
The copyrightable subject matter doesnt even need to be text content. Copyright extends to alot further than simply text content when art installations, dance moves, performances, music, songs all receive copyright.
uncopyrigghtable stuff tends to be useless stuff that cannot be described by a piece of text.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: No, if MM understood what API is, he'd s
Facts aren’t copyrightable and can be described by a piece of text.
Scenes a faire aren’t copyrightable and, when discussing books, can be described by a piece of text.
Ideas aren’t copyrightable (only particular expressions of those ideas are) and can often be described by a piece of text.
Languages and definitions aren’t copyrightable and can be described by a piece of text.
None of these things are generally “useless stuff” either; in particular, scenes a faire is about stuff so integral to expressing an idea that you essentially can’t express that idea without them (or at least they are expected when doing so), which is why they can’t be copyrighted.
For reasons why an API shouldn’t be copyrightable, I refer you back to the article, as you have yet to actually address those arguments.
[ link to this | view in chronology ]
Re: No, if MM understood what API is, he'd support copyright.
Tell me, why hasn't Microsoft shutdown the WINE project years ago? WINE is basically reverse engineering the Windows API and using it to create a run-time environment which allows you to execute Windows applications on non-windows operating systems?
[ link to this | view in chronology ]
Re: Re: No, if MM understood what API is, he'd support copyright
Copyright was designed so that authors can decide themselves when the copyright infringement what they see in the marketplace has gone too far and then decide to sue the people responsible. If they don't care, copyright has no value whatsoever. So it's up to the authors to enforce their copyrights, and some authors decide to not go after the people who violate their copyrights. Still copyright infrinngement is illegal, even if the authors do not care about sueing when they don't see it as profitable activity.
[ link to this | view in chronology ]
Re: Re: Re: No, if MM understood what API is, he'd support copyr
Another comment completely ignoring the point of the question or the realities of what copyright does and does not allow.
Perhaps it would help if you tried to answer why it is legally recognized that a recipe is not legally copyrightable? Maybe having to learn about that will help you learn why copyright isn't allowed to apply to everything anyone can create.
[ link to this | view in chronology ]
Re: No, if MM understood what API is, he'd support copyright.
Let me guess - you were and still are a fan of SCO
[ link to this | view in chronology ]
Re: Re: No, if MM understood what API is, he'd support copyright
The sco vs ibm saga had some troubling aspects. Like the fact that linux folks copy-pasted the api definitions of the unix header files. SCO vs IBM saga would be completely irrelevant without the claims of API copying by the linux programmers. All the nerds harassing sco managment wouldn't have happened if this api copying was properly implemented by the linux programmers.
[ link to this | view in chronology ]
Re: No, if MM understood what API is, he'd support copyright.
It's not. Anyone saying this has a very vague notion of what programming is.
So.. They took ALL the code... Hmm.. So API's contains ALL code now? Btw, did you know that Sun was actually cheering Google on? If you feel that Google should pay Oracle - have you ANY clue what would happen? I bet you don't, because you are so myopic in your views you don't see the repercussions for the things you advocate.
As I said, you don't understand the repercussions. Also, please provide citation for your statement about Mike's views on intellectual property (hint: you can't).
No, the best practical way to ensure good software design is to have good tools, architects, programmers, testers and a real understanding what the end goal is. Licensing only comes into the picture due to the technological and architectural choices you make which can affect the software design if you don't do your due diligence at the start.
[ link to this | view in chronology ]
Re: No, if MM understood what API is, he'd support copyright.
Software engineer here. Two comp. sci. degrees. 30 years experience. You are full of shit. An API is no more creative than a phone book. Certainly NOT as creative as the actual code that does all the work.
[ link to this | view in chronology ]
Re: No, if MM understood what API is, he'd support copyright.
Obviously you've never written code either. Perhaps you should stop embarassing yourself and talking about things you don't know.
[ link to this | view in chronology ]
So how about putting APIs in terms they CAN understand?
Wall sockets and utility power standards: APIs for connecting powered devices to the power grid.
Airlock connection standards: APIs for connecting two space vehicles together.
[ link to this | view in chronology ]
Re: So how about putting APIs in terms they CAN understand?
I have to license APIs for every wall socket?
[ link to this | view in chronology ]
I wholeheartedly agree. "Recipe" is just a terrible analogy; doesn't fit at all and may it never be spoken again.
This statement is absurd. An API is just a function prototype. I know some programmers have trouble naming things, but it's not really that hard, and it's the only place for any creativity in a function prototype.
Do you think the guy who came up with the name "open" for getting a file descriptor was being creative with the function name?
The creativity is in the guts of the code.
Take a look at list.h's implementation and tell me whether the CENTER of CREATION was naming a function (i.e., an API) "list_entry" or the pointer tricks used in "container_of".
https://github.com/torvalds/linux/blob/master/include/linux/list.h
[ link to this | view in chronology ]
Re:
This was supposed to be a reply to OG Offit.
[ link to this | view in chronology ]
Re: Re:
I doubt OG Offit is a gangster, and I doubt Offit knows what a file descriptor is or what is used for.
Imagine a world where everyone had to create a unique API to access the same function. It would be as if they all were speaking a unique language. Interoperability would vanish as civilization crumbles. But I feel fine.
[ link to this | view in chronology ]
I don't know ...
He looks kinda dodgy. His bios reads as mostly a lawyer type with no real world experience outside of government bribes and the usual tricks of despots.
Since he is installed in this administration this one suspects that the bribes experience is the most pertinent.
[ link to this | view in chronology ]
Re: I don't know ...
Bribes are the most pertinent thing for government work.
[ link to this | view in chronology ]
API is interface, not implementation
The distinction between interface (API) and implementation is vital to understand.
An API is an interface. An API merely specifies how to connect to an implementation. It's the implementation that actually does the work.
Consider a wall socket. The shape of the wall socket is the interface. It's not the power generator. It doesn't do the work. It's just a standard shape so various appliances can use it. That's essentially what an API is.
Consider an API for discovering the current date. Here's one I've just created (in the C language):
void get_date(int year, int month, int *day);
That API specifies a way to call a function and get back some data, in this case three integers specifying the year, month, and day numbers. Note that the API doesn't specify how the data is obtained or calculated (that would be the implementation's job behind the scenes). The API is just an agreed interface that some calling code could use to get the data. It's akin to the shape of a particular wall socket.
By comparison, the implementation is the guts of the code that resides behind the scenes. It does all the heavy lifting. It might do things like obtain from the hardware the number of seconds since January 1 1970, compute when leap years have happened, divide the number of seconds by 60 a few times and by 24 and so, to finally work out the current year, month, and day. You can see that's the real work the function does. The API is just the simple one-liner that you can use to call on it. Another anology is that the API is the hyperlink, but the implementation is the actual web page.
Suppose Oracle has copyright on the abovementioned date-getting API (I am supposing for the purpose of argument that copyright in API is possible, which is debatable, and which I think does not exist in Europe for example). Such a copyright would cover all possible implementations that could exist behind the scenes, because the copyright says you can't even use that API without getting permission from Oracle. That would preclude anyone making a different implementation without calling it something else.
In practice this means when Apple goes to implement such a function, their API must be different, e.g.
void getDate(int &day, int &month, int &year);
This leads Google to make their own API:
struct Date {int year; int month; int day; } DateGetter();
And so on and so forth. Mindless variation just to satisfy a copyright ruling. There's no value in such a copyright on API for the public, only for a specific company. But actually, it just means everyone rolls their own APIs all the time, and there are no standards, and that'll just lead to more security bugs.
[ link to this | view in chronology ]
Re: API is interface, not implementation
I understand what you are trying to argue.
You have provided a very technical implemention of a functional definition.
You have not provided an API.
Is it true that an API is merely a collection of very many such functional definitions? (a curated list of your favourite recipes) Might that length have an impact on copyright law? (substantial novelty)
Importantly, in coming up with your example "line of C code" you have made a handful of (small) creative choices. It is quite impressive work to a novice. A worse coder may have made different choices. Do you think that those creative and clever choices might (perhaps after many iterations) one day add up to an impressive mountain of work? Let's say we are now at the day when very, very many such lines of code have been "invented".
Because I think, that the courts may think, that any such a simple example as I have seen is (or at least arguably is) making little mole hill out of a huge mountain.
[ link to this | view in chronology ]
Re: Re: API is interface, not implementation
It's a valid question, and I think in the case of Oracle the appeals court did indeed buy into the argument that a large collection and arrangement of these small APIs did amount to something creative therefore deserving of copyright protection.
I'm not trying here to argue there is no creativity in such work. There's some creativity in designing a power socket, for example. Rather, I'd say the interoperative purpose of specifying such machine interfaces means that we as a society should not allow copyrights to be placed on them, because there is an overriding value to the public in allowing multiple implementations and in allowing interoperability.
Software is often akin to a machine in that is has functions and must connect to other pieces of hardware and software to operate. Software is a functional piece of many machines. Sometimes it is also artistic or entertaining in nature, but for now let us just consider the more machine-oriented uses of software. Things like a database being a tool to store and retrieve data, or an operating system or hardware driver or a programming language that allows your computer or phone to run. This kind of software clearly must move data around, and operates rather like a machine.
An electrical analogy may be useful. A single function's interface is an API, and I've used the analogy of a single power socket. There's a little creativity there. A collection of function interfaces is also an API, just a larger one. Think of a collection of mathematical operations for doing trigonometry, e.g. sine, cosine, etc. The electrical analogy might be a power board with many sockets arranged with switches and a power light. You might say there's more creativity there, because there's an arrangement of smaller APIs into a single, bigger API. The question is at what point should we say "this collection now meets some criteria that mean it now can be owned by only a single company, rather than being available to all?"
As an engineer, I'd like a clear line to be drawn so I know where that line is. I don't think the law can or will supply such a clear line. That creates risk for companies and individuals in implementing any software. I think that lack of clarity is to the net detriment of society.
I think there is a clear line that can be drawn in many cases between API interface, and implementation. The API is the name of the function (with some input/output specification), whereas the implementation does the work. It's long been accepted in the industry that the implementation can be subject to copyright, but the present dispute is about the widely held belief that APIs were not copyrightable, when now it seems some US courts may hold otherwise. Google acted on that widely held belief and got burned, but this is surprising to many in the industry. It upends entire industry wide practices such as clean room reverse engineering, for no clear benefit. Reverse engineering allows companies like AMD for example to use the same silicon chip instruction sets, so as to compete with the likes of Intel and NVidia (which promotes competition via different implementations).
Here's a car analogy: An individual API might be the shape of a steering wheel. Another small API might be a gear change stick. Another might be a pedal for the brake, and another pedal for the gas. Put these things together and you have a larger API. You might say that's more creative. Let's say Benz invented that. Allowing copyright on that larger collection would force other car manufacturers to do one of two things: either pay Benz a licensing fee (perhaps until the end of time) to use the same arrangement, or else each car manufacturer must invent their own unique arrangement of controls, and possibly even their own kind of controls too (think hexagonal steering wheels or joysticks in some car models). I argue both outcomes are not useful in the long run to society, and we should curb copyright at the interface.
[ link to this | view in chronology ]
Re: Re: Re: API is interface, not implementation
Some things, even things that contain "creative work", are not copyrightable for one simple reason: Accessibility. If everything constructed of alphanumeric characters and punctuation were copyrightable (and copyrighted) interoperability and communication in general would nearly cease to exist. Even if something can be described as "creative" that's not the only test for whether it should be copyrightable.
[ link to this | view in chronology ]
Re: Re: Re: Re: API is interface, not implementation
People who designed copyright 300 years ago didn't have this use case in mind when they extended copyright to apply to all the text content. Their only problem was people with easy printing press machines who failed to distribute the wealth gained while printing the books to the actual authors of the text content. While the interoperability and communication aspects are interesting, they cannot change the scope of the copyright analysis. Further, google's position is that they want just appearance of interoperability, but when oracle wants them to actually get (old) java applications to work, it's too much work to implement. So google isn't really interested in this aspect or at least they're not willling to do it properly.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: API is interface, not implementation
when they extended copyright to apply to all the text content
They didn't.
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: API is interface, not implementation
The brief has these words: "Computer code also fits comfortably within the statutory definition of "literary work" because it is a work "expressed in words, numbers or other verbal or numerical symbols or indicia".
How do you explain that these "litterary works" are receiving copyright protection and they seem to define literary works with accurate definition like that?
[ link to this | view in chronology ]
Re: Re: Re: API is interface, not implementation
There is no such thing as "being available to all". There just exist some authors who decide not to sue. Some standardisation organisations are willing to license their software modules to other companies in such way that everyone can use the same set of interfaces. Oracle is such standardisation organisation, but they just placed some strict requiremennts when the platform implemntation actually fullfills the required level of interoperability. Oracle decided not to license their software to google, after hearing the level of interoperability they're going to archive.
[ link to this | view in chronology ]
Re: Re: Re: Re: API is interface, not implementation
There is no such thing as "being available to all"
Other than the natural state of all knowledge and power to create, which is the sum total of what copyright is blocking.
[ link to this | view in chronology ]
Re: Re: API is interface, not implementation
I'll give this a try without analogies.
An API is a function prototype, i.e., function "declaration" (not "definition", these are terms of art and there is a big distinction between the two).
A function prototype is just a variable name for a pointer to an address in memory. The instructions at that address comprise the implementation.
I can see how implementation can be copyrighted, but I don't see a path to copyrighting the name of a variable nor a memory address.
[ link to this | view in chronology ]
Re: Re: Re: API is interface, not implementation
This is similar to how a phone book gets copyright protection. Single name just chooses one person out of thousands other names, and when you have enough of those names in a list, there's enough choices that the author of the material made to receive copyright. It's these selection of words from the whole dictionary and creation of a book containing the words that originally received copyright protection. More generally, it's the effort spent on the selection process that receives copyright protection. Note that the effort isn't any effort whatsoever, but only the effort spent on the word selection process.
Selecting single name isn't enough for copyright protection, you need to have at least 15 words. But given that oracle's java api had tthousands of these names, it is guaranteed that the work received copyright protection.
[ link to this | view in chronology ]
Re: Re: Re: Re: API is interface, not implementation
This is similar to how a phone book gets copyright protection
Ok, seriously. Go look things up before you just spout off with your assumptions. Phone books DON'T get copyright protection for the very reasons he listed. If this is where your understanding of copyright is you need to go reeducate yourself about it.
See Feist Publications, Inc., v. Rural Telephone Service Co.
[ link to this | view in chronology ]
Re: Re: API is interface, not implementation
I'll reply to this statement more directly:
Although I have a different idea of what an API is (since I believe the term is wide enough to encompass even a single function declaration), the important point in the above quote is the term "curated list", in particular the word "list" (I would actually use the term "index" or "table of contents").
All analogies can be fraught, but let's go with a recipe book analogy, in order to examine why the term "recipe" is incorrect. A single recipe is a procedure for making something happen. It's like an algorithm in computer terms. A recipe is thus very much like an implementation. However, the name of the recipe is its API, its functional declaration. Just as "Salmon Salad" give you an idea of what the recipe might entail without telling you the details (the specific recipe), so too does the function name CalculateCircumference reveal something about what that software function might do, without really telling you the implementation.
If we're talking about a "curated list of recipes", that is a larger API that is akin to a recipe book's table of contents. You might say a recipe book is large and inventive and is deserving of copyright, and fair enough, but what of its table of contents? Does having all the fish recipes listed before the poultry with the desserts at the end of the book constitute sufficient novelty to be deserving of copyright protection? What of having "Salmon Salad" right before "Crab Soup"? Should a cookbook author be able to sue any other cook who writes a cookbook having identically named recipes in the same order (despite the actual recipes being different) just because the table of contents can be copyrighted? Because to me that's what the Oracle ruling seems to boil down to (please excuse the pun).
The table of contents of a recipe book is like the API, but the implementation is the actual recipes. Google took the Sun Java APIs (freely given away by Sun) and implemented their own recipes behind the scenes. But for the sake of interoperability, they used the same recipe names, in the same order. They copied the table of contents, but invented their own recipes within their recipe book.
The question of whether the length of a list should impact the copyrightability seems to me to be the wrong question to ask. There is a difference in copyright law between the idea and the expression of the idea. In theory, copyright should cover only an expression, not the idea itself. An API is, like a table of contents in a recipe book, merely a collection of ideas albeit in a specific order, whereas it is the implementations, the recipes, that are the expressions of those ideas. This distinction between API and implementation mirrors the distinction made in copyright law between idea and expression, so it seems to me APIs shouldn't be copyrightable any more than ideas should be, and thus that's the correct place to draw the line between what is and isn't copyrightable: between the interface(API) and the implementation.
[ link to this | view in chronology ]
Re: Re: Re: API is interface, not implementation
Table of contents in recipe book receives copyright protection when the ideas are being expressed as text. i.e. when the selection of glyphs in your printing press has been decided by someone else than yourself.
[ link to this | view in chronology ]
Re: Re: Re: Re: API is interface, not implementation
You clearly don’t understand copyright. Not everything expressed in a text format is copyrightable. Facts, scenes a faire, quotes, generic ideas (rather than particular expressions of ideas), scientific laws, language, book titles (just the text, not the font or depiction of the title)… none of these are copyrightable.
[ link to this | view in chronology ]
Show us your working out please
Really easy? "An API is easily covered by that designation"
Please tell me which one is the API in this list: (copyright cannot apply to any...) idea? procedure? process? system? method of operation? concept? principle? or discovery?"
[ link to this | view in chronology ]
You Just Have to Use a Language They Understand
An API is a formalized agreement that says "if you give me x in a certain format, I will give you y in a certain format."
For government officials, you could explain it like this: "If Lobbyist gives you Campaign Contribution, you give Lobbyist Favorable Legislation."
Nobody wants that copyrighted, then they couldn't do it as freely anymore.
[ link to this | view in chronology ]
Re: You Just Have to Use a Language They Understand
I thought it would be more like the currency serial numbers must match to some predefined set of serial numbers or else the campaign contribution fails.
[ link to this | view in chronology ]
I think they would have a better case arguing that their comments deserve copyright.
[ link to this | view in chronology ]
All backed up...
Keep in mind that there are cases where SCOTUS asked for the SG's brief in October of 2018 that the SG still has not supplied said brief for...(going all the way back to Poarch Band of Creek Indians v. Wilkes
...so don't hold your breath waiting for the SG's opinion here. It could be 2020 or later before the SG gets around to supplying a brief to SCOTUS.
[ link to this | view in chronology ]