-
Notifications
You must be signed in to change notification settings - Fork 2
Dual License? #8
Comments
I'm okay with either, or both. Would be good to tackle this now before we need to build a bigger checklist. |
My thoughts exactly 👍 |
I'd like to get @TeXitoi's thumbs up too since |
The WTFPL explicitly allow to relicence. Thus there is no problem. Note that without the licence allowing it, the validation of the other contributors of structopt would be needed. |
I didn't realize clap was going to be using a WTFPL licensed dependency, but if it does without structopt itself being relicensed properly, then we might have a bit of a problem. The WTFPL does not have widespread acceptance, and I speak on this not with authority, but with first hand experience. I've used the WTFPL in projects before, and certain large corporations could therefore not use those projects. I will absolutely never repeat that mistake again. The problem with saying that the WTFPL permits relicensing is that it requires accepting the WTFPL as a valid license in the first place. Regardless of what any of us here thinks, or even what the courts think, there are large parts of the open source community (funded by corporations with reasonably unreasonable legal departments) that will not be able to use WTFPL licensed code because they've banned themselves from using it. Some might not even be able to contribute to projects licensed under the WTFPL. What that means is that I basically want nothing to do with the WTFPL in any of my projects (despite the fact that I love the WTFPL itself). It's a non-starter. I don't know if there are compromise points. For example, if structopt was an optional dependency and I opted out of it, does that mean I'm not impacted? I don't know. Probably not? I'm not a lawyer. For additional context, see my comment from reddit. |
@BurntSushi the goal is not to use structopt as a dependency, but rather to build clap_derive based on it. clap_derive will be Apache2/MIT or clap won't use it. This clap_drive plans to be a derivative work of structopt with a different name and thus clap would not have a WTFPL dep. This is simply so I don't have to rewrite the custom derive bits from scratch (which is my other option, but feels wrong). It also won't be a pure 1:1 because there may be small things that change, which should help the derivative work argument. I'm obviously not a lawyer, but does that address the concerns you have or is doing the custom derive from scratch the only way? |
There will be code, thus the actual plan does not validate @BurntSushi requirements. These is 3 possibilities to meet these requirements:
|
Well, anything is a bit strong, but I may find the motivation to relicense if it convert @BurntSushi as a user of structopt and clap-derive when it's out. |
@kbknapp I think unfortunately that if you're creating a derivative work, the ability to use a different license is... murky territory. It was murky enough that in some circumstances, I will use the original license even though it deviates from my normal MIT/Unlicense scheme. I am not a lawyer either, and unfortunately, my concerns aren't necessarily tied to the law directly, but rather, how others react and interpret said laws, which can be hard to predict. It is very possible you could create a derivative work, put it under MIT/Apache, and nobody will ever complain. (I am, however, relatively confident that if there are any explicit WTFPL deps, then someone will complain eventually.) It's definitely a risk, and it's hard to say whether I'd be willing to take it or not, which I realize isn't helpful. I'd definitely prefer not to. @TeXitoi I appreciate you trying to resolve this. I will say that I doubt ripgrep (as one example) itself will ever use structopt since its CLI requirements are a bit complex and I prefer dealing with the most native API in those circumstances. But certainly, I might use structopt in simpler CLI utilities! |
I totally understand this, and we share the same concerns. Also I'd like to point out that my intentions are for the derive portions of clap (i.e. the structopt parts) to be under a cargo feature, so it will be possible to compile without them. Like ripgrep, there are applications which have more custom needs and I want people to only be able to pull in the parts the require (or alternatively, opt-out of the parts they don't). Hence, the desire to put the shell completion script portions in a sub crate, put the Here is how I would recommend we move forward:
If the structopt devs are unwilling to relicense the code, we can re-address this by either conducting a re-write of the custom derive parts (as a last ditch effort), or make the custom derive portions of clap opt-in instead of opt-out (which I'm slightly more hesitant to do because I think it still leaves us in murky water). Thoughts? |
@kbknapp That sounds good to me! Thanks. :-) |
@BurntSushi , given that you seem to prefer dual MIT/Unlicense for your own projects, do you think @TeXitoi could dual-license as MIT/WTFPL (or tri-license with Apache or w/e)? It shouldn't matter if one of the licenses isn't recognized by all users as long as the other is, not that I'm a lawyer though. |
@bstrie Dunno. Probably? It would still need to go through a proper relicensing process where copyright holders agree to the new dial license. (AFAIK that doesn't mean a sign off from every single contributor, but just the major ones.) |
Looking at the list of contributors' additions to TeXitoi/structopt, it looks like this is the (current) exhaustive list of "proper" contributors:
Thus for full acceptance of re-licensing StructOpt's work, the above need to sign off on the re-licensing. Here's a quote you can copy-paste below:
(If this doesn't seem like an acceptable disclosure, (@BurntSushi especially) tell me so we can put an acceptable seed here!) EDIT: Moving into the StructOpt repository TeXitoi/structopt#71 |
@CAD97 since the relicensing you mentioned in this comment is about structopt, i think it is more appropriate to ask on the structopt repo. |
Well this seems to be where it's being tracked--the relicense is really about being able to license this derivative as Apache/MIT--so I thought I'd collect the information here. I'll let @kbknapp/@TeXitoi call on whether the process should happen in the structopt repo or here. I just want to get the ball rolling wherever. |
Better to do it in the structopt repo in a dedicated issue. You can remove the "in addition of the WTFPL", I prefer it simple, thus just the de facto rust license will do the job. Thanks for taking the lead on that. |
(FWIW tell me where to write the blurb, I'll do it as fast as I can) |
I was thinking of doing the pull request of the relicensing and asking everyone to approve. But do as you wish. |
To make this compatible with the great Rust ecosystem and the direction clap 3.x is going I'd propose a dual license Apache-2.0/MIT.
Permission granted:
The text was updated successfully, but these errors were encountered: