search

flux-framework / flux-core

core services for the Flux resource management framework
GNU Lesser General Public License v3.0
167 stars 50 forks source link

License recommendation inconsistency #483

Closed trws closed 8 years ago

trws commented 8 years ago

RFC 2 states "Flux projects are RECOMMENDED to be licensed under GPL version 3 or later."

The flux command and associated non-linked non-interface components are licensed under GPL2, and the largest set of it, by inference from the "license for flux user interfaces" section from the same would be under LGPL (presumably also 2, though the RFC says 3 here as well).

Two actual issues here:

garlick commented 8 years ago

Let me state the position reflected in those RFC's and add that of course this is open to debate:

We consciously chose v3 at the time the licensing words in those RFC's was updated, but were forced to release under v2 (or rather convey under v2 but state "or any later version") by the lab's industrial partnerships group, which contends that the patent clause in v3 is incompatible with the lab's patent portfolio strategy. An argument was made and in theory we are still waiting for the end result. Maybe we should ping them again and try to get a definitive answer and update our RFC with a license we are actually allowed to use :-)

Regarding LGPL for interface components, there's a question of where to draw the line. Obviously MPI runtimes, tools, and applications will be licensed every which way yet should be able to use Flux, but third party Flux framework components probably should be coerced to openness some way. (There is some discussion of this in RFC 2). At the moment all we are declaring explicitly LGPL is our libpmi interface, but that will need to grow as we figure out what tools need from us.

trws commented 8 years ago

Thanks for the background, it certainly clarifies how things arrived in their current in-between state. I'm curious about the reasoning for preferring v3 over v2 though. The patent provisions in v3 along with some of the derivative work clarifications make it rather harder to convince companies to deal with it than v2, though nowhere near so much as if the affero clause had stayed in thankfully. Is there a specific provision or alteration that makes it materially preferable for this project? It sounds like an argument was provided, probably to IPO, is that anywhere I could read over the exchange?

As to what is and what is not LGPL, I have a feeling that's going to get complicated, fast. The main reason is that we currently have no way for a company or user to write a module that interacts with flux without loading flux-core, so if flux-core is GPL then they must be too. That seems potentially problematic... If the module as process setup gets finished, and we can define a subset of the interface used to communicate between modules and core without actually loading core then it wouldn't really be a problem, rather like the solution used for closed-source linux modules. Without that or perhaps a rest-ish API or similar we'd be losing a lot of potential sources of plugins, any chance of adapters for things like moab for example. I'm sure there is more than one good way to address this, but we'll need to work out how that split is going to work before a 1.0 release for sure.

garlick commented 8 years ago

There is not much written beyond rfc2, sorry. Since none of us are lawyers I felt that we should document our general intentions and concerns there as opposed to trying to be overly specific, but perhaps as a result we didn't get enough detail down. We could have another round of discussion and update that RFC with the result,. There's been a lot of Flux work under the bridge since then and perspectives may have shifted.

A concern I had before was that without some license pressure towards openness, vendors supplying extensions to Flux to fulfill a contract delivery for a big system, say, will apply a default restrictive IP policy, resulting in a) tighter constraints on our API/ABI evolution, and b) no leverage by the community at large on the fruits of that procurement.

I was picturing the portion of our interfaces that we expose under LGPL to be stable implementations of things like the launchmon interface, PMI, FTB, etc., and for there to be a "socket barrier" (carrying RFC-documented messages) between the LGPL code and the GPL core.

garlick commented 8 years ago

Also on v3 the patent clause seemed like the main attraction over v2, besides the general cleanup and modernization.

Some companies we deal with have extensive software patent portfolios. Say company A releases a Flux extension under GPLv2 to fulfill a contract, then in the next contract they lose to company B, and company B leverages the open source from the first contract. Company A, feeling burned, realizes they have a patent covering the software they open sourced, etc.

A more likely scenario (?) is that company B will be too paranoid to leverage company A's work without patent protection.

garlick commented 8 years ago

I don't think there's any action required here, so closing for now.