Terminology beyond the NixOS Trademark

Links
1

You can ofc call things what you want, just the words I’m using/going to be using for now. This isn’t foreshadowing, I swear.

7 Likes
2

Using the NixOS logo may also get a similar treatment

Tim Cuthbertson released the NixOS logo under a permissive CC-BY license and it was later clarified as CC BY 4.0.

This essentially give freedom to share & adapt under the condition of attribution and no additional restrictions (details on Deed - Attribution 4.0 International - Creative Commons).

3 Likes
3

Interesting read. Btw s/Twix/Tvix

1 Like
4

That’s good to know, I like the logo, glad I can use it for random stuff. I guess the best way to read the start is then as how I read the board as thinking about this. I really am not a lawyer and am trying hard not to step into saying anything about that part.

I was hungry when writing this so makes sense I’d mix this up. Will fix.

4 Likes
5

I am similarly not a lawyer, but reading the Creative Commons FAQ, it seems there may be some abilities to enforce a trademark policy on the logo:

CC licenses do not license rights other than copyright and similar rights … For example, they do not license trademark or patent rights

Although, they also specifically do not recommend licensing trademarks under any CC license:

Creative Commons does not recommend using a CC license on a logo or trademark. … Allowing anyone to reuse or modify your logo or trademark as a matter of copyright could result in your inability to limit use of your logo or trademark selectively to accomplish those purposes.

It’s not clear to me how that would work given the logo was licensed before the trademark existed.

6

Thank you for the article.

I just wanted to elaborate on a claim:

Lix is an functional package manager (FPM). Same functional store convention (FSC) as Nix […]

FYI, we do not plan to continue to support the functional store convention that CppNix has in the future, e.g. allowing xattrs in the store. This may not change the fact that we are compatible with nixpkgs but we also do not plan to remain compatible in the long term future (at least with nixpkgs in its current form).

5 Likes
7

Thanks, amazing! I may use this as an example of how this helps disambiguate actually.

Also, I had a vague feeling Lix/AFNix might come out with a system distribution at some point, but I couldn’t find anything to point at. If you have something let me know!

5 Likes
8

AFNix do not have an active system distribution project at the time being.

4 Likes
9

Is “functional” a good word to use? I know until now, all the solutions are functional, but there are also programming languages that are not functional. The same thing could be done with them. Then, “functional” wouldn’t really fit.

“Declarative Package Manager”, “Declarative Package” and so on could also work. Or Code Based Package Manager.

2 Likes
10

Good read. One new term for the collection that it would be cool to align with:

** Functional Store Conventions (FSCs)**

I say convention because it’s the shared layout and hashing and “where do the built things live” rules — not one fancy network protocol. Nix, Lix, Determinate and friends mostly share one FSC (…)

Nicely enough for us, the FHS 4 draft already calls us a “store-based system.” If you go to the “view app” button on the above draft’s merge pipeline which at present links here (though I assume that’ll get blown away) you can read about what the FHS spec sees us as, for example:

Store-based distributions are often designed to share the filesystem with a more conventional distribution (conforming to one of the above two profiles). When this is a design constraint, the store root should be, or be within, a top-level directory identifying the distribution, such as /nix (this is the directory used by NixOS) or /gnu (Guix). When it isn’t, we recommend using /store as the entire pathname of the store root.

(So a functional store convention is just a certain type of store-based distribution by my read).

The original FHS 4.0 feedback request was by @zwol in this thread:

2 Likes
11

I mean, I get the appeal of using a broader term.

But “declarative” by itself does not capture everything. Plain configuration files are declarative, and so are things like SQL. Likewise, “code based” could describe a package manager built around an unrestricted imperative language, which would be a poor fit for a reproducible declarative system unless the language were heavily constrained. Not that I’d stop anyone from trying, just I’d probably not use it!

The functional and purity related aspects are not incidental implementation details. They are a large part of what makes NixOS and GuixSD work. Configurations can be composed and evaluated as values, dependencies are explicit, and results are not supposed to depend on hidden state or arbitrary side effects.

So yes, something similar could be built using a language that is not usually called functional. But it would either need to reproduce many of the same functional and purity-oriented semantics, or it would become a substantially different kind of system that may no longer feel much like NixOS or Guix System. And I think without a somewhat pure model getting any of this to work at scale is really hard and brittle to maintain.

So I think “functional system distribution” still identifies something more specific than merely “declarative” or “codebased”, something load bearing for what makes these systems special.

Of course, Nix(OS) essentially has counterexamples where any and all of these rules can be broken, but those are more divergences from the actual paradigm, not really intentional parts of how it works, so I don’t think it defeats the point.

12

I agree, and I think this is a good umbrella term, but a bit like my reasoning in Terminology beyond the NixOS Trademark - #11 by cafkafk above, I think that there are many many many things that can be store based that are nonetheless nothing like specifically what we are doing.

There are many ways to construct a system with a store that would still not feel anything like what we are doing, and while that’s certainly a property of what makes a functional system distribution like ours, I think that having a store based system in this sense of e.g. a file system hierarchy at root isn’t actually load bearing to getting something like what we are doing.

Hence the niceness of the idea that it’s a convention. It may well be a useful convention, but a NixOS shaped thing could do something very different with the store, and that wouldn’t necessarily break it’s NixOS like feel.

1 Like
13

Yeah, I immediately thought of some inadvisable things that one could do with snaps, and decided to just not think about that much more.

The spec even specifically allows the generic /store as an option, but doesn’t specify it more presumably so the contents of the store can be implementation-defined as Nix’s and Guix’s are in the previous examples.

3 Likes
14

Thanks for the write-up!

“Nix” can be used in some cases, albeit only when there is no confusion or product conflict with official NixOS foundation projects.

Since neither of us are lawyers, I just want to challenge this.

Is Nix really covered by the NixOS™ trademark?

I think that’s not going to work out in practice.

On another note, here’s something else I’d really like to know:

Since the trademark was made to have some possible control of how the brand is used (and possibly misused), perhaps we can have an official guideline for how to advertise that you’re a Nix(OS) consultant?

For example, Numtide.com writes:

Nix & NixOS Support

We provide hands-on NixOS commercial support to help your team build, maintain, scale, and troubleshoot reliable systems faster.

Now, maybe the official guideline says “Remember to write NixOS™!” with no strict enforcement, but with the appeal that it makes the endeavor more professional and legitimate. So more of a celebration of the trademark to engage commercial interest than a scare tactic to “use it the wrong way.” – this is entirely my suggestion, maybe the NixOS™ legal team has a completely different idea.

Another consultant might like to say they’re a Nix Consultant, or a NixOS Consultant, or a Nix Sultan, or a Certified NixOS™ Consultant. Now we’re in another territory. Having clear guidelines on how you can address your affiliation with these terms when you do consulting would be very comforting, since ™ can provoke a sense of authority in both good and bad ways.

1 Like
15

Is there anywhere I could read more about this?

16

Unfortunately, we do not have written up plans yet, but we basically want to drive some fundamental changes to Lix that requires also fundamental changes to stdenv and the way nixpkgs operates to unlock true ca-derivations among other improvements (xattrs, etc.). It’s still quite far away (>1 year) in the planning, you will see news regarding this in time.

8 Likes
17

@rhendric perhaps it would make sense to split the thread so we can have a focused one for discussing the trademark?

But ultimately the board is significantly more capable of answering these questions since they’re the ones that deal directly with the legal process and ramifications of the trademark.

I have my own views on how I’d want it to be implemented in trademark policy. I’d agree having guidelines would be very nice. I’d also temper expectations given the SC isn’t the fastest team in NixOS, unfortunately.

1 Like