
The Death of “Free” Software or How Google Killed GPL - jcox92
https://www.linkedin.com/pulse/death-free-software-how-google-killed-gpl-annette-hurst
======
dpc_pw
Google did not take Java code. It wrote it's own software with exactly same
API.

Any API that is "in the open" is free to be emulated. Especially Open Source
ones!

What this mean for open source software is that if I write a GPL library, and
someone can't use GPL software and writes it's own implementation to be a
drop-in replacement, it's free to do so. Which I believe is OK with everyone,
except Oracle corporate rent-seekers, that can't get over the fact, that they
can't monetize SUN Microsystems corpse even more.

~~~
prutschman
> Which I believe is OK with everyone

What's the FSF's position on this, I wonder. The whole premise of the GPL as
opposed to the LGPL is that even dynamic linking creates a derived work.

If someone creates a completely drop-in replacement for readline (I don't know
if libedit and kin are drop-in or not) and releases it under a BSD license,
there's no way to distinguish my app linking against one vs the other, I'm
simply making use of the API in the abstract.

This isn't exactly the same as the Java case, but the copyright status of APIs
per-se sure seems to have implication for the GPL's teeth.

~~~
belorn
Lets imagine that we create a third way to link software. There is static
linking, dynamic linking, and now we got this imagined third thing called
adaptive linking. In this made up linker, it magically combines the different
parts and uses neural networks (ie, more magic) to figure out how to make the
two parts communicate without a API.

Okey, in this fantasy world, do we still have the concept of derivative work?
I would say Yes. Would thus GPL still apply? Yes. Is there an API? No.

GPL is not based on the technology of linking. As a software license, it used
the concept of derivative work, distribution and other concept in copyright
law to define the scope. LGPL in contrast do specify linking technology, but
that is only an additional permission which would need to be modify if it were
to function with new linking technologies.

