Join GitHub today
snappy-java is Apache 2.0 licensed but ships GPL code #113
snappy-java is Apache 2.0 licensed,
Eclipse.org IP review found this in the context of https://bugs.eclipse.org/bugs/show_bug.cgi?id=461974
snappy-java does not distribute a pure libstdc++. See also the discussion in https://lwn.net/Articles/549573/ :
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.
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):
@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:
I think this FAQ tells me enough:
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.