Computer Scientists, Legal Experts Explain To Supreme Court Why APIs Are Not Copyrightable

from the let's-try-this-again dept

Mon, Nov 10th 2014 3:39am — Mike Masnick

Back in May, the appeals court for the Federal Circuit (CAFC) enhanced its reputation of consistently getting basic patent law wrong by deciding to get copyright law wrong too, in declaring that APIs were copyrightable subject matter, in the Oracle v. Google lawsuit. As we explained at the time, the court appeared to make some rather serious fundamental errors, not understanding the difference between software and interfaces (and worse, totally misquoting some experts). Last month, Google asked the Supreme Court to review the case. On Friday, a bunch of interesting amicus briefs were filed, asking the Supreme Court to fix the CAFC's big mistakes.

Perhaps the most interesting was put together by the EFF, and was signed by 77 computer scientists, including many of the most well-known and most respected computer scientists around, including Hal Abelson, Brian Behlendorf, Ward Cunningham, Peter Deutsch, David Dill, Dave Farber, Ed Felten, Mitch Kapor, Alan Kay, Brian Kernighan, Guido van Rossum, Avi Rubin, Bruce Schneier and Bjarne Stroustrup among others. There are a lot more, obviously, but those were just a few of the names that stood out.

The key point made in the filing is that this upsets decades of what was considered a settled matter in computer science, while highlighting how much of computer history was built off of the recognition of non-copyrightable APIs, allowing for the creation of interoperable systems, much of which drove the early computer revolution. Here's the summary from the brief:

For decades, computer scientists have relied on the open nature of APIs to enable rapid innovation in computer technology. For decades, circuit courts have supported that reliance, concluding that Section 102(b) of the Copyright Act protects a programmer’s source code as creative expression, but does not cover the processes, systems, and methods of operation that code may employ to interface with other software. The district court correctly followed that precedent and rejected Oracle’s claim that the Java APIs could be copyrightable. Sadly, the Federal Circuit chose to split with the other circuits and reverse the district court. That decision upended decades of industry practice and threatens the basic principles upon which our technology sector was built.

Not surprisingly, the Federal Circuit’s decision has been harshly criticized. As many commentators have noted, if the Federal Circuit’s view had been accepted at the birth of modern computing, many important technologies would never have existed, and/or succeeded. For example, the widespread availability of diverse, cheap, and customizable personal computers owes its existence to the lack of copyright on the specification for IBM’s Basic Input/Output System (BIOS) for the PC. And open APIs were essential to many modern computing developments, including those of operating systems such as UNIX, programming languages such as “C,” the Internet’s network protocols, and cloud computing.

Today, open, uncopyrightable APIs continue to spur the creation and adoption of new technologies. When programmers can freely reimplement or reverse engineer an API without obtaining a costly license or risking a lawsuit, they can create compatible software that the interface’s original creator might never have envisioned or had the resources to develop. Moreover, compatible APIs help enable people to switch platforms and services freely, and to find software that meets their needs regardless of what browser or operating system they use. Without the compatibility enabled by the open nature of APIs, consumers could be forced to leave their data and programs behind when they switch to a new service.

The freedom to reimplement APIs also helps developers rescue “orphan” software or data—systems that are no longer supported by their creators. When a company stops supporting a computer platform or service, the ability to freely reimplement APIs protects the communities that rely on that software. Government entities and non-profi ts are especially susceptible to the orphan programs problem as they often cannot afford to upgrade and are left using legacy technologies for years or decades.

Next up, is a filing from CCIA written in part by Jonathan Band, which is noteworthy in part because Band co-wrote the book on copyright and interfaces (first published nearly 20 years ago), explaining how interfaces aren't copyrightable and why that simple fact was responsible for so much of the computer revolution. This filing similarly notes how much of history was driven by interoperability, but also digs deeper into what a mess it would be if the CAFC's view was determined to be correct:

