snappy-java is Apache 2.0 licensed but ships GPL code

[jsievers]

snappy-java is Apache 2.0 licensed,
but it looks like it ships GPL code (contains statically linked libstdc++ governed by license [1])
which according to [2] is not license compatible.

Eclipse.org IP review found this in the context of https://bugs.eclipse.org/bugs/show_bug.cgi?id=461974
(we want to use plexus-archiver https://github.com/codehaus-plexus/plexus-archiver which in turn uses snappy-java).
Unfortunately as long as this license issue is not solved this renders plexus-archiver (and snappy-java) unusable for our purposes as governed by EPL license compatibility .

[1] https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html
[2] http://www.apache.org/licenses/GPL-compatibility.html

[pwendell]

This could be an issue for us (Spark) too as well as several of the Apache projects that use Snappy. I think it might be necessary for snappy-java to have a mode where it does dynamic linking rather than embedding the C++ standard library.

[xerial]

snappy-java does not distribute a pure libstdc++. See also the discussion in https://lwn.net/Articles/549573/ :

True. This exception means you can propagate (== distribute) program linked with libstc++ under license of your choice if GCC embeds bits and pieces of libstdc++ in your program. But if you propagate libstdc++.so itself then you are not propagating just such a bundle! You are propagating libstdc++.so as independent, isolated module, too and such propagation does not fall under the aforementioned exception (there are no "Independent Modules" in libstdc++.so).

This, paradoxically, means that it's safer to distribute libstdc++ linked statically rather then linked dynamically.

@jsievers
Please confirm the above explanation is correct or not. If every program that is statically linked with libstdc++ falls under GPL, what was a purpose of preparing such an exception in GPL [1]?

I think this is not a compatibility problem of APL and GPL because even if snappy-java uses BSD license, which is compatible with GPL, shipping a binary that is statically linked libstdc++ could be under GPL. If applying BSD license to snappy-java solves this, I would like to do so.

@pwendell
Preparing a version that does not use embedded libstdc++ is an option, though less portability.

[xerial]

@jsievers
Please look at this official FAQ: http://www.gnu.org/licenses/gcc-exception-3.1-faq.en.html

As long as you use an Eligible Compilation Process, then you have permission to take the Target Code that GCC generates and propagate it “under terms of your choice.”

snappy-java just uses GCC (without any modification to GCC itself), so it is under Eligible Compilation Process.

An important point is GPL and GCC Runtime Library Exception never distinguish linking methods (dynamic and static link):

While combining libgcc with GCC-compiled object code is probably the most common way the exception is used, neither the GPL nor the GCC Runtime Library Exception distinguish between static linking, dynamic linking, and other methods for combining code in their conditions. The same permissions are available to you, under the same terms, no matter which method you use.

@pwendell According to this, providing a dynamic-link version does not make much sense. As long as snappy-java does not distribute libstdc++.so itself, it never falls under GPL.

So the point is whether GCC Runtime Library Exception applies to snappy-java. I believe this applies to snappy-java.

See also the discussion for a similar case:

• http://stackoverflow.com/questions/10838807/license-of-runtime-libraries-included-in-gcc

[jsievers]

I am forwarding the legal questions to the eclipse.org IP review team as I'm not qualified to answer. Hope they will post here.

[xerial]

I think this FAQ tells me enough:
https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.license.what

c++ library uses a lot of inline functions and templates, which will be eventually embedded in the compiled objects. So technically speaking there is no difference between statically- and dynamically linked objects in that they contain a part of GPL code.

This exception is for allowing to use libstdc++ to develop non-GPL products. On the other hand, if we embed libc.so, it would be GPL since glibc is LGPL, but for c++, for the reason mentioned above there is no way to distinguish GPL and LGPL, that is why such an exception was needed. This is my understandings.

I feel there is no need to wait the third party opinion, since we already get an answer from the official site.

Let me close this ticket.

Thanks.