Folks, he’s a human being. He’s made his desire known and you don’t have to like it, understand it, or agree with it. Just leave him be.
Are HN readers/commenters known for harassment? How alone are folks supposed to leave him?
But by being unkind himself, he surrendered that privilege.
So now he won't and shouldn't get what he asked for.
I don't understand how an adult human could fail to understand this.
Asking a favor while simultaneously being a jerk is not likely to work.
Especially since the code layer is so thin. The project has existed for a week, and consists of 360 lines of python, most of which are get/set on what I think is JSON.
Edit: Geez. Half the commits are bumping dependencies. The project is incredibly clean and beautifully structured, but gosh...
Now those are two very active projects but what I mean is that no one is forcing the author of the repackaged code to support anyone he does not have time to support. If they want support they can ask the nixos project maintainers for it.
I don't think there's a way to actually do that with an open source project though.
> If users experiencing issues with the ambee library in this package, they will knock on my door. And I'm not willing to support that or accept that burden. Especially as I don't see a good repacking reason in this case.
requiring users to explicitly set config.ambee.acceptThatThisPackageIsNotSupportedByUpstreamDevelopersAndIWillGoToNixpkgsToReportAnyIssues = true to be able to install the package, or they would get an error that would make it even clearer. Would that be enough for you?
the author replies just:
I feel like I'm starting to be on repeat now. Please don't add any of my stuff to this project.
The whole chain is a guessing game trying to figure out what the real issue is (and in the end, it’s not even found — the author randomly finds an alternative he likes)
"I'm running into some issues with ambee..."
"First, make sure you aren't using the version in nixpkgs. I do not support that distribution and cannot help you."
He misunderstands how nixos works and suggests that Home Assistant will be able to install his package via pip on nixos.
From his conduct in the thread this seems a red herring. The nixos devs have proposed a selection of reasonable solutions to avoid any support burden on his part, all of which he's rejected outright.
This sucks for nixOs, but it looks like community incompatibility means they won’t be able to support HomeAssistant at all.
https://github.com/NixOS/nixpkgs/pull/126326#issuecomment-86...
Users will contact the author for support, but users are getting the software indirectly via a packager, which means a) there might be changes from the packager b) they might be getting an older version that appears to be the "latest" and c) they don't have a way to install a modified version provided by the author to test out a fix in the same way that they installed their current version.
(It's true that with nixpkgs these problems are much more solvable than in basically any other distro, but the risk is stil there.)
There are likely multiple root causes. The whole space of issue management around libraries and applications using those libraries is a horrible and abusive mess. In my experience, between an application using a library and a library users will target whichever is easiest; not most applicable. Plus, most opensource user support is a fucking chore (you'd need to pay me for these days) that's unsustainable.
Another cause is likely the cost of nixpkgs contributions themselves. Personally, I no longer contribute to nixpkgs because even for tiny changes the process is ridiculously expensive. That's not including the cost of getting up to speed with nix/nixpkgs and the, often, highly opinionated packaging.
nixpkgs needs to be broken up into multiple independently distributable packages.
But he hasn't had to face any of that, and a couple different methods to avoid that happening were suggested and rejected offhand.
In this case it clearly hasn't happened to this author (yet) AND the nixos devs have put forward a selection of reasonable proposals to prevent it happening to him. All of which he has rejected without and real justification.
If you read the full thread it becomes clear that his citing fear of support burden is not made in good faith. His acts of blocking redistribution of his package in any Linux distro (here & Fedora at least) is clearly a bigger burden for him to take on than he would take on if he allowed the redistributions.
I think he also posts some of the funny ones on Twitter
[1] - https://twitter.com/ChristianHeimes/status/13828152605586554... [2] - https://github.com/samuelcolvin/pydantic/issues/2678#issueco...
Part of the beauty of Nix is it's easy to maintain patches - this can be nice cost-wise compared to upstreaming in many cases.
Not saying upstreaming isn't a generally good thing, but it's nice to have this other option.
https://github.com/home-assistant/core/issues?q=is%3Aissue+n...
https://community.home-assistant.io/search?q=nixos
I sampled a few of the closed issues and it cemented my decision to not use Home-Assistant for my Zigbee setup at home because of the recent behavior of frenck and other Home-Assistant top tier persons.
Reminds me of this story:
4. Integrity of The Author's Source Code The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.
to force nixos either to fork completely or become humble again.
"I'm also a little anxious that this thread has the potential to get heated quite quickly, so if you have the time and are willing to it might be worth setting up a quick Jitsi Meet to talk about this. Failing that, maybe we should pull this off into a separate issue thread so we can discuss there instead."
but he replied curtly with
"My wishes are above, please do not repack my code into this project. Please respect that request. It is a fairly simple request, nothing heated about it. I have no intention of spending time in this project.
Thanks."
If you read through the thread, the author makes it extremely clear that he has zero interest in collaborating or coming to any kind of mutually agreeable solution.
We sometimes like to think that software architecture decisions are made by rational actors using logic to choose the technically best solutions, but here's an interesting example where Home Assistant may need to change its dependencies because the author of the library it relies on is too difficult to work with.
You don't need to suffer any degree of support. Software in most cases is literally provided "as-is." There are no fruits to bare from providing something for free. Clout doesn't pay the bills.
I think people get really weird as soon as you cross the threshold of providing something for free versus something for even a nominal amount. As soon as you have to pay anything, it turns people off. Which is a good thing.
I think it's entitled to want to use someone's free work against their wishes. Why is he the bad guy? He acknowledges the licence allows it, but wants to change the licence in response to people wasting his time. That's surely fair game too.
There’s no silver bullet. Sometimes things just don’t work out right and you need to fork or make an alternative. I’d personally lean towards making an alternative in this case, if it’s possible.
You're entitled to nothing when authors write FOSS. They provide it as-is. Take it or leave it. No one is obligated to take support harassment.
The arguments left on GitHub are "well you chose this license" and generally, sure that's done out of good faith, but when organizations test the boundaries of an author's intent, they have no option but to relicense or dual-license.
And you know what, this isn't even unique! Tons of FOSS projects do not support alternative distributions. In fact, implicitly, virtually no one does. Most authors publish software with the expectation you'll use their distribution channels.
I don't think ... that's how the internet works?
(edit: I mean the "because... he doesn't want it to be" part)
https://www.jwz.org/blog/2021/06/to-be-clear-the-whale-did-n...
edit: maybe jwz took the image down?
1. in this case there's... more to it, as you've been pointed out
2. I still think it's polite to respect someone's wishes, especially when it is trivial to do so.
This attitude of "well I can because I can and what you think doesn't matter" is promoted as the culture of "the internet" by a lot of folks, but it's a cultural thing that not everyone agrees with.
Author ships code with a permissive license, other people build code, and view things from a purely legal perspective.
Author realizes that code doesn't exist in a vacuum, and that actual binaries/packages matter (different versions, etc) , which he doesn't control, and it's a problem to him.
He then asks the distro guys to do things differently. Distro guys are either offended (evil author!) , legalists (he chose the wrong license, his fault) or sometimes helpful (maybe there's an alternative) .
I think it's obvious the authors made a licensing mistake, and I don't understand why distro maintainers don't want to see this.
All in all, it's quite fascinating : a bit of law, a bit of social contract, and something truly in the 'grey area' where we, humans , don't always shine.
The author is additionally being intentionally dense and inflammatory. They are unlikely to get their way acting like this instead of trying to find a compromise as others are trying to do.
It also seems the author wrote this library specifically to be included in Home assistant (since HA only allows glue code to be included in the core and keep the implementation specific parts in dependencies) and does a lot of HA development. So he knew what he was getting into. It's not like he's library was added by someone else and he will now be overwhelmed by all the additional NixOS users. His requests to not repackage his code because of the support burden seems a little moot to me.
I don't think so. The "problem" here is that the author doesn't want nixos to repackage his library because he's concerned about a "support burden" imposed, presumably, by nixos users who might get confused and report issues to him instead of the packager. I can vaguely understand where he's coming from, but being as his library in question[1] doesn't even have a single issue submitted, I can't help but feel that the "support burden" is either a consequence of paranoia or an excuse to have his sources pulled from nixos.
Worse, his package is being pulled--if I'm not mistaken--as a dependency of home-automation. So this is a totally different issue than yours.
As the sibling poster said, once you license something under a FOSS license, your intentions are pretty clear. If you don't want that to happen, pick a different (non-free?) license. Saying "this is open source, but I don't want $CLASS_OF_USER using it" no longer makes it open source by definition and thus no longer a free license.
His solution is to release a new version distributed under a license denying repackaging of his code, which is one solution, but that's almost certainly going to cause his package to get forked from an earlier version (under MIT) or dropped from home-automation.
Either way, this issue is going to get resolved, and I suspect it'll be resolved in a way he doesn't like. This should be a warning to anyone distributing under FOSS licenses: If you're squeamish about any vague possibility that someone, somewhere, might--maybe--post an issue on your issue tracker that has something to do with a use case you didn't plan, then you really ought to not distribute it under a FOSS license.
There is ZERO obligation for an OSS author. Nothing, zilch. It is NICE to respect requests or help with issues you don't care about, but clearly not required when you are working on something FOR FREE.
https://community.home-assistant.io/t/consider-to-avoid-addi...
It's worth pointing out that for the time being, all of frenck's packages are still MIT, so there's no current danger. It's totally reasonable (IMO) to request things as a OSS developer that aren't technically license requirements, but equally there's not much you can do if the answer to that is "no" and the use is in the scope of the license.
Everything else is simply noise.
Once you make your software free, it isn't yours any longer and your opinions about it (or what others do with it) aren't relevant.
On the non-legal side, there’s still a much broader issue of being good members of a community. We do, in fact, live in a society.
While it's technically true that a free software author owes nothing to any of their users, it's a legitimate problem that there's no good way to selectively offer help and support to those getting the software directly but not to those getting it from a package.
"As the author of the package that is being re-packaged here. I'm against it being repacked into here. While licensing wise I cannot stop you, I do hope you can honor my request.
Thank you for considering respecting the author's wishes."
It seems more like a matter of respect than a matter of law.
The project could have pinned the version and downloaded from pypi rather than repackaging.
This isn’t a situation of “can do” it was “is it nice to do.”
And the author mentioned that he’s changing the license to prevent it so it no longer becomes possible legally.
I typically don’t like authors demanding stuff outside their license, but this started as a simple technical/community request to not do something dumb and escalated.
Just because you're legally entitled to be a pain doesn't mean this leads to good things. If the source owner has a polite request, honoring that is usually the best course of action, independent of what the law says. (Ask people who thought image hotlinking was OK even against requests, and how goatse looked on their page)
"It's legal" doesn't mean that it's decent behavior.
Not in common-law jurisdictions, where an open source license without consideration is a bare license and can be revoked at will by the licensor.
Do you have a reference or, more preferably, casserole to share on this point?
In this case it seems NixOS is just trying to exercise the “take it” option, but the author only wants to offer them the “leave it” one. If it’s actually “take it or leave it,” what’s the issue?
the author of the lib literally pushed it to Home Assistant, so he gave it to a relatively famous project that is present in a lot of distro and Snapstore. Pushing to such project is a guarantee that your code will be repackaged. He could say it was a misunderstanding and require to be remove from HA, but to go to a project that uses the project that you PR your code into? eh. We have licensing for this reason and I am quite sure if frenck had choose the correct license/limitation from the beginning, it would have never been accepted into HA and this whole problem would have been avoided
> Tons of FOSS projects do not support alternative distributions. In fact, implicitly, virtually no one does. Most authors publish software with the expectation you'll use their distribution channels.
I don't think this is true, and the fact that already author's libs had been already packaged in Gentoo, Fedora and possibly more distro (and he said he will request to remove them) show how quickly alternative and well used channel can and will pick them up if not specified in your license. Especially if the project you are contributing is ALREADY packaged in different disto.
Having the author's wishes expressed in law ensures that all users can receive equal, non-discriminatory and predictable treatment, rather than having to walk on eggshells around what an author may or may not like you doing.
Which is something of a bait and switch for a MIT licenced library
Hell, I could go make that overlay right now and link it in a nixpkgs issue for discoverability. What's this frenk person gonna do? Cut me an issue saying "pls delete this code from the internet"? Hah!
His library was written specifically for Home Assistant and it's an internal dependency that no one usually sees. It's a 300 lines wrapper for Ambee API.
$ curl -D - -H 'referer:https://news.ycombinator.com' 'https://www.jwz.org/blog/2021/06/to-be-clear-the-whale-did-not-want-him-in-its-mouth/'
HTTP/1.1 302 Found
...
Location: https://cdn.jwz.org/images/2016/hn.png
I don't know when precisely that stopped happening. Perhaps when OSS became more commonly hosted on sites like GitHub that have more easily-approachable issue trackers, users became more savvy about talking to upstream directly.
But he cannot retroactively remove MIT license. Changing license will only affect newer versions afterwards.
> If the source owner has a polite request
If this is your definition of polite so be it. I think it's quite unfriendly. Asked for a valid reason he basically says "because I want it".
If he want's them to remove it even though they have the right to use it he should at least explain why (or not publish MIT in the first place). His only argument is that he will get support requests, but he could just ignore them...
I'm not exactly sure who's being a "pain" in this case outside of the potential future concern that someone might wrongly blame him for package failures via nixos which is packaging it as an upstream dependency of home-automation.
I think I'd be more concerned about the latter's users!
In order for a contract to be valid, and enforceable on both sides, there has to be an offer, acceptance, and consideration. No consideration (payment), no contract, and the open source license reverts to what is known in law as a bare license. Bare licenses can be revoked at any time, at will, by the licensor, regardless of any promises made by the licensor to respect the license in perpetuity. (You can always tell a squatter to leave your property, regardless of how permissive you've been in the past.) This includes revoking the license to software downloaded under an open source license for which the licensee has given no consideration.
If instead of packing these separately, the home assistant nixpkg for home assistant simply downloaded all the required dependencies from PyPi, and verified them against a maintained list of checksums as part of the nixpkg (for reproducibility), then frenck probably would not object to that, since the last I knew the some of the official home assistant docker images do preinstall the requirements for the majority of plugins like that.
I'm suspect frenck's real concern comes from any possibility of modifications in the packaged version, combined with any possibility of nix allowing home assistant to be used with a version that is not an exact match of what home assistant specifies.
Alternatively If this could be packages as some form of home-assistant sub-package that was guaranteed to always match the PyPi version specified for home assistant exactly, without any mixing and matching, it would likely allay his concerns. Unfortunately he has not spelled out his concerns fully, so I cannot know for sure. I also have no idea if this is at all feasible in the nix packaging system.
From what I can tell the Home assistant core team doesn't not want to deal with any other installation variants than their own supported ones. Their user base consists of a lot of technical tinkering people (hobbyists, electricians, etc) but those who don't necessarily have Linux sysadmin skill's. So you could say they are skilled enough to get themselves in any of a hundred different configuration scenario's that would then need to be debugged by the HA developers for each support ticket. For a developer knowing the installation environment is at least sane is a great help.
That said, Home assistant does lend a lot of its growth to open source contributions, collaboration and being free software. If it was not as open in the beginning it might not have gathered enough attention to grow its current size. Cutting off developments in other directions like this to me feels against what FOSS stands for.
Honestly sounds like they just cannot have his project or anything that depends on it.
Luckily that ambee code looks trivial to duplicate.
This library was written specifically to be used in Home Assistant, as per project policy the code that interfaces with devices needs to live in a separate python package. So there is no real fame to be had from this particular package.
He surely sees this repackaging as a source of potential headaches. If the nix folks could convince him that the package would never contain modified code (no no untested/unsupportable modifications), and further that the home-assistant package in nix would always use exactly the version specified upstream (so no version mismatch concerns), he would likely be less opposed.
Unfortunately the latter is very much not true right now.
They did everything possible to try to convince him but he had his ears closed and refused to listen.
> Unfortunately the latter is very much not true right now.
Based on the above, it is very much true.
Well, you can disable the issue tracker for a project on GitHub. You're not even required to publish a project on GitHub, you can host it somewhere that doesn't offer any way to contact you.
Only the license terms that the software is released under matter.
Most FOSS licenses include disclaimers like: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."
If you did not pay the author for support, they do not owe you anything.
If they choose to provide support or fix reported bugs, that is their choice.
The NixOS team can use the code regardless of the developer's wishes if the license allows it.
If the developer chooses to not support the software on NixOS or change the license, that is their choice.
Additionally, the license is a contract (license don't exist as a separate category like in the US), the "[...] WHETHER IN AN ACTION OF CONTRACT" is particularly misplaced.
Are you by any chance a Firefox user and you have auto-correct enabled?
I'm guessing that because of "casserole", which is what Firefox corrects to if you accidentally double the 's' in 'caselaw'. Chrome goes for "casual", and Safari goes for "caselaw".
It's a swype keyboard, I'm not always awake enough to catch the errors. Casserole is good too though! ;o)
You can't demand respect from the Nix folks after disrespecting them by telling them to do something "just because".
I get being done with something when you've had a bad experience, but the maintainers here went to every effort to accommodate, and did so in a friendly way.
It reads like this guy wanted a fight and an excuse.
I think the correct answer is to just make the fork as proposed and use that instead, it solves the problem and removes the guy from the equation entirely. The fact he rejected it doesn't matter and he can be angry all he wants.
Daniel Stenberg creator of cURL has famously gotten a lot of weird support requests and emails over the years due to his license being shipped with an insane number of different utilities. He has handled them gracefully and with good humor from what I've seen, but not everyone is comfortable with fielding questions from random non-technical users - if that's where this dev is coming from then forking the project would probably let him dodge a lot of the responsibility. I just can't clearly tell due to how terse[1] his replies are.
1. I would say succinct here due to the fact that it lacks the negative connotations of terse, but it also implies a completeness of information which sadly isn't here. Please don't read terse as insulting or negative in any way.
The existence of pypi does not mean everyone is forced to link back to it and use it has their own source repo. Frenk insistance that everyone uses pypi and only pypi is just a tantrum not based on reality.
People could use his package from pypi and still have an outdated version. People could use a pinned version from pypi and they would always get an outdated version. People could be using an installed software from long ago and thus have an outdated version.
Thus his concerns are not magically solved by not packaging sources.
Plus, he has an attitude problem, is passive-aggressive, is closed minded and won't discuss. May he have fun with his newly weirdly licensed package,
You're right that the existence of PyPI doesn't mean everyone is forced to link back to it, but damn it would make a lot of stuff a hell of a lot easier if it did. I've been bitten by Debian packages being years out of date, I've seen packages modified by maintainers in ways that are poorly documented and useful for Debian users rather than Python ecosystem participants.
I've managed to work my way out of that now and would never go back to that world if I can help it as the trade of reduced engineering quality (along various axes) for increased "freedom" is not one that I value (personally, or at work). So I can really empathise with this persons position.
I think they handled it poorly, communicated poorly, came to the wrong conclusions, and left the discussion in a bad place, but all of that just screams frustration to me, and I can understand where it comes from.
Fast forward 3 years and a bug impacted a user's data in the portable package. The developer became increasingly irate even after it was fixed and demanded we stop publishing it. To avoid confusion, I even renamed the portable package to a new app name, forking it. That made him even more angry and he started publicly claiming we were "stealing" his work, despite following the license, maintaining his copyrights, and directing users to donate to his donation page to support development. He put up banners on his website and documentation pages about the "theft". As his emails to me went downhill, I got the feeling he might poison the code itself upstream to mess with the fork. I didn't want to deal with that just for one small app, so I abandoned it.
So, yes, this does happen. And some people thing "because I said so" is a valid position.
I would have forked his repo, and said, "We'll be happy not to include any of your code. We'll just use this forked repo which is now our code."
To make matters worse, he even used the fact that the NixOS discussion was temporarily locked down due to high tensions and accused NixOS maintainers of attempting to shift the maintenance burden on Home Assistant, which is hardly what all this is about.
https://community.home-assistant.io/t/consider-to-avoid-addi...
I'm afraid they do[1] (that's from the project founder, and current CEO of the company supporting HA development).
https://community.home-assistant.io/t/consider-to-avoid-addi...
which is something I haven't really seen anything in the open source world manage, though that might be because I'm not much of a contributor. What happens if a utility explodes in usage and the author can no longer effectively support it as a result of being buried in overhead?
Are there any mechanisms for limiting how much of one's life an author signs away to their project (without feeling compelled to grow an operation) while still retaining an Open Source designation?
In this particular instance, if you think the problem is "nix users are overwhelming me" - then you have a hard and fast requirement of: if you want support fill out this form that includes OS version. If someone lists NixOS as their version you give a canned response linking them back to the Nix github page.
If the issue is just a generic: my package is so huge there is just an unending list of people asking for help. Ignore them? I get as a maintainer you may have a desire to help folks, but nobody is forcing you to. Browse github and respond to the things you feel like responding to, and ignore the rest.
I mean this with all due respect, but part of being an adult is knowing when and how to say no.
You don't have to do anything to keep it open source. The source is already open, others can use it, fork it, etc. There is no formal obligation for you as maintainer. However as a maintainer you can feel a moral obligation for whatever reason (pride, guilt, peer pressure, etc).
https://github.com/frenck/python-ambee
The project has zero issues right now. I think that is not the real reason.
That way, the project lives on with minimal disruption to its users.
Yeah, it's called setting realistic expectations. If I release something open source, I don't owe you anything. Support, help installing, fixing bugs, spending time implementing your specific feature...
For distribution repacks specifically, there’s the old device of providing a configuration-time option to change the web and email addresses in the documentation (e.g. GCC does this), but I’m not sure if this will work when Google results for the error message will still point you to the upstream. There’s also the bug report checklist with “I have verified I am running the last development version”, but that comes with its own limitations.
1. Some kind of forum/wiki starts providing community support and increase community contributions pick up the burden
2. Some business starts supporting this component and picks up a lot of the burden because they fix things that cause them pain in their business.
I've never seen a single person passion project be both open source and well supported for a long period of time without healthy community engagement.
Exactly. He made that point a few times, but the replies don't always seem to address the issue he raises.
No, they offered solutions and only gave up when the author refused to provide any actual objection other than that he didn't like it. "Doesn't want people to file bug reports because downstream broke something" is a reasonable objection, but it's also a fixable problem. "The only thing that will ever make me happy is you completely removing this package from your distro" is neither.
I can fully empathize with him that he doesn't want some other project shipping an old an broken version of his project even though it is allowed by the license.
FOSS is really quite ill at this point. If you don't recognize what is happening, you're going to see this happening more. Continuing to blame maintainers that are burned out and frustrated and broke won't fix the systemic issues.
I can understand the author's concern, and NixOS offered to maintain it's own fork to mitigate it, and the author rejected the idea. That tells me that it was more of a temper-tantrum stemming from some other deeper issue than just a concern about support.
That response was what confused me as to the problem with packaging the library, as it seems like that would fix the inundated-with-support-requests issue.
They can also act as a bigger person and say "Sure, we understand, respect your wish and will find an alternative."
The author's conduct in that thread is certainly not what I'd call "acting as the bigger person".
If they were serious about their request they'd be looking into having the homeassistant guys removing it, or PRing to homeassistant. Or changing the license to make it closed source.
He just doesn't want the extra work to support another distro which would include an outdated version of his package.
If you make a license FOSS then people are free to do what they want. Just don't make it FOSS if you don't want.
> Seems like an author that doesn't understand the spirit of FOSS.
> Why is a person like this even engaged in FOSS if they don't have a desire to share or even engage in a reasoned discussion?
That said, the thread ended with something to the effect of "well, we can include instructions on how to install his software" -- an option which wasn't presented until the end, yet it fully complies with his request.
He added the dependency himself https://github.com/home-assistant/core/pull/51645
Nobody gives a shit about frenk or his code directly here - they want to use Home Assistant. But now that frenk added his code as a dependency, he has the right to transitively make Home Assistant un-packagable on NixOS?
EDIT: On top of that, the way NixOS works is philosophically in-line with Home Assistant
> Open source home automation that puts local control and privacy first
Pinning every Python dependency instead of fetching HEAD is how you get local control and security!
The argument that "In that case you are shipping an broken Home Assistant version."[1] is incorrect, since we also enable tests[2], when possible, on Python packages to ensure they are packaged correctly.
[0] https://github.com/NixOS/nixpkgs/pull/126326#issuecomment-86...
[1] https://github.com/NixOS/nixpkgs/pull/126326#issuecomment-86...
[2] https://github.com/NixOS/nixpkgs/blob/821b34edaf9911481ad4dd...
Even if home-assistant would download the files at runtime it can't put them at the right location and it would only work for python only packages.
IMHO the author needs to put the license he really wants (restricting the use of his project) and deal with the consequences. If you put an open source license to your project people make certain assumptions... like they can use your project.
If you want your software to be used in one and only one project and in a certain way, then it is not open source.
Is it the official policy of the home-assistant project that their software should not be packaged by NixOS?
frenck is the fourth most active contributor to home-assistant - and it uses quite a few libraries he has authored: https://github.com/home-assistant/core/graphs/contributors
If frenck is saying NixOS can't package his libraries, he's actually enforcing that NixOS cannot package home-assistant. Is this direction agreed by the other maintainers of that project?
I have the impression that it is the policy of the home-assistant project that their software should not be run in any way not supported by them, and not redistributed by any distribution or other third party. They're somewhat actively hostile against people not following that.
Though if that's the case it seems misleading of frenck that he hasn't clarified that this is a home-assistant policy in any of his comments around this.
https://community.home-assistant.io/t/consider-to-avoid-addi...
For context, balloob is the founder of Home Assistant
https://community.home-assistant.io/t/consider-to-avoid-addi...
If the views in that discussion are generally representative of the perspective of a majority of homeassistant maintainers & stewards, I'd be extremely wary of relying on the software long term.
> Just do as he asks
This is the absolute antithesis of the intent of open source.
What an awful community response.
I disagree with this assertion (...and with Frenck too). There was no need for NixOS packagers to involve HA here, they are outsourcing work upstream. Imagine some small-time driver author/maintainer asking Debian to remove their driver - and Debian's solution to honor this request is to ask Linus to drop the driver from his upstream tree!
The long-held tradition, when you disagree with upstream, is to maintain your own patch-set that you are responsible for and have to labor to keep current - that is not the antithesis of open source - it is very much in the spirit of exercising the right to change the source code as you see fit.
You're expecting an entirely unrelated community of users to be invested in the goals and interests of NixOS. They're not, and perhaps they see Frenk's point in a way that people that aren't part of their community do not.
I'm sure someone like that would do a little more diligence before blasting on the home-assistant community forums about one of their moderators (and apparently the 4th largest code contributor to the ha project overall).
if you contributed to nixpkgs in the last months you have probably seen me already but for the people that don't know me already: I am Sandro, one of the more active reviewers and contributors of NixOS/nixpkgs in the last months.
If you have any question about the situation or NixOS in generally feel free to drop me a comment and I try to answer them to the best of my knowledge. I can't speak for the entire NixOS organization so all my comments on this thread are my own views. I also do not receive any benefits from this in form of money or something else.
IANAL but it seems to me that even if he switches to some custom no redistribution/repackageing license unless he stops using pypi's infrastructure he's granting all pypi users the right to publish the code independently. By uploading it to pypi he's explicitly given all users of pypi the right to publish it[1].
1. Spending so much time trying to get the project to stop what they were doing.
2. Peacefully come to a mutually beneficial arrangement.
3. Front page HN where I will most certainly be avoiding using any project the author is part of.
> I just did notice Fedora redistributing some of my packages because of your question, so will file a similar request with them.
https://github.com/NixOS/nixpkgs/pull/126326#issuecomment-86...
Btw speaking of licenses, since frenck said he will be changing it by adding exceptions and making it non-free. Douglas Crockford said in one of the talks that one certain three letter company contacted him and wanted to use JSON format but weren't sure they could comply with "The Software shall be used for Good, not Evil." And he gave them that exception by stating: "I thereby allow ** to use JSON for Evil". My advise to Frenck is to adopt some similar proprietary license if he wants his work not be included in distros like Fedora and Debian. And grant exceptions to his fav projects like HA /s
> Are you enjoying my work? And want to support me in my effort helping the world to become a better place by dedicating my time & knowledge to create & innovate open source software solutions. Allowing everybody on this earth the privilege to enjoy those things for free?
Really looks to me that Mr. Nijhof doesnt quiet get what open source is about.
I mean, c'mon, Nix is a tiny niche. It's not like the support burden will be colossal.
https://github.com/flathub/flathub/pull/1978#issuecomment-74...
I'm really astonished with this comparison.
> Slightly assholic at first sight Actually a nice guy that just likes to get stuff done. @home-assistant Herder @hassio-addons Creator
In the github issue, as far as I can see, he doesn't "complain" at any point about having "no time to support users".
What he does say is "I'm not willing to support that or accept that burden" [of supporting NixOS users], and "I have no intention of spending time in this project" [meaning NixOS].
It appears that he just isn't interested in NixOS or supporting NixOS users. That's absolutely his prerogative, and does not mean he is "complaining" about not having "enough time" for it. And regardless, how he chooses to spend his volunteer/unpaid time really isn't anyone else's business.
There are some other valid criticisms here but I don't feel this particular point is a fair take.
Don't do open source (especially a very permissive licence) if you don't want others using your code as a dependency.
https://pypi.org/project/ambee/#history https://github.com/frenck/python-ambee/commits/main
That wasn't the issue and it's crazy how much people interpreted it as such. His issue is with how it was packaged with it. He want it to be exclusively distributed using PIP.
If you don't want to depends on PIP, well sure don't use it.
They do finally go into a little more detail about what their issues are with the packaging, beyond the single post with details originally in the thread.
> In the end, I think the way this project distributes Home Assistant (and its integrations, including Ambee) is not providing the intended working and thus may surprise the end user. In the end, those users are likely to knock on the doors of the Home Assistant project and their integration maintainers, not this project. As a matter of fact, most of my packages in this project are outdated and don't match the distributed version of Home Assistant.
They don't seem to address why they don't think that any of the proposed solutions would have addressed their concerns.
[0] https://github.com/NixOS/nixpkgs/pull/126326#issuecomment-86...
> I like to give back my knowledge and time to the open source community.
Considering how unreasonable he was in that thread, I'm assuming he was just in a bad mood or something like that. Except now he's on the front page of HN with tons of comments criticizing him and painting him as a bad person.
99.999% of people will probably forget this by tomorrow, but it still would suck to be on the receiving end of this kind of attention I think.
However the MIT license dictates what can or cannot be done. No need for further drama.
Seems like he does give back his knowledge and time to the open source community. Much more than me I can tell you, and probably more than many of people in thread.
What he don't like is people expecting support from him in ways that differ his initial distribution methods, which makes sense when time is a limited ressource and he clearly has expectations on how he want to spend it.
https://github.com/NixOS/nixpkgs/pull/126319
In response to "not having the latest": Generally we (nixpkgs) lag behind a bit, as managing ~60-100k packages takes some time. But as long as the process to build a package hasn't changed, we will have a bot which automatically attempts to update packages based on metadata from pypi, github, and repology.
"If you want to report a bug, please reproduce the issue with the latest pypi package. Reports for any other deployment methods will be closed without further discussion."
The Nix community is one of the few that has feet in both camps, so it's all the more frustrating to see a stupid reaction like this; a traditionally distro wouldn't even bother packaging any of this stuff or engage at all.
unfortunately the library author made a PR to Home Assistant, a program that is packaged in many distro; all those distro will add his package. see https://github.com/home-assistant/core/pull/51645
So long as everyone is supposed to just grab some docker container or OS image from the home-assistent people, the traditional distros that should back up NixOS here won't even be looped in.
It couldn't, since Nix is a package manager and will only download things from its repository. It can't access the internet otherwise.
And "becomes his problem" isn't right either. If he wasn't upset by normal packaging then there wouldn't be a problem at all.
However, this would become problematic if Home Assistant also uses a GPL dependency (which it probably does). That dependency would impose a requirement that all other libraries used by Home Assistant use a GPL-compatible license (which his license likely wouldn't be).
yes it is? they make sure the user get a specific version that is (hopefully) vetted and know as working properly; this is much safer than pulling HEAD for a 3th party repo. As long as the libs are updated regularly and when security issue are found, I see no problem with this approach
> he has the right to transitively make Home Assistant un-packagable on NixOS?
Pretty sure a custom license is not compatible with the Apache 2 license of "Home Assistant"; also as the code is in use by a third party, the author should not be able to retroactively change license, only next releases. Probably will be forked or removed depending on the specific of the case and of the code.
This is exactly what nixpkgs maintainers do, using more reliable and explicit tools than the likes of pip. A significant effort is made to enable tests on as many packages as possible, meaning that when you get a package from nixpkgs, it has been tested against the exact dependency chain (down to the libc) it is being shipped to you with. If tests fail, issues are investigated and solved.
This is a far stronger guarantee than you get from almost any other installation method.
The point of NixOS is reproducible builds, that is if you build a given nix environment you will always get the same code. Dynamically pulling from PyPI at runtime defeats that.
The author doesn't want any way of downloading the code other than getting "the supported version" from PyPI, as they don't want to deal with support requests for issues that are fixed later. They are likely worried that packaged versions will become stale, and users will expect support for specific versions, which they are unprepared to offer.
I think the offers from NixOS of having to enable config flags to get this enabled which make it clear it's not supported by upstream should be fair. Part of open source is that others are free to modify your code, and if you have a problem with that you're not really ok with the idea of open source.
Package versions are recorded in component manifests so it will not default to the latest version, someone has to make a code change and PR on homeassistant to update the version. And they are collected in a requirements file for every HA release[0]. So it should not be hard to automate that if needed whenever the HA Nix package gets updated to ensure the latest used version of ambee package is included.
[0] https://github.com/home-assistant/core/blob/dev/requirements...
Why would users report to his project when installing Home Assistant? That's not usually how it works and Home Assistant has a lot of other dependencies.
The person proposing the Nix package is a Home assistant developer afaik, so that would be weird.
The nixos guys also offered various proposals to him to completely avoid any support burden on his part, all of which he roundly rejected.
Seems he's just being unreasonable for the sake of it tbh; I can't see any logical reasoning behind it all.
"Slightly assholic at first sight Actually a nice guy that just likes to get stuff done."
If you have to warn people that you're an asshole and then try to convince people that you're actually a nice guy, then you're probably not a nice guy.
When we release software to others under an open license we are explicitly allowing them to do exactly what nix is doing.
I'm not sure what other reason we have a component independently deployable other than to make it usable by people in other projects.
AFAICT it's kind of the opposite problem to systemd owning unrelated stuff because it's easier on those developers.
But then the problem would be that it probably could not be on PyPI, since by putting it to there you grant users the right to do stuff with source, including distribution.
"If I upload Content other than under an Included License, then I grant the PSF and all other users of the web site an irrevocable, worldwide, royalty-free, nonexclusive license to reproduce, distribute, transmit, display, perform, and publish the Content, including in digital form." https://pypi.org/policy/terms-of-use/
(first pointed out here: https://news.ycombinator.com/item?id=27507770)
Additionally Frenk didn't react to any proposal to still distribute home assistant and it's dependencies while respecting his wishes. This seems like a pretty clear-cut case of involving the upstream community, to make sure they're aware and ok with their dependencies trying to block distribution or to change something if that's not the case.
The whole saga left me rethinking my home assistant usage, since it seems like this could become a larger issue with other distribution mechanism not sanctioned by upstream.
Nope.
I'm expecting an open-source community to adhere to the intent of open-source, which is to provide software in a freely redistributable way to that puts users first in contrast to traditional Berne-convention-based IP approaches focused on author protection & remuneration above user utility.
Any community placing authors as dictators of the distribution of their work at the expense of users are not aligned with open-source in intent.
That's a perfectly reasonable stance if you have no interest in open-source: everyone is entitled to release closed-source software if they prefer.
IMO there was no discussion in that thread just "remove from no" "we can't do that" repeat
If the HA community's stance goes on to be made official (for now it's informal forum posts, albeit from senior maintainers), I would argue this is then a case of one FOSS community (Nix) having irreconcilable differences with the community of a proprietary software project falsely advertised as FOSS.
I think you're right. This is largely a difference of opinion. It's a shame it couldn't have worked out better.
Another incident was when they deprecated/unsupported installing it on a generic Linux install last year, which they had to (somewhat) back down from after community outrage.
What do you mean by that, why shouldn't they include it?
It sounds like this author is looking for a third option, one that doesn't involve people management (1) or ghosting (2), and as far as I can tell, no mechanism for this exists that doesn't violate the current tenets of open source.
A direct consequence of open source is that the good user experience burden falls to the consumer, not the producer. If someone wants control over the user experience, they want a closed-source model.
From looking at the ambee repo the license appears to still be MIT; can't see any relicensing anywhere.
(And actually, as has been mentioned elsewhere, it seems like it wouldn't be possible for him to relicense in reality as the package is explicitly developed for homeassistant and as such would need to comply with homeassistant's licensing to be included as a dependency of it)
Aside from how this issue has been handled, poorly, that seems like a reasonable technical decision for HA to make, particularly given that their main use case is semi-technical user installing on a Raspberry Pi, and in that case is it something they should be forced to support? A fork seems like the right option there?
I've been bitten far harder by pypi packages trying to download random opaque binaries, miscompiling their own binaries, vendoring and failing to update large packages, having impossible-to-satisfy dependency requirements (relying on pip only ever making a half-assed attempt at satisfying them) and generally making strange assumptions about the target system.
I'm starting to get the feeling that home automation might be somewhat hostile to repackaging.
[0] https://community.home-assistant.io/t/consider-to-avoid-addi...
> Would you be happier if we forked your upstream source to provide our own, or provided a similar Python package with an identical API that we can use as a drop-in replacement?
Wouldn’t this remove the burden of support from the author? Or it might be that I don’t understand exactly their proposal.
So for example if this will be the case with a package I use I will report the bug to the fork because the package manager showed me their link.
I will not search for name-like projects or the original one and report there if a fork was distributed to me.
This is why I am confused why a fork is not solving the burden of possible bug reports. Also the fork assumes its own maintenance this is the purpose of the fork.
If users experiencing issues with the ambee library in this package, they will knock on my door. And I'm not willing to support that or accept that burden. Especially as I don't see a good repacking reason in this case.
I agree.
Which is the whole point of acting on it before it happens...
It's crazy the amount of entitlement I see toward open-source developers. You don't like his stance, then fork it and support it yourself. You are already lucky to have a good base to work on, you shouldn't even be entitled to that!
The only entitlement form the nixos devs has been using a right which Frenck explicitly chose to provide when licensing his software.
In the end, the will have to fork it, and probably maintain a fork of HM, since he is relicensing it to disallow repackaging.
So far, so good, until folks actually leverage the rights frenk handed them and he shows up and says "Please respect my wishes and don't distribute my open source code." I can see how this is very confusing for a packaging team.
It sounds like the "correct" approach here is for frenk (and HA?) to signal this lack of flexibility up front and stop distributing HA under an open source license. This will at least prevent other projects from investing in a packaging effort only to be asked to stop somewhere along the way.
There are also a lot of contributors who might have an opinion about closing the license: https://github.com/home-assistant/core/graphs/contributors
The "fine article" always contains the correct bits.
(Sure, that's slightly different than identifying such an auto-update point and then trying to do a supply-chain attack. But do maintainers look at what they package? In how much detail?)
Nobody does this, as this is completely unreasonable thing to expect.
It is not uncommon to see them request changes to the bumped library to fix any issues they have noticed.
Now, some users will perform due diligence and maybe find the NixOS issue referenced in OP and look elsewhere, but many will find the project and immediately file an issue there in the upstream, leading to the author's main concern of "I don't have time to support NixOS issues".
I was thinking that people will do the same or else how will they know if the github repository returned from search results is truly the one installed?
If their reason is "we don't want our driver distributed from someone else's git repo" then it would be a very good idea to warn Linus about it!
HA are perfectly entitled to continue including the package. The NixOS dev opening that thread was doing so with the intent of warning them about a potentially problematic upstream maintainer. There's an argument to be made that that dev was overstepping, but they weren't making any demands: their intent was informational.
The community response was multiple HA admins expressing the opinion that NixOS should remove the package. That's definitively overstepping on their part, and completely against what open source is about.
The "potentially problematic upstream maintainer" being a Home assistant core developer.
To me - the subtext was NixOS still wants to do both: have reproducible builds that match HA and honor lib authors wishes. Lib author "rejected" forks, so one way was for NixOS to ask upstream HA to drop the library as a dependency. It doesn't sound like a friendly heads-up to me, from the thread title.
There are two HA folk (excluding frenck) commenting on that thread. The first demands than nixos devs should "Just do as he asks", which seems to me like they are very much getting involved in the dispute.
The second only comments to close the thread, and—while they do include the phrase "it's not our issue" in their closing comment—the rest of that comment accuses the OP of bad faith posting, and goes on to misrepresent the issue completely, claiming the problem is that NixOS are doing things that are unsupported (Frenck's objection was to NixOS packaging his package at all in any form, not to anything specific they were doing with it). So again, that seems like the second poster is very much contributing to the dispute, not "not getting involved".
> one way was for NixOS to ask upstream HA to drop the library as a dependency. It doesn't sound like a friendly heads-up to me
I guess a lot of this does depend on how reasonable you think that request would be. I thought the post seemed friendly as it was phrased politely. And I think removing the dependency should be reasonable if HA wished to remain an open source project given the dependency is now defacto closed source (perhaps not technically in licence text, but the author harassing anyone wishing to avail of the licence would seem to nullify that).
> from the thread title.
Title opens with the word "consider". Seems polite to me...
> If users experiencing issues with the ambee library in this package, they will knock on my door. And I'm not willing to support that or accept that burden. Especially as I don't see a good repacking reason in this case.
I absolutely agree that there is a legitimate reason to say "look, I can't handle the support burden from this", but users aren't going to track down the original project to make support requests if you fork it, rename it and point everything to the new one.
(Obviously you might get one or two, but anyone that motivated would probably be making their own package and run into the exact same issue anyway, at some point you can't really blame the package).