If a company could exercise proprietary control over the interface specifications implemented by its products, that company could determine which products made by other firms – if any – would be compatible with its software. And should that company have a dominant position in a particular market, it could use its control over compatibility to expand its dominant position into adjacent markets. Moreover, such authority would extend the rights under copyright beyond what is necessary to protect the original expressive elements that have traditionally been offered protection under American copyright law, and it would override limitations on copyright crafted to protect the public good.

Such a broad monopoly would have serious implications for consumer welfare. In the absence of competition during the effective lifespan of the product, the first developer would have little incentive to develop more innovative and less costly products. These negative consequences would be compounded by the fact that the personal computer revolution and the emergence of the Internet have produced an overwhelming need for interconnection between different elements of computer systems. Prohibiting competitors from accessing de facto standard interface specifications would lock users into a particular operating system or network software environment, and would inhibit the transfer of data between users with different computing environments.... The Petition shows a host of real-world problems and economic harms that would result if API copyright could foreclose compatibility, including the cost of rewriting interface code formerly understood to be unprotected, and lock-in costs resulting from consumers’ inability to switch operating systems or cloud computing providers.... Lock-in would deter competition, investment, and innovation in the burgeoning cloud computing industry, which is known to be sensitive to policy changes in copyright.

In short, in the computer industry, overly broad intellectual property protection directly restricts competition and innovation. This was the status quo in the computing environment in the 1970s. Once a buyer purchased a computer system, the buyer was essentially locked-in to that system: the system was incompatible with products manufactured by other companies, and conversion costs were high. Although “locking in” was extremely profitable for dominant vendors such as IBM, competitors and users suffered from high prices, indifferent service, limited choice, and slow innovation.

CCIA also reminds the Supreme Court that Oracle (and Sun) not to long ago were among those who fought strongly for the position that interfaces were not copyrightable and that interoperability should be allowed. The filing notes that Sun and Oracle fought hard against parts of the DMCA when it was introduced that would have blocked interoperability. For example:

In a 1998 press release, Michael Morris, then Vice President and General Counsel of Sun Microsystems, argued that the DMCA as introduced would “impose[ ] a new and unnecessary layer of restraint on lawful access to those unprotected elements of computer programs that are necessary to achieve interoperability, thus placing developers of interoperable products at the mercy of proprietary vendors.”

That resulted in changes to the DMCA to make sure that interoperability was allowed. And yet, now, Oracle (via its Sun acquisition) is trying to argue that the exact opposite is true.

Finally, Public Knowledge also submitted an interesting brief which lays out the ridiculous situation we're in today with an analogy using amusingly named stand-ins and products:

Say that Delphi Corporation manufactures screws. It hits upon a new design for a screw socket—the interface between screw and screwdriver—that is more efficient than the prevailing Phillips and flathead insertions. Capitalizing on this novel idea, Delphi manufactures a line of screws using this socket, which it calls Sumatra. The Sumatra socket is wildly popular. New lines of screwdrivers are made for the Sumatra socket. Engineering textbooks praise the Sumatra design. Wood-workers teach their sons and daughters to use it. And competing screw manufacturer Zillion decides to make its own screws compatible with the Sumatra socket. The screws otherwise differ, but use the Sumatra socket so that woodworkers need not purchase new tools.

Only then does Delphi declare the Sumatra socket a sculptural work, suing Zillion for copyright infringement.

Rather than focusing on more recent rulings concerning software, the Public Knowledge brief goes all the way back to Baker v. Selden from 1879, which found that you couldn't copyright a set of blank ledger forms.

Oracle repeatedly points to the “intricate web of connections" of the Java API, in an effort to suggest that its structure, sequence and organization of the API is copyrightable. Oracle Brief, supra, at 26. But so too can uncopyrightable blank forms constitute an intricate web of connections. Selden’s book included 19 forms and 24 pages of demonstrative explanation designed “to compress almost innumerable accounts under a few specific, intelligible heads.” .... For either blank forms or APIs, intricacy does not confer copyrightability.

Given that an API is factually on par with a blank form, it is unsurprising that the reasoning of Baker directly applies to the copyrightability of APIs. Baker held that blank ledger forms, including the “ruled lines and headings,” could not properly be the subject of copyright.... The Court said that copyright cannot cover “systems” or an “art”; the Java API is certainly a system, one that teaches the “art” of using the Java system....

