Skip to content
This repository has been archived by the owner on May 11, 2020. It is now read-only.

Dual License? #8

Closed
3 of 4 tasks
kbknapp opened this issue Nov 12, 2017 · 19 comments
Closed
3 of 4 tasks

Dual License? #8

kbknapp opened this issue Nov 12, 2017 · 19 comments
Labels

Comments

@kbknapp
Copy link
Member

kbknapp commented Nov 12, 2017

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:

@Hoverbear
Copy link

I'm okay with either, or both. Would be good to tackle this now before we need to build a bigger checklist.

@kbknapp
Copy link
Member Author

kbknapp commented Nov 12, 2017

My thoughts exactly 👍

@kbknapp
Copy link
Member Author

kbknapp commented Nov 13, 2017

I'd like to get @TeXitoi's thumbs up too since structopt would be a major component. Once they are good with it, we can move forward.

@TeXitoi
Copy link
Contributor

TeXitoi commented Nov 13, 2017

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.

@BurntSushi
Copy link

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.

@kbknapp
Copy link
Member Author

kbknapp commented Feb 11, 2018

@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?

@TeXitoi
Copy link
Contributor

TeXitoi commented Feb 11, 2018

There will be code, thus the actual plan does not validate @BurntSushi requirements.

These is 3 possibilities to meet these requirements:

  • rewrite, and I'll do anything to avoid this loose of time
  • get the relicensing agreement from structopt developers here
  • relicense explicitly structopt

@TeXitoi
Copy link
Contributor

TeXitoi commented Feb 11, 2018

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.

@BurntSushi
Copy link

BurntSushi commented Feb 11, 2018

@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!

@kbknapp
Copy link
Member Author

kbknapp commented Feb 11, 2018

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.

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 serde portions behind a cargo feature, etc.


Here is how I would recommend we move forward:

  1. @TeXitoi can work on having structopt proper relicense to Apache2/MIT (if that can't work, at least MIT)
  2. clap_derive will rebase on the new [Apache2/]MIT licensed code
  3. clap will only include the derive bits behind an opt-out cargo feature

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?

@BurntSushi
Copy link

@kbknapp That sounds good to me! Thanks. :-)

@bstrie
Copy link

bstrie commented Feb 12, 2018

@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.

@BurntSushi
Copy link

@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.)

@CAD97
Copy link
Contributor

CAD97 commented Feb 17, 2018

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:

I permit any contribution submitted for inclusion in StructOpt by me, as defined in the Apache-2.0 license, to be dual-licensed under Apache-2.0/MIT in addition to the existing WTFPL license.

(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

@kennytm
Copy link
Contributor

kennytm commented Feb 17, 2018

@CAD97 since the relicensing you mentioned in this comment is about structopt, i think it is more appropriate to ask on the structopt repo.

@CAD97
Copy link
Contributor

CAD97 commented Feb 17, 2018

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.

@TeXitoi
Copy link
Contributor

TeXitoi commented Feb 17, 2018

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.

@bestouff
Copy link
Contributor

(FWIW tell me where to write the blurb, I'll do it as fast as I can)

@TeXitoi
Copy link
Contributor

TeXitoi commented Feb 17, 2018

I was thinking of doing the pull request of the relicensing and asking everyone to approve. But do as you wish.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

8 participants