When creating the poll the intention was less for licensing documentation but code, particularly because thats where the prior discussion was leaning. However, I think SIG: Documentation would be a good place to have a vote or discussion on documentation licensing.
7 Likes
Same here. Tools make sense, but if other material starts going copyleft and the state is more or less “well, new stuff could go either way”, then I can’t make actual use of anything aux.
I’ll stop by and throw around some likes every now & then though 
2 Likes
Just so everyone knows you can change your vote if you think there is a better fit.
1 Like
Classic haha, the best kind of work
1 Like
I think the Fedoraproject is a good place to look at when it comes to legal stuff.
The fedora developer portal licenses all of it’s documentation as GPL 2 and the fedora wiki licenses everything as CC BY-SA 4.0 International.
They also have a dedicated wiki page explaining the different licenses they allow and for what reasons.
2 Likes
Can we have a runoff vote with the top 2 votes once the voting ends?
4 Likes
I think that is probably the most straightforward way to handle this right now.
I do want to repeat, my understanding is this is a feedback tool not a final-decision poll. There’s still no governance setup for handling this as a final decision poll.
As a feedback poll I think its doing a great job. I didnt realize how many people were in support of GPL or MPL.
2 Likes
Due to the considerations of Voting and ensuring integrity, I think a follow up poll will be a good idea too. But like Jeff I also don’t want to repeat this current poll.
2 Likes
We discussed this a little yesterday in call, didn’t we? I had believed the conclusion was to be compatible with the NixOS Wiki by using the same license (which is MIT)
3 Likes
For those that require MIT they can stay MIT for compatibility, otherwise software and original works produced by Aux can be GPL right?
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