Package usage license clarifications

[canesin]

Dear developers, first congrats on this great project. Second, would be great if you can clarify the LGPL application in libmesh, can I develop a FEM code using it as shown in the examples and release it as a closed source commercial software ? Which dependencies of libmesh don't allow this, what is the license covering the "standard environment" ?

I would appreciate if these questions are answered, maybe adding it to the repository readme is a good practice.

Regards, Fábio

[jwpeterson]

can I develop a FEM code using it as shown in the examples and release it as a closed source commercial software

That's the intent, yes.

Which dependencies of libmesh don't allow this,

As far as I know, none of the software currently distributed with libmesh is LGPL2.1-incompatible. However, you should "trust but verify" this statement as I don't regularly check up on this.

what is the license covering the "standard environment" ?

Not sure what "standard environment" means in this context, but I would say probably LGPL2.1.

maybe adding it to the repository readme is a good practice.

Good point, I wasn't aware we didn't have our license information there.

[jwpeterson]

License information added in e20ac6249d7ca6b172b11a26e290a60f14cf488b

[roystgnr]

Whoa, back up a minute. There are still some exceptions to LGPL2.1 compatibility. fparser is LGPL3 (fine for most commercial purposes but not strictly LGPL2.1 compatible). Metis/Parmetis are currently Apache 2.0, which I believe is LGPL3 compatible; commercial compatible iff you don't have any patent disputes with those developers.

And worse: Laspack and Triangle have some weird custom non-commercial-compatible licenses, and would have to be configured out of any binary-only release.

[roystgnr]

And here's an oversight I never noticed before - we should contact Bill/Bob/Carter and get an official license to stick on their stuff in contrib/sfcurves.

[jwpeterson]

So I stand by my previous statement :P

I don't regularly check up on this.

[jwpeterson]

And worse: Laspack and Triangle have some weird custom non-commercial-compatible licenses, and would have to be configured out of any binary-only release.

The Triangle one is weird, but isn't completely commercial-incompatible, is it?

