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

Neovim CLA disallows incorporation of code licensed under Apache/MIT/etc when submitter is not the author #3036

Closed
ghost opened this issue Jul 17, 2015 · 25 comments
Assignees
Labels
project-management Neovim project matters (release process, logo, etc.)

Comments

@ghost
Copy link

ghost commented Jul 17, 2015

Take some existing code licensed under Apache 2.0 or MIT or some other permissive license, incorporate it somehow into your personal repo, then submit a pull request for the changes. Does the Neovim CLA allow this? No.

It's section 3 here which is problematic. It's the same flaw that makes the (well-intentioned) NASA Open Source Agreement incompatible with "actual" licenses—including, e.g., the GPL. It requires that the contributions be the submitters' own code, which rules out the above scenario.

This section exists because:

  1. You don't want some contributor introducing legally conflicting code because they found it on the 'net and think that makes it public domain.
  2. You don't want anyone introducing legally conflicting code when their work arrangement stipulates that all their work belongs to their employer but their employer hasn't actually signed off on open sourcing this contribution (in which case you get their employer to sign the CLA)

Notice how MPL 2.0 section 2.5 handles this. It simply requires that the submitter assert that if the patches contain any third-party code, then the code must be conflict-free.

This should be fixed in one of two ways:

  1. Amend section 3 of the Neovim CLA to address this similar to the way the MPL does, or
  2. Get rid of the CLA altogether. Anyone doing Fix build #1 from above can't exactly be trusted to begin with, so it's not actually any use there, and otherwise, the project operating in contradiction of its own CLA is proof that nobody is reading it anyway, which means the only real effect it has is to introduce unnecessary process and friction for contributors.
@justinmk
Copy link
Member

How does the FSF handle this?

@justinmk
Copy link
Member

Thanks for the thoughtful post. Here are my thoughts:

Addressing your specific comments:

Does the Neovim CLA allow this? No.

Why do you think that? Anything third-party thing that is incorporated into the project lives under its license. Furthermore, our LICENSE and README.md explicitly state that Vim patches in particular are copyrighted by their original authors and are licensed under the Vim license.

It requires that the contributions be the submitters' own code,

Right, the Contribution. I doubt that any court or legal department would understand a third-party component or module which includes its license, as being a Contribution by the person who happens to commit it. That is, a third-party component is not a Contribution. So the CLA does not apply to it.

It requires that the contributions be the submitters' own code, which rules out the above scenario.

By that logic, the FSF's extremely strict CLA would preclude them from ever incorporating other GPL works into FSF projects (except by direct submission of the copyright holders of those works). That would be amusing.

Notice how MPL 2.0 section 2.5 handles this.

Is that a license or a CLA? If we want to change the license, we need consent of the copyright holders, unless they signed the CLA. Good thing we did that ;)

Anyone doing #1 from above can't exactly be trusted to begin with, so it's not actually any use there,

Its primary use is to demonstrate due-diligence; it's understood that we cannot control or prevent malfeasance.

which means the only real effect it has is to introduce unnecessary process and friction for contributors.

Removing friction is a high priority, but our CLA is pretty low-friction. (Of course, zero is better than almost zero)

At any rate, the tide seems to be turning against CLAs:

I never wanted a CLA. I did a lot of searching 1 year ago, and decided (1) it would be in the best interest of the project and (2) it would help users and plugin authors feel confident about using the project for their applications.

A few months ago I noted the DCO option: #2306 . Would like to hear from anyone who has experience with that.

@ghost
Copy link
Author

ghost commented Jul 18, 2015

How does the FSF handle this?

They've historically gone with copyright assignment and don't do CLAs, AFAIK.

Appeal to authority (?): our CLA is nearly identical to the node.js CLA. If we have problems, they have big problems.

This is a side concern, but looking into it, yeah, your comment seems to be correct.

It's not my intent for the following comment to come off as a scathing one. (And if it were, I wouldn't be doing a very good job; just about anyone could take it and "punch it up" to be moreso). I just don't know how to put otherwise: There's a history of really silly legal goofs in that circle (cf CDDL).

Why do you think that? Anything third-party thing that is incorporated into the project lives under its license.

