|
Authored by: Anonymous on Tuesday, May 08 2012 @ 01:44 PM EDT |
The simple answer is because it is all written (or caused to be written) by
human beings and then extracted by a program.
I'm not sure which copyright law you are referring to in terms of machine
generated works, but I don't think that that is settled law anywhere (at least
not in the common law world, including England) except maybe (IIRC) Australia -
and even then I think that there are arguments that weren't made in the
Australian case that may be persuasive to overthrow the decision.
Also, there is the question of which was written first: the spec or the code.
These things usually evolve organically somewhere between fully spec out ahead
of time and fully derived from the code.
Also, Oracle is raising the issue of copyright in the API - which is something
else entirely, and is not computer generated. Let alone that APIs really only
exist in the heads of human beings.[ Reply to This | Parent | # ]
|
|
Authored by: PJ on Tuesday, May 08 2012 @ 02:07 PM EDT |
The jury found that Google didn't infringe
the documentation.[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Tuesday, May 08 2012 @ 04:46 PM EDT |
I'm pretty sure "generated code" has copyright protection, otherwise
the whole software industry that have been selling compiler generated machine
code will find themselves in deeper troubles than it has today (very few would
hand code the instructions byte by byte nowadays).
At the very least, it would be considered derivative work of the original
source. Otherwise, I could even argue that what a typical programmer write using
a simple text editor is not copyrightable "machine generated code" as
well, since most likely said programmer don't actually key in, number for
number, each character that ends up in the source file for a program, and the
text editor has to "generate" the file when it is saved (not to
mention in an "IDE" set up, many times the structure of the source
code is guided and sometimes even pre-generated).
It wasn't always the case that software as we know today was copyrightable,
maybe two decades plus ago I suppose, but I'm pretty sure whatever that is
generated from a tool is potentially copyrightable with the same caveat for all
other potentially copyrightable works (fair use, ... etc).[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Tuesday, May 08 2012 @ 05:04 PM EDT |
Yes, No, mostly No.
For example, we write specially formatted comment code, just before the code of
a method, which contains the descriptions of the paramaters, return value, and
usage of the method. This is read by a program (javadoc), along with the method
signature and parameter names, to generate the documentation for that method.
So, part of the documentation is machine generated, and part is human written.
The machine generated part is only a little bit useful without the human written
part. The value of the documentation is in the human written part.
[ Reply to This | Parent | # ]
|
|
Authored by: jbb on Tuesday, May 08 2012 @ 07:19 PM EDT |
The judge made a distinction between compilable code and source code comments.
They were both copyrighted. The source code comments are what get turned into
documentation.
Oracle only showed 3 examples of copying in the
comments/documentations and none of those was literal copying. I'm not sure if
this was part of the judge's instructions but the copyright protection on such
documentation is "thin" which means the plaintiff needs to show there was
literal copying. There was no literal copying so Google easily won on this
point.
One thing I find interesting is Oracle was also suing over the SSO
of the documentation. The judge tossed this out (presumably via a rule-50
motion from Google right before deliberations were to start) so the question
never got presented to the jury. This puzzled me because it was clear there was
no evidence of literal copying (which got sent to the jury) but the SSO was
copied (but got tossed out by the judge). I'd bet that if the judge told the
jury that the SSO of the documentation was protected by copyright then they
would have found that Google infringed it.
It seems extremely bizarre that
the SSO of the APIs would be protected by copyright while the SSO of the
documentation would not. If anything, I would have expected it to be the other
way around. One argument Google made to get rid of the documentation SSO
complaint was that the SSO of the documentation comes from the SSO of the APIs
so there was no need for them to be penalized twice for the same infringement.
If the judge accepted this argument it would explain why the jury never got to
consider the SSO of the documentation.
--- Our job is to remind
ourselves that there are more contexts
than the one we’re in now — the one that we think is reality.
-- Alan Kay [ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Tuesday, May 08 2012 @ 08:13 PM EDT |
The javadoc tool extracts certain comments from .java source files and
reformats them into HTML. Humans write the comments. Here's an example, one
function from FNV.java, a source file that I wrote 10 years
ago.
/**
* Update an existing 64-bit FNV hash with one
more byte of data, using the
* FNV-1a algorithm.
* @param value
FNV hash of previous part of message, or the FNV
* 64-bit initial
value
* @param datum the next byte of data
* @return the FNV hash
of the message with the datum
*/
public static long update(final
long value, final byte datum) {
return ((datum &
0xFF)^value)*PRIME_64;
}
javadoc recognizes comments
that begin with "/**". The comment continues through the following "*/". The
"@param" starts a description of a parameter of the function. The "@return"
starts a description of the value returned by the function. javadoc reformats
the above into HTML that looks like the following when displayed in a browser.
To get it to display properly, I've replaced most of javadoc's tags with HTML
tags that groklaw supports.
update
public static long update(long value, byte datum)
Update
an existing 64-bit FNV hash with one more byte of data, using the FNV-1a
algorithm.
Parameters:
value - FNV hash of
previous part of message, or
the FNV 64-bit initial value
datum -
the next byte of data
Returns:
the
FNV hash of the message with the
datum
Anyway, javadoc doesn't make up
documentation from uncommented source code. It just rearranges and reformats
what the programmer wrote. (The comments have no effect on the binary output
from a Java compiler reading the source file.) [ Reply to This | Parent | # ]
|
|
|
|
|