
Computer Scientists Ask Supreme Court to Rule APIs Can’t Be Copyrighted - jrochkind1
https://www.eff.org/press/releases/computer-scientists-ask-supreme-court-rule-apis-cant-be-copyrighted
======
acqq
Signed by

    
    
            1. Harold Abelson.*
            2. Alfred V. Aho
            3. Tom Ball.*
            4. John Perry Barlow
            5. Brian Behlendorf
            6. Richard A. Belgard
            7. Jon Bentley
            8. Matthew Bishop
            9. Joshua Bloch
            10. Dan Boneh
            11. Gilad Bracha.*
            12. Eric Brewer.*
            13. Frederick Brooks
            14. Rick Cattell
            15. Vinton G. Cerf.*
            16. William Cook
            17. Ward Cunningham
            18. Mark Davis.*
            19. Jeffrey Dean.*
            20. L Peter Deutsch
            21. David L. Dill
            22. Les Earnest
            23. Brendan Eich
            24. Dave Farber
            25. Stuart Feldman.*
            26. Edward W. Felten
            27. Jeremiah Flerchinger
            28. Martin Fowler
            29. Neal Gafter
            30. John Gage
            31. Allan Gottlieb
            32. Miguel de Icaza
            33. John Hennessy.*
            34. Tom Jennings
            35. Mitchell Kapor
            36. Alan Kay
            37. Brian Kernighan.*
            38. David Klausner
            39. Ray Kurzweil.*
            40. Kin Lane
            41. Ed Lazowska
            42. Doug Lea
            43. Sheng Liang
            44. Barbara Liskov
            45. Paul Menchini
            46. James H. Morris
            47. Peter Norvig.*
            48. Martin Odersky
            49. Tim Paterson
            50. David Patterson.*
            51. Alex Payne
            52. Tim Peierls
            53. Simon Phipps
            54. Bill Pugh
            55. Larry Roberts
            56. Guido van Rossum
            57. Avi Rubin
            58. Bruce Schneier
            59. Curtis Schroeder
            60. Barbara Simons
            61. Dave Snigier
            62. Alfred Z. Spector.*
            63. Bjarne Stroustrup
            64. Gerald Jay Sussman
            65. Brad Templeton
            66. Ken Thompson.*
            67. Michael Tiemann
            68. Andrew Tridgell
            69. Josh Triplett
            70. Jeff Ullman.*
            71. John Villasenor
            72. Jan Vitek
            73. Phillip Wadler
            74. James H. “Jim” Waldo
            75. Dan Wallach
            76. Peter Weinberger.*
            77. Frank Yellin.*
    

Asterisk:

"presently Google employees, consultants, and/or directors. Those amici are
signing this brief as individual computer scientists whose work in the field
long preceded their affiliation with Google. They are not signing this brief
on behalf of Google or at Google's request."

~~~
rayiner
I think it was a tactical mistake to include the folks affiliated with Google.
Amicus briefs are supposed to be from parties who have an interest in the
dispute, but not a personal stake in either party. Including so many people
affiliated with Google will come across negatively.

~~~
flebron
Unfortunately, it's just a background fact that Google employs a lot of well-
known computer science figures. So this was bound to happen unless they
explicitly forbade them from signing this, which I also don't think is good.

------
EGreg
Maybe someone should look up the stated reason for awarding a Copyright in the
first place.

Isn't it to "Promote the Progress of Science and the useful Arts?"