Because the CLA requires the contributor to assert that the code is his or her own. From section 3:

You represent that the Contributions are Your original works of authorship

If I'm someone trying to incorporate third party FOSS code, I can't actually claim this (and not be lying).

I doubt that any court or legal department would understand a third-party component or module which includes its license, as being a Contribution by the person who happens to commit it.

They would be crazy not to, because it's defined as such to cover them...

That is, a third-party component is not a Contribution.

This does not jibe with the way the terms are defined.

Is that a license or a CLA?

It's a license, but the point is that if you want a CLA, you're going to need similar allowances, else you face the following dilemma:

  1. Require contributors to lie about the code being their original work when incorporating third-party code, or
  2. Don't actually allow any code that isn't their original work, by nixing all patches "tainted" with third-party code (and make it well-known that this is the policy).

If we want to change the license, we need consent of the copyright holders, unless they signed the CLA. Good thing we did that

There are two groups we're discussing here: the original authors of the third-party code, and the Neovim contributors who incorporated the code into the project. You'll have a signed CLA on file for the latter, but not the former. But if you hope to change the license for some reason, the latter is not going to be much help, because the former is who you'll need to seek consent from.

@justinmk
Copy link
Member

There are two groups we're discussing here: the original authors of the third-party code, and the Neovim contributors who incorporated the code into the project.

Third-party code is not a Contribution. It doesn't fall under the CLA. The fact that someone submitted it to the project makes no difference. The CLA specifically addresses Contributions. Third-party code, whether it arrives by courier pigeon or pull request, remains under its license, and is not covered by the CLA.

But if you hope to change the license for some reason, the latter is not going to be much help, because the former is who you'll need to seek consent from.

We won't (and can't) change the license of third-party code. Third-party code includes the copyright and remains under its copyright, as enumerated in the project LICENSE file.

@ghost
Copy link
Author

ghost commented Jul 18, 2015

We won't (and can't) change the license of third-party code. Third-party code includes the copyright and remains under its copyright

Yes, I know. I don't understand what you're getting at.

You mentioned that the CLA is useful if you ever attempt to change the license. I am pointing out that the CLA doesn't actually help you if the project contains third-party code.

Third-party code is not a Contribution

You said that in your last message. I'm at a loss. Repeating this statement doesn't jibe with the CLA as written.

This isn't me; this comes from the Neovim CLA.

The point is, if you don't want the definition of a Contribution to include third-party code, then you need to revise the CLA to so that it matches this stance.

@ghost
Copy link
Author

ghost commented Jul 18, 2015

the FSF's extremely strict CLA

Do you have a link to this?

@justinmk
Copy link
Member

, if you don't want the definition of a Contribution to include third-party code,

The reason you're frustrated by my reply is that we each made our own definition of Contribution. Where in the CLA do you think Contribution is defined?

@ghost
Copy link
Author

ghost commented Jul 18, 2015

I'm not making up a definition for "Contribution"; I'm reading the definition as it appears in the CLA.

Were it not defined there, I still wouldn't make one up. I would defer to the Apache 2.0. Were it not defined there either, I still wouldn't make one up. I would defer to its definition in contemporary open source licenses, which I would use to guide my interpretation. Neither of these approaches would be compatible with the interpretation that a Contribution excludes modifications that incorporate third-party code, and it's only in the second case (consulting general legal use) that there would be room for interpretation.

Fortunately, we don't have to do either of those, since as I mention there's an explicit definition in the CLA itself, at the first occurrence of the word "Contribution".

This is the revision of the CLA I'm referencing: https://docs.google.com/forms/d/1u54bpbwzneDIRltFx1TGi2evKxY3w0cOV3vlpj8DPbg/viewform

@justinmk
Copy link
Member

The form of license below is a document that clarifies the terms under which You, the person listed below, may contribute software, bug fixes, configuration changes, documentation, or any other materials that you send to us related to the Project (each a "Contribution") to the project.

So just to be clear, you think that this sentence means that if a person sends a commit that adds a dependency (directly or indirectly, I guess) on a third-party project which includes that third-party license, then we have somehow asserted that the third-party license is irrelevant and the person who submitted the third-party-licensed content has Sent a Contribution to the Neovim project.

