Clarify Neovim License

[ardagnir]

I was looking at license compatability after I was asked to support Neovim in one of my projects and saw what might be a problem: I'm not a lawyer, but it looks like Neovim may (inadvertantly) be under proprietary copyright. At best, the license is unclear.

The Neovim readme says "Vim is distributed under..." but never says anything about Neovim. Same for the included vim-license file.

I was under the impression that the creators want Neovim to also be under the Vim license, but since section II.c of the Vim license says that if you make all the changes to Vim available (which Neovim does) and include Vim's license file (which Neovim does), the changed version (Neovim) can be distributed under any license. Since copyright defaults to being proprietary in most countries, it is probably a good idea to EXPLICITLY state the license that Neovim is using.

TLDR: There should probably be a statement in the readme clarifying that Neovim (and not just vim) is covered under the Vim License(or some other license).

[justinmk]

the changed version (Neovim) can be distributed under any license.

Can you point out the relevant passage?

Also discussed at length in #370 but never concluded. Reading the actual Vim license makes it clear that we can license our modifications at our discretion:

 c) Provide all the changes, including source code, with every copy of
      the modified Vim you distribute.  This may be done in the form of a
      context diff.  You can choose what license to use for new code you
      add.  The changes and their license must not restrict others from
      making their own changes to the official version of Vim.

[...]

III) If you distribute a modified version of Vim, you are encouraged to use
     the Vim license for your changes and make them available to the
     maintainer, including the source code.  The preferred way to do

I am not in favor of GPL for Neovim. Vim license is more liberal than GPL, we should use a license that is at least as liberal (MIT, BSD) for Neovim-original code.

Original Vim code remaining in Neovim is probably required to remain under the Vim license.

Other notable passage:

- If you link Vim with a library that goes under the GNU GPL, this limits
  further distribution to the GNU GPL.  Also when you didn't actually change
  anything in Vim.

- Once a change is included that goes under the GNU GPL, this forces all
  further changes to also be made under the GNU GPL or a compatible license.

@tarruda et al: We definitely need to decide on a license sooner rather than later. I think it may be counterproductive to continue with the Vim license, since it is focused on Vim and Bram: this could be very confusing in the long term.

[ardagnir]

You're right, I read it to quickly: it is the changes that can be under any license, not the entirety of Neovim. This still causes the same problems and I'm in agreement that it's better to fix sooner rather than later.

[ZyX-I]

Is there a description of labels used in issue tracker somewhere? I can hardly understand why this is labeled “community”.

[justinmk]

Is there a description of labels used in issue tracker somewhere? I can hardly understand why this is labeled “community”.

My thinking was that "community" means "non-technical issues". I didn't want to create a "legal" label because it's probably only going to be used for maybe one or two issues. But since you mention it, I'll re-tag it.

[aktau]

Fwiw, I thought the community tag was quite alright. Because it's something
the community will have to perhaps debate a little or at least reach a
consensus, since it concerns all of our contributions. As for me, I would
favor a freeer license for the new code, if at all possible.

Am Samstag, 21. Juni 2014 schrieb Justin M. Keyes :

Is there a description of labels used in issue tracker somewhere? I can
hardly understand why this is labeled “community”.

My thinking was that "community" means "non-technical issues". I didn't
want to create a "legal" label because it's probably only going to be used
for maybe one or two issues. But since you mention it, I'll re-tag it.

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

[justinmk]

BTW @ardagnir , regardless of the license, if you are communicating with Neovim over TCP or some other channel (not compile-time nor dynamic linking), your project will not be affected, regardless of the final license. We will not be choosing a license that restricts communication via TCP or pipes.

[ZyX-I]

@justinmk It would actually be better to describe labels in CONTRIBUTING.md. I.e. say that these labels (e.g. buildsystem, api) refer to components, these (e.g. enhancement, idea, bug, question) refer to issue kind and may (not) be present more then one on one issue, these (invalid, duplicate, wontfix, in progress, ready) to issue status and may not be present, with these (platform:*) platform-specific stuff is marked, etc.

Regarding this issue: I think that something like MIT is indeed good choice. GPL is not good at all since one of our goals is to make Neovim embeddable.

[ardagnir]

@justinmk, Any exception-free GPL code that sends complex internal data structures between itself and Neovim would need Neovim to be available under a GPL-compatible license, whether it uses dynamic linking, TCP, pipes, or carrier pigeons.

I know this is a legal gray area, and there's disagreement about it, but there's no point debating it here because I'm not going to support weakening the GPL, and whether or not a small project of mine supports Neovim is far from the most important consideration when chosing a license.

[rlidwka]

Any exception-free GPL code that sends complex internal data structures between itself and Neovim would need Neovim to be available under a GPL-compatible license, whether it uses dynamic linking, TCP, pipes, or carrier pigeons.

I'm pretty sure GPL doesn't ban data exchange between two separate programs, that's nonsense. There is no gray area here.

Dynamic linking is only an issue because it creates a single combined work.

[justinmk]

Any exception-free GPL code that sends complex internal data structures between itself and Neovim would need Neovim to be available under a GPL-compatible license, whether it uses dynamic linking, TCP, pipes, or carrier pigeons.

@ardagnir I am not following your reasoning. Is there something that prevents a GPL v2 or v3 client from communicating with, for example, a commercial, closed-source REST API? There are also plenty of MIT-licensed emacs plugins. Furthermore, Emacs (GPL) runs on Windows, using the proprietary Windows API.

I'm not going to support weakening the GPL, and whether or not a small project of mine supports Neovim is far from the most important consideration when chosing a license.

I'm confused by this. Can you give an example scenario from what we've discussed, that would weaken the GPL?

[justinmk]

describe labels in CONTRIBUTING.md.

@ZyX-I Why add ceremony and formality to this informal search and organization aid?

[ZyX-I]

@ZyX-I Why add ceremony and formality to this informal search and organization aid?

It is an aid only when the following statements are true:

1. All issues are correctly labeled. If not all issues are labeled then you cannot say that selecting enhancement label will show you all enhancement proposals, thus it is no aid.
2. Person who does the search understands why issues were labeled as they were. If person who searches does not understand the meaning of labels then obviously he cannot use them for searching, because it will be searching for something undefined.

Thus I can say that without description labels like decision, idea, community and enhancement are pretty much useless for me: first three does not follow 2. (and maybe 1., but I do not know), last does not follow 1. (I can hardly believe there are only eight enhancement requests in 144 issues). Some definitions may solve 1. without making more labels: just define enhancement label as “enhancement request reviewed by somebody from the main developer team”.

Without formality it is only aid to those who are making labels and random noise for everyone else.

[justinmk]

@ZyX-I It's an exaggeration to call it "random noise". Think of it as a "best effort": not formally verified, and not useless.

I can hardly believe there are only eight enhancement requests in 144 issues

No one was fastidious about tagging until recently, so there are many un-tagged issues. It's still useful to be able to search for known build-system issues, for example, by using the build-system tag.

Feel free to label issues according to your judgment. Be aware: some labels such as "ready" are used by waffle.io (I think), so please don't remove them from issues.

However I'm not in favor of creating a formal system nor policing the use of labels.

[ardagnir]

@justinmk If the GPL application is built specificly to communicate with proprietary code, such that they functioned as one program it would be in violation. If it just communicated with REST APIs in general and ended up being used on a proprietary one after distribution, than there is no violation.

Re: MIT Emacs plugins, The MIT license is GPL compatible so there is no violation. See: module license.

The GPL can run fine on windows because of the system library exception.

Communicating over TCP/pipes usually means there are two completly seperate programs. But you can't simply use these methods in place of dynamic linking to avoid the GPL or the GPL would have no power. If GPL code is communicating with Neovim such that it is explicitly using the Neovim API and couldn't function without Neovim, then it and Neovim are clearly functioning as one program (in the since that plugins and their app function as one program) and is only allowed if Neovim is under a GPL-compatible license (and that includes MIT).

I don't want to take this discussion off track so I'm going to point people to the gpl faq. If you still have disagreements with my interpretation, we're probably going to have to agree to disagree. If Neovim does end up under the MIT license (or technically a combination of Vim-License and MIT), then who's interpretation of the GPL is correct won't affect it anyway.

[justinmk]

@ardagnir Good information, thanks.

The GPL can run fine on windows because of the system library exception.

Very interesting, kind of amusing even.

If Neovim does end up under the MIT license (or technically a combination of Vim-License and MIT), then who's interpretation of the GPL is correct won't affect it anyway.

I want to solve this unambiguously within the next week. We may need to get some past contributors to explicitly sign off, which could take longer.

[rlidwka]

If the GPL application is built specificly to communicate with proprietary code, such that they functioned as one program it would be in violation.

A computer program can't violate GPL at all. Only people can violate licenses, and it could be done in three ways:

1. Usage. GPL allow anything, so it isn't applicable here.
2. Modification. GPL allow it, so it isn't applicable here.
3. Distribution. Only this action is restricted by GPL.

In other words, if you don't distribute Neovim with your app, you cannot violate GPL at all (as far as these programs are considered).

For example, there is a GPL-covered game called OpenXcom that uses proprietary resources from the original game. It is "functioning as one program", but they don't violate GPL in any way, because original game isn't distributed with it.

FAQ doesn't have any legal significance. Only license text does, and it defines "modifying" strictly leaving no room for interpretation. There is nothing about "internal data structures" there.

[justinmk]

@aktau @jszakmeister @mhinz @oni-link @philix @schmee @Hinidu @elmart @ashleyh @lslah @stefan991 @watk @harsh1kumar @simendsjo and all other contributors: please speak up sooner rather than later if you object to licensing your contributions under MIT, Apache, BSD. I will seek formal approval once we finalize a decision about the license.

[aktau]

I have no objections to MIT and/or BSD. Don't have enough experience with Apache to be honest.

[redchair123]

@aktau in practice, the main differentiator of the Apache license is the patent clause. IT is OSI-blessed and in fact FSF recommends it:

The patent termination provision is a good thing, which is why we recommend the Apache 2.0 license for substantial programs over other lax permissive licenses.

https://www.gnu.org/licenses/license-list.html#apache2

@justinmk keep in mind that every contributor has to explicitly agree to the license shift. If you cannot get confirmation from a particular contributor, the relevant lines of code must be rewritten. VLC went through this process a few years ago: http://www.videolan.org/press/lgpl-libvlc.html

[Hinidu]

In my opinion license should be simple, concise and as permissive as possible. I vote for MIT or ISC (It is functionally equivalent to the simplified BSD and MIT licenses, with language that was deemed unnecessary by the Berne convention removed.)

The patent termination provision is a good thing

This statement is too obscure for me. I don't know anything about patent law. But if Neovim really can have benefits from it then I'll be happy with Apache license too.

[ZyX-I]

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

By the way, what about documentation license? I think it should be

1. different from source code one and
2. one of the latest CC* (Creative Commons) licences.
   -----BEGIN PGP SIGNATURE-----
   Version: APG v1.1.1

iQJNBAEBCgA3BQJTp8vvMBwfMDI7PjIgHTg6PjswOSAQOzU6QTA9NEA+MjhHIDxr
cC1wYXZAeWFuZGV4LnJ1PgAKCRBu+P2/AXZZIs8ZEADcQsbyg8Yz1AZdJWO+v6F4
vPc2bp2tkfH0GNsr6UN2GKbldVzWNpxkGJAt13xAHlLE4lFvIiV9IWf84Gaeopop
bjrz3ESUqGtn1phLHoScgzfVwqGxDmZsoMKSPatO5b32HyI/vnKJC3vt6SR9QSrN
fsfb27G585sq1p1QXu1P0hN0VExhOfKWZsVvNHhet8I+xlFpnvDK8XAT116EZT9b
Z8IO3fvuOLGAwCCcT00h6SEf50/tUsaYCxCrF/UEJEqtWYY3IX01EQThxn2s/maX
65ObhttGLHKYVnYQnk0SW0vHx4RgMi3RfkP5Aqe8OBF6XQ3AkyMv6cfNK3hm7yA1
mjLbBNgIt59Ngbyif7DYH+XLWCxDWhSeJrugKhk3Fh10LhtqqOCOOAUqGrMo+9/W
yFKshLgKKiqS/YC/8yUIk16Sb7aE/OwKk8SRVDoEl6K1+HOrmWr/Tui5bzP3wK0s
0Plj0Mz4lmuthdfenoq+HlP0zGFL0QQJrEqgU+vfDGTEFzar7gWIvQ+3IeO0U8Sp
bCwhGP/cfBr1qELin1BEM2S6T2jZIHHbmrbNDgLsYMg7TryX0uNPQcNMBLGXy587
T/aaDMMNWghouEOks+X0V7Aayb4ic7PH18QNTGd0JjWnSSREcb6iOSKNq65+V4X1
STSbGfSp3n1U/wZQlONLVg==
=p+vC
-----END PGP SIGNATURE-----

[aktau]

By the way, what about documentation license? I think it should be

1. different from source code one and
2. one of the latest CC* (Creative Commons) licences.

In principle I agree with you ZyX. Though I reckon the current docs (you mean the :help docs and the function docs right?) are also under the vim license.

To all: do you think we should have an AUTHORS file or something then? Many projects seem to have them, perhaps it has licensing/copyright-checking consequences? Would be nice to have a lawyer here :).

[ZyX-I]

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

On June 23, 2014 11:16:14 AM GMT+03:00, Nicolas Hillegeer notifications@github.com wrote:

By the way, what about documentation license? I think it should be

1. different from source code one and
2. one of the latest CC* (Creative Commons) licences.

In principle I agree with you ZyX. Though I reckon the current docs
(you mean the :help docs and the function docs right?) are also under
the vim license.

To all: do you think we should have an AUTHORS file or something then?
Many projects seem to have them, perhaps it has
licensing/copyright-checking consequences? Would be nice to have a
lawyer here :).

---

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

Yes, but like with code we are going to have plenty of new documentation: developer guides, API reference, (bindings documentation), ... I think that issues requiring us to step from Vim license for source code also apply to documentation.

By the way, things like doc strings, Doxygen in-source documentation comments, ...: are they source code or documentation?
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQJNBAEBCgA3BQJTp+ZXMBwfMDI7PjIgHTg6PjswOSAQOzU6QTA9NEA+MjhHIDxr
cC1wYXZAeWFuZGV4LnJ1PgAKCRBu+P2/AXZZIsxREADVAYq5WNUvDJt0Pj9p5dX9
BwD8qmenwtHhFfxFhKBxmr5uDzJeOenYN9jW4mQCOEo0RUEiCCss4Yd9KRXXu7Gv
ksHdbxkwg8ilTIfhCmIT2lQPyjRf2bbQhPSw7H9yk1ga38VYcVnVFL1twExC1jtD
61Jz96X0RbE1NfIiHRpfYY80veJOOnF6odixt9+QuA6Otnff7pLwBHfGJFPrN8+Y
9uUmoQremYcNkWnVLu856xUoMpjQa4KlCLPNVmnUlLjRAOiBK71MUBJq4uFnp4t5
sXvR+3ENgKjZ+3dOrcPmu/cQUKRqdGw9fcDr7KyCx2jXvVTxhSQSdCrkOuvhbxlG
WAw44fy9sG9B1jXXZITziImz3AZks5GnHo17h3Zh8hyV3so9VGdmvc5IDve+JxC/
QkcvlxvrUzj2cz1lhsjDPzAXebcDUCcPG77GCI4mqH5Pq5fRxGkWgpDk9e8IIP/v
Jrrg1sCmBUVs25PF9eVF1ptglx1MhgRuP7Wclr0tsk6vnvYYSIGWkiovwW1fVwK5
qpr1L8b8usN5tgWR9ctV+WNfKDBVBT28llLyEla3CQ9waNPB7Q6+QL2RRuG1bEaM
Zk31leAO6c6UfzgE87MqC2J0c+00IQcvEeq92Ft5eA6tJJ84C7YHgMR6KYEYZPz8
2S3DvJHRH5BJixvmr+8Y2w==
=YWWk
-----END PGP SIGNATURE-----

[felipecrv]

@justinmk no objection to any of the three licenses (MIT, Apache 2.0, BSD).

__
Felipe O. Carvalho (philix)
http://felipe.rs
On Jun 22, 2014 5:44 PM, "Justin M. Keyes" notifications@github.com wrote:

@aktau https://github.com/aktau @jszakmeister
https://github.com/jszakmeister @mhinz https://github.com/mhinz
@oni-link https://github.com/oni-link @philix
https://github.com/philix @schmee https://github.com/schmee @Hinidu
https://github.com/Hinidu @elmart https://github.com/elmart @ashleyh
https://github.com/ashleyh @lslah https://github.com/lslah @stefan991
https://github.com/stefan991 @watk https://github.com/watk
@harsh1kumar https://github.com/harsh1kumar @simendsjo
https://github.com/simendsjo and all other contributors: please speak
up sooner rather than later if you object to licensing your contributions
under MIT, Apache, BSD. I will seek formal approval once we finalize a
decision about the license.

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

[jszakmeister]

@justinmk I don't object to any of the three either, though I'm biased towards Apache 2.0. :-)

[schmee]

@justinmk I don't know the first thing about software licensing, I trust you and the rest of the community to make the right decision :) So I'm OK with whatever!

[stefan991]

@justinmk I'm fine with MIT, Apache 2.0 or BSD.
I prefer MIT over BSD as it's not always obvious which version of BSD is used.
Apache 2.0 is not compatible with GPLv2, which could cause problems when "embedding" Neovim into a GPLv2 application.

[harsh1kumar]

@justinmk I am okay with any licence.

[redchair123]

@justinmk as a friendly reminder: confirm that all previous contributors agree to the license before application.

[justinmk]

confirm that all previous contributors agree to the license before application.

Any contribution who does not agree, remains under the Vim license.

[redchair123]

I don't see where that is indicated in your proposed license @justinmk

[simendsjo]

@justinmk : I'm fine with any of them, but I'd prefer MIT. (Not that I think I've made any contributions of size that requires you to ask for my permission)

[matjon]

Hello,
A similar issue is currently discussed on debian-devel with respect to some PHP addons:
https://lists.debian.org/debian-legal/2014/08/msg00023.html
and they are asking SFLC for some comments because they are unable to handle it on its own:

"I. Requirement to perhaps-falsely acknowledge:
Paragraph 6 of the main licence text requires this notice:
"This product includes PHP software, freely available from
http://www.php.net/software/".

This is probably unproblematic for PHP itself. However, most PHP
addons are also distributed under the PHP licence. The worry is that
putting that statement in the copyright information for a PHP addon
package might be making a false statement, since (i) the package
itself does not include PHP and (ii) the addon may not in fact be
available via that URL."