The Java API is on all fours with the blank forms of Baker, both factually and legally. Since copying of the blank forms in Baker was permissible, copying of the Java API is too.

It's also nice to see the Public Knowledge brief call out the simple factual errors in the CAFC ruling (some of which we pointed out in our post at the time):

... the Federal Circuit misunderstands arguments that interfaces are more properly protected by patent law than copyright law... Google, several amici below, and the district court merely proffered the unremarkable argument that functional elements should be excluded from copyright law by § 102(b) and the idea/expression dichotomy... But the Federal Circuit mistook them to mean that software may only be patentable or copyrightable, but not both. The Federal Circuit further assumed that criticisms of software patents equate to suggestions to expand copyrightable subject matter to cover interfaces.

These propositions are flawed. First, the Federal Circuit t neglects that there is matter outside the realm of both copyright and patent; the court apparently supposed that every element of a software program must fit into one or the other. Second, the Federal Circuit fails to differentiate the discrete elements of a given software product that may be copyrightable and those that may be patentable, instead lumping those elements together into a single entity. Third, the Federal Circuit conflates programming interfaces with computer programs generally.

Hopefully, these and other arguments convince the Supreme Court of just how wrong the CAFC was in its ruling. Recently, the Supreme Court has been pretty bad on copyright cases, while generally good on patent cases, so it's always a little nerve-wracking when copyright cases get there. The one bit of good news is that the Supreme Court has clearly found itself regularly questioning CAFC's interpretation of laws, since most of those patent cases come up via CAFC. The only reason this copyright case went to CAFC was because it started out as a patent case, though the patent issues got tossed out early on.

Google v Oracle Computer Scientists Certpetition Amicus Brief 14 410 Final (PDF)Google v Oracle Computer Scientists Certpetition Amicus Brief 14 410 Final (Text)

Google v Oracle Cert Nov 2014 (PDF)Google v Oracle Cert Nov 2014 (Text)

Brief Oracle v Google (PDF)Brief Oracle v Google (Text)

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: api, apis, computer scientists, copyright, copyrightable subject matter, functions, interfaces, software
Companies: ccia, eff, google, oracle, public knowledge

49 Comments

If you liked this post, you may also be interested in...

Reader Comments

Subscribe: RSS

View by: Time | Thread

Anonymous Coward, 10 Nov 2014 @ 4:00am

Simplified argument
If APIs are ruled copywritable, then judges' paychecks will be delayed while contracts are negotiated to allow the use of paycheck APIs by HR to transfer payroll information. This would be expected to take six months or more.
Then the use of the banks' APIs have to be negotiated. Which due to the complexity of the financial world, it is not unreasonable for contracts to take a year or more.
Direct deposit APIs are affected, so everything will have to be by written check for the foreseeable future.
Then the credit card company APIs, expected to take 18 months or more to clear up......
[ link to this | view in thread ]
That Anonymous Coward (profile), 10 Nov 2014 @ 4:03am

But what if the APIs have deeply held convictions that would be violated...
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 4:13am

Net result: people will work around the Oracle API.
[ link to this | view in thread ]
hij (profile), 10 Nov 2014 @ 4:43am

Where is Microsoft on this?
I am kind of curious why Microsoft is not soiling their pants over this development. If this were allowed to stand their claims that they should not be subject to monopoly laws would be suddenly left behind for dead. Their basic argument is that anybody can swoop in and take their market share because tech is so volatile. If their APIs are suddenly subject to copyright that argument is gone.

Ironically it is in their best interest to over turn this ruling. For the same reasons I am not sure why anybody would want to use anything related to Oracle if it is allowed to stand. It could result in a new era of free licensing activities.
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 4:52am

Sounds like Oracle is circling the drain, talk about frivolous lawsuits...and I thought the NSA would be the one to bring our economy to it's knees.
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 4:55am