What I am saying is that third party software is not a Contribution. You insist that it is, and you seem to be vexed by the disagreement. Sorry.

@ghost
Copy link
Author

ghost commented Jul 19, 2015

you think that this sentence means that if a person sends a commit that adds a dependency (directly or indirectly, I guess) on a third-party project

Given the turn this conversation has taken, I don't plan on commenting further here. But no, that's not what I think, and that's not what I've written.

What I am saying

Respectfully, this doesn't matter. What matters is what's actually written in the respective documents.

third party software is not a Contribution

¯_(ツ)_/¯

At this point I can only strongly recommend that you have a chat with your legal counsel.

@justinmk
Copy link
Member

Legal counsel would be greatly appreciated. Are you a lawyer?

You pointed out some valid flaws that make the CLA less desirable. I don't think the legal system works so rigidly as you imply, but your skillful use of condescension and memes reminds me to keep my dumb thoughts to myself.

Amending the CLA seems like a mess: we would need to ask everyone to sign again. So the only option is to cancel it...

By the way, I have never seen such scrutiny of the Vim license itself, which seems to be a rough draft transcribed from a napkin while watching Wheel of Fortune. I guess this is a good sign for us, at least.

@cweagans
Copy link
Contributor

cweagans commented Aug 5, 2015

@justinmk I think you might be mistaken here. In the CLA, a "Contribution" is defined as "software, bug fixes, configuration changes, documentation, or any other materials that you send to us related to the Project", which almost certainly includes third party libraries that are included as part of a pull request ("any other materials"). Clause 1 says Apache 2.0 and Clause 2 says that the submitter must have the legal authority to grant that license, which is not the case for third party libraries. Clause 3 even specifies that Contributions are "are [submitters] original work", and if you accept that a Contribution does include third party libraries, then you're outright denying the inclusion of code that somebody didn't specifically write for Neovim.

IP contracts (and that's exactly what the CLA is) aren't something to mess around with. I'd categorize this as a very serious problem.

@justinmk
Copy link
Member

justinmk commented Aug 5, 2015

I understand the contention. The loophole I was attempting to establish is that it is not possible to "send" third party materials. Just because somebody links to a dependency does not mean they have "sent" the contents of that dependency. Anyways as I said, yes, it is clear that the CLA is broken. It was derived from node.js. What did node.js do? Just walk away from it? It isn't clear from the blog post I linked above.

Also this really sucks because (1) now there is ambiguity regarding commits before and after the introduction of the CLA, and (2) @colbyrussell is going to feel extra smug for the next three days.

@justinmk
Copy link
Member

justinmk commented Aug 5, 2015

ambiguity regarding commits before and after the introduction of the CLA,

Actually that's not true. Contributions before the CLA go under the Vim license, and after the CLA go under Apache. So that's fine. Still bummed out about the smugness though.

@cweagans
Copy link
Contributor

cweagans commented Aug 5, 2015

The Node community is probably not a great example to follow for things like this, IMO. They have some interesting opinions about how the legal system works, IIRC. I'd suggest looking into the Firefox or Chromium communities to see how they handle things. It may be as simple as adding an explicit exemption for third party code as long as the licenses are compatible or something like that.

@justinmk
Copy link
Member

justinmk commented Aug 5, 2015

Yeah, but then we'd need to get everyone to re-sign the new CLA. I don't think it would be good to change the CLA and then declare it retro-active... right?

The main reason for the CLA was to establish the license for contributions that were made before we adopted Apache. If we have to get everyone to sign a new CLA, that defeats the purpose of the original CLA, and it's just not going to happen. I'd rather just drop the CLA.

@cweagans
Copy link
Contributor

cweagans commented Aug 5, 2015

That's probably the better option, unless you want to go through the re-signing process with the added clause that you can make retroactive changes at anytime in the future (a la commercial software's EULAs). Then you'd for sure only have to do it once.

Dropping the CLA can't hurt, though.

@bfredl
Copy link
Member

bfredl commented Aug 5, 2015

IANAL or anything, but is a complete resigning by all contributions really necessary? If parties A and B have an agreement, still one of the parties could one-sidedly grant additional rights to the other, like allowing to contribute third-party code (identified as such)? The original CLA required signing by all existing contributors as the contributors were granting additional rights, right? (Not that I have anything against just dropping the CLA...)

