Google did not take software (other than rangeCheck), they took interfaces.
That said, it is common wisdom around F/OSS folks that you can't take other people's interfaces and change the license on it, e.g., I can't write and distribute a proprietary Linux kernel module using EXPORT_SYMBOL_GPL functions. I haven't seen a good analysis of whether this case is relevant to that—would a Google victory mean that VMware's use of vmklinux is legal (well, at least in the US), that ZFSonLinux is in the clear, that Nvidia can write proprietary drivers using dma-buf, and that CLISP should have been able to use readline without relicensing itself under the GPL?
> I can't write and distribute a proprietary Linux kernel module using EXPORT_SYMBOL_GPL functions.
That is because by using EXPORT_SYMBOL_GPL functions you are invoking code that is GPL'ed. If you made a clean room implmentation of a kernel that exposed the same interfaces as Linux, you could licence it anyway you want.
By calling any kernel API you are invoking code that is GPL'd. It is not like EXPORT_SYMBOL functions are BSD-licensed (and even if they were, they themselves call GPL-licensed code). In fact even making a normal system call from userspace invokes GPL'd code.
So I think there are only two interpretations. One is that EXPORT_SYMBOL_GPL attempts to claim a copyright on the interface, and not the code. The other is that redistributing a GPL-incompatible object that invokes GPL'd code is always infringement, and (possibly) the special exception for userspace in Linux's copyright statement, https://github.com/torvalds/linux/blob/master/LICENSES/excep... , is the only thing that makes normal userspace processes non-infringing, and that regular EXPORT_SYMBOL is basically also an explicit exception (which may or may not even be legally meaningful - during the dma-buf discussion, various copyright holders expressed that they did not interpret EXPORT_SYMBOL as an exception).
>By calling any kernel API you are invoking code that is GPL'd.
What does this have to do with anything? If you think this is a relevant statement you are severely confused about the current subject matter and what is being argued in court.
Please explain how the above statement is relevant to the current case.
That sentence is a reply to the comment above it, which states, "That is because by using EXPORT_SYMBOL_GPL functions you are invoking code that is GPL'ed."
My claim is precisely that this is not a relevant statement.
On a legal level, no, that's not a mistaken belief. Prior to this case, that was in fact the legal consensus. Given this case, it's only a mistaken belief if the Supreme Court decides for Oracle (or declines to take the case).
Yes, that is exactly my contention. An interface is no more software than a recipe is food, than a credit card statement is money.
From a technical perspective, interfaces in, say, C are mostly compiled out. There is no place in a (stripped) binary where you can point to a structure definition. There is a place you can point to names of functions that are yet to be dynamically linked, but only their names, that place is different from the program code (text section) itself.
None of this is to say interfaces are not an important part of software engineering. Interfaces, APIs, internal zero-cost abstractions, tests, comments, design documents, threat models, bug triage, commit messages, code reviews, operational techniques, runbooks, monitoring and alerting systems, end-user documentation, etc. are all important work products in the discipline of software engineering. They're also all (IMO) something different from the software itself.
> Please explain to me the fundamental difference between an interface and what you consider software.
"Software" is code. An interface is the expectations of code.
In particular, if software X implements interface A, it is possible to write a compatible drop-in replacement of X using software Y, which does not incorporate any portion of software X, is it not?
GNU libc and Apple libc both implement the UNIX libc interface. If you claim that an interface is indistinguishable from software, is there a portion of the GNU libc software that also present in Apple libc? Where is it? Can you point to it? (The source code of both is public, so this should be easy for you to do.)
Google gave another example in the blog post: the interface of keyboard shortcuts. If I implement a text editor that uses Ctrl-X for cut, Ctrl-C for copy, and Ctrl-V for paste, have I copied the software of another text editor that uses that interface?
> An interface in all its various forums as we understand interfaces are placed in binary. From object implementations to ABI's and API's.
An API, an "application programming interface," is distinguished from an ABI, an "application binary interface," precisely because it does not mandate what appears in the binary.
If you think that there is in fact a way where you can point to a structure definition in a compiled C object file, please identify where it is in this object: https://godbolt.org/z/SVhsJk
I agree with you: the interface is represented in actual binary format. But Google didn't copy that either. Dalvik doesn't even use the same binary format as Oracle's JDK.
That said, it is common wisdom around F/OSS folks that you can't take other people's interfaces and change the license on it, e.g., I can't write and distribute a proprietary Linux kernel module using EXPORT_SYMBOL_GPL functions. I haven't seen a good analysis of whether this case is relevant to that—would a Google victory mean that VMware's use of vmklinux is legal (well, at least in the US), that ZFSonLinux is in the clear, that Nvidia can write proprietary drivers using dma-buf, and that CLISP should have been able to use readline without relicensing itself under the GPL?