sorry if i;m asking an embarrassing question but, how many of those on the Supreme Court bench know what the hell they're talking about when it comes to anything Internet related? the majority of cases they rule on, like CAFC, seem to be done after trying to turn a digital case back to an analogue one first, which obviously wont/doesn't work!
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 5:06am

Re:
No need to apologize.

Why would that question be embarrassing and to whom?

Is CAFC a case, or is it a lower court - you seem confused.

Please state the particular case(s) in which the SCOTUS attempted to rule by making analog analogues.
[ link to this | view in thread ]
Andrew D. Todd, 10 Nov 2014 @ 5:25am

Brown Instrument Co. vs. Warner (1947)
There is one significant old case which the Amicus brief does not appear to have noted.

In Brown Instrument Co. vs. Warner (1947), the U.S. Court of Appeals for the District of Columbia said "[Baker vs, Selden] involved blank forms for use in bookkeeping. They were intended to be written on by hand, and the blank forms now in suit are intended to be written on by a machine, but this difference is immaterial. Neither sort of form is intended to communicate facts or ideas. Both sorts are intended solely for use in making records of facts. Articles intended for practical use with a machine are not copyrightable... both law and policy forbid monopolizing a machine except within the comparatively narrow limits of the patent system."

This was a case involving a recording thermometer, and the special graph paper which had been made to with it. The manufacturer found it convenient to scale the graph paper to correspond to the machine's operation, rather than to attempt to design mechanical linkages to correct the anomalies in the machine. I don't know specifically, but I would guess that the recording thermometer was more or less like a household thermostat in construction, that is a coiled bi-metallic strip with a lever at the end, and a pen at the end of the lever, so that the pen moved in an arc with changes in the temperature, and some kind of motor which caused the paper to advance. The lines on the paper indicating time would have been curved to correspond to the pen's arc, and the lines indicating temperature would have corresponded to the pen's actual position at a given temperature. This is a fairly close fit to what an API does.

The manufacturer wanted to copyright the graph paper in order to make the machine useless without a fresh supply of legally protected paper. And the court slapped the manufacturer down. This case tends to supply a "deep precedent" for the uncopyrightability of API's.
[ link to this | view in thread ]
PaulT (profile), 10 Nov 2014 @ 6:19am

Re: Where is Microsoft on this?
"If their APIs are suddenly subject to copyright that argument is gone. "

Not really. It's what they choose to do with the copyright that would be the issue, not the mere fact that copyright existed. If they chose to try and leverage the copyright in order to negatively impact suppliers and competitors, there would be a problem. There are other approaches that wouldn't get them into any trouble.
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 6:26am

Question. When this article (and the sources quoted) say API, do you really mean method signatures?
[ link to this | view in thread ]
This comment has been flagged by the community. Click here to show it

Guardian, 10 Nov 2014 @ 6:27am

HAHA i hope they copyright it
HAHA i hope they copyright it, then your fucking retard nation will be complete as every actual engineer and scientist flees the country to every nation that doesnt do this stupid retard move , YES RETARD

HEY SUPREME RETARD COURT BE ALL YOU CAN BE !!!!
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 6:59am

The HTTP protocol has been DMCA'd
[ link to this | view in thread ]
tqk (profile), 10 Nov 2014 @ 7:21am

Re: Simplified argument
If APIs are ruled copywritable, ...

Still too technical for mortals to understand (though I enjoyed it, thanks).

As I read through this (thank you, Mike, for an excellent and easily understood report on legalistic minutia :-), I thought it might be instructive to use the example of various countries legal systems' interfaces, as that's where the judges might more easily find common understanding. British Common Law is different from Napoleonic Code is different from Russian, Chinese, ...

This story also reminded me of how often learning about this stuff is like being cuffed upside the head. Somebody tried to patent accounting leger forms hundreds of years ago? Well, yeah, I guess some smart ass would have tried that considering what I see going on in law making today. Yet we're still fighting that battle today, yet again, something that the court had settled long ago. Why's it coming up again now? Why's it seemingly so easy for lawyers to forget there is settled precedents for some given situation? Easy money, perhaps?
[ link to this | view in thread ]
Pragmatic, 10 Nov 2014 @ 7:24am

