can you make future commits permissively / portable license?

[tony]

Can future / ongoing contributions to this project under MIT/BSD/Apache2?

Unfortunately GPL isn't backwards compatible to other licenses in the open source world. A permissive license would make future contributions still compatible with GPL, but down the road if there was a license change, the transition would be a lot smoother.

The project would still be considered to be GPL unless contributors agreed to change. neovim has done a similar thing with its contributions on top of vim.

[b4n]

The question is whether developers want this project to allow non-free use of it (the main difference between GPL and more permissive licenses like BSD or Apache). Using CTags in a BSD/Apache2/MIT license software makes that software GPL as a whole, yet not its whole source code; so it effectively doesn't really change much for them: only the CTags part of it would be concerned.

Apart from whether we want to do that or not, how legal is it? I could imagine it would be a problem to have patches under a license incompatible with the code it alters -- yet maybe not, I genuinely don't know.

Finally… why? It's mostly unrealistic to ask everyone who actually contributed whether they are OK with changing the license. OK, most people don't explicitly list their copyright information, but I don't think we say contributors give up copyright to use either, so again, might be a gray area.
So, what would we gain apart a more complex license?

BTW, I took a quick glance at neovim's case, and it seems like they did that because their license was ambiguous, because the base license didn't explicitly cover derivatives, rather made it clear they could be under any license they wished.

[masatake]

@b4n, thank you. Today this issue hogs my physical CPU clocks.

So, what would we gain apart a more complex license?

I would like to know this.

[tony]

non-free use

Freedom is great, but people use it in different ways. Soviets use the word free in their anthem, so did USA, they had interpretations. FSF uses freedom as a buzz word. In practical terms amounts to heavy restriction, lack of portability with other licenses. etc.

I'm running FreeBSD right now and have total and absolute freedom. Ironically, despite using software under a license that offers me no such guarantees, "non-free" as you would say it, I have more convenient access to the source and toolchain than any contemporary linux distribution has. I can go into /usr/src and build a thumb drive img with the source code files for the kernel and whole userland right there. I didn't need the GPL to assure it, the nature that its an open source project itself meant the source would be there. They're doing it for convenience of developers above all else, or else why would there spend their time.

It's mostly unrealistic to ask everyone who actually contributed whether they are OK with changing the license

Well, the other option is to rewrite ctags from scratch under a permissive license. That would be painful and time-consuming. Even more so than trying to shepherd a conversion.

The main focus is seeing if larger contributors are on board. If it was 98% people on board and filibusters by holdouts that did spelling changes writing 10 paragraph GPL manifestos, those can be rebased out in a new cloned repo. That said, in the case of bootstrap I think that person eventually switched.

Conversions happen all the time.

However, the scope of this issue isn't conversion, only that future changes are permissively licensed. It doesn't guarantee conversion, but it stems the GPL contributions from piling up.

Apart from whether we want to do that or not, how legal is it?

If GPL strikes you as legally ambiguous in any sense, why are you contributing your code under a license you're not sure of in the first place?

In all these years I can probably say 9/10 people misunderstand the GPL. No case law. No precedents. That complication is also pushed around to developers, because they're going to be told to go pay for a lawyer for advice.

But, I never doubted the good will and intention of people who stick with GPL. They often are often do-gooders speaking out of emotional warmth they have to the unchallenged indoctrination FSF had for the past 2 decades. I remember in 2001 finding it insulting when I read Ballmer said Linux was a Cancer. I merely identified myself with GPL/GNU/FSF as a nobel cause, enough to go around with a tux hoody. So if someone insulted GPL, it was equivalent to saying I was bad also. But then, I never read the GPL.

I didn't know GPL really screwed over legitimate use cases. I was saving the world plastering copyleft everywhere. Despite the license is totally non-portable to other open source licenses. Commercially unfriendly. It was impossible to quantify what possible users or contributions were "lost" due to GPL terms. The most damning manifestation came to light when GCC doubled down and went GPLv3, and LLVM and Clang gained powerful commercial backers and momentum.

Aside from that, the pains of the GPL aren't really provable unless people make issues on trackers and say, "can't use it because of X". Not many potential users or contributors are going to make a drive-by issue on a tracker for software they can't use and say "nope, we're moving on to other things". Its annoying enough for maintainers to hear anything non-code related, let alone stir up license emotions.

I could imagine it would be a problem to have patches under a license incompatible with the code it alters -- yet maybe not, I genuinely don't know.

MIT is forward compatible with GPL.

So, what would we gain apart a more complex license?

Future contributions are under a simpler license. In the short term is has no effect.

The distribution itself is GPL until it is free of GPL code.

If future contributions are not licensed permissive, the list of contributors to get permission from just grows larger and larger.

BTW, I took a quick glance at neovim's case, and it seems like they did that because their license was ambiguous, because the base license didn't explicitly cover derivatives, rather made it clear they could be under any license they wished.