[http://en.m.wikipedia.org/wiki/Copyright_Clause](http://en.m.wikipedia.org/wiki/Copyright_Clause)

In this case it would seem that in fast-moving industries, monopolies would
retard, rather than promote, the progress. Especially seeing as how copyright
can be extended to 100 years or more after the author's death, here the author
being a corporation?

------
jrochkind1
Many in this thread seem to be wondering about the legal argument itself --
that API's being copyrightable is inconsistent with existing pretty well-
established law.

Which is, yes, a different thing than arguing about whether it's "a good idea"
for society or innovation or whatever. The EFF summary focuses on the "good
idea" thing, but the actual amicus brief addresses both -- although I bet you
can find even more of the legal arguments in the first party brief.

From the amicus brief, take a look at the original brief, starting on numbered
page 4, "I. The Federal Circuit’s Decision Has Disrupted Decades of Settled
Expectations That APIs Are Not Copyrightable"

> That assumption was well-founded. It was based, in large part, on this
> Court’s own recognition, in 1996, that menu hierarchies that control
> functional capabilities are a method of operation, and thus uncopyrightable
> under 17 U.S.C. § 102(b). Lotus Dev. Corp. v. Borland Int’l, Inc., 49 F.3d
> 807, 815 (1st Cir. 1995), aff’d by an equally divided Court, 516 U.S. 233
> (1996). Programmers and developers relied on that ruling for the proposition
> that APIs, like the menu hierarchy in Lotus, may not be copyrighted under §
> 102(b). Ninth Circuit law—which should have been controlling in this
> case—was the same: the “functional requirements for compatibility” between
> computer programs “are not protected by copyright.” Sega Enters., Ltd., v.
> Accolade, Inc., 977 F.2d 1510, 1522 (9th Cir. 1992); see alsoSony Computer
> Ent’mt, Inc. v. Connectix Corp., 203 F.3d 596, 599–600 (9th Cir. 2000)
> (describing Sony’s PlayStation BIOS as a “system interface procedure[]” that
> Connectix was entitled to reimplement under § 102(b)).

~~~
vegedor
>>functional requirements for compatibility” between computer programs “are
not protected by copyright

This was in regards to Accolade (game company) reverse engineering, and
reimplementing the software side of the security procedure of the sega genesis
for third-party game cartridges. Following the source leads nowhere to an
explanation of the quote. Must be a pretty trivial notion.

Still interesting case, though. First of all, it's puzzling that they just
talk about "functional" requirements and concepts. "Well, what isn't
functional?", said the Haskeller.

>The TMSS initialization code is a functional feature of a <24 USPQ2d 1577>
Genesis-compatible game and Accolade may not be barred from using it.

>Functional features of a product are features ‘which constitute the actual
benefit that the consumer wishes to purchase, as distinguished from an
assurance that a particular entity made, sponsored, or endorsed a product.’”

I don't, what? Are they basing copyright-eligability on consumers' ability to
understand features that interact to form other features? How is the
Trademark, that was shown as part of the security check (only on consoles
newer than the games), precluded from that desire?

>Accolade did not seek to avoid paying a customarily charged fee for use of
those procedures, nor did it simply copy Sega’s code; rather, it wrote its own
procedures based on what it had learned through disassembly

Wait, did they pay a fee to use the procedures? What's the case about again?
Then, reimplementation is based on the understanding derived from the
translation of the object code. Translation is prohibited under copyright,
except for _fair use_. The fair use here is interpretation of an idea and
expression of the same idea in different semantics, translation for short.
Never mind the irony, surely there wasn't any commercial gain involved, so
it's still somewhat fair use. Apparently, a security check that can be broken
isn't a commercial advantage, so, its defeat is no benefit. It's defeat is
only lawful, because it isn't copyrightable in the first place.

This is so messed up, it just doesn't make sense.

~~~
lmm
> I don't, what? Are they basing copyright-eligability on consumers' ability
> to understand features that interact to form other features? How is the
> Trademark, that was shown as part of the security check (only on consoles
> newer than the games), precluded from that desire?

The point is that it's in customer's interests for Sega to be able to e.g.
only display the Sega logo for games that use Sega chips. That's a non-
functional feature, so to speak, and there are good reasons for it (e.g. some
low-quality third party chips could damage the console itself). The court is
looking after customers' interests by distinguishing between that and a
functional feature.

> Translation is prohibited under copyright, except for fair use.

Nope. Translations are derived works and may not be _distributed_ without the
copyright holder's permission, but there's no law against making a translation
in-house and using it internally.

> surely there wasn't any commercial gain involved, so it's still somewhat
> fair use

That's not what fair use means.

~~~
dragonwriter
> Translations are derived works and may not be distributed without the
> copyright holder's permission, but there's no law against making a
> translation in-house and using it internally.

Incorrect. The right to _prepare_ (not merely _distribute_ ) derivative works,
including translations, is one of the exclusive rights of creators included in
copyright. [0]

[0] 17 USC Sec. 106.

------
sillysaurus3
Quick question: Why can't an API be copyrighted? My understanding is that the
purpose of a copyright is to protect a specific arrangement of ideas. A piece
of music, a book, a painting. All of those things are an arrangement, and the
arrangement itself is what's protected by copyright, not the physical object
that was created.

So, given that an API is an arrangement of ideas, and that copyright
apparently protects arrangements of ideas, why is copyright inapplicable here?

If the argument is that copyrights _shouldn 't_ apply to APIs, then I
understand. It's probably more harmful than beneficial, and thus should be
prevented. But if the argument is that copyright is incompatible with the
domain of APIs, as if you were trying to copyright a taste like chocolate or
copyright a smell, then I don't understand that at all. Would anyone mind
clarifying?

~~~
ewillbefull
The Copyright Act states:

"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."

The common belief is that an API meets this "system or method of operation"
standard.

~~~
sillysaurus3
Hmm... What's a "method of operation" in the context of computer programs?

This isn't helpful: [http://legal-
dictionary.thefreedictionary.com/Method+of+oper...](http://legal-
dictionary.thefreedictionary.com/Method+of+operation)

I really don't understand how an API is a method of operation in any sense.
It's an understanding between people about how to use a software library. The
only sense that I could see it being a method of operation is literally "This
is a description of how you operate the software library." In other words, an
API is an instruction booklet for people, not computers. But in that case, why
are instruction booklets copyrightable, but not software APIs?

~~~
dragonwriter
> What's a "method of operation" in the context of computer programs?

The more dangerous question is "what is a computer program except a method of
operation?"

~~~
AnthonyMouse
That isn't really a problem. You can have two programs that do the same thing,
e.g. BSD cat and GNU cat, but you're copyrighting the specific implementation
rather than the method of operation. Each method of operation can have
arbitrarily many different implementations.

~~~
throwawaykf05
By that logic, copyrighting APIs is not really a problem either: Each API can
have arbitrarily different concepts, paradigms, organization, and naming and
calling conventions. Hence even APIs for doing the exact same things can (and
do) look completely different from each other. Compare, for examples, the Java
APIs with those for C++, C#, Python, Ruby, Go, etc. etc.

~~~
AnthonyMouse
> Each API can have arbitrarily different concepts, paradigms, organization,
> and naming and calling conventions. Hence even APIs for doing the exact same
> things can (and do) look completely different from each other.

If they're "doing the exact same things" then they're the same API. That's
what an API is -- it's a formal declaration of the function(s) implemented by
the implementation. Its purpose is literally to separate the part that can be
implementation specific from the part that can't. The purpose of an API is to
be the part that can't.

~~~
throwawaykf05
_> If they're "doing the exact same things" then they're the same API. _

And yet somehow I can reliably differentiate the Java API from the C++ API
from the Python API etc. etc. doing all the same things in their respective
standard libraries. That is, each one expresses the same concepts in different
ways. You seem to be conflating the _concepts_ represented by an API with the
_specific expression_ of that API. This being a copyright case, the issue at
hand is clearly the expressive aspect.

~~~
AnthonyMouse
They aren't doing the same things. You can't copyright a bolt with specific
dimensions and thereby prevent anyone else from making nuts compatible with
your bolts or bolts compatible with your nuts because you can't copyright
function. It is also true that you can't copyright the entire concept of a
bolt, but how does that help you?

Let's try a specific example. Here's a function from the C library:

    
    
      int tolower(int c);
    

The following is _not_ the same function:

    
    
      int64_t tolower(int64_t c);
    

Even though the concept of what the function does (convert a character to
lowercase) may be the same, you still can't switch them around in the
compiler's symbol table. You can't link a binary that calls one with a library
that implements only the other. They are not functionally equivalent.

~~~
throwawaykf05
I don't see the relevance of that. Of course those are NOT the same function.
But they would logically belong in the same overall API, where "API" as used
in this particular context means an overall logical collection of modules and
methods, such as that of a standard library. The more relevant comparison
would be between "int tolower(int c);" and "char
java.lang.Character.toLowerCase(char c);"

This specific case is _not_ talking about copyrighting "java.io.File(String
filename)" or "Character.toLowerCase(char c)" in isolation, but rather the
overall collection of the whole API. It's all about covering the "structure,
sequence and organization" of the API, and there's not much of that in a
single function call.

But your point about linking relates to another point I made elsewhere
([https://news.ycombinator.com/item?id=8581069](https://news.ycombinator.com/item?id=8581069)):
you can compile arbitrary textual code to binary code that links to the _same
symbol in the function table_. That is, "new File(fname)" in Java and
"open(fname, 'r')" in Jython can both point to the same symbol ("invokespecial
#4" in Java bytecode). This is what I mean by "different API for same
functionality". Google argues that they needed "binary compatibility" (by
citing the Sega and Sony cases), but you _do not_ need to copy the API
wholesale for that! They could very well have defined their own new API (e.g.
"android.fs.FileObject android.fs.FileSystem.openReadOnly(String fname);")
that compiles down to the same bytecode, but then they wouldn't have been able
to leverage the widespread pre-existing Java knowledge in the industry.

------
WalterBright
> The list also includes designers of computer systems and programming
> languages

I'll sign it, too. - designer of the D programming language

------
snarfy
Map makers should just copyright the lines that represent the borders of
states, counties, and cities. Heck, copyright lines, points, and legends too.

~~~
jofer
This is actually a very major issue. They are copyrighted to varying degrees.

The fact that feature "z" is located at "x,y" can't be copyrighted, but the
data file that describes exactly that can be and is. (There are good reasons
for this. It's not as simple as the straw man I set up there.)

The US is very fortunate to require all government-produced cartographic data
is solidly in the public domain. This is not the case in most countries.

Now there are several public-domain global datasets, but not very long ago
obtaining basic cartographic data for many parts of the world was fraught with
copyright issues.

It's rather annoying to have made a map of your study area and then find out
that:, "Oh, wait. You can't publish that. Our license for the river locations
only allows us to use the data internally. We can't publish a figure with that
data on it!"

~~~
Nitramp
_The US is very fortunate to require all government-produced cartographic data
is solidly in the public domain. This is not the case in most countries._

You can make the argument that making these maps costs money, so those that
benefit from the maps should actually pay the government for them - thus
people who don't need these maps don't have to pay for them through their
taxes.

I'm not entirely sure I subscribe to that - often having something publicly
available like some kind of a utility is more beneficial to everybody than
properly allotting the cost.

But I don't think it's clear cut in the case of maps, and in any case it's a
reasonable argument to make.

~~~
hawkice
So, the census needs maps (and best we are able to double check that, as it is
used to apportion representatives). But also: the modern nation-state is, in
many ways, founded on the notion of maps. A nation exists not just by itself
but instead of and in place of other government. So it's pretty reasonable to
assume public maps come from a time where e.g. the western border of the
country was fuzzy and who controlled what was information of great importance.
For instance, if it's 1823 and I'm looking to farmstead, a map both
legitimizes, in some way, American rule, and delineates reality about Comanche
raids (which were not something you'd want to bump into).

I generally like open government, but I think this particular practice may
come from a history where maps were more interesting and relevant to the
integrity of the nation-state.

------
spullara
In a world where people copyright the laws you are supposed to follow I can't
imagine they won't let people copyright an API that absolutely is a creative
work. Instead we should accept that they can be under copyright but make
implementing and using them explicitly fair use.

~~~
jobu
Book Titles are not copyrightable, even though they are arguably the most
important part of a creative work. While APIs are not a clear analog to
titles, they are a huge exception to the copyright law, and it seems like APIs
need this exception as well.

~~~
Fargren
So if I were to write a book named A Game of Thrones, under the pen name
George R. R. Martin, would it be permissible by law to publish it?

~~~
raldi
As far as copyright law is concerned, yes.

However, you would be in violation of _trademark_ law.

------
zaroth
I really do hope we can't copyright a single function signature. But then, you
expand it into an entire framework, or the perfectly designed kernel... What
is software if not a collection of API calls? There's clearly something worth
copyrighting at some point.

I think what it comes down to is it's copyright, but there's an exception for
compatibility. Like a 3rd party part in your car. You can't claim it's the
other brand's product, but you can claim it's compatible with that brand. It
happens all the time, in all industries. So why can't it be the same with
software APIs? A copyright exception for "interfaces" sounds like a pretty
safe approach.

Unless their's a patent involved preventing someone from recreating a certain
process or method, or a trademark preventing confusion, the act of creativity
itself cannot be bounded. Copyright gives rights to the creator for their own
creation. It can't prevent someone else from trying to create the same thing
with their own hands.

------
tzs
I'm a little confused by how precedent works here.

Normally, in a copyright case, the appeals court for a case heard in the 9th
Circuit would be the Court of Appeals for the 9th Circuit. The ruling of that
court would then be binding precedent for future 9th Circuit cases.

However, in this case the case in the district court was both a copyright case
AND a patent case, and for patent cases the appeals court is the Court of
Appeals for the Federal Circuit (they have exclusive subject matter
jurisdiction over patent appeals). The CAFC only got the copyright case
because it came along for the ride with the patent case.

How does precedent work when the CAFC gets something that would normally not
go through them? Do they still set national precedent for that, or do they
just set precedent for subsequent cases that are appealed to CAFC (e.g.,
subsequent copyright cases that hitch a ride on something the CAFC has
exclusive subject matter jurisdiction over)?

------
hdra
Quick question, where do Mono/Xamarin or similar projects stand on this whole
API copyright? Aren't they essentially writing a library with the same API as
the .NET or other single-platform framework? Or am I misunderstanding what
they meant with API in this case?

~~~
wmf
Yes, this case is highly relevant to Mono/Xamarin, although in practice I
think it would be suicide for Microsoft to start suing people who clone their
technology. Note that Miguel de Icaza is a signatory.

~~~
Blazespinnaker
Miguel/Xamarin is a very strong partner of Microsoft as well :)

------
Radim
Mandatory link to the _" What colour are your bits?"_ article:

[http://ansuz.sooke.bc.ca/entry/23](http://ansuz.sooke.bc.ca/entry/23)

(law vs. computer science perspective on information; go read if you haven't
yet!)

------
christianbryant
While I personally fully support this, I wonder if we shouldn't be doing this
in two stages, where the first stage is that we ask the penalties for
perceived AIP copyright or intellectual property infringement be modified.
Multi-million and multi-billion dollar lawsuits continue to be sickening in a
world where these dollar amounts could be used to save human lives. Long live
FLOSS, but we need to also be strategic and remember who our audience is.

------
judk
Why was Microsoft's J thing an illegal Java bastardization, but Google's
Dalvik/Android is not?

~~~
gdwatson
Microsoft had licensed Java, and had agreed to the terms of Sun's trademark
license, including compatibility terms. Google avoided licensing Java
entirely, hence the lawsuit.

~~~
judk
But licenses grant (limited) rights, not take rights way.

~~~
lmm
Microsoft was granted a right to use the Java trademarks under certain
conditions - conditions which it then violated while continuing to use those
trademarks, meaning it was violating Sun's Java trademark, not the copyright.
Google avoids using the Java trademarks entirely.

Trademark law is primarily to protect customers - people who bought "Microsoft
Java" (yes, it was more complicated than handing cash to MS and getting
Microsoft Java, but the point stands) thought they were getting Java, and they
weren't (the whole point of Java was "write once, run anywhere", but programs
written under Microsoft Java often wouldn't run on Sun Java). Whereas there is
no such confusion when people buy "Google Dalvik".

------
nimbosa
i Think the best analogy to this situation: Oracle (or its predecessor)
published a cookbook and it tries to indemnify anyone profiting from it, like
a restaurant or catering service that utilizes the same recipes compiled
therein..

the cookbook in itself has copyright, but utilizing the instructions from it
for your own food or business is not exactly the same as republishing the
cookbook itself or redistributing it

imagine if someone could copyright the way we make grilled cheese sandwiches

------
skylan_q
oblig: But if you can't copyright APIs no one will make them!

------
DevX101
Although these issues are very important, something feels wrong about having
the Supreme Court justices (avg. age ~70) rule on tech matters like this.

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).

~~~
kybernetyk
> avg. age ~70

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.

~~~
pdabbadabba
Yes, and remember that each justice has an office full of clerks who will
typically be in their late 20s and early 30s advising them.

~~~
stonogo
The problem is the reprehensible ageism inherent in claiming older people are
not capable of understanding technology. The same ageism you are implicitly
supporting by "reassuring" us that young people (hence, magically tech-savvy
people) will have input.

~~~
pdabbadabba
A bit shrill, I think. I don't think it's ageist to acknowledge that a lot of
technologies didn't exist when older people were born and, thus, they are less
likely to be familiar with them. That doesn't make them dumb, it's just an
accident of history. And certainly I think that a good lawyer (and amici)
should be able to explain anything the justices need to know -- the justices,
whatever else you may think about them, are very intelligent people and surely
capable of understanding just about anything, given sufficient time,
regardless of their age. (Though this time caveat is a significant
consideration. Overcoming that restriction is largely what clerks are for.)

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.

------
mooph
APIs that simplify DDOS attacks from sites with JavaScript should not be
copyrighted?

~~~
JoshTheGeek
I don't understand how copyright would help in this case.

~~~
mooph
I've created MOOPH module in JavaScript. Purpose of this module is to make it
easy to code a pseudomultithreaded application (so it can be seen as API).
This module can be used to create various creative content (games, editors,
whatever...). However one of possible pseudothreads may include quickly
content from external sites to DOM - making a DOS. If multiple users access
such project, it could make a DDOS. I hope this module is copyright protected.
I hope anyone who wants to use (publish on their site) this module must ask me
(I am author) if I allow use of this module anywhere else than on my domains
(where I've uploaded and publish my code, applying copyright).

I don't think it's a good idea to turn off copyright protection of APIs,
moving all of them to public domain. Some of them may be "public bad" instead
of "public good" if they don't get managed using license agreements.

~~~
marcosdumay
You seem to be missing the meaning of the word API. I sugest you look it out.

~~~
mooph
I've always understood API as "Application" (meaning application, program,
something similar to script) "Programming" (creating code, writing)
"Interface" (abstract definition of meaning of variables and functions,
preferably with some code that makes those meanings "live", something real,
"behind" those variable and function names). Maybe I'm wrong.

However code is code, be it a library, module, framework, API, program or
anything else...

~~~
xorcist
Code can _implement_ an API, but an API is not code. Not using any reasonable
definition of code. Code is something you are theoretically able to execute,
in one way or another.

~~~
mooph
OK, for some time I've lived in one file projects (PHP) where I've defined
interface and in the same file implemented the code itself, so I've seen too
little difference... Maybe in other projects the difference is sharper.

Is MOOPH module copyright protected?

~~~
pbhjpbhj
> _Is MOOPH module copyright protected?_ //

Most likely yes. Because you gave it a specific implementation that is not
required to make it work. The functionality - and any elements of the module
that spring directly from that functionality - is not copyrightable.

If you gave a programmer pseudo code for your module and they created near
enough the same module from it then the creative elements don't lie in the
aesthetic art and so the copyright in it is very weak.

------
forrestthewoods
This world where judges are effectively used to write laws is bullshit and it
sucks. Judicial activism sucks ass. Judges are not supposed to be lawmakers.
If API's should not be protected by copyright then we should be writing
letters to actual lawmakers who can write that explicitly into law. Not rely
on interpretation of political appointees.

Urgh.

~~~
frostmatthew
> This world where judges are effectively used to write laws is bullshit and
> it sucks.

Judges aren't writing laws - they're doing their job to "act as interpreters
of statutes and the constitution by elaborating and precisely defining the
broad language"[1]. There's a difference between "Judicial activism" and
Common Law working as intended.

[1]
[https://en.wikipedia.org/wiki/Common_law#States_of_the_Unite...](https://en.wikipedia.org/wiki/Common_law#States_of_the_United_States_.281600s_on.29)

~~~
forrestthewoods
People treat judges as a way to write laws. Many judges like to use their
powers to make rulings on what the law should be rather than is. So I'd
strongly argue that yes, in a roundabout way judges are in fact writing laws.

~~~
UrMomReadsHN
"Many judges like to use their powers to make rulings on what the law should
be rather than is."

This is by design. Its checking the powers of the other branches of government
so we don't end up with "tyranny of the majority." Without judicial review,
legislators are free to pass any law they'd like without taking into
consideration the constitution. No constitution or law can interpret or
enforce itself. Without enforcement laws are just pieces of paper. Someone's
gotta do it.

Judges have the hard issue of interpretation of laws. Someone is probably
going to disagree no matter what they do since every layman has an opinion and
laws can sometimes be unclear. Just because your interpretation is different
than theirs that doesn't mean that they are nessesarly wrong or trying to
legislate. They may even thought they were right at the time but then time
proved them wrong and then there must be reinterpretation.

"Judicial activism" is, of course, entirely subjective.

The other thing is times change. One interpretation might have worked 100
years ago but not today. The ethos of a populace are subject to change. New
technology comes along. Interpretation can change with it.

Sometimes legislatures go back and try to change the wording of laws after
judicial review to make the meaning clearer or to come into compliance of the
construction. Or even implement new laws for various reasons.

It is an imperfect system. People are imperfect. They are subject to bias and
the accepted values of the time period. The constitution and laws can also be
vague.

Some people even think the Constitution is deliberately vague in many area in
order to allow it to be a "living document" so it evolves with the times, so
to speak. Of course, like most things, this is controversial.

Congress has the power...

"To promote the Progress of Science and useful Arts, by securing for limited
Times to Authors and Inventors the exclusive Right to their respective
Writings and Discoveries." Article 1, Section 8, Clause 8

This is so vague that it practically begs for judicial interpretation.

------
justifier
> justices should review a disastrous appellate court decision finding that
> application programming interfaces (APIs) are copyrightable

when the federal circuit originally ruled i read the ruling and walked away
with a completely different understanding than the eff touts in their
headlines

this whole farce hinges on fair use stead copyrights

in terms we understand :

    
    
      checkFairUse(GOOG_USE){
        FAIR_USE=[http://www.copyright.gov/fls/fl102.html]
        for (rule in FAIR_USE)
          for ( usage in GOOG_USE) )
            if ( usage < rule )
              use="fair"
            else
              use="unfair"
        if ( use == "fair" )
          return true
        else
          return false
      }
      
      GOOG_USE=[googSRC]
      if ( API_COPY == "left" || checkFairUse(GOOG_USE) )
        print("allow legal use") 
      else
        print("penalise")
    

so alsup says that even though API_COPY==undefined the statement still passes
because he found GOOG_USE to be "fair", the federal circuit is saying
GOOG_USE!="fair"

why does the eff consistently tout copyrightability of apis? this case has yet
to rule on copyrights was alsup being clever attempting to end the suit
quickly using the mature, uncontroversial fair use clause, or was it a
spineless way to avoid making a ruling on the question that the tech community
really wants: are apis copyrightable?

slightly off topic, this whole debacle just screams avoid java at all costs
because if you write anything financially successful in the language oracle is
going to drag you through courts