Re: Brown Instrument Co. vs. Warner (1947)
Thanks for that, Andrew D. Todd.
[ link to this | view in thread ]
tqk (profile), 10 Nov 2014 @ 7:32am

Re:
What's a "method signature"?
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 7:59am

Re: Re: Where is Microsoft on this?
It's what they choose to do with the copyright that would be the issue,

Unless permission is signed and delivered, a change of ownership or leadership of a company can change the attitude to use of APIs. Therefore there would be a risk of legal action, loss of use unless a license being is obtined first.
[ link to this | view in thread ]
RR, 10 Nov 2014 @ 8:26am

The first two arguments are horrible. They come off sounding like "think how fucked up we'll be if you uphold the law", instead of "that's not the law". It's not the court's responsibility to fix broken law, in fact they should enforce them strictly, as they are written, so that the writers take the blame.
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 8:26am

Re:
Well, Oracle does worship at the altar of the sacrd dollar.
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 8:34am

Re:
That might sound like a good idea for teaching lawmakers a lesson (if that were even possible), but if the court allows evils to occur that it could have stopped instead of trying to teach a lesson, they have acted unethically.

You don'tlet a child die because the parents refuse to give it medicine just so you can say, "see? You should have given the child medicine."
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 8:50am

Re: Re:
A method signature is the name of the method along with the list of parameters and return type.

So, for example, lets say you're using ABCPDF (real software I use) which has an API specifically built for interacting with PDFs. It has the following:

virtual int AddBookmark(string path, bool open)

http://www.websupergoo.com/helppdfnet/

That right there is a method signature. If you import their DLL you can call this to add bookmarks to a PDF. Technically, this isn't an API, its just the name of a call located within their API.

I've never heard of anyone reference an API and not be referring to the underlying code. So, if I was talking about the ABCPDF API, I would be referring to everything included in the DLL download.

Moving on from there.

So, my question is if I were setting up another PDF API of my own to sell, is this lawsuit claiming that I can't use that same method signature in my own code? Is it stating that the list of method signatures is the API, and I wouldn't be able to have my own method of the form:

virtual int AddBookmark(string path, bool open)