The example demonstration it being possible to make future contribution after a certain point under a different license. Here's another example: pytest-dev/pytest-mock#45 (comment)

[raphinesse]

Real world use case incoming.

I am using atom as my primary editor. Its symbols-view package uses node-ctags to read tag files, which in turn uses a slightly modified version of the readtags.{c,h} files from dhiebert's exuberant-ctags.

Unfortunately, as the contributors of this repository should know, this implementation is broken. I just spent about a day figuring out that my "Go To Declaration" command was not working because the binary search in readtags.c is broken on Windows. and then fixing it.

The next step would be a pull request to fix the broken software. But wouldn't it be good to fix the software upstream, instead of just in the node-ctags repo? Sure! However, the apparent state of exuberant-ctags did not leave me with much hope that my patch would ever be accepted.

Then I stumbled across this fork. I rejoiced. I noticed that a lot work has been and is being done to improve the code quality of ctags. Even the bug I worked so hard to locate and fix in the original version of readtags has already been discovered and taken care of (632be59), thanks to modern software engineering principles.

However, node-ctags is licensed under the MIT license. So I cannot suggest they take your version of readtags instead, since they would have to change their license for that. So in this case, the GPL clearly restricts our freedom and prevents propagation of free code.

I hope this exemplary real-world use case backs up the relevance of this issue. I would certainly advocate for a license change, and the action proposed here would be a good first step.

[masatake]

See the header of readtags.[ch].

This source code is released for the public domain.

It is nothing to do with GPL.

[raphinesse]

@masatake Well, the original code was released into the public domain. However, with the whole project marked as "licensed under GPL" by COPYING, it is by no means clear that the contributions to this file that were done in the context of this project are also in the public domain.

But if you say that the intention is that all contributions are also released into the public domain, that is indeed good to hear. 👍

[masatake]

How about adding following sentence to COPYING file?

Exception: readtags.c and readtags.h are released into the public domain as
written in header of the files. Contributors for the files must accept this
exception.

[t-b]

@masatake That sounds good.

[raphinesse]

@masatake That would surely make the intention clear.

However, IMHO a better option would be to separate the readtags component into its own repository (see #1040 for a comprehensive argumentation). What do you think about that?

Edit: Furthermore releasing into public domain does not seem to be a particularly good alternative to an actual license. But that's a different issue. Just wanted to mention it.

[tony]

ISC/MIT should be ok in lieu of public domain.

This issue seems to be slimmed down in scope for readtags..

What about making parsers/ permissively licensed?

I'm still a big fan of making future commits permissively licensed (so GPL commits stop piling up) and seeing if this project can be licensed ISC/MIT/BSD.

In my position, I don't want to use ctags as a program. There are pieces of code that'd be helpful for me to bake into an application, I'm happy to contribute back stuff if its useful, but I don't want to have to license my whole program as GPL. Most of the time though, the license drama ends up draining the energy out of me and I move on to hack on something else

If it doesn't seem in the realm of possibility to change the license / have new commits be licensed permissively, you can close this issue and fork it into one about readtags / #1040

[b4n]

I'm running FreeBSD right now and have total and absolute freedom. Ironically, despite using software under a license that offers me no such guarantees, "non-free" as you would say it,

I don't say anything of the sort. BSD, MIT, Apache2 and the like are free software license just fine. I even do use some of those for some things. And I totally agree that they technically allow more things -- basically not enforcing the same license in derivative work.

I have more convenient access to the source and toolchain than any contemporary linux distribution has.

That's hardly relevant to any licensing issue here. I imagine nobody will be talking about closing this project's sources, so how your favorite tool or OS presents you the software is irrelevant.

Well, the other option is to rewrite ctags from scratch under a permissive license. […]

…or not need to do something against the GPL (basically, closed-source software, yet I agree it can be slightly more subtle). Yes, GPL "is a virus" in the sense that as it's more restrictive (places more conditions) it overtakes most other licenses, but I don't see it being so bad at all as you suggest it is.

If GPL strikes you as legally ambiguous in any sense, why are you contributing your code under a license you're not sure of in the first place?

That's funny :) BSD or Apache2 are very short, yet I won't say I understand the whole implication of them all, in all situations I encountered or didn't encounter. The problem here is not really what I understood or think it should mean for me, but what someone could argue without technically be off topic. Yes, I have a twisted view of law(yers).

This said, I don't think I'll want to re-license what I license under GPL, so I must admit I didn't ask myself whether patches would be derivative work or not.

Commercially unfriendly. It was impossible to quantify what possible users or contributions were "lost" due to GPL terms. The most damning manifestation came to light when GCC doubled down and went GPLv3, and LLVM and Clang gained powerful commercial backers and momentum.

That problem only arises because some people don't want to release their changes under the GPL, and GPL doesn't allow that. It impacting commercial use is a biased view due to current practice, where we imagine that if a company doesn't have a secret it isn't worth nothing.

And for the GCC/LLVM case, yes, GCC "suffered" because it was more restrictive, but you could also just as well say LLVM killed GCC by selling itself out to closed-source derivatives. Sure, as a BSD license enthusiast, that's not a point, but some people probably see it that way.
Also, GCC was old, and LLVM was young, fresh, and designed to solve a lot more than GCC :)

