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

[RDY] Add LICENSE #883

Merged
merged 1 commit into from Jun 26, 2014
Merged

[RDY] Add LICENSE #883

merged 1 commit into from Jun 26, 2014

Conversation

justinmk
Copy link
Member

Followed the pattern of nodejs/libuv. License is MIT "expat" Apache 2.0.

Moving forward with MIT Apache 2.0, but I think it is advisable to to ask contributors to sign a CLA to move existing contributions to MIT Apache 2.0. Any contributions that are not approved for MIT Apache 2.0, remain under the Vim license. Existing Vim code and Vim patches also remain under the Vim license.

Reference:

Neovim CLA summary:

  • You retain the copyright to your work.
  • You are not obligated to support your contribution.
  • Neovim is allowed to use your work under the Apache 2.0 license.
  • Neovim may relicense your work under the following conditions (this does not affect your copyright):
    • Any license change will be announced 1 month in advance, on the neovim mailing, website, and the email address you provide. If no objections are raised then that is interpreted as approval of the license change.

@justinmk
Copy link
Member Author

May be useful or ridiculous: http://clabot.github.io/

@justinmk justinmk changed the title Add LICENSE [RFC] Add LICENSE Jun 24, 2014
@justinmk
Copy link
Member Author

This comment makes a good case for apache: https://news.ycombinator.com/item?id=4518204

Using apache could avoid having to ask new contributors to sign a CLA, I think.

Problem with apache is that it is not compatible with GPL v2, but I think GPL v2 programs could just communicate with the API instead of linking to nvimlib.

@tarruda
Copy link
Member

tarruda commented Jun 24, 2014

This comment makes a good case for apache: https://news.ycombinator.com/item?id=4518204

Using apache could avoid having to ask new contributors to sign a CLA, I think.

I don't have preferences over open source licenses, but we should probably go with apache to avoid any headaches that will certainly come with requiring 83 contributors to sign the CLA

Problem with apache is that it is not compatible with GPL v2, but I think GPL v2 programs could just communicate with the API instead of linking to nvimlib.

I still didn't had the time to start a detailed discussion about what needs to be done for libnvim, but it's very likely that a large portion of the code will have to be rewritten before we even think about it. In fact, I don't think any libnvim code exists yet, so another license can be chosen once it starts being developed.

@felipecrv
Copy link
Contributor

I don't have preferences over open source licenses, but we should
probably go with apache to avoid any headaches that will certainly come
with requiring 83 contributors to sign the CLA

Are these headaches really a big problem?

Problem with apache is that it is not compatible with GPL v2, but I
think GPL v2 programs could just communicate with the API instead of
linking to nvimlib.

That's much big of a problem than requiring 83 contributors to sign the
CLA. Anything that diminishes the usefulness of Neovim is really bad.

If someone who has donated money to the libnvim bounty can't use it in his
GPL software, we got a real problem.

On Tue, Jun 24, 2014 at 8:33 AM, Thiago de Arruda notifications@github.com
wrote:

This comment makes a good case for apache:
https://news.ycombinator.com/item?id=4518204

Using apache could avoid having to ask new contributors to sign a CLA, I
think.

I don't have preferences over open source licenses, but we should probably
go with apache to avoid any headaches that will certainly come with
requiring 83 contributors to sign the CLA

Problem with apache is that it is not compatible with GPL v2, but I think
GPL v2 programs could just communicate with the API instead of linking to
nvimlib.

I still didn't had the time to start a detailed discussion about what
needs to be done for libnvim, but it's very likely that a large portion of
the code will have to be rewritten before we even think about it. In fact,
I don't think any libnvim code exists yet, so another license can be chosen
once it starts being developed.


Reply to this email directly or view it on GitHub
#883 (comment).

@ZyX-I
Copy link
Contributor

ZyX-I commented Jun 24, 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On June 24, 2014 9:59:01 AM GMT+03:00, "Justin M. Keyes" notifications@github.com wrote:

Followed the pattern of nodejs/libuv. License is MIT "expat".

Moving forward with MIT, but I think it is advisable to to ask
contributors to sign a
CLA to
move contributions to MIT.

Useful discussion of jQuery's move to MIT, which required a CLA:
https://news.ycombinator.com/item?id=4515362

Neovim CLA:
https://docs.google.com/forms/d/1u54bpbwzneDIRltFx1TGi2evKxY3w0cOV3vlpj8DPbg/viewform?usp=send_form

CLA means:

  • You retain the copyright to your work
  • You are not obligated to support your contribution
  • Neovim is allowed to use your work
  • Neovim is allowed to relicense your work

I do not like this last point unless you can add the following things here:

  • - Neovim is obliged to inform contributors about relicensing in one week before actual relicensing.
  • - Informing should be done by sending email and posting a note in some predefined location.
  • - During this week contributors may reject relicensing of their work. Silence is treated like absence of objections. (If I happen to miss this I most likely do not care any longer. If I do I can vote against certain licenses.)

or

  • - Neovim is allowed to relicense your work with some OSI-approved license.

(first is better, I do not like all OSI approved licenses).