@justinmk
Copy link
Member

justinmk commented Aug 5, 2015

@bfredl I'm not sure, but changing the CLA at all without re-affirmation, I think, will not instill confidence in the integrity of the CLA. Looking back, this happened in June 2014, and relative to now, I am not too worried about leaving the commits from Feb-Jun 2014 under the Vim license.

@cstrahan
Copy link

@justinmk

Just because somebody links to a dependency does not mean they have "sent" the contents of that dependency.

I think @colbyrussell was misunderstood and consequently misrepresented here, so I feel the need to chime in. It was pretty clear to me that @colbyrussell was saying that if one sends a pull request with the _contents_ of someone else's work (either verbatim or derivative), then the CLA (as it stood in the revision posted) would consider that code a Contribution per the definition therein, though the CLA would deem that contribution unacceptable as the code wouldn't be "original work" (as required per Clause 3 of the CLA).

When asked multiple times if @colbyrussell was suggesting that references to third-party works (say, linking via pkg-config to a shared library, or something along those lines) was a contribution of the code thereof, he repeatedly clarified that that's not what he meant. Admittedly, @colbyrussell seemed to lose a little patience towards the end, but I can't blame him, given that he was subjected to the same question repeatedly (which wasn't a very charitable interpretation[1] to begin with).

I believe @colbyrussell raised a valid concern, and I feel compassion for him when I see him coming under attack for being "smug", when it's apparent that he's just trying to help out.

I don't think there was any malice intended on either side; however, as an outsider looking in, it would also be easy for me to interpret how this unfolded as "neovim is a hostile project where issues are interpreted in the most uncharitable way possible, and then you're called names when you get exasperated after repeatedly trying to clarify that you're not irrational - you're just being treated that way".

Again, I don't believe any malice was intended. I do, however, think that it would benefit the project if there was some recognition of how this (probably) felt for @colbyrussell, and a recognition that better communication could have avoided this. We're all guilty of miscommunication at times, but - as with all skills - taking ownership of mistakes is necessary to improve. In other words, I'm not questioning your character.


[1]: "In philosophy and rhetoric, the principle of charity requires interpreting a speaker's statements to be rational and, in the case of any argument, considering its best, strongest possible interpretation."

@justinmk
Copy link
Member

I do, however, think that it would benefit the project if there was some recognition of how this (probably) felt for @colbyrussell, and a recognition that better communication could have avoided this.

Ok, I hereby recognize that I handled this like an asshat. If anyone else wants remind me again next month, do feel free.

@cweagans
Copy link
Contributor

@justinmk lock thread plz? There's no point in rehashing this any longer. The issue has been fixed.

@cstrahan
Copy link

@cweagans I just wanted to point out offensive behavior; I suppose I can do that through other channels, if that's what's expected.

@cstrahan
Copy link

Oh, didn't see a notification for Justin's response. My apologies - by all means, feel free to lock the thread.

@cweagans
Copy link
Contributor

Personally, I don't really care about "offensive". We're here to make a good code editor, not talk about our feelings. Neither party was particularly friendly in their interaction, but they also weren't unfriendly or uncivil (and for the record, I'm pretty sure @justinmk was joking in a way with his "smug" comments). Precision of language was the issue here, by the way: nobody was referencing specific clauses from the CLA which would have wrapped this issue up in like comment 3 or so.

as an outsider looking in, it would also be easy for me to interpret how this unfolded as "neovim is a hostile project where issues are interpreted in the most uncharitable way possible, and then you're called names when you get exasperated after repeatedly trying to clarify that you're not irrational - you're just being treated that way".

That itself is an uncharitable interpretation. Disagreement != hostility. Simply don't interpret it that way.

mgraczyk pushed a commit to mgraczyk/neovim that referenced this issue Nov 2, 2015
@clason clason added project-management Neovim project matters (release process, logo, etc.) and removed license labels Jul 30, 2021
@neovim neovim locked as resolved and limited conversation to collaborators Aug 10, 2023
@neovim neovim deleted a comment Aug 10, 2023
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

No branches or pull requests

5 participants