Future contributions are under a simpler license. In the short term is has no effect.

OK. So in the short term, it only makes the licensing more confusing.

If future contributions are not licensed permissive, the list of contributors to get permission from just grows larger and larger.

Fair enough.

---

Anyway, I myself don't really care. I don't know examples where being GPLv2 was a problem apart for creating closed-source derivative. Yes, it has other impact, but all the ones I know simply makes the derivative effectively GPL. And I don't care for allowing closed-source derivatives.

However, with the discussion here, I wouldn't really be convinced, because I find it lacking any argument for doing it that convince me. "BSD/Apache2/MIT is better" isn't enough for me. "I want to make closed-source derivative" neither.

[b4n]

ISC/MIT should be ok in lieu of public domain.

Without proposing a license, yes, a proper license should probably be used, because it seems (?) that public domain isn't a thing everywhere in the world, so that's ambiguous at best, and proprietary at worse.

What about making parsers/ permissively licensed?

I don't see it making any sense to propose something that would mess up the licensing even more. What would be the point of licensing parsers differently?
IMO, either way this goes should be global, not more complex without actually pleasing anyone.

In my position, I don't want to use ctags as a program. There are pieces of code that'd be helpful for me to bake into an application, I'm happy to contribute back stuff if its useful, but I don't want to have to license my whole program as GPL. Most of the time though, the license drama ends up draining the energy out of me and I move on to hack on something else

Well, first off, again, changing the license isn't that easy (and you agreed so) so you won't get GPL-free code just yet. Also, copying code around sounds like a poor idea, until proper reuse (library?) is rolled out. But well, it's free, fork it if you like :)

And honestly, license drama really strikes me as well, drama. There is an ideology difference between i.e. GPL and BSD, but I hardly see it as a valid reason not to want and touch code licensed under either of those. Yes, I somewhat fear myself some BSD code being reused in ways I do not like, but that worry is outweighed by the usefulness of contributing to something useful rather than starting form scratch/doing nothing. And as said above, I do even use BSD or similar myself in some cases, it's not like I consider it a bad license.

[b4n]

Note: the sentences below use "you" a lot, but it's not really targeted at any person specifically (and least of all personally), the quotes just made a good basis for that answer.

---

@raphinesse

Real world use case incoming.

I am using atom as my primary editor. Its symbols-view package uses node-ctags to read tag files, which in turn uses a slightly modified version of the readtags.{c,h} files from dhiebert's exuberant-ctags.

[…]

However, node-ctags is licensed under the MIT license. So I cannot suggest they take your version of readtags instead, since they would have to change their license for that. So in this case, the GPL clearly restricts our freedom and prevents propagation of free code.

I know your issue itself has been cleared out, but your point itself is not valid. @universal-ctags did not (really) change the effective license of CTags at all (yes, it went from an inconsistent mix of "GPL" to "GPLv2+", but you probably won't argue you preferred GPLv1).

So there was 3 possibilities:

• node-ctags was violating the CTags license already
• node-ctags had parts effectively GPL'd (with what this implies)
• readtags.[ch] was under another license

We know it's the latter, but your reasoning that the current license prevented what you wanted to do was biased.

So in this case, the GPL clearly restricts our freedom and prevents propagation of free code.

Well… I'll repeat myself, but no it doesn't prevents propagation of free code. It does "restrict [y]our freedom" as in it forces derivative to GPL-compatible-licensed, but it doesn't even prevent you from releasing other sources under other license.
The effective end license will depend on whether or not it makes use of that GPL code, but in the case of readtags the covered area would be pretty thin even.

So yes again, GPL code will affect the licensing of other code interacting with it, but it certainly doesn't make it not be "free code".

I would certainly advocate for a license change, and the action proposed here would be a good first step.

Well, actually you made me think of a good question: why would we want to change the license? You said that "[…] I cannot suggest [node-ctags] take your version of readtags instead, since they would have to change their license for that.", which is fair. But instead, you suggest we change our own? How do you come up with that?

Suggesting you cannot ask them to do so but you can ask us means that somehow GPL is worse than MIT. And good luck convincing anyone of that if they chose either themselves, we basically have all the same argument: "my license is more free, so it's better"; we just have a slightly different understanding of the meaning of "free" (or "libre" if you want).

[masatake]

As far as I am the maintainer, about licensing @universal-ctags will change nothing. We just continue what people did at exuberant-ctags respository.