Any contributions that are not approved for MIT, remain under the Vim
license. Exiting Vim code and Vim patches also remain under the Vim
license.
You can merge this Pull Request by running:

git pull https://github.com/justinmk/neovim license

Or you can view, comment on it, or merge it online at:

#883

-- Commit Summary --

  • Add LICENSE.

-- File Changes --

A LICENSE (32)

-- Patch Links --

https://github.com/neovim/neovim/pull/883.patch
https://github.com/neovim/neovim/pull/883.diff


Reply to this email directly or view it on GitHub:
#883

-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQJNBAEBCgA3BQJTqY9GMBwfMDI7PjIgHTg6PjswOSAQOzU6QTA9NEA+MjhHIDxr
cC1wYXZAeWFuZGV4LnJ1PgAKCRBu+P2/AXZZIha7D/4rG/PSjb5vMzPK2YGlRc+0
9liuBUW2J4o3K+2/jUQU+HBEQdW9AaduNHpZkKzU39FM8P0XGtzc64ktID2HE8sq
NrYPoFJ8CdwEG+Xb7NWHscbjOmgm8Tk19bXV3nDPxQheuA0ag0ikQycg1TjEi/3b
DEX2O6QHjXDCuberOh4lJSpSzQx7ZWADIFEJgKcIlggVzhn66lEp7jgKYZgoEZnI
ATvXpcNpo1uPiU3T3DAxqs0FIEkEJhwagrgSrqq89N0YaFXE/bf6DICN2f9EKk+I
CJ6ECoFuw/yhM206iiEgz+n9hZsAkDqXuJXTL9hCqFzdy135BWfTeJd/D4FPREXd
YDI/ozzRgHTr9QUCsZesngbFGIMrtGYLgwUObWeLHCI8uCVO28cAz9yVeZT0DZnc
YDPgeTCIwdVU8QRrPniAa9lDsG8le1gQR3+qm9cMEP6fIOOcVKXnV/Q1w1Chex6u
/n81LYAOc0x6BMeM6ZSrZokuvztSr09xgU48nByvNPcglbiDrpr+aF3p8dmsrPKs
Khl7aemRoXtPs8y+/nvN5UK0A74GvRiAAKrOvRB3h8OENCDxxOWvQ+H12s9CqK0p
cet1tJMdsOZpiRnscFZR3w3aIC19H3LFcbyQ2xqWIWIziXx9vGoJFlY+6/z5xdgu
PvTHQx/nV6LknLIOT37+8Q==
=YFKp
-----END PGP SIGNATURE-----

@justinmk
Copy link
Member Author

During this week contributors may reject relicensing of their work

@ZyX-I That defeats the purpose of all this busy-work. If we have to track down everyone and/or have a debate about relicensing, might as well not have a CLA. Which is fine with me. It just means we better pick a license we want to stick with. It took VLC 4 years to change license.

@ZyX-I
Copy link
Contributor

ZyX-I commented Jun 24, 2014

On June 24, 2014 6:51:35 PM GMT+03:00, "Justin M. Keyes" notifications@github.com wrote:

During this week contributors may reject relicensing of their work

@ZyX-I That defeats the purpose of all this busy-work. If we have to
track down everyone and/or have a debate about relicensing, might as
well not have a CLA. Which is fine with me. It just means we better
pick a license we want to stick with. It took VLC 4 years to change
license.


Reply to this email directly or view it on GitHub:
#883 (comment)

Not actually. If I understand correctly without any CLA developers must explicitly agree to relicense their work and just be silent to reject. With my variant they have to explicitly reject relicensing and stay silent to agree. This is a big difference for neovim team which still leaves a good level of control.

@jszakmeister
Copy link
Contributor

If I understand correctly without any CLA developers must explicitly agree to relicense their work and just be silent to reject.

That's the way I understand things too, but IANAL either.

With my variant they have to explicitly reject relicensing and stay silent to agree. This is a big difference for neovim team which still leaves a good level of control.

A week doesn't seem like nearly enough time to me--I've had plenty of things come up over the past couple of years that have taken me offline for a week for various reasons.

Perhaps it would be better to reach out to the Software Freedom Law Center for some advice?

@justinmk
Copy link
Member Author

Changed to Apache v2 license.

That's much big of a problem than requiring 83 contributors to sign the
CLA. Anything that diminishes the usefulness of Neovim is really bad.

GPL v3 projects may include Apache v2 libs. I do not know of any significant GPL v2 software that may be restricted by Neovim's Apache v2 license. Emacs is GPL v3.

If someone who has donated money to the libnvim bounty can't use it in his GPL software, we got a real problem.

They can use it via msgpack, or by licensing under GPL v3. We didn't make any promise to be compatiable with every license. In fact, we're currently under the Vim license, and that's incompatible with any MIT-licensed project that wants to link to libnvim.

So the benefits of Apache outweigh the problems. As @tarruda pointed out, we can discuss a potential license change (or dual license) for libnvim when we get to that point.

That's much big of a problem than requiring 83 contributors to sign the CLA.

Getting 83 people to do anything is nearly impossible. I doubt we will collect even half of the CLAs needed, and the project isn't even 1 year old.

