License?

[hagberg]

What license will this have? I noticed there is both Apache2 and LGPL v2 code here.

[OrkoHunter]

METIS is licensed under the Apache License, Version 2.0 and I think networkx-metis should also be distributed with the same license. All the terms are permissible. So, respective Add-ons are to be distributed with the license their original code are licensed under.

[hagberg]

There is also LGPLv2 code in your pull request.

[OrkoHunter]

Indeed some of the source files use code licensed under LGPL. As suggested by @ysitu, I tried eliminating them, but two of the files seem to have an important role in the goal of this add-on. It is hard to remove them.

DOUBT : If METIS (Apache v2) can use a code licensed under LGPL v2 then, why can't networkx-metis(if licensed under Apache v2) use both likewise?

[ysitu]

The point of LGPL is that you can link to it without going LGPL yourself. But bundling it is not okay. Well I don't know enough to say more, actually.

[ysitu]

Perhaps it is okay to include the LGPL stuff after all. That is what METIS already does, which I suppose is vetted by University of Minnesota. We are not doing any worse things here.

[hagberg]

I agree that this is what METIS already does. I don't know if it is OK.

What concerns me more is that there would be some code at the networkx github site that has LGPL or other restrictive license. That might be a surprise for users or integrators looking here since the rest of the code (as far as I know) is BSD. It is intentional that NetworkX is BSD.

[dschult]

Would it alleviate license surprise to create a networkx-addons github site?

[jfinkels]

Note: the Free Software Foundation has an extensive FAQ on their licenses. Since NetworkX is a relatively large project, you might also contact the Software Freedom Law Center, the organization that enforces GPL-compliance.

[ysitu]

@OrkoHunter In private communication, we discussed a bit about removing/replace the LGPL bits. We came to the conclusion that the only essential LGPL part is the quick sort implementations. Are you able to assess the feasibility of replacing those with something like C++'s std::sort?

[OrkoHunter]

@ysitu I say that's feasible. We can work out on that!

[OrkoHunter]

All I doubt is whether it's a good practice to create our own code with the same header files and function names. But will that solve the issue @hagberg mentions about NetworkX being purposefully BSD?

[hagberg]

The concern about non-BSD code on the networkx github site would certainly be solved by a separate org. What do others think about doing that?

[chebee7i]

If we are going to demand that all addons have BSD code, then I think we'll be pretty limited. So if that is a sticking point, then a separate organization seems necessary.

I can go either way. There is a very clear license file in each repository, so I'm not too concerned with people confusing networkx-metis as being BSD code.

[hagberg]

I am not suggesting all things connected to networkx have a BSD license. But is potentially confusing to have mixed licenses around.

[ysitu]

The simpler solution is to remove the LGPL bits, which @OrkoHunter is already doing. There are just six LGPL files after all, four of which are not really needed, and the other two deal with quick sort. After this is done, we can release the whole thing under Apache License 2.0, which is not much less permissive than BSD.

[ysitu]

The LGPL parts are gone. We should be able to proceed with Apache.

[hagberg]

Nice - you guys might consider contributing this back to METIS.