If you decide to accept the code under MIT, then the added restrictions of the GPL no longer apply to your copy; if you decide to accept it under GPL, then the absence of those restrictions from the MIT licence no longer matters with respect to your copy. That’s why any contradiction between the two doesn’t matter in this case.
It just means that in practice the freedoms of the MIT apply to aux’ packages, which, are just build descriptions anyways, but peoplencan always decide to only honour GPL in their fork and then later upstream changes, honouring both licenses again.
1 Like
IDK if it’s too late since the poll already exists, or already mentioned, but GPLv3+ instead of just GPLv3 seems like a good idea.
2 Likes
The issue is that you can accept the code under MIT, which makes the protections of the GPL no longer apply.
1 Like
I don’t think this is how that works. As I understand it, if someone else also contributed to their GPLed fork we would no longer be able to accept the code under GPL or MIT, we would have to use GPL.
Similarly, someone could fork a MIT bit of code, stick the new bits under GPL and still upstream it so long as all the people with copyright (presumably just them, unless other people contributed) were OK with relicensing it under MIT. In other words, my understanding (not a lawyer, etc.) is that this would be possible anyway, and would only add complexity to do this dual-license dance
3 Likes
Already mentioned, this was actually a second iteration of the poll that removed the split there because they were too-similar of options. It’s possible that GPLv3 in this poll means either -or-later or -only… we haven’t specified
If instead of forking nixpkgs, we do our own thing, as per On the future of our nixpkgs fork, wouldn’t this also mean we could put our own nixpkgs equivalent under GPL?
A minor technicality: if the package build rules are GPL, then there are a couple of ways to accidentally propagate GPL’s virality into the build product - for example applying a checked-in patch file.
This is manageable, there’s only a few things that propagate the build recipe’s source license into build products under the GPL’s definition, but strictly speaking the license will have to be “GPL with additional exceptions”, spiritually in the vein of SPDX’s GNU-compiler-exception identifier. But it is a slight headache that doesn’t happen with the permissive licenses, specifically for package build recipes.
EDIT: resolved below, as far as I’m concerned. I think I was wrong with this theory.
9 Likes
That makes sense, maybe it is best to have our nixpkgs equivalent be under something like MPL then, where I don’t think you’d have those kind of headaches.
If we license parts of our code (for example, the Core repo) under a copyleft license, does that mean that anyone who consumes Core for their project’s build definitions must also follow our license?
I’m not very well versed on how copyleft works in cases like these. But if this is the case, I consider adopting a copyleft license to be significantly harmful to the success of this project.
2 Likes
I agree that using some kind of weak copyleft license (mpl, eupl, etc) might be the appropriate middleground here.
(Weak copyleft: direct changes to aux provided code must be copyleft too, but using it does not force any license, i.e. allows for anything from proprietary over MIT to GPL)
2 Likes
I don’t know the MPL license text very well, but something permissive yeah. I don’t have the legal training, for optimal results we should consult a lawyer if correct answers matter 
Two empirical studies though:
nixpkgs is under MIT license, which is permissive but does require a copyright notice and passing on the license text. I’m fairly sure nixpkgs doesn’t embed required attribution when applying patches authored in-house, but MIT attribution is also one of the more often ignored requirements.
Guix’s package tree is GPLv3, and the patches do not carry other license information - though they frequently (by policy?) have an origin, e.g. “this patch came from Debian’s bugtracker” or “this one is from guix”, etc.
So, I suspect the pragmatic answer is that distro patches are either out of scope based on some piece of the GPL text, or it’s one of those things where nobody really cares because it’s not a problem in practice 
Afaik patches inherit the license of the source code they apply to, because they are considered a part of said source code. That is to say, most patches are probably licensed differently than guix/nixpkgs/auxolotl anyway.
3 Likes
… oh, yeah, that makes sense. It’s the same intent as sending a patch upstream, with that framing this is an irrelevant issue, sorry I brought it up!
1 Like
I think this a very relevant topic to consider, even if it turns out it has no practical consequenes. Thanks for bringing it up!
Not necessarily. But let’s say you are a small coding shop doing consulting which includes some service development & configuration for customers:
- With Nix:
- Development and deployment of these internal systems comes with no strings attached beyond a copyright notice.
- With Aux:
- If you declare the system in nix code using Aux nix code then that whole config is also copyleft and thus must be made publicly available.
- If you declare a shim which manages all the systemd stuff by launching non-nix authored systemd config then only the shim is copyleft and thus has to be made publicly available.
- Objectively, for customer privacy and flexibility you are delivering a subpar service if you do not suggest a more flexibly licensed product. Nix is the vastly superior choice. But more likely the customer does not have that insight and will in stead go "No that does not work for us - give us something Ubuntu or Windows based’'.
Right now this is the reality the community is voting for. Dismissing the business case out of hand as “corpo can buzz off” is very easy and highly popular - no surprises there
Only point of slight critique being that this stance ought to have been very clearly communicated in the key project principles rather than snuck in after the fact in a poll.
8 Likes
@isabel / @jakehamilton Incidentally, given that the poll closed yesterday, could we please have that clear communication explicited on the site now? As things are, people are still going in blind with the fair assumption of MIT - having been not told anything to the contrary.
2 Likes
Do you have an idea around the ways you would expect this to be communicated?
I would suggest adding it in as a point in the Values section of the site. It is prominently displayed at the top of the page, a key differentiator, and copyleft licensing is very much a choice solidly anchored in values & beliefs
Ah and ofc. to cover people who already signed up, a pinned post here in Announcements would probably suffice.
I don’t get why such a significant decision, which likely affects project values is being made without a ranked choice poll. Obviously, there are people who strongly prefer the copy-left license, and there are also those who strongly oppose it, with others falling somewhere in between.
2 Likes
When I voted in this poll, it barely even occurred to me that it would be binding.
Ideally, I’d like more time to think about it.
I did vote, and I didn’t complain at the time, so I have only myself to blame (seriously - not being pasag). But my current opinion, FWIW, is that we should aim to choose our licence later. (In the meantime, we’d need to use a licence that made it easy to relicence, and maybe we’d need to keep track of copyright holders just in case.)
4 Likes