Right I understand the nuances - I was simplifying for the sake of brevity.
However, "binary form" isn't the only issue. You also can't distribute
things in source form under a license that further restricts its
distribution. ie - you can't distribute a libMesh based code under NDA.
The GPL is more onerous than you believe - it's not just about what ends up
in your ABI... it's also about what can be considered a "derivative work".
Go look up the discussions about PyQt and GPL. It's a python library
using GPL. What does GPL mean to python? I mean, you don't ever
distribute a "binary" linked with that python library, right? However, it
has been decided that even though you never "link" to it... any python code
"using" PyQt still has to have a GPL license because it's a "derivative
work".
Lots of quotations in that paragraph because I don't quite agree... but the
Qt people were upset enough that they created PySide:
http://qt-project.org/wiki/PySide which is a complete reimplementation of
PyQt under an LGPL license...
Anyway - we gotta get this stuff out of libMesh... it goes against the
general principles I think most of the developers have: that we want to
create open source software that can be utilized for both open and closed
development...
Derek
On Wed, Feb 26, 2014 at 6:55 AM, Roy Stogner <royst...@ices.utexas.edu>wrote:
>
> On Wed, 26 Feb 2014, Derek Gaston wrote:
>
> How in the hell did we end up with GPL software in libmesh/contrib?
>>
>> libHilbert is GPL (says so right in the COPYING file we have for it in
>> contrib).
>>
>> Linking libMesh to that software in any way is a violation of that
>> license.
>>
>
> No, it's not. You can link LGPL and GPL software together, you just
> have to license the result as GPL, and you basically can't license the
> derived work (in this case, "any libMesh library binary built with the
> default --enable-libhilbert" or "any binary statically linked to such
> a build") as anything else. But this doesn't preclude also licensing
> non-derived works (e.g. "the rest of libMesh's source code", "libMesh
> builds with --disable-libHilbert", and probably even
> "dynamically-linked apps" thanks to the fact that libHilbert doesn't
> make it into user code or our ABIs) under other licences like LGPL.
>
>
> We should remove libHilbert from libMesh immediately!
>>
>
> Okay, your previous sentence might be wrong, but IMHO this one isn't.
>
> The libHilbert license basically prevents anyone from distributing a
> libMesh app plus all dependencies as binaries unless they compiled
> libMesh with --disable-libHilbert or they license the whole binary
> under the GPL! I don't think anyone's actually passing around
> binaries (we add new features and change the ABI often enough that you
> really want to distribute libMesh apps as source code), but the whole
> point of us choosing LGPL is that we want to allow people to do this.
>
>
> How much do we rely on it?
>>
>
> Narrowly but heavily: IIRC libHilbert is basically the only thing
> we've got that makes N-to-M restarts possible, which is a very nice
> feature to have.
> ---
> Roy
>
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
