> Those in Oracle's camp say if its copyright is not protected, that will discourage innovation.
Look at the way YouTube Content ID encourages innovation and then imagine GitHub Content ID.
“Your repository contains 3 copyrighted method calls. You’ve been issued a copyright strike.”
I’d love to see every open source repo on the internet go private for 1 day as a demonstration of what could be lost if copyright is allowed to weasel its way into APIs.
GitHub and NPM should give users the option to block their repos for a day. A bazillion failing builds would open some eyes IMO.
Then imagine the outrage from European companies and users getting hit by this ludicrous US copyright thing that doesn't apply to them (the European court rejected oracle claims long ago).
To add to this, EEA members still have to comply by EU laws. Norway and Iceland are EEA members. Switzerland is not, but it has made a separate deal with the EU that has almost the same content as the EEA deals (idk the differences in detail).
It applies to them the same way the GDPR applies to American companies: If they have sufficient money in the US which can be hit by a judgement, it applies.
Wine's userspace being legal is probably what keeps the gamers from just running the available userspace source code from Microsoft. I doubt getting it banned would be something Microsoft actually wants.
It's an interesting perspective. Microsoft already promised not to harm Mono, so if the lawsuit is won by Oracle, it's certainly possible for Microsoft to promise not to harm Wine as a PR move without addressing the actual issue, and this strategy can actually work better for Microsoft to keep its control on APIs! It can be similar to how Apple had broadened the scope of its repair program to weaken the Right to Repair movement.
But unless Microsoft actually embraces Wine, that would still leave the project in a weird legal gray area. Will e.g. Valve want to support the project, knowing that at any moment Microsoft could theoretically have a shift in strategy and become litigious?
anyone who believes that GPLd dynamically linked libraries impact code written to use them effectively believes that APIs can be copyrighted. (ex: the FSF believes this).
Those two are complete different concepts within copyright.
Oracle claim is that google copies of header files requires copy right permission, with google saying that header files are either not protected by copyright or that using them is fair use.
FSF claim in regard to dynamically linked libraries is that using them in a work creates a derivative work. For C code, software without its dynamically linked libraries won't even load past the linker, and in their view, a judge/jury will see the program as a single work rather than two independent works.
This court case will not define what is a derivative work or when two combined works should be seen as independent of each other. It may explore the limits of what is copyrightable and what is fair use, which is interesting in terms of API's and compatibility but less so for defining the limits of the GPL as an copyright license.
You don't just dynamically link a library. You link it and then use its API, it's precisely the using of the API that creates the derivative work (if you accept FSF's position). I don't see how e.g. calling dlopen() on its own but not using the API could create a derivative work any more than calling fopen() does.
The original case for RMS when he created the position for dynamically linked libraries where when apple created an GCC version that had a Objective-C frontend. RMS initially did not think this would be covered by copyright but after talking with the lawyer Eben Moglen he got the following explanation: A judge would unlikely see it as an objective-C fronted as an independent work that is talking with GCC, but rather just a compiler. That compiler would be the work, and thus a derivative work since it combines the GCC code and the objective-C fronted.
Nothing in there is about API's. There is also nothing about linking. It just about what a judge would perceive as being "the work". FSF however do seem to have a policy about enforcing the license at the technical distinction of linking, but that is just a policy decision based on where they think a judge would likely side with them. Apple were free to go to court arguing that it is not a compiler but rather different independent works simply communicating with each other, but they chose not to do so.
hmm. I had a discussion about dynamic linking with Eben years ago, and my memory (hazy as it might be) what that he implied that it was coming from the FSF, not from him (at least the libreadline argument). But as I said, this was a long time ago. (probably 15 years at least).
Apple could have decided it wasn't worth the fight, i.e. the benefits of thei front end being GPLd or not being GPLd in the end made no difference, so no reason to fight it.
I heard that version about Apple and the Objective-C frontend case from Stallman during a talk at Gothenburg if I remember right. He consulted eben moglen and based on that change his opinion. It is possible that Eben consider the decision to still be Richards, which technically it was.
When it come to apple I strongly suspect there are a few things companies like them will try avoid putting lawyers and money on. What is the definition for derivative work and what is the definition of fair use. If you do want to stake money on that you likely want aspects of the case being stacked in your favor, and basing the majority of a product on a GPL code base is not that. A single function call to libreadline would likely be more favorable, but a company like apple would just rewrite such trivial amount of code.
You may be right, but can you supply a citation for this? I believe many open-core software vendors work around this idea by doing exactly what you suggest: creating an API barrier where the proprietary software lives on one side and the GPL'd software on the other. It requires some care so you don't cross GPL'd software into the proprietary side, but it's fairly common. I think the Linux Nvidia GPU driver works this way.
It's called a GPL condom, and that's a bit different in the end in that the GPL mandates GPL'ing code that links against GPL symbols. It's more of a contract than copyright. If you want to use these in your code, you must GPL, or reimplement at your leisure!
That's less Copyright in the sense that it's mandating the relinquishing of monopolistic control of the work product in question to the public. Oracle wants the opposite. They want Java used everywhere, and the right to sue anyone who does anything too similar to it too.
This is absolutely an act of monopolistic market shaping. No smaller firm would ever have utilized this nuclear option of a lawsuit given the widespread damage this could potentially cause to the entire software ecosystem.
This would honestly be enough to get me moving completely out of Software if the Court screws the pooch on this badly enough.
I'm not spending the rest of my life debugging code that as a matter of fact must be run through obfuscate steps to avoid copyright liability.
I agree that many create that API barrier (ex: ZFS on Linux). Those that argue that ZFS on Linux is legally problematic agree with the FSF's definition (which I would argue leads to the belief that APIs are copyrightable). Those that think ZFS on Linux is on a fine footing believe that APIs aren't copyrightable and one can create a shim to decouple your non GPLd code from GPL "libraries", especially if the coupling that ends up happening is never distributed as done by the end user.
Yes, that's exactly what I was looking for. Thanks for the read, it was very interesting. I thought this was a settled matter, but it looks like I was wrong.
if I distribute the GPL library (say libreadline) with my app, I'd probably agree with you.
If I expect the end user to have libreadline installed on their machine (from debian / redhat repos, and for argument sake Debian/Red Hat/et al aren't distributing my app), I think I'd disagree. I'm not distributing any GPLd code.
I think its a bit more complicated if Debian/Red Hat are distributing my non GPLd app that links against a GPLd library that they also distribute, but aren't really distributing them together. The reason I say this, is because even though they are "distributing" both "together", we wouldn't say that GPLd code and BSD code that they "distribute" "together" infects the BSD code.
I might also agree that its not exactly the same issue, but I do think it should make one think about it.
If you explain to a judge the difference between distributing a library and app code to the user, and expecting the user to download the library themselves and then you combine the app-code and the library afterward, will they care or will they see the two methods as being practically identical in terms of forming a single derivative program out of the library and app-code.
In the past people argued that streaming could not be copyright infringement since the recipient never received a copy of the movie. Courts however did not see much of an meaningful distinction between streaming a movie and downloading a movie since the experience from the user were close to identical and the perceived impact on the publisher were also identical.
During a conference I recall a lawyer explaining that a judge does not like arguments that try to use tricks to walk around laws. It makes the judge look like a fool and that annoys them.
except in the case of libreadline, its highly likely that any Linux user (i.e. bash depends on it) already has the library on the system. I'm not distributing it.
But lets get into the weeds a little. Lets say I am distributing it according to all definitions. I'm allowed to distribute GPLd material. I'm allowed to distribute non GPLd material. I'm allowed to distribute them together even (say a linux CD without the GPL impacting the rest).
The question the judge would have to answer, is the non GPLd portion a "derivative work" of the GPLd portion and is that derivative work being distributed. I'm not so clear that this the case unless one really believes that APIs can be copyrighted (then it is clearly the case).
As a simple example: lets say we accept that it is a derivative work, but then lets say I made a replacement version of libreadline that was ABI compatible (but not feature complete) with the original one, so hence my program can be dynamically linked against both but it will be a better end user experience if they use the GPL version.
To provide a somewhat more concrete thought experiment (concrete as an ABI copatible reimplemntation under a different license, thought as its making up a fact):
imagine microsoft dual licensed windows with GPL and not and they believed that if one wanted to ship a non GPL program one had to pay them a license fee to keep the program not GPLd. Now, as wine has implemented the required APIs to run my program, can I ship a non GPLd program where I refuse to license the right to be non GPLd from Microsoft that will still run on Windows? Does it change because wine exists (i.e. the answer would be different if wine didn't exist) and if so why? This case isn't to nitpick how windows is different than libreadline or the like, but just as an example of ABI compatible non feature complete implementations can exist.
> The question the judge would have to answer, is the non GPLd portion a "derivative work" of the GPLd portion and is that derivative work being distributed.
Technically the derivative work is the combination of the two, not just the non-GPLd portion. Part of the argument that a lawyer would have to do is to define what "the work" is, and arguing distinction in linking technology might not be that great strategy to an non-technical judge or jury. If you present a video player what people likely will see as the work is the video player, not some independent code, independent glue and 20-30 independent library dependencies. As programmers however we might see things a bit different in the same way a painter will look at paint on a canvas.
However I would agree that if there exist multiple interchangeable libraries the argument for two independent work seems to be much stronger. There are for example multiple libc implementations, and for those one could make a case that a program and its libc dependency does not create a derivative work. In practice however I doubt such argument would be much of a benefit in real GPL infringement cases.
The wine project has a rather strong fair use clause regardless of the outcome of this court case, since it would be a rather difficult argument for Microsoft to argue that wine has caused considerable commercial damage. Basically every point of fair use is applicable here, from "Purpose and character of the use", "Amount and substantiality", "Effect upon work's value" and additional values like acknowledgement of the copyrighted source (if the API is copyrightable). Wine is a compatibility layer, not an re-implementation. Courts would naturally have to consider if that distinction is relevant but I suspect they would have a much easier time than java on android.
I think there were some legal fighting over PHP and the Mysql client over that exact issue. PHP generalized their interface and was deemed not derivative, but I don't know what kind of judgment it got.
> If I expect the end user to have libreadline installed on their machine (from debian / redhat repos, and for argument sake Debian/Red Hat/et al aren't distributing my app), I think I'd disagree. I'm not distributing any GPLd code.
Well, IANAL, but I fail to see how you are bound by the GPL in any way on that situation.
There used to be a market of proprietary software patches, that fixed stuff the software creator didn't bother changing. AFAIK, nobody ever contested its legality until EULA came and made it illegal to the end-user (instead of the distributor). There is a famous guy who sells proprietary security patches for Linux, isn't there? Your example is much clearer than patches.
The situation of RedHat distributing both isn't as clear.
I think I'd personally put the line a bit farther. If you distribute libreadline, that would be fine without GPLing the main program. If you make any check to verify that you are running a specific version of libreadline, then that is not fine, because you are preventing me from replacing it with a different version.
This is a complete dramatization. Are you copying 10k lines of code from a licensed code base into your project without permission and using it in your commercial product?
Github projects already should strive to use correct licensing, and comply with the license of code they use. There is nothing new here.
You don't understand what this case is about. This is about copyrighting API descriptions. Not copying code, but reimplementing an API that someone else created. Think about how many people created each part of the various web APIs. Is XmlHTTPRequest now owned by Microsoft? Who invented the Blink tag? Who owns which parts of the SQL language? The entire software industry is built on the idea that APIs are not copyrightable. If you thought software patent trolling was bad, buddy, you ain't see nothin' yet.
hehe this is the correct answer. basically if i make my own FileWriter class and choose to name one of the methods in that class "write()", then I'm infringing on Oracle XD
Using String as a ProgType(tm)? That's a paddlin'. We use CharGroup around here, which we are willing to license for a small fee. For a limited time, get 10% off when you license three or more ProgTypes(tm)! Indemnification licensed separately. Contact our enterprise relations desk for details.
And then when you contact them it goes to voicemail, they call you back 9 times 3 days later and sell your email address to everyone under the sun :)
OH and then when theyre about to drop in stock price because they dont know how to deliver valuable products, they use the US government to force other companies to buy their product otherwise the US government will kick that prospective customer out of US markets ^.^
This is why clear copyright and licensing is so important. Unless something is in the public domain, don't use it unless you have permission.
> The entire software industry is built on the idea that APIs are not copyrightable.
The entire open source movement was built on copyright (ala FSF and the GPL). So this doesn't even make sense. It's not anarchy as you imply and copyright has a purpose.
Also, copyright is far more limited than patents. Patents are dangerous because it's like claiming ownership over a mathematical formula that anyone can derive. It's completely different.
11k Lines of code seems like a lot especially if you're insisting that it was just wholly ripped out of an existing codebase but that isn't the case here at all and even Oracle make that clear in their analogy:
>It says what Google has done is like taking key parts of those books — chapter titles, character names, the first sentence of each paragraph — writing a new book, and selling it.
If you're reimplementing APIs as Google has done then at some point you _need_ to copy the structure of the existing API, the method signatures, the names of the methods, the descriptions of what they do, etc, and while you may be able to dig out a thesaurus to claim enough original creative work at some point it's all for moot because there's only so much you can do before you'll start infringing upon Oracles creative expression of their API which severely limits what you are able to do with it.
If Oracle wins this case it will have huge implications for any reverse engineered work like Wine or graphics drivers where such projects will cease to exist, because it won't actually matter if it's 100% your own implementation as any interface to existing APIs or hardware _will_ infringe upon other companies copyright.
As far as Youtube Content ID goes it doesn't actually matter if it's 3 seconds or 3 minutes of copyrighted work, if it's matched then Youtube will let those companies claim revenue from your video which may be an hour long. The alternative here is the legal system and courts which may absolutely agree that 3 seconds of use in an hour long video is fair use, but you're still going to end up in court to defend that usage. It's unlikely that Oracle has enough sway to force Github to implement a similar content matching system but if they did it doesn't really matter what threshold the courts set for fair use for reimplementing APIs just like it doesn't matter for Youtube, best make sure all your repos don't use something like XMLHttpRequest() or your repo may disappear, and of course if Oracle doesn't have the sway to force Github into implementing such a system you're still going to have to go check through all your your repos because if they feel you've infringed upon their creative work they'll be able to issue takedown requests and your only recourse will be through the courts.
I'm not sure it is. Given that an original API might have a single method with the same signature as one used in a copyrighted API or the malicious actors we have in this industry, I can see the problems with YouTube Content ID coming to GitHub.
Look at the way YouTube Content ID encourages innovation and then imagine GitHub Content ID.
“Your repository contains 3 copyrighted method calls. You’ve been issued a copyright strike.”
I’d love to see every open source repo on the internet go private for 1 day as a demonstration of what could be lost if copyright is allowed to weasel its way into APIs.
GitHub and NPM should give users the option to block their repos for a day. A bazillion failing builds would open some eyes IMO.