I appreciate it. My actual stance on it is that there is a somewhat justified worry that DS isn’t being a good steward of the community. I’d go into how the LGPL in particular interacts with this and how I think all companies should push upstream when possible, but don’t love how these concerns turn into an opportunity to dunk on “the wrong people.” It has made interacting with the community frankly depressing, and is the kind of zero sum game I refer to.
I now see your point a bit better and I concede that there is a significant amount of that sort of zero-sum thinking going around.
I mean, I’d write a whole essay on it, and maybe I will. I think that Nix’s LGPL is good and the big question is whether DS is trying to work around it, or work with it, or some combination of the two options, and how much a lack of leadership has let the status quo unfold by default. What I will point out is that the LGPL is a license that means people’s work can’t be stolen and appropriated, so the source of perceived unfairness is coming from other locations likely related to expectations of how their contributions track with upstream.
Edit to add: in a matter of weeks, the community will be able to manage those expectations by talking with the stakeholders involved and doing the thankless work involved in getting a bunch of people with slightly differing motives to agree, so hopefully this cold war can end.
I don’t know that the LGPL comes into the picture given that detsys created an allegedly rust-based impl of the daemon. The main contention I saw was misleading marketing, for example:
Right, this is the possible “working around it” I was referring to. Is it a full replacement for the daemon? I was under the impression it was some sort of orchestration process that serves a different purpose.
Edit: It’s this daemon, which handles logging into FlakeHub and scheduling GCs, and doesn’t replace nix-daemon. They also say:
At the moment, the Nix in Determinate Nix matches the upstream version. In the future, however, Determinate Nix will include patches that have not yet been released by the upstream project.
So, it’s more like another Nix distribution. This still brings me back to my initial question about the expectations about upstreaming patches for this sort of thing, and that the LGPL says anything that’s core Nix will remain open.
The LGPL doesn’t compel a fork to upstream its patches, but modified source code still has to be released if the modifications are released in binary form.
If Determinate Nix were to dynamically link to CppNix or just call its CLI directly, there’s no obligation to release source code. The dynamic linking exception is the main difference between the LGPL and the GPL.
Yeah, the “being nice” part is a social contract. Given history, I understand why people are hesitant to trust that they’ll uphold it. But, again, this is where clear expectation setting and boundaries help for the future. Especially around coordinating things like CVE releases which require a cohesive approach across projects, but it could be extended to “work with the team in general if something is to become an upstream standard.”
There’s technically nothing stopping CppNix pulling patches from Determinate Nix without their approval. May not fall under “being nice”, but, that’s the license.
Reciprocal licenses FTW!
@grahamc are you (read: Graham and Determinate Systems, the company Graham represents) this unresponsive when it comes to feedback with your actual customers too? (Or I should rather say, negative feedback, as since the last time I posted you seemed too happy to reply when no one’s complaining (link, link))
This seems like something any current and potential customers (which may include me too, who knows!) lurking on this forum may want to know. If not, do we need to fund an entire new company just so we can make you answer a few simple questions?
I have brought this up twice. So, for the third time, what is up with post you linked referring to Determinate Nix as just “Nix”? Have you not noticed how this may mislead people?
And as @olaf has brought up before, how do you plan on solving this obvious name collision?
If this was an honest mistake you can just say so, fix the blog post, and all this discussion will be over.
To clarify the distinction further, we’ve updated the blog post link to point here instead. The now-linked page provides, I think, a “softer landing” than the official landing page and explicitly demarcates upstream Nix from Determinate Nix.
So you changed it from a link to your site to… a link to your site. Also, that page immediately starts with “We recommend starting with [a different page]” and then initially goes on to describe Nix as confusing.
We recommend starting with the Nix quick start and consulting concept docs primarily for clarification. Feel free to click x to the right to disable this notification on all concept docs.
Nix can be a somewhat confusing term because it refers to multiple things:
That’s not a good landing page for marketing purposes. It’s more of a technical overview. And it doesn’t resolve the problem of DetSys continually making efforts to brand Nix under their own domain.
It goes on to say:
- The pure and functional programming language
- The Nix CLI
- The overall Nix package management system
Is that not a common confusion?
Should it be?
I think that page is a decent technical overview but a landing page it is not. And you’re right, it’s not supposed to be. That just makes it all the stranger that you’ve linked to it as the introductory link to the Nix ecosystem in the blog post.
Removed because it goes against my communication values.
It doesn’t say that Nix is confusing, it says that the term Nix is confusing because it can refer to three different things. This is a common complaint about Nix that, to me, feels worth tackling head-on.
Removed out of respect for the removal of its parent comment
Our blog style is to heavily reference concept docs and similar sources. It’s an editorial style you’ll find throughout everything we write. Not to push people to a specific flow, but to generally provide deeper dive educational resources.
I suppose I’m still a tad bothered about linking community-wide words like Nix, nixpkgs, and NixOS to your own site, but I guess it’s hard to see that as a significant issue on your own blog site.
Regardless, in this particular instance, it seems like linking to the quick start makes more sense than that clarification page.
Everything about Nix was a hugely rewarding puzzle. Every successful build was a huge dopamine hit, rewarding the challenges of navigating the Nix libraries and fixing build problems. Every pull request to Nixpkgs was quickly reviewed, merged, and celebrated by a relatively small group of dedicated folks who loved this tech as much as I did.
This really spoke to me, too. I got into NixOS around the same time as you, @grahamc— although I never made comparable contributions to Nixpkgs or communiry infrastructure. I remember the coziness (which is certainly gone) and the brilliance (which has not diminished at all) of the community at that time fondly. When I first tried NixOS, I knew I’d stumbled upon a secret treasure, and I wanted to show it to everyone.
Nixpkgs was smaller then, and so packaging something just to be able to play with it on NixOS was a given for basically all NixOS users at the time. And especially at that phase of my own discovery, there was joy in the puzzle-solving of it. There was joy, too, in encountering the incredible generosity of the Nix community, in how people worked to help newbies like me solve our own problems and improve our little contributions.
We had (and have) something really special here.
An aside regarding the link text for the word ‘Nix’ pointing somewhere internal: we do the same thing on my team on our docs site (which is aimed at external teams within the same company). We try not to redundantly document much that is covered upstream, and we do direct users to the actual Nix docs.
Nonetheless, we have a little Nix section in our docs that contains those links to upstream, some additional context, and various recommendations about how to approach Nix and its own documentation. I don’t think it’s that unusual a practice for blogs or docs sites. It’s the norm for wikis, too, of course.