During this week contributors may reject relicensing of their work.

@ZyX-I @jszakmeister In a few hours I will update the CLA to allow a month. edit: done. Please look it over.

@felipecrv
Copy link
Contributor

@justinmk thanks for the clarifications. It makes total sense now.
On Jun 25, 2014 7:10 PM, "Justin M. Keyes" notifications@github.com wrote:

Changed to Apache v2 license.

That's much big of a problem than requiring 83 contributors to sign the
CLA. Anything that diminishes the usefulness of Neovim is really bad.

GPL v3 projects may include Apache v2 libs
http://www.apache.org/licenses/GPL-compatibility.html. I do not know of
any significant GPL v2 software that may be restricted by Neovim's
Apache v2 license. Emacs is GPL v3.

If someone who has donated money to the libnvim bounty can't use it in his
GPL software, we got a real problem.

They can use it via msgpack, or by licensing under GPL v3. We didn't make
any promise to be compatiable with every license. In fact, we're currently
under the Vim license, and that's incompatible with any MIT-licensed
project that wants to link to libnvim.

So the benefits of Apache outweigh the problems. As @tarruda
https://github.com/tarruda pointed out, we can discuss a potential
license change (or dual license) for libnvim when we get to that point.

That's much big of a problem than requiring 83 contributors to sign the
CLA.

Getting 83 people to do anything is nearly impossible. I doubt we will
collect even half of the CLAs needed, and the project isn't even 1 year old.

During this week contributors may reject relicensing of their work.

@ZyX-I https://github.com/ZyX-I @jszakmeister
https://github.com/jszakmeister In a few hours I will update the CLA to
allow a month.


Reply to this email directly or view it on GitHub
#883 (comment).

@justinmk
Copy link
Member Author

CLA is updated with @ZyX-I suggestions. I think is good enough to have some weight without being burdensome by collecting physical addresses or scanned signatures.

@philix @aktau et al, I removed your signatures from the first version because it wasn't ready (the CLA text has changed since then). It's ready now .

@ZyX-I
Copy link
Contributor

ZyX-I commented Jun 26, 2014

I am wondering whether here:

agree to the re-licensing of your work.

you should say either agree to re-license (to + verb) or agree with the re-licensing (with + noun).

provide on this form

Here you should use in, not on.

And there are lots of commas. AFAIK none of them are required, but I am not an expert in this matter: I used to write them a lot too (I heard this is very common among Russian people, should be a common problem always when native language uses lots of commas).


CLA is updated with @ZyX-I suggestions. I think is good enough to have some weight without being burdensome by collecting physical addresses or scanned signatures.

Russian law has support for normal electronic signature via a cryptographic token. I did not bother with receiving one yet and do not know anybody who did (except for some enthusiasts from https://habrahabr.ru).

@justinmk
Copy link
Member Author

@ZyX-I

you should say either agree to re-license (to + verb) or agree with the re-licensing (with + noun).

It's a reference to a specific instance of potential re-licensing. If the wording difference doesn't have any legal bearing then we should not change it again.

Here you should use in, not on.

Prefer to avoid changing it unless there is a potential for ambiguity.

And there are lots of commas

I wrote only section 5 and the first sentence of section 1. The other language is taken from Node.js CLA, probably written by a lawyer.

Russian law has support for normal electronic signature via a cryptographic token

Based on the jQuery discussion and this article and this one, the goal is to demonstrate "due diligence". In our case, we are trying to validate contributions by people whom we know only via github identities and email addresses. The CLA does a reasonable job of that: user is sent a (extremely non-cryptographic) token via email, to prevent false signatures; if user adds the token to the wiki page then we can be reasonably sure that the GitHub user is the one who signed the CLA[1].

I don't know how we would go about verifying crypto tokens against past contributions. However, it could be useful in the future. I was wondering earlier today why GitHub doesn't automatically sign commits. Seems like an obvious, valuable feature.

[1] We also aren't dependent on GitHub for authentication, because the wiki is a git repo which we can mirror locally and elsewhere, and contains the same email address that signed the CLA.

@justinmk justinmk changed the title [RFC] Add LICENSE [RDY] Add LICENSE Jun 26, 2014
- change to Apache 2.0
- include Vim license in LICENSE
- upate README
@justinmk justinmk merged commit b17d969 into neovim:master Jun 26, 2014
@justinmk
Copy link
Member Author

Changed license to Apache 2.0. Let's get back to programming :)

@justinmk justinmk deleted the license branch June 26, 2014 22:59
@tarruda
Copy link
Member

tarruda commented Jun 27, 2014

Changed license to Apache 2.0. Let's get back to programming :)

👍

@justinmk justinmk mentioned this pull request Jun 28, 2014
fmoralesc pushed a commit to fmoralesc/neovim that referenced this pull request Aug 19, 2014
- change to Apache 2.0
- include Vim license in LICENSE
- upate README
@neovim neovim locked as resolved and limited conversation to collaborators Jun 28, 2020
@clason clason added project-management Neovim project matters (release process, logo, etc.) and removed license labels Jul 30, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
project-management Neovim project matters (release process, logo, etc.)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants