We need a new legal system for arbitrating disputes in technical disciplines overseen by a panel of technical experts. Or perhaps a trial by jury where the selection criteria is employment in the relevant discipline for at least 10 years (academia or corporate).
Its not a tech matter, its a matter of the application of Copyright law. Its exactly what the Supreme Court exists to do.
> We need a new legal system for arbitrating disputes in technical disciplines overseen by a panel of technical experts.
Specialized trial or intermediate appellate courts of this type may make some sense (though such a specialized body --whose members are no doubt both drawn from and likely to leave to industry -- runs a particular risk of regulatory capture and becoming a body that reflects very well the interests of the bigger players in the industry), but I don't see any good reason for fragmentation at the top of the judicial branch just because technology, so I don't see any reason that ultimately such issues wouldn't end up with the Supreme Court.
> Or perhaps a trial by jury where the selection criteria is employment in the relevant discipline for at least 10 years (academia or corporate).
Specialized juries defeat the purpose of trial by jury -- and, anyway, then you just create a bunch of additional litigation over the boundaries of the "relevant discipline" for each case as each side tries to set the experience qualifications to suit the pool of jurors it thinks will be most favorable.
This could be egregiously abused without too much cleverness.
"Oh, you're self employed in software? No jury duty for you." "Oh, you don't work for GE, the only company approved by the 'What Counts As Corporate Software' board? No jury duty for you."
One must be very careful advocating for the creation of special courts. History is rife with examples of these being particularly corrupt and deplorable.
One can predict with high accuracy a SC Justice's vote on most cases based on the political party of the president who appointed him/her.
Having taken a number of law and judicial politics courses, I can say this has been studied and its not at all true. You can tell with some accuracy a SC Justice's vote on issues that had high political salience at the time the individual justice was appointed by the position of the appointing administration on those issues, but predicting votes by party identification fails rather drastically for most other issues. There's a few evergreen issues that have had both high political salience and fairly consistent partisan breakdown of positions over a long time (e.g., abortion, gun control), and so these issues tend to be pretty consistently predictable by party ID.
OTOH, most issues aren't like that (though issues that get lots of mainstream news coverage are disproportionately likely to be -- though even there many aren't), and issues like the particular one here (whether APIs are within the scope of copyright) haven't ever had high political salience.
Sometimes you can predict how a given Justice will act, based on how he feels about the specifics of similar cases.
Why is that a problem? It's certainly possible that the judge was an avid home computer enthusiast in the 1980s and knows about tech.
Old age doesn't automatically mean technological incompetence anymore.
None of this is inconsistent, though, with it's being beneficial that there are additional very smart younger people, who may be more likely to be familiar with newer technologies just in case their perspective becomes relevant.
Just curious as I turn 35 in a couple of years...
Edit: to the person who downvoted this, it's a joke in case you didn't notice
For example, Judge Alsup was born in 1945 and demonstrated a perfect understanding of the issues in his ruling. As I recall he even taught himself Java programming during the trial.
This is not a case where you're digging around in the weeds trying to figure out which function does what. You don't need to be a computer scientist to understand the legally-relevant concepts in a case like this. Especially at the appellate level, where you're working with high-level concepts, and where you have people with the relevant technological background submitting amicus briefs explaining the concepts. I don't think anyone on the panel read the amicus briefs in this case and simply failed to understand what an API is.[1]
The real issue in this case is that a judge, applying the copyright law, simply does not care about whether finding API's to be copyrightable hinders interoperability or cloning of software. It's simply not legally relevant. The lynchpin of copyright is originality and creativity. Are the Java API's original and creative? That's the only relevant question.[2]
[1] And I would posit that software is easier to understand for a lay-person than a complex reinsurance arrangement or financial instrument. How would Hacker News react to the proposition that we should have specialized courts to decide financial disputes, with judges required to have a minimum of 10 years experience in Wall Street?
[2] Having written internal API's for software products, I would say they definitely are! API design is hard work that requires a lot of careful thought. Making a beautiful API is as much a creative expression as writing a sonnet or a short story, and is no less deserving of copyright protection.
That is exactly why a legal professional is the wrong person to decide the issue. I've written plenty of APIs myself, and when it comes to interoperability, anybody should be free to reimplement the same interfaces, no matter how creative my design. Anything else would destroy competition in the software industry and promote a virtual dystopia of vendor lock-in.
But that isn't a technical argument. If it had some empirical support it might be an economic one, but it's mostly just an ideological argument. One that, I might add, many software engineers would disagree with.
The courts have regarded interoperability as a fair use in the past. https://en.wikipedia.org/wiki/Sega_v._Accolade
How is it not? Interoperability is functional. If you can't copyright function then you shouldn't be able to copyright anything necessary for interoperability.
> The lynchpin of copyright is originality and creativity. Are the Java API's original and creative? That's the only relevant question.
That obviously isn't the only question, otherwise you could copyright anything which is patentable and get 95 years of monopoly rather than 20.
This is 100% false of course. My shopping lists are creative and original, but certainly not copyrightable.
You know it's not the only question, and not even the most relevant one (which is whether the structure, sequence, and organization part of an API is the copyrightable part, or whether the literal implementation only is protected).
"[2] Having written internal API's for software products, I would say they definitely are! API design is hard work that requires a lot of careful thought. Making a beautiful API is as much a creative expression as writing a sonnet or a short story, and is no less deserving of copyright protection."
1. API's are not expressions of anything. They are literally interfaces. An outline of a story in abstract terms is not copyrightable. The actual story is. Such should it be with API's. API's are not copyrightable, their implementations are.
2. The fact that it is hard work and requires careful thought is 100% irrelevant in united states copyright law, since we have no sweat of the brow doctrine.
To me, an "API" is just the "structure, sequence, and organization part," distinct from the implementation. I.e. you can't take a C header file and delete the parameter names, and replace all the types with typedef'ed names and get a different API. So the question is whether that (whatever you call it) is copyrightable. And under 17 USC 102, how you answer that question is to look at whether that is original and creative.
> 1. API's are not expressions of anything. They are literally interfaces. An outline of a story in abstract terms is not copyrightable. The actual story is. Such should it be with API's. API's are not copyrightable, their implementations are. 2. The fact that it is hard work and requires careful thought is 100% irrelevant in united states copyright law, since we have no sweat of the brow doctrine.
Of course, but something being hard work and requiring a lot of thought is indicative of whether it requires originality or creativity. Take, for example, the POSIX file API's. That specific combination of orthogonal function calls, the concept of passing around file descriptors as small integers, etc, is definitely a creative expression, distinct from the underlying functionality. And it's a distinct creative expression from, e.g., the Win32 file API's, which express similar functionality in a very different way.
If you pass the file descriptors because that looks pretty, because of the beauty of the form and not for any functional effect. And, if the same functional effect (if there is one) can be achieved in other obvious and equally functional ways, so the only reason to do it this way is aesthetic, then yes - the essential elements are creative.
Just because you can achieve the same technical outcome in a different way doesn't make this way specifically creative however.
If an obvious way to create a specific technical effect creates a specific art-like outcome too then it's probably not copyrightable. Tyre treads, say: if your tread is created to appear different and there's no other reason to make it that way then you're covered by copyright; but if they have a technical benefit and you don't have other IP protection (patent or design patent) then others are free to duplicate that design because they are allowed to generate that technical outcome and the visual "artistry" is subordinate to that it's emergent rather than being directed.
Of course, if you did so, the fact that you ended up with the same API means you have removed any expressive portions, and are left with purely functional constructs and short names.
". And under 17 USC 102, how you answer that question is to look at whether that is original and creative."
Sorry, but no. The fact that something is original and creative does not, by itself, make something copyrightable in any way, shape, or form.
"Of course, but something being hard work and requiring a lot of thought is indicative of whether it requires originality or creativity."
It 100% is not indicative of this. It is hard work to compile address lists and phone numbers into the white pages. It requires a lot of thought to think through physics and math problems, and write down equations.
Neither is subject to copyright protection.
"the concept of passing around file descriptors as small integers, etc, is definitely a creative expression, distinct from the underlying functionality. "
However, as a concept, it is one completely and totally ineligible for copyright protection.
That presupposes that there is nothing expressive in the structure of the API itself, beyond the names. But the combination and structure of calls in an API is an expression in and of itself, as evidenced by the fact that the same functionality (e.g. file access) can be expressed in many different ways.
> Sorry, but no. The fact that something is original and creative does not, by itself, make something copyrightable in any way, shape, or form.
I didn't say it was the only requirement for copyrightability. There's obviously the exclusions in 17 USC 102(b). But in addition to the "work of authorship" and "fixation" requirements in 17 USC 102(a), which I assume aren't in dispute, originality is what matters.
> It 100% is not indicative of this. It is hard work to compile address lists and phone numbers into the white pages.
Ditch-digging requires a lot of work too, and I'm not asserting that is creative, but I do think API design is a creative process that requires a lot of careful thought.
> However, as a concept, it is one completely and totally ineligible for copyright protection.
Sure, the concept of passing around file descriptors as small integers is not protectable in the abstract. But it's an expressive choice that, when weaved into an API, takes it beyond purely functional into a creative expression.
By this argument, everything ever, including my shopping lists are creative expression and copyright eligible.
Copyright protection in software has never extended this far, and your argument is not particularly convincing (at least to me :P)
"Sure, the concept of passing around file descriptors as small integers is not protectable in the abstract. But it's an expressive choice that, when weaved into an API, takes it beyond purely functional into a creative expression."
We're going to have to agree to strongly disagree.
By your abstract arguing, almost everything can be found to be expressive as long as it's "an expressive choice". This would extend copyright far into the realm of methods and processes.
I'm not sure that necessarily follows, but if you do use creative expression in write your shopping list, why is it not copyright-eligible? Just because it's a "shopping list"? Where do you draw the line?
And what if you no creative expression is involved in writing some code... is it not covered by copyright?
Is a "Hello World" program copyright-eligible?
Is a FizzBuzz program copyright-eligible?
Is a library that implements atoi and itoa copyright-eligible?
Is a program simply implementing a detailed spec copyright-eligible?
Is a service implementing PageRank copyright-eligible?
> This would extend copyright far into the realm of methods and processes.
I'm sure you know this, but copyright expressly excludes protection for functionality (leaving that to the realm of patents), and isn't that what methods and processes are?
What would it mean to use creative expression to write a shopping list?
"And what if you no creative expression is involved in writing some code... is it not covered by copyright? " It is clearly not covered by copyright in that case.
I'd need to see specific code to answer the rest of your questions.
Copyright is not a binary thing. There is essentially a 'strength of protection' that goes along with it. For example, you can have copyrights on compilations of works. Your copyright does not extend to the underlying works. Anyone can copy them (assuming they otherwise have rights).
"I'm sure you know this, but copyright expressly excludes protection for functionality (leaving that to the realm of patents), and isn't that what methods and processes are?"
No.
Make it rhyme? Interject humor? Use archaic language? :-)
The question is, of course, why would you ever bother when it's only ever going to be you who reads the shopping list? But that's not the case with APIs! APIs are made primarily for other people to read, understand and compose other programs with. If I were to design an API that I wanted other people to use (and I have), I'd try my hardest to make it as attractive as possible.
> I'd need to see specific code to answer the rest of your questions.
I did give a list of examples, but your next paragraph answers my question, in a way. I guess "hello World" is probably not copyright-eligible, but more complex programs are. My question is, what if a complex program was just a mechanical implementation of a very detailed spec?
As to the methods and processes bit, I'm not quite clear what aspect of those you fear would be covered by copyright. If it's the actual implementation, it's just the code, which is already copyrightable. If it's the functionality or the "idea" behind the code, it is explicitly excluded.
This brings me back to my general belief that copyright is not appropriate for protecting code. (Good) code is supposed to be as boring as possible! The actual creative expression in programming goes into how problems are solved, i.e. the "idea" behind the code, and that is explicitly excluded by copyright.
"In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work."
I could easily see an API being an "idea" or "method of operation". I have no idea how this squares with precedent.
Do you know, off hand, what excludes mathematics from copyrightability?
I can copyright the text of my proof, but not the fact being proved.
The Supreme Court spends much of its time interpreting the patterns that are laid out in the constitution and laws passed by congress. Sometimes it synthesizes a new pattern, which will be interpreted for the next 10's or 100's of years.
For copyright, there is some value in recalling patterns from the last few decades. For example, the film industry thought that TV and later VHS would kill their business. Another is when the music industry thought that radio, cassette tapes, and MP3 files would kill their business.
The problem of employing experts as the final judge is their bias towards a particular pattern. The time spent going deep in a particular field would mean that they have less time to go broad across all fields. IMO, how to benefit US commerce is about as broad as it gets.
[0]arstechnica.com/tech-policy/2012/09/how-a-rogue-appeals-court-wrecked-the-patent-system/
What have we done recently?
Supreme court justices are (hopefully) legal experts, not technical experts. Having younger supreme court justices doesn't change that _at all_. I don't know of many lawyers that know what an API is.
Sarah Jeong has written thoughtfully on whether justices need be tech savvy: http://sarahjeong.net/2014/04/23/scotus-is-bad-at-computers-...
The good thing about non-technical courts is that they force the parties to explain what is at stake in terms that every intelligent person can understand. This process is very important because it can highlight things that are often assumed by people in the trade. It is the law equivalent of "rubber duck" debugging.
A specialised court notorious for blindly enforcing tighter interpretations of IP laws reversed the decision.
You might want to try drawing your examples from reality, not prejudice.