I'm just asking because I've seen mostly a mental distinction between an API and a list of method signatures. Two APIs would be distinct from each other if they were implemented differently (say one in C# and another in Java).

However, the article makes it sound like they are referring to APIs simply as a list of method signatures, so I want to be sure that's what is meant. Because, it would be crazy to try to copyright a list of method signatures, but not an API as I understand it. However, I know how crazy copyright can be, so I'm actually pretty afraid that it is in fact the former!
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 8:53am

Re: Re:
Anti-vacciners would like to have a word with you.
[ link to this | view in thread ]
John Fenderson (profile), 10 Nov 2014 @ 9:04am

Re: Re: Re:
"I've never heard of anyone reference an API and not be referring to the underlying code."

Huh? The primary design goal of a good API is to eliminate the need to know anything at all about the underlying code.

"Because, it would be crazy to try to copyright a list of method signatures, but not an API as I understand it."

Method signatures are a part of an API. You can divide an API into two broad parts:

The contract between the implementers of the functionality and the users of the functionality: that when a particular call is made, the implementation will react outwardly in a specific way.

The protocol by which you talk to the implementation. (This is technically part of the contract, but bear with me.) This is a bit like a language: if you speak in this specific way, the implementation will understand what you're saying to mean this specific thing. Method signatures are part of the definition of this "language" and are formally part of the API.

This is distinct from the implementation behind the API. Just because you make the call matching the signature "virtual int AddBookmark(string path, bool open)" doesn't mean that the implementation handles the parms "path" and "open" as a string and bool internally. It just means that's how you talk to it, nothing more.
[ link to this | view in thread ]
JWW (profile), 10 Nov 2014 @ 9:09am

Actually
While thinking about this I came up with a idea about how to relate to this.

API's are like recipes for how to get things done by calling API functions on computers. Recipes are printed in a cookbook and people who want to use the recipe can cook the dish that is described. Companies that publish cookbooks NEVER EVER sue people for cooking the dishes that are listed in the cookbook. I mean what would the point be? The cookbook would be useless. Just like APIs would be useless if using them was a punishable copyright offense.

Therefore, I think what the supreme court should do is declare that yes, API's are copyrightable, BUT using API's is an exercise in FAIR USE and cannot be punished.
[ link to this | view in thread ]
Sheogorath (profile), 10 Nov 2014 @ 9:29am

Hal Abelson, Brian Behlendorf, Ward Cunningham, Peter Deutsch, David Dill, Dave Farber, Ed Felten, Mitch Kapor, Alan Kay, Brian Kernighan, Guido van Rossum, Avi Rubin, Bruce Schneier, and Bjarne Stroustrup.
Is it bad that I recognised only two names from the above list (Ed Felten and Bruce Schneier)?
[ link to this | view in thread ]
Karl (profile), 10 Nov 2014 @ 9:33am

Re: method signatures
Question. When this article (and the sources quoted) say API, do you really mean method signatures?

That is indeed what Oracle is suing Google over. Though, technically, they are claiming that the collection of method signatures is copyrightable.

They already sued Google over the implementation of those methods, but Google did a (mostly) clean-room implementation. Google was found to have infringed something like a dozen lines or so, and they settled for zero dollars in damages.

Here is the relevant part of the district court's ruling:
So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical.

This is the part that was overturned by the appeals court, and is the subject of the Supreme Court case.
[ link to this | view in thread ]
Karl (profile), 10 Nov 2014 @ 9:50am

Re:
Is it bad that I recognised only two names from the above list (Ed Felten and Bruce Schneier)?

It's bad that the two names didn't include Brian Kernighan (creator of AWK, co-author of "The C Programming Language" with C creator Dennis Ritchie) or Bjarne Stroustrup (creator of the C++ language).

If you've studied CS, you'll probably know Hal Ableson (co-author of the SICP book on Scheme), Peter Deutsch (who I assume is L Peter Deutsch, Smalltalk and Lisp implementation author, Ghostscript creator), or Mitch Kapor (Lotus founder, original member of the EFF, chair of Mozilla).

The others I had to look up, but they're all really heavy-duty programmers and technology experts. You'd be hard pressed to find a group more knowledgeable about programming anywhere.
[ link to this | view in thread ]
JS, 10 Nov 2014 @ 10:36am

Is it bad? I don't know, but
Bjarne Stroustrup created C++.
[ link to this | view in thread ]
maroon78 (profile), 10 Nov 2014 @ 10:53am

Re: Re:
The list of parameters for a method or procedure. In Java, for example, the name of a method is not the complete identifier for the actual code because there may be more than one method with that name but a different set of parameters, e.g. name(first,last) versus name(first,middle,last) may both be methods that return a name string. Only one of them considers using a middle name or initial. So there are 2 different signatures for the method called name.
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 10:56am

Re: Re: Re: Re:
"Huh? The primary design goal of a good API is to eliminate the need to know anything at all about the underlying code."

Right, but that underlying code has always been copyrightable as far as I know. That's why I'm asking if this is about *code* or *signatures*, and it looks like this is actually about signatures, which is unsettling.

"Method signatures are a part of an API."

A part of, yes. That's why I'm asking. So, really, this isn't about, for example, the ABC PDF API (ie, the downloaded DLL) being a copyrightable thing. Of course it's a copyrightable thing.

This is, apparently, about a list of method signatures being copyrightable.

Which is absolute nutballs crazy. Lists shouldn't be able to be copyrighted. The mind can't even comprehend such a stupid concept. I hope SCOTUS buries this entire idea, but I won't hold my breath.
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 10:58am

Re: Re: method signatures
Thanks. That's crazy. I am not pleased. =/
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 11:08am

Re:
Is it bad that I recognised only two names from the above list...?

Yes. Very bad.

It's even worse that Masnick didn't think some of these other guys "stood out". Looking over the bios at the end of the brief...
2. Alfred V. Aho. Alfred V. Aho is—
—AWK.

13. Frederick Brooks. Brooks is—
—The Mythical Man-Month. And it happens to be Fred P. Brooks. Why do I know his middle initial off the top of my head?

15. Vinton G. Cerf.* Vinton G. “Vint” Cerf is—
—well, Masnkick mentioned him up above, didn't he?

33. John Hennessy.* John Hennessy is—
—the co-author of one of my textbooks.

35. Mitchell Kapor. Mitchell Kapor founded Lotus—
—yeah, I know he founded Lotus.

37. Brian Kernighan.* Brian Kernighan is—
—the “K” in “K & R”. Yeah, and I already mentioned Aho up above for the “A” in AWK. Guess where that “K” in AWK comes from, too.
[ link to this | view in thread ]
tqk (profile), 10 Nov 2014 @ 11:40am

Re: Re: Re:
Ah. I know them as function prototypes.

So, the upshot of all this is if you want to use C, you'll need to buy a SysVr4 licenced Unix box to get an AT&T compliant C compiler. Borland and Microsoft C cannot exist, Mix Power C is right out, and don't even think of creating gcc. I guess we may as well close up shop on ISO Standards too.

Asinine. Way to promote the useful arts and all that, Supremes.
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 11:48am

Re:
41. Ed Lazowska. Ed Lazowska is the Bill & Melinda Gates Chair in Computer Science & Engineering at
the University of Washington.
Well, that's the only reason I know who he is.

50. David Patterson.* David Patterson—
—see Hennessy.

56. Guido van Rossum. Guido van Rossum—
—doesn't really belong with all these famous superstar big-shots.

57. Avi Rubin.—
—yeah, I've talked to him.

58. Bruce Schneier. Bruce Schneier is—
—Schneier on Security. Also Applied Cryptography, Second Edition. And Blowfish, etc., and more recently, Skein.

65. Brad Templeton. Brad Templeton—
—never mind about that.

66. Ken Thompson.* Ken Thompson—
—what can I say about Ken?

67.Michael Tiemann. Michael Tiemann—
—Cygnus, acquired by RedHat.

68. Andrew Tridgell. Dr. Andrew Tridgell is a
Samba, and rsync.

69. Josh Triplett. Josh Triplett is—
—also not a big-shot superstar.

70. Jeff Ullman.*—
—I've talked to him, too.

75. Dan Wallach. Dan Wallach is a—
Hi, Dan!
[ link to this | view in thread ]
tqk (profile), 10 Nov 2014 @ 12:33pm

Re:
I'd say it depends who you are and what you do, and perhaps how old you are. If you've never been a programmer, you may never have needed to know. Programmers my age think of many of these guys as Graybeards. I wonder why Stallman's not on the list, but maybe he just wasn't asked.
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 12:46pm

Re: Re:
... it depends who you are and...

It also depends on how social you are. A lot of programmers are fairly introverted. And I sometimes describe myself as “entirely anti-social”.

I wonder why Stallman's not on the list, but maybe he just wasn't asked.

There were a lot of names I didn't see on that list. Maybe I just skimmed over them.
[ link to this | view in thread ]
tqk (profile), 10 Nov 2014 @ 12:58pm

Re: Re:

Hal Abelson, Brian Behlendorf, Ward Cunningham, Peter Deutsch, David Dill, Dave Farber, Ed Felten, Mitch Kapor, Alan Kay, Brian Kernighan, Guido van Rossum, Avi Rubin, Bruce Schneier, and Bjarne Stroustrup.

It's bad that the two names didn't include Brian Kernighan (creator of AWK, co-author of "The C Programming Language" with C creator Dennis Ritchie) or Bjarne Stroustrup (creator of the C++ language).

Just sayin'. Might want to get your eyes checked.
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 1:13pm

Re: Re: Re:
Might want to get your eyes checked.

Speaking of getting eyes checked, I'm not seeing the Google v Oracle cert petition over at SCOTUSblog: “Petitions We're Watching” ? What's up with that? Anyone know?
[ link to this | view in thread ]
Johnny B. Goode, 10 Nov 2014 @ 1:53pm

Re: Re: Re:
I was going to respond to the question of the differentiation between method signatures and an API(comments #10 and #15), but Anonymous Coward has already done a good job of explaining that(comment # 20). My only comment on that subject is that there seems to be some confusion on the difference between the API proper, and an implementation of that API;
Two APIs would be distinct from each other if they were implemented differently (say one in C# and another in Java).

This is not true. The implementation would be different, the API itself would not. This is the crux of abstraction; providing a standard method of interaction, regardless of the underlying concrete implementation.
[ link to this | view in thread ]
Johnny B. Goode, 10 Nov 2014 @ 2:07pm

Applicability of Baker vs Selden
Baker vs Selden seems to be particularly applicable to this situation, because conceptually the scenario is the same in both cases.

A blank form can be thought of as a standardized method of communication(transfer of data). Two companies could use the same blank form, but have entirely different business processes to handle that form once it has been submitted.

An API is nothing more than a standardized process for communication with a series of guaranteed responses. To illustrate:
If you submit a form to open a checking account(standardized communication), the bank will open a checking account for you or return the form for some reason(guaranteed responses).

At a conceptual level, instruction sets are essentially the same thing, and protocols differ only in that the guarantees apply to the process as well as the responses. What this means is that if the SCOTUS rules in favor of Oracle, then it is a matter of time before the ruling is applied to protocols and instruction sets, and we either end up with a tangled web of rules and exceptions for dealing with software, or the world of technology comes to a grinding halt while license agreements are made, lawsuits are settled, etc.

In the world of software development, we call this dependency hell.
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 2:12pm

Re: Re:
Guido van Rossum—
—doesn't really belong with all these famous superstar big-shots.

Yeah. Python? WTF is that shit? This guy's trying to claim for inventing snakes? WTF?

Oh yeah, /s, by the way in case it wasn't obvious.
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 2:49pm

Re: Re: Re:
WTF?

Well, it's not we're talking about Larry Wall, is it?

Btw, did I miss Larry while I was saying “Hi” to Professor Wallach?
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 3:12pm

Re: Re:
Pop quiz for psych students: name the top three most likely personality disorders that could lead to someone making a post like this.
[ link to this | view in thread ]
tqk (profile), 10 Nov 2014 @ 3:47pm

Re: Re: Re:
Speaking of which, why isn't Larry Wall in there?!?

Watch it bud! I could replace you with a perl one-liner.
[ link to this | view in thread ]
Anonymous Coward, 10 Nov 2014 @ 3:51pm

Re: Re: Re: Re:
Speaking of which, why isn't Larry Wall in there?!?

Anyone know what the deadline for amici briefs is?
[ link to this | view in thread ]
Togashi (profile), 10 Nov 2014 @ 4:24pm

Re: Re: Re:
Bad that the two names he recognized didn't include those two. Not the list itself.
[ link to this | view in thread ]
Anonymous Coward, 11 Nov 2014 @ 4:54am

The blank form and screw analogies, helped me clearly understand why API's should not be copyrightable or patentable.

I find it interesting that so many computer scientists recognize how patents and copyrights slow innovation down to a crawl.
[ link to this | view in thread ]
John Fenderson (profile), 11 Nov 2014 @ 8:18am

Re: Re: Re: Re:
Function prototypes and function signatures are different, but related things. A function prototype is a means by which you declare function signatures.

Neither are exclusive to C/C++.
[ link to this | view in thread ]
Sheogorath (profile), 11 Nov 2014 @ 6:01pm

Re: Re: Re:
I think Karl was referring to the names I recognised, not the list I quoted. Of course, since I'm not a programmer, I can't really be expected to recognise the names of people who are underpublicised. Simples!
[ link to this | view in thread ]
Anonymous Coward, 17 Nov 2014 @ 10:07am

Re: Re:
The input parameter(s) (or absence of them), output value (or absence of one) and the "name" of the method. (All 3 of these combined are generally considered to be the "signature of a method)
int Math.Max(int,int) would indicate that a method named "Max" expects two integer values to get passed in and one integer to come out as the result.
[ link to this | view in thread ]