These programs may be freely redistributed under the condition that the copyright notices (including the copy of this notice in the code comments and the copyright notice printed when the `-h' switch is selected) are not removed, and no compensation is received. Private, research, and institutional use is free. You may distribute modified versions of this code UNDER THE CONDITION THAT THIS CODE AND ANY MODIFICATIONS MADE TO IT IN THE SAME FILE REMAIN UNDER COPYRIGHT OF THE ORIGINAL AUTHOR, BOTH SOURCE AND OBJECT CODE ARE MADE FREELY AVAILABLE WITHOUT CHARGE, AND CLEAR NOTICE IS GIVEN OF THE MODIFICATIONS. Distribution of this code as part of a commercial system is permissible ONLY BY DIRECT ARRANGEMENT WITH THE AUTHOR. (If you are not directly supplying this code to a customer, and you are instead telling them how they can obtain it for free, then you are not required to make any arrangement with me.)

[roystgnr]

Well, technically every license permits commercial distribution by direct arrangement with the author. ;-) But I suppose Shewchuk is probably much more open to such arrangements than, say, Stallman would be, so good point.

[jwpeterson]

Laspack on the other hand... yikes!

4. No fees may be charged for distribution of the codes, other than   
   a fee to cover the cost of the media and a reasonable handling fee.
5. This code, and any derivative of this code, may not be used in a   
   commercial package without the prior explicit written permission   
   of the author.                                                     

[jwpeterson]

we should contact Bill/Bob/Carter and get an official license to stick on their stuff in contrib/sfcurves.

Email sent to Bill.

[jwpeterson]

Laspack on the other hand... yikes!

@benkirk, since you wrote the EigenSparseLinearSolver, what do you think about moving Eigen in front of Laspack as the first "fall back" serial sparse linear algebra package we go to, and eventually disabling laspack by default in configure?

[canesin]

Inst the serial version of SuperLU a option ??

[pbauman]

Through PETSc

[benkirk]

I've got no issue giving eigen preference over Laspack!

[roystgnr]

Thanks for checking with everyone on sfcurves, John. Looks like that's GPL and so not-commercial-compatible either.

So it looks like, with the current libMesh, all you need to do is configure with "--disable-sfc --disable-triangle --disable-laspack" to get a commercial-compatible binary. You'll also need to distribute a bunch of copyright notices and license notices along with the binary (do we include those in a "make install"? We should...) to satisfy the various licenses' attribution requirements.

[benkirk]

Any preferences on how licenses are arranged into the installation tree? I should be able to handle that...

${LIBMESH_DIR}/etc/libmesh/LICENSENAME.pkgname

or something??

[roystgnr]

I think ${LIBMESH_DIR}/share/doc would be the standard directory to use.

Maybe either pkgname/COPYING or COPYING.pkgname for each license?

[roystgnr]

Oh, but wait - it's not just the license we need, it's the attributions.

AUTHORS.pkgname or pkgname/AUTHORS for that, I suppose.

[friedmud]

I also wouldn't mind a summary file that lists all of the names of the licenses (like LGPL 2.1 etc) for each package.

I didn't realize that we were depending on so many odd licenses like this - it's really not good from my standpoint and I think we should seek to replace a lot of these packages that will cause trouble with commercial, binary distribution...

Derek

On Fri, Apr 18, 2014 at 6:07 AM, roystgnr notifications@github.com wrote:

Oh, but wait - it's not just the license we need, it's the attributions.

AUTHORS.pkgname or pkgname/AUTHORS for that, I suppose.

— Reply to this email directly or view it on GitHubhttps://github.com/libMesh/libmesh/issues/224#issuecomment-40804309 .

[roystgnr]

I really like the summary file idea.

We've basically already got replacements for two out of the three anti-commercial packages. Metis/Parmetis beats sfcurves for partitioning, and Eigen is probably competitive with Laspack as a "default" serial solver for people who don't want to bother with installing PETSc/Trilinos.

Triangle is the remaining offender, but in that case one reason we don't have an alternative option for the functionality is because I'm not aware of any better-licensed alternatives existing.

In any case... what more should we do? Perhaps change those three configure options to be disabled by default (or even during a --enable-everything?) to prevent people from incorporating them by accident?

[benkirk]

I think a --strict-lgpl or something might be a better option than turning it off even with --enable-everything, IMHO.

-Ben

On Apr 18, 2014, at 10:19 AM, roystgnr notifications@github.com wrote:

I really like the summary file idea.

We've basically already got replacements for two out of the three anti-commercial packages. Metis/Parmetis beats sfcurves for partitioning, and Eigen is probably competitive with Laspack as a "default" serial solver for people who don't want to bother with installing PETSc/Trilinos.

Triangle is the remaining offender, but in that case one reason we don't have an alternative option for the functionality is because I'm not aware of any better-licensed alternatives existing.

In any case... what more should we do? Perhaps change those three configure options to be disabled by default (or even during a --enable-everything?) to prevent people from incorporating them by accident?

— Reply to this email directly or view it on GitHub.

[pbauman]

On Fri, Apr 18, 2014 at 11:49 AM, Benjamin S. Kirk <notifications@github.com

wrote:

I think a --strict-lgpl or something might be a better option than turning it off even with --enable-everything, IMHO.

+1 FWIW

[friedmud]

--strict-lgpl is fine with me.

How does QHull compare to Triangle? http://www.qhull.org

On Friday, April 18, 2014, Paul T. Bauman notifications@github.com wrote:

On Fri, Apr 18, 2014 at 11:49 AM, Benjamin S. Kirk < notifications@github.comjavascript:_e(%7B%7D,'cvml','notifications@github.com');

wrote:

I think a --strict-lgpl or something might be a better option than turning it off even with --enable-everything, IMHO.

+1 FWIW

— Reply to this email directly or view it on GitHubhttps://github.com/libMesh/libmesh/issues/224#issuecomment-40830468 .

Sent from my iPhone

[StefanBruens]

Unfortunately, concerns regarding METIS/ParMETIS have not been addressed yet:

• Metis is APL 2.0
• libMesh is LGPL-2.1

Both can be included in a package licensed as GPL-3.0, but a libMesh built against Metis is definitely no longer LGPL-2.1.

[dknez]

Note also that as we have discussed elsewhere ParMETIS has a restrictive license: http://glaros.dtc.umn.edu/gkhome/metis/parmetis/download

[StefanBruens]

@dknez: correct, ParMETIS has a "non-commercial by default" restriction

[roystgnr]

Oh, hell. I noticed when METIS got the new license, but I didn't realize that ParMETIS hadn't gotten the same treatment. We'll need to remove ParMETIS from --enable-strict-lgpl builds.

As for METIS itself... we're still LGPL-3.0 compatible there, aren't we, not just GPL-3.0? LGPL-2.1 isn't compatible with the patent clauses in APL-2.0, but is saved by its own "or any later version" clause.

[StefanBruens]

No, libMesh is LGPL-2.1, not LGPL-2.1+, so a combined libMesh is GPL-3.0 (smallest common denominator). See https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility

[StefanBruens]

Instead of (Par)METIS, probably scotch/pt-scotch should be bundled. (pt-)scotch is under the CECILL-C license, which is, as far as I understand but AINAL, LGPL-like, thus likely had no influence on a combined work.

[jwpeterson]

Regarding CeCILL-C and LGPL compatibility, I found the following document.

There is a graphic on pg. 16 which shows the compatibility relationships between some of the more popular open source licenses. According to the description of the graphic, "licenses placed on the same horizontal line could cohabit" (LGPL and CeCILL-B, not C, are on the same line). Furthermore it labels LGPL as "Weak copyleft" while CeCILL-C is "No copyleft".

My (non-legal) interpretation of this is that attempting to license a combined work with LGPL and CeCILL-C licensed components under the LGPL would be invalid, as it would place additional restrictions on the CeCILL-C licensed component. But I would also like to note that I have no idea what I'm talking about...

[jwpeterson]

On the other hand, the CeCILL FAQ itself states:

Q: What are the differences between CeCILL, CeCILL-B and CeCILL-C?
A: "If you distribute a program that is a modification of a program
under one of the licenses in the CeCILL family, or that incorporates
such a program, totally or partially, [and that CeCILL-licensed]
program is under CeCILL-C, you can also distribute your program
under any license but you have to distribute under CeCILL the
possible modifications you did to the original source code (and
mention the use you made of the initial program)."

The "any license" language seems overly broad to me (?) but it seems to suggest we would be allowed to license libmesh-with-contrib-ptscotch under the LGPL.

And, specifically to our case:

Q: I only modified only the Makefile of a software under CeCILL-C,
or I did nothing but rename one function. Must I really redistribute
that?
A: The spirit of the licence is that the modifications that should
be given back are the ones that could be useful for the
community. The text of CeCILL-C indicates "such that such
modifications may be carried over in a subsequent version of the
Software".

Looking at their build system, it's likely that will have to make some changes in order to automate it, but it's unlikely that they would be useful to the community at large.

[roystgnr]

it seems to suggest we would be allowed to license libmesh-with-contrib-ptscotch under the LGPL.

Not quite, I think. We would be able to license libmesh.so under the LGPL, while simultaneously distributing a compatibly-compiled libptscotch.so under CeCILL-C, but we wouldn't be able to relicense PT-Scotch as LGPL. It's basically the same situation as when you distribute a commercial code linking to an LGPL library, only here there's nothing commercial, just two mutually incompatible copyleft codes.

[roystgnr]

This isn't entirely a new situation. If you configure libMesh with --disable-strict-lgpl then you get other libfoo.so that can be linked to our LGPL code but that can only be redistributed if you also meet their peculiar licensing requirements. We ought to nearly be in the same boat even with METIS (except for GPLv3/GPLv3+/AGPLv3 exceptions) according to @StefanBruens, who I believe to be correct.

What's unique about scotch is that it's license is nearly as good as the LGPL, so we'd love to be able to enable it even with --enable-strict-lgpl, but it's not LGPL relicensable (which makes a difference, not just because multi-license redistribution is more confusing, but because CeCILL-C isn't GPL compatible, and users of --enable-strict-lgpl might reasonably expect to build GPL codes with the result).

[roystgnr]

Reopening until we get the ParMETIS/--enable-strict-lgpl issue straight.

Looking at scotch, it seems to be an orphaned project? The team and project web pages are dead, and the main page is advertising their latest release as of 5 years ago. The forge page is still active, and shows a few bugfix releases in 2015 and 2016, but nothing major. Their tracker includes 5 patch submissions in 2017, none of which has received any attention.

I harassed @bangerth, and his suggestion was Zoltan. They're also not getting a lot of recent development, but they do have the basics (parallel, 64-bit) we need, and as long as they're part of Trilinos they shouldn't be subject to bitrot at least. Trilinos inclusion also means we'd have less trouble hooking them into our build system, they're BSD licensed, and they have a shim to Scotch so we could probably use them to experiment with Scotch "under the hood" after only writing one Partitioner subclass.