What license should we use?

Given the recent change events, I’d like to see Aux really define what it wants to do as a fork. The reason for its existence was a change of leadership, but now that that’s (tentatively) fixed, what is Aux?

I’d like to maybe differentiate it with a license change – maybe have it be a more rapidly iterated nix but under the GPL, since Nix is MIT? I don’t know about the minutia of that change, but it could be cool to see.

2 Likes

I wonder… I would think this would make contributions-back impossible, which is maybe not what we’d want

5 Likes

It would be really great if we could use the GPL for our repositories, it sends a clear signal that we care about software freedom.

3 Likes

Again, as I understand it (I am not a lawyer) this is something we cannot do if we want to be able to contribute back/upstream any improvements. If this is something we mind then we can’t change the license like that.

2 Likes

I mean the current nix repositories use the MIT licence which is still a OSS licence

1 Like

We can use a dual license of MIT and GPT3+, that works and still sends a signal!

2 Likes

If you want to lean towards GPL, consider the EUPL instead. Despite its name, it is a general purpose license that can be summarized as a modern GPL.
The clear and added benefits are the more easily approachable text and that its officially translated into 23 languages, which improves accessibility a lot.

Some discussion on the topic

4 Likes

It would probably be good to make this a separate thread. I’ve got some things to say but I’ll save them for later.

3 Likes

Thanks @Jeff, done so. Feel free to say whatever things you want about the license here, or continue saving them :slight_smile:

2 Likes

I think it would be nice to have EUPL!

I think that during the time The Future of Aux and Nix is still a question we shouldn’t go all out on that change yet.

But if this project will continue to be a replacement - GPL-styled license may be the better option.

3 Likes

Yes, let’s first setup things and do that later

I like GPL, some of my repos use GPLv3. Copy left is extremely powerful, and I think that power should be used strategically. I switched to GPLv3 for my C++ Syntax repo that Microsoft uses (and told them) because I was in a position to negotiate, my tool was not the foundation of other tools (no cascading downstream effects), and I wanted to give VS Codium a leg-up over VS Code.

But, if Aux switches to a strong copy-left FOSS, I don’t think I can support/use it.

Unlike the situation above, Aux is both not in a position to negotiate, and Nix/Aux is as foundational as any tool can possibly be. Potentially everything could have nix/aux as part of its codebase. There are a great number of tools build on top of nix, whether its Flakehub or Repl.it or Devbox or Flox. All of those get called into question with copy-left. Its not just about “we don’t want to open source” a lot of them are already open source, the issue is they effectively loose the ability to protect themselves from being steamrolled: they can’t stop Amazon from copying their whole codebase and hosting the same service for cheaper while Amazon contributes nothing to the original project.

More important than my personal opinion though! There is no comittee or voting system right now. It would be best by far if we can decide this once Aux has a functional governance system. If we use MIT (or equivlent) right now we can vote to change it later to GPL. But we cannot easily do the reverse

Finally, I think it is incredibly important that Aux have the least amount of friction until its actually functional.
GPL adds friction when it comes to using or contributing.

9 Likes

Adding here in writing that I share much of the same views as Jeff mentions (thank you for writing this post). Starting with the existing MIT licensing is probably the right course of action and considerations for GPL can be made later. I will, however, say that for non-nix things such as our branding repository I think it is perfectly acceptable to use copy-left licenses since ownership of those things belongs to the community.

8 Likes

Do we want to make sure we have something that’s compatible with the ZFS license? My view is that almost anything is compatible, and I have done some reading about that, but IANAL so I thought I’d raise the topic just to be sure.

1 Like

My personal preference is also to share as much of my work as possible via as permissive licensing as possible - which means MIT when I don’t just use Public Domain.

I emphasize with and respect the preference for copyleft licensing, but speaking for myself I would exfiltrate from the project if it were to swing copyleft.

2 Likes

Working in Embedded Systems development I have a “professional preference” for MIT/BSD-licenses when it comes to libraries. Regarding the package definitions, I thin EUPL would be a good choice, with dual-licensing as MIT for the transition period and maybe a prolonged exemption for nixpkgs after this phase.

This is also a good discussion of permissive vs. copyleft:
https://drewdevault.com/2024/04/19/2024-04-19-Copyleft-is-not-restrictive.html

Differentiation definitely makes sense. The way I see it, cppnix should most definitely be copyleft licensed.

nixpkgs and cppnix forks should stay MIT imo

i feel it would be extremely unfair to not just the maintainers, but the entire community of either project to take their work and license it in such a way that they can no longer realistically use it. i would like to see a future where we can go our own ways, but still improve each other as projects - especially with a member of the nix team already reaching out. a copyleft license could easily create issues here

6 Likes

We have quite a few repos which are unlicenced. It would be awesome if someone could identify these repos and raise a PR when this poll is closed.

For reference without providing a licence by default the following happens:

nobody else can copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation
- No License | Choose a License

  • MIT
  • GPLv3 or later
  • GPLv3 only
  • EUPL
  • 0BSD
0 voters
1 Like