If you created a drop-in replacement for readline, the argument that the
complete work is readline + some code get weaker. However, if the police finds
some emails on your drive that states your intention to combine readline +
some code, and then go to copy readline by reimplemented the software in a
identical (copy'ish) way, then you might very well be infringing on the right
of the readline authors. It depend what a judge/jury think your intentions
was.

~~~
prutschman
It's an interesting thought experiment.

I agree that GPL doesn't get it's "teeth" unless linking creates a derivative
work. The FSF (and Linus) for that matter have Opinions about what
does,though, so I'm curious how and whether this ruling changes those.

I don't know whether to be thankful or not that there's still a circuit split
in the US over what constitutes a derivative work in the software realm.

------
jclulow
It's honestly pretty difficult to take an Oracle lawyer's word on what would
be good or bad for open source or free software.

------
larryfreeman
I really wish that Google had bought Sun instead of Oracle. I worked at Sun up
until 2007 and the feeling at Sun was very supportive of what Google was
doing.

Oracle bought Sun's assets and they have every right to what they are doing.
But a failed business effort to make additional fees is not, in my opinion, a
risk to "free" software.

------
dragonwriter
This is a decidedly non-factual account. In more detail:

> Google won a verdict that an unauthorized, commercial, competitive, harmful
> use of software in billions of products is fair use.

No, the only part of this description that is clearly correct is that Google
won a verdict that its particular unauthorized commercial use (that the use
was unauthorized and commercial are facts not in dispute) of Java APIs is
"fair use". While the verdict required the jury to weigh whether and to what
extent that use was harmful, a separate finding on that point was not made.

> No copyright expert would have ever predicted such a use would be considered
> fair.

IIRC, several copyright experts publicly _did_ predict that, at least, a
finding that the use in question was "fair use" was a reasonably likely
outcome after the ruling that APIs were copyrightable in the first place.

> the free software movement itself now faces substantial jeopardy.

Certainly, any ruling which restricts the scope of copyright protection or
finds broad fair use rights poses problems for enforcing the restriction of
copyleft licenses, so, while I think the concern here is exaggerated greatly,
there is _some_ impact to the GPL.

OTOH, there's very little impact to the utility of permissive free software
licenses in achieving the goals of said licenses.

> Google's narrative boiled down to this: because Java APIs have been open,
> any use of them was justified and all licensing restrictions should be
> disregarded. In other words, if you offer your software on an open and free
> basis, any use is fair use.

No, it didn't. Google's arguments included a lot of points, including arguing
that Google's use of Java _increased_ the commercial relevance of the Java,
and boosted Oracle's business. They did not argue, at any point that I can
find documented that free licensing made any use fair. This seems to be a pure
invention.

> No business trying to commercialize software with any element of open
> software can afford to ignore this verdict. Dual licensing models are very
> common and have long depended upon a delicate balance between free use and
> commercial use.

While Hurst radically misrepresents both the substance of the verdict and the
nature of the argument Google made in pursuit of it, there is some truth to
this: certainly, firms relying on an extremely broad interpretation of the
scope of copyright protection and an extremely narrow interpretation of the
fair use exception in developing a business plan around dual licensing like
the "copyleft or pay us" model, _should_ carefully consider what impact actual
rulings on the scope of copyright and fair use like this one have on their
business models.

OTOH, lots of commercial software that has an element of open software don't
rely on the restrictive nature of copyleft license as a means to upsell to
commercial licenses, instead packaging additional features and/or professional
services with commercial licenses (e.g., EDB's Postgres-based products.) These
kinds of commercial open-core systems aren't particularly impacted.

> It is hard to see how GPL can survive such a result.

Well, sure, its hard to see how the GPL could survive the rule that Hurst
fantasizes was applied here becoming generally accepted, where any use of any
software under an open-source license was "fair use". But that has little
bearing on reality.

Viewing the use of the Java APIs in this case as fair use _might_ imply that
some of the FSF's interpretation of where adherence to the GPL is required
might be wrong, but this doesn't invalidate the GPL. (It might, if well-
established in law, actually make the GPL more attractive for use, though it
would no doubt be somewhat troubling to those who see the GPL as a wedge to
force other and only tangentially-related software to be released under the
same terms.)

> Nonetheless, Google exerts control over its APIs. Google prohibits copying
> of its APIs for competitive uses.

I can't see any evidence of Google either asserting that its APIs are
protected or acting to prevent competitors from copying them. Is there any
example of this?

> In fact, Google has in the past settled with the FTC over the manner in
> which it has restricted its APIs.

This is pure equivocation (using the same term, "API", for two different
meanings.) What Google has settled with the FTC isn't over APIs-as-elements-
of-intellectual-property, it was over APIs-as-specific-services. This has
nothing to do with the APIs-as-IP issue in this case.

~~~
kazinator
When a court finds API implementation to be fair use, there is an impact on
free software, and that impact is basically positive. The idea of API's being
copyrightable threatens the status of free software projects which implement
("clone") previously proprietary API's.

~~~
dragonwriter
> When a court finds API implementation to be fair use, there is an impact on
> free software, and that impact is basically positive.

It certainly is positive for the ability to create new free software. It is
negative for the ability to control other people's actions through copyleft
licenses, since the same ability to create new free software also allows
creating new _permissive_ licensed or _commercial_ software rather than
adhering to the copyleft terms.

So, for some interpretations of the "Free Software Movement", there may be a
net negative effect (though, again I should emphasize, nowhere near of the
size or nature of that that Hurst is trying to paint.)

~~~
slgeorge

      It certainly is positive for the ability to create new free software. It is negative for the ability to control other people's actions through copyleft licenses, since the same ability to create new free software also allows creating new permissive licensed or commercial software rather than adhering to the copyleft terms.
    

Agreed. As a point of practicality I can't think of anyone whose created
'commercial' open source who depends on copyright protection 'of the API' for
their commercial elements though, can you?

It feels like the OSS ecosystem has always concluded that creating drop-in
replacements using API's are 'fair use'.

~~~
schoen
Hurst's argument would be somewhat convincing if there were people trying to
apply the GPL to prohibit, say, the Windows Subsystem for Linux (or other
efforts to make Linux binaries run natively under Windows). I don't think it
would be easy to find a consensus that that is appropriate or supported by the
law, and indeed, there's been tons of concern that proprietary software
copyright holders will try to sue people for writing new interoperable
implementations that use the same protocol or API.

Maybe there are some narrower cases involving proprietary Linux kernel modules
(which many people have suggested could be improper derived works that
constitute copyright infringement of the kernel); there this result might make
the infringement argument more difficult.

But as people here have pointed out, almost nobody ever attempts to limit
implementation or use of APIs as a "work based on the program" for GPL
purposes, almost nobody assumes that would be successful, and almost all uses
of the GPL are based on limiting the literal copying of code from one program
into another.

