Voting for a licence

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 :slight_smile:

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.