Earlier quoted context omitted.
This argument is hard to swallow: > declaring code would satisfy the general test for copyrightability.. they are expressed in “words, numbers, or other verbal or numerical symbols It is common knowledge that mathematical formulae & equations, which are also expressed in words, numbers, and symbols, do not have copyright protection. > Copyright protection is therefore not available for... mathematical principles; for…
When you get down to it, copyright is a whole bunch of contradictory rules. Courts decide every time there is a new kind of work, whether it is copyrightable or not. Trying to divine whether something is copyrightable by analogy to other kinds of works is a hopeless endeavour.
Google’s copying of the Java SE API was fair use [pdf]
211–220 of 965 posts
Re: Google’s copying of the Java SE API was fair use [pdf]
#212This is one of the most important legal decisions in the history of software. The US Supreme Court has basically just saved the whole software industry (and FOSS projects) from being wrecked by patent trolls.
At least in the US
Re: Google’s copying of the Java SE API was fair use [pdf]
#213Earlier quoted context omitted.
Can you copyright generated things? You probably could copyright the way you're generating it, but I doubt you have a legal standing about the generated text or melody itself.
My understanding is no. Copyright requires human authorship (the case of the monkey selfie found it to be public domain because a monkey did it, e.g.), and code written by a machine is likely to follow similar precedent and be uncopyrightable.
Re: Google’s copying of the Java SE API was fair use [pdf]
#214For better or worse, the same arguments ( "API is copyrightable" ) is what was used in the past to prevent 98's Microsoft from doing embrace-extend-extinguish to Java with their "JavaVM with P/Invoke'd Win32 API". The idea in that case was that when you try to implement something identical to the Java language and standard library, it doesn't matter if you call it Java or "Visual J++"; you are still implementing Java…
But Google (at least with respect to phone OS) was in the position of the startup, and Sun was the big market player. Now, Google had with ridiculous resources at its disposal, of course, but at the time not using a monopoly position to twist arms of carriers, for example. It's not anti-competitive to spend a lot of money to win.
Of course, things change....
Re: Google’s copying of the Java SE API was fair use [pdf]
#215Re: Google’s copying of the Java SE API was fair use [pdf]
#216> "Google copied approximately 11,500 lines of declaring code from the API, which amounts to virtually all the declaring code needed to call up hundreds of different tasks. Those 11,500 lines, however, are only 0.4 percent of the entire API at issue, which consists of 2.86 million total lines. In considering “the amount and substantiality of the portion used” in this case, the 11,500 lines of code should be viewed as…
It is fascinating that code is now being measured quantitatively. Number of "lines of code".
Re: Google’s copying of the Java SE API was fair use [pdf]
#217Earlier quoted context omitted.
It is fascinating that code is now being measured quantitatively. Number of "lines of code".
Now? I've personally heard quantities of code measured in "lines of code" (or, thousands of lines of code-- "K-LOCs") going back to the mid-90's. An acquaintance who worked for IBM in the 70's said it dates back at least that far (measuring developer productivity in the "K-LOCs" they produce).
Personally, I think the best code is the code I don't write.
A significant part of my refactoring, is removing as much code as possible, by tweaking algorithms, deriving common base classes, and removing unused code branches.
Every line of code is a potential bug. The less code, the less bugs.
Re: Google’s copying of the Java SE API was fair use [pdf]
#218Now can they please use a modern jdk on Android? It's about time
They are using a modern JDK on Android. The standard library is literally OpenJDK, and the runtime is the excellent ART JVM, which has super-fast GC and tons of mobile-specific optimizations (like zygote space support and switching to a different GC when the app goes into the background). IMHO, you really don't want HotSpot on mobile. ART is good work.
Re: Google’s copying of the Java SE API was fair use [pdf]
#219Earlier quoted context omitted.
I am not a lawyer, but I don't see why not. Have you ever used code generation as part of software you have built? Is there any reason why generated code could not be copyrighted as part of a larger system? For example, suppose I define a data model for a public-facing API and then generate SDKs in various popular programming languages to interact with the public-facing API. If I were a major corporation that owned s…
> I am not a lawyer, but I don't see why not. The involvement of actual human creativity is required for a work to be copyrightable.
So human creativity is involved, but is not the direct creator of the SDKs. Does that count? I am not really sure.
I bring up the generated SDK example because I have used just such a system when I worked at a major corporation: I created a data model in Web Services Description Language (https://en.wikipedia.org/wiki/Web_Services_Description_Langu...) and used a company-owned tool to generate SDKs in various programming languages. All of the generated SDKs had the company's copyright notice in the generated code.
Re: Google’s copying of the Java SE API was fair use [pdf]
#220While the result is a big relief, I think it's not as decisive as I'm noticing some headlines (and commenters) are claiming. One of the big open questions is "are APIs copyrightable?" The court skirted that question, and instead focused on whether it was fair use: > To decide no more than is necessary to resolve this case, the Court assumes for argument’s sake that the copied lines can be copyrighted, and focuses on…