Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Apache license #610

Closed
4 tasks
j-wags opened this issue May 29, 2020 · 3 comments
Closed
4 tasks

Add Apache license #610

j-wags opened this issue May 29, 2020 · 3 comments

Comments

@j-wags
Copy link
Member

j-wags commented May 29, 2020

Some users have asked whether our software can be used under different licenses. In particular, some people are most comfortable working with Apache-licensed software. I don't have any problem with this, and other efforts seem to have a way to present multiple licenses and say "here they are: pick one". So, this issue is to:

  • Figure out the wording/legal mechanism to declare a "pick one" license system
  • Figure out what sort of consent we need to get from this repo's contributors
  • Actually gain those consents
  • Open a PR to add the new license and the "pick one" mechanism
@j-wags
Copy link
Member Author

j-wags commented Jul 15, 2020

Based on a lawyer's unofficial comments, multi-licensing is very complicated and can have far-reaching consequences. I'll wait for another request to prioritize this.

@j-wags
Copy link
Member Author

j-wags commented Sep 21, 2020

Update: Based on a lawyer's somewhat official, written comments, multi-licensing is very complicated and can have far-reaching consequences. We should not naively dual-license this codebase. I think two ways to move forward on this are:

  • If we do want to provide this code under the Apache license, consider a structure like "sub-releases", where during each release, we make a standard (MIT) release, and then modify that, and produce a descendant Apache release. I don't fully understand the details of this, but it was implied other orgs seem to use a mechanism like this to safely dual-license.
  • Currently a license change would require tracking down and gaining agreement from all historical contributors. If OpenFF can become its own legal entity, it can own things. So, if OpenFF ever becomes a standalone OSS organization, we should ask the contributors to this codebase (myself included) to give ownership of their contributions to that organization. We would also want to begin including cpython-style contributor agreements in PRs from new users to ensure they understand that the OSS organization owns the code.

@mattwthompson
Copy link
Member

There hasn't been movement on this in three years so I have to say it's not likely to move anytime soon. If we truly want this we can hire lawyers ourselves and act on it

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

No branches or pull requests

2 participants