|
Authored by: Anonymous on Tuesday, May 08 2012 @ 04:27 PM EDT |
The names just make it obvious, especially since they are only accusing (AIUI)
the non-private elements, which need to be copied literally for compatibility
with existing code (for re-use).
Let's take java.util.Currency, for example. It's nice and simple because it has
no non-private fields. Not including inherited methods that are not overridden,
it looks something like this:
getCurrencyCode() returns String
getDefaultFractionDigits() returns int
getInstance(Locale locale) returns static Currency
getInstance(String currencyCode) returns static Currency
getSymbol() returns String
getSymbol(Locale locale) returns String
toString() returns String
If the API, including its non-literal elements is copyrightable, then I would be
infringing with a class newlang.x.A that looks like this:
a() gives Z
b() gives whlnum
c(Y y) gives singleton A
d(Z z) gives singleton A
e() gives Z
f(Y y) gives Z
g() gives Z
If the meaning of this class and the methods it exposes is the same (that is, it
provides the same functionality). We've simply abstracted the names out,
nothing has been literally copied, but you can see that the structure is the
same.
So if Oracle's crazy theory of API copyrightability is upheld, it wouldn't
matter what Google called their classes, they would still be infringing. So
it's not the literal names at all, it's the patterns underlying the names.
Mind you, I don't think that code (whether literal or non-literal elements - and
certainly not anything that's not in source format) should be protected by
copyright due to the functional nature of the work. Until more lawyers, judges,
and politicians become educated and change the law, we're stuck with it the way
it is now for at least a while, and probably, unfortunately, a long one.
[ Reply to This | Parent | # ]
|
|
|
|
|