No, it's a different issue. When you take a GPL (not LGPL) library (not an API, an actual piece of software) and "use it", you're creating a derivative work of that library. The only way to license such a work is under the GPL. Because if you don't, you don't get a license to use the library (not the API, the software) under copyright law. But it's the copyright on the software that is the teeth here. In principle you could distribute your code under GPL-incompatible licenses, but only as a piece of useless source code. Anyone who wants to ship useful software needs to abide by the copyright of the software they use.

What Google (really Harmony) did is mere cloning. They (very) expressly didn't use Java the software, only the "Java API".

> In principle you could distribute your code under GPL-incompatible licenses, but only as a piece of useless source code.

It's not useless. Your customers can compile it, and link it to the GPLed library. After all the GPL allows you absolute freedom of use, as long as you don't distribute the derivative work.

No, the point is that your code is the derivative work. If you distribute it to the customer with the intent of it being a useful integration, you can only do so legally under the GPL. The GPL library owner could sue you to stop that distribution.

Obviously there's some gray area if you, say, publish your code in the context of fair use (as an academic paper, say) and someone else does the integration work without your blessing (this is what I meant by "useless piece of source code"). But simply saying "build it yourself" is not a get out of jail free card for the GPL.

If my code just uses APIs from a GPLed library, how is it a derivative work? APIs aren't copyrightable (yay).

In my understanding only the compiled result which links to the GPLed library is a derivative work.

The GPL never forbade creating a nonfree library with the same interface as a free one.

That's my reading too, though I remember someone who wrote a MySQL API layer that was not libmysql was accused of violating the GPL. Amusingly, MySQL is now an Oracle product (though I'm not sure it was at the time).

It had been MySQL's standard MO for a while. Their point of view was you either had to completely open source your product, or you had to pay them lots of money. Using it in an in-house webapp, or as you mentioned, reverse engineering the API, would get them knocking on your door threatening to sue you.

Which is, incidentally, not too far from how GNU/Linux came to be - a free OS with the same interface as a nonfree[1] one.

[1] AT&T was legally required to provide the source code of its OS 'for free', I'm not sure if the terms actually qualify as 'free-as-in-freedom', hence the impetus to create an alternative implementation.

This posts siblings are correct - the GPL can forbid linking because it is a condition of you being able to use the library. Reimplementation of a GPL library to be distributed under different terms is certainly permitted, and has happened (see readline).

There is still some debate -- and this case didn't touch it -- over linking and derivative works. Static linking pretty clearly involves something that requires a license from the copyright holder, but dynamic linking is far from clear. The GPL basically asserts that dynamic linking makes a derivative work, but there's no guarantee that this is how copyright law would actually be interpreted by a court.

There is more to it than just the technical nature of the linking, though - the court would take into account all of the circumstances of the claimed infringement.

For example, if you distributed your commercial software packaged up with a GPL library, with scripts or links or whatever designed to have that library loaded together with the commercial binary as part of a finished product, then the "dynamic" nature of the linking might well be considered to be a technical irrelevancy.

On the other hand, if you distributed your commercial binary on it's own, and expected your customers to find a compatible library to dynamically link against it, then that might be a different matter.

The second case is the more common one, and has come up a few times. See, for example, debates over whether code written to a generic readline-esque API must comply with readline's GPL, even though non-GPL alternatives are available.

So if you code against a GPL library, but don't distribute that GPL library with your code, are you still bound by the GPL? According to the GPL license itself, it seems so, as long as there is not other library that implements with the same interface. But what part of copyright law makes this possible?

Do people distribute their non-free code, which then, somehow bootstraps GPL libraries (from GPL sources)? Would that be compatible with the GPL, or is there a provision against that?

Any project that builds using Maven does that all the time!

(And really it's not simply a question of "non-free" -- there are plenty of open source licenses that are incompatible with the GPL. Is this technically a workaround for the incompatibility between Apache v2 and GPL v2?)

But a non-free villain could bootstrap a build using Maven without even publishing their source at all -- just keep a Maven repository with their binary jars and and a pom.xml that specifies dependencies on a whole bunch of GPL libraries.

Is there a provision against it? I hope so, but I haven't found it yet.

http://wbillingsley.blogspot.com.au/2012/06/does-oracle-v-go...

Presumably, if proprietary code isn't linked with GPL code, it's not a derived work, but two separate works under different licenses. If your situation can tolerate it, you might could write a gplserver running in a separate address space. Or, if it's hardware to hide, video drivers frequently provide a razor-thin kernel driver that does little more than let you mmap the device's I/O space, with all the action sequestered in a proprietary userspace library.

c.f. rlwrap

You're still linking in the free software. If dynamically linking the normal way would be verboten, I can't see why dynamically linking that way would be any different.

I suppose linking to a library is quite different case than re-implementing it with the same interface.

> re-implementing it with the same interface.

That is, after all, what the GNU project was created for.