My understanding is that this (the software and original works produced by Aux) is what the poll is for
3 Likes
As per the original post âwe do NOT plan on changing the licence for nixpkgs or nixâ
This.
3 Likes
This is pretty much my feeling. My first impression about Aux (from the aux.computer website) was that it was first and foremost about addressing governance issues in the Nix(OS) project(s), but Iâve been seeing a fair few threads already pushing for changes I see as outside that scope, which has made me feel much more uncertain about whether I can realistically replace Nix(OS) with Aux for my uses.
On the licensing issue, if the Aux community wants to shift hard to copyleft licensing, why not just use Guix? Are there technical or governance reasons not to use that over Nix(OS)?
Speaking just for myself, guix is incompatible with my needs for reasons other than licensing:
- Guix restricts itself to purely libre software, and disallows firmware. This makes guix unusable on all my computers, since I need firmware and a small veneer of unfree software. nonguix exists to bridge this gap, but the adversarial relationship with the main project tells me my values and Guixâs arenât well matched.
- Guix System (the NixOS equivalent) makes some radical system design choices (e.g. using GNU Shepherd as pid1 rather than systemd), which make it even harder to gracefully integrate new things. Itâs already a chore to integrate upstream software into a nix-like universe sometimes, and I donât want to make it even harder on myself by also having to adapt software to a very âalienâ system.
- On a purely technical level, at least the last time I gave it a test drive, the use of Guile forced a lot of the critical path of deploying configs to be single-threaded, and it ended up being an order of magnitude slower than a comparable (already slow for my tastes) nixos-based system.
(Guixâs governance, general vibes and technical choices all seem reasonable and valid, to be clear! I admire that they know what they want and stick with it, itâs just not a match for what Iâm looking for.)
Guixâs license never really factored into my evaluation (in fact I had to go look up just now which one it is! Itâs GPLv3-or-later). Iâve gone full circle over the last couple decades, starting out as a strong copyleft believer, then seeing the good in permissive licenses like Apache2/BSD/MIT.
In recent years Iâve swung back towards GPL, AGPL or even non-OSS outliers like Polyform Noncommercial, in response to what I see as companies violating the social contract at an increasing pace (most recently the un-opening of things like Terraform and Redis, but also more generally consuming volunteer energy without giving back - legally permitted, but still a jerk move).
When it comes to Aux in particular, I have my own preference for copylefting original works, but itâs a mild preference not a deal breaker.
So I guess the short answer for me is: yes, there are both technical and governance reasons Iâm not using Guix, regardless of its license 
14 Likes
ops i let the global pin expire⌠i wish i could set it for a given time, rather then a set time.
I think I should repeat what I did before: it makes the most sense here to go dual license I feel like.
Isnât dual-licensing with GPL and MIT kind of pointless? You donât get any of the copyleft protections because anyone can just take the code under MIT and push it into proprietary software.
6 Likes
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