Seems like an author that doesn't understand the spirit of FOSS. The nixos team was clearly allowed to use it and include it when asking for some technical merits as to why, and even offering many alternative options to appease the author the author seemed to just childishly stamp their feet and say, "because I said so". Eventually the author took the position of "taking my ball and going home". 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?
When they offered to fork it completely to avoid the issue and he rejected that, it really just looks bad.
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.
From what I can see in the thread (and I'm not very familiar with the tech so I'm working off of inference here) it looks like the library fetching tool is well equipped to fetch the freshest branch from his repository directly. His responses are very minimal but it sounds like he's objecting to older versions of his library being bundled in and causing breakages on the client side - forking would potentially just make this problem worse from his point of view if his primary concern is the fact that users get out of date code - compared to the concern of code maintenance.
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.
IMO, it's worse than that: frenk does seem to understand the history of FOSS distribution. Most Linux distributions included packaged sources for the software. This is no different. They did not point back to the original repo, not to the source control repo. They had rmps or the equivalent.
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,
He strikes me as someone who has been burnt by the packaging issues that have been around in the ecosystem for years.
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.
Some people release something as FOSS but don't understand what that means. We had a developer we worked with at PortableApps.com release his software under a FOSS license. He requested we package it portably in our format and release it. His users and ours were happy.
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 agree. This is kind of bizarre behavior from someone who is such an important contributor to Home Assistant, a large scale open source platform. I can’t imagine most of the leaders in Home Assistant would share this attitude, but maybe I’m wrong.
Unfortunately, the founder of Home Assistant has acted similarly too. When NixOS maintainers raised concerns, he accused them of having "no intention to contribute anything positively." This was despite NixOS maintainers' best efforts to engage in a civil discussion.
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.
It seems like the reason is (paraphrasing) "because I can't meet the resulting burden of support."
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?
I guess I've always struggled with this, because this seems like an extremely easy problem to solve.
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.
> 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?
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).
I lost the blog post I learned this from, but one way to do it is whenever someone opens a PR on a project you don't want to maintain anymore, make them a maintainer!
That way, the project lives on with minimal disruption to its users.
>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?
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...
> 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?
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.
It's not about popularity. Distributions often ship outdated or modified code, link it against unsupported versions of dependencies, etc. When this causes problems users will contact or blame the author of the code, instead of the distribution which broke it.
Sometimes when a package gets very popular other people step up to help, or take over. Other times the maintainer has a mental breakdown or just disappears.
He doesn’t understand the letter of OSS either. Limiting who can distribute a project means it no longer meets the Open Source Definition and is therefore not OSS.
I think there’s some emotional nuance here. After a certain point he basically said all of his technical justification and the request does boil down to “because I said so and I’m the author.” The Nix maintainers explicitly do not want to respect the author’s wishes (which is fine) but that makes the whole thing turn adversarial because “okay we won’t include it” wasn’t even something the maintainers considered for even a second. It was pretty level headed discussion until it was clear that their only motivation was getting to yes or enough justification to ignore him.
> It was pretty level headed discussion until it was clear that their only motivation was getting to yes or enough justification to ignore him.
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.
The only solution Franck gave is to not re-package for any emotional reason he had. The Nix developers gave their reasons why they need to re-package. Franck just ignored everything and gave no reasons to justify his request.
The broader issue here, again, is that maintaining FOSS software seems to be becoming a shittier and shittier proposition.
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.
Just because you are legally allowed to do so doesn’t mean that you should. Hopefully you have a similar stance towards Amazon’s behavior in the OSS community.
It's not an issue of legally allowed. It's the very spirit of the community that allows for this. The FOSS community has worked very hard to create a system where permission isn't needed because it's already there, baked into the system. So while yes, some large corporations abuse this, I also don't consider Amazon to be part of the FOSS community, and I definitely consider NixOS to be a part of the FOSS community. To declare that you will go so far as changing the license to prohibit certain persons or projects from using your software is an affront to the FOSS community itself. If the whole FOSS community degraded into "It's free for everyone except you and you and you because I don't like you or maybe you're gonna make my life difficult" then we would have no FOSS at all.
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.
None of the alternatives were something like "rename, so it isn't attached to them any more". I understand their issues, at present they can push new releases via pip, with this many nix users could have very out of date packages.
If I understand you, they offered that very thing in https://github.com/NixOS/nixpkgs/pull/126326#issuecomment-86... and it first wasn't answered, and then was dismissed with "This was already answered. Please don't repack my source in this repository was my request. I don't see how your suggestion is changing that."
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.
This is a subdependency of a larger project (homeassistant) so doing so would involve nix maintaining an entirely separate fork of homeassistant, which is a completely unviable ask.
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.
It's being added as a dependency to home assistant, a popular package, so they are pretty much between a rock and a hard place. Ultimately, if the author of the code doesn't want it redistributed by distributions, I assume home assistant will have to remove it from upstream. It might be good for someone to raise the flag with home assistant since this is apparently becoming a point of contention with two different distros now.
What you're describing would be to comply with what are effectively shadow terms in an apparent open source license, which is not something that should be tolerated as it makes a farce of the whole purpose of licenses.
He understands it perfectly. That's why he asked nicely at first. Nixos just "request denied" him after rounds of requests and discussion. With that he's roiled up to change the license to exclude Nixos.
He just doesn't want the extra work to support another distro which would include an outdated version of his package.
I have no specific opinions on the author really, but:
> Seems like an author that doesn't understand the spirit of FOSS.
The author states he understands the licensing and the project's rights to use his software earlier in the thread. He was simply making a request.
> 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?
Again, he stated his reasons in the thread. He didn't want to have to potentially support their repackaged and/or old versions of his software. His software being OSS did not give up his right to make nuanced requests.
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.
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!
I’m no expert, but I’m fairly sure that Frenk’s license has to be compatible with home assistance’s license for it to be included. If home assistance has a normal OSS license, I doubt it can use a dependency with a very restrictive license. (Such as one with a list of what can use it!) In other words, I don’t think it’s possible form him to transitively make home assistant’s license more restrictive.
Home Assistant itself uses the Apache 2.0 license, which is pretty permissive. It doesn't impose much requirements on derivative works, so it can use a dependency with a restrictive license without problem.
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).
> Pinning every Python dependency instead of fetching HEAD is how you get local control and security!
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.
> they make sure the user get a specific version that is (hopefully) vetted and know as working properly
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.
Nixpkgs contributor here. One of the misunderstandings by frenck is how Nix operates[0], which is not via mutable site-packages folders but more accurately as an immutable graph structure. What this means is that to have home-assistant packaged properly, we need to also package its dependencies, which includes ambee.
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.
Isn't the argument that HA has this functionality, thus if it cannot download its plugins/manifests at runtime, then it can be considered not fully functional? (Even though Nix users likely consciously trade off that for reproducibility.)
As I see it, the author want his software to be "de facto" not open source while retaining the Open source label. And he tries to achieve that by appealing to the kindness of the people: "I'm the author, please do like I say...".
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.
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?
> Is it the official policy of the home-assistant project that their software should not be packaged by NixOS?
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.
In which case I think that's the story here - this isn't so much about frenck v.s. NixOS as it is about home-assistant v.s. repackaging.
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.
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.
> This is the absolute antithesis of the intent of open source.
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.
Are you sure that's NixOS? Perhaps the issue is that NixOS doesn't have an official spokesperson?
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.
The more I observe this situation the more I'm fascinated by the dynamic of his releasing an internal dependency to homekit as a "public library" leaning on the public infrastructure provided by python to distribute a dependency that he's actively hostile to anyone else using.
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].
I find it quite amusing that the package author refuses to act reasonably and states he wishes to spend no time on the project, whilst being pulled further into the project. If he simply willingly engaged with the project owners to resolve the situation he could avoided:
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.
This will be interesting to see how they will react.
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?
Plus Nix is a crazy deep rabbit hole. If you're at the point where you're trying to make something work with Nix, you'll know when the problem is upstream and when it isn't.
A very similar thing happened when the folks at flathub tried to package MultiMC. Unfortunately the author threatened to sue for trademark infringement and they backed down.
Huh, I'd been pretty happily using MultiMC for some time and even thought they were in the right of the Forge dispute. Might have to look for alternatives next time I get back into Minecraft.
Well, Home Assistant's handling of this is well-timed. I was just looking at the possibility of redoing my openHAB config in HA but this makes it really clear I don't want to go within a 150 mile radius of HA.
I've been using HA a lot in the past and written some components. But a while back they moved away from allowing pure YAML configurations and required some components to do setup via the GUI only. So it's not longer trivial to make a immutable deployment of HA since you will always need to manually make adjustments afterwards.
Funny that the author complains they have no time to support users, but they have time to waste that of other open source maintainers and users as if the wish to package their Open Source software deserved no respect.
> the author complains they have no time to support users
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.
I can understand the author not wanting to deal with extra noise. But they did try to accommodate them. Forking and changing the contact info is probably the best tactic. The author didn't like that, but is probably the best outcome.
Don't do open source (especially a very permissive licence) if you don't want others using your code as a dependency.
If the response to someone finding and using your work is the kind of over the top demand to "don't use the thing I just released under a permissive license" with multiple replies that amount to, "Don't use the thing in a way I don't like kthanxbai" how can you depend on it?
The project is written specifically for Home assistant by a core developer, it's not a small time developer who's project got accidentally included in a major project.
> If the response to someone finding and using your work
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.
It seems that the author has posted again on the github issue after it got unlocked [0].
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.
I think this is a cautionary tale about using social media while in a bad mood.
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.
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.
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.
Is there greater context here that helps explain what's going on? Reading the comments in the thread didn't clarify much for me as someone unfamiliar with NixOS, their apparently unique Python packaging scheme, and Home Assistant.
It sounds like Home Assistant by default pulls the (EDIT: Home assistant specified, not latest) version of the package from PyPI at runtime and loads it dynamically.
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.
Yeah I really wouldn't want to use anything that dynamically pulls a package from PyPI at runtime, because I don't trust this guy not to add a vulnerability to the code at a later point in time.
> It sounds like Home Assistant by default pulls the latest version of the package from PyPI at runtime and loads it dynamically.
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.
His project has zero issues created. It's a pretty small and simple library.
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.
I think the greater context is that the Home Assistant developers are somewhat hostile to people running, and especially packaging, their software outside of their own supported methods (which are Docker containers or their own full OS). It's somewhat understandable as it creates a support burden for them, but especially given the enthusiast nature of the community this doesn't seem like a smart decision. There's been some outrage in the community about the developers deprecating platforms before.
> I think the greater context is that the Home Assistant developers are somewhat hostile to people running, and especially packaging, their software outside of their own supported methods..
The person proposing the Nix package is a Home assistant developer afaik, so that would be weird.
He just doesn't want anything of his included in nixpkgs because he doesn't want to deal with anyone opening Github issues against his repos if there happen to be build / installation issues that are coming from some kind of failure in the nixpkgs install / build process.
Also they offered various options to appease the author including code forking and the author rejected them all. Basically the team exhausted all of their options to make this author happy but the author seem not to understand the reality of FOSS. This author shouldn't be in the FOSS if the author is going to roadblock every options despite his licensing explicitly allows including the codes.
I fail to see why the author could not add instructions to their project's issue tracker, something to the effect of
"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."
I often have a sinking feeling the free software world is going to fall apart because upstream developers don't know what the distro is even for (curation, consistency, etc.), and legacy distro downstream developers haven't kept up with any of the development rends in recent years (good or bad).
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.
> 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
Is home-assistant packaged in any traditional distro like Debian or Fedora? I didn't think so.
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.
This is an extremely odd request for something licensed as MIT.
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...
I've seen a similar situation when Ansible were resolving issues with Jinja2 but Ansible contributors simply helped the Jinja contributors to resolve the issue. It wasn't like all the burden was put on the jinja project.
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.
It still takes effort to sort support requests into those he wants to handle and those he doesn't. If he thinks that the manner in which is work is being used is going to bury him with requests, whether he takes them or not, it makes sense to try to avoid the situation altogether.
I don't think there's a way to actually do that with an open source project though.
I think he’s so focused on time management (from his about page), that he is catastrophizing about the future. He also clearly wants the fame from having a library in Home Automation, but doesn’t want to provide any support.
> 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 mean, yes, but then when the NixOS folks offer something like:
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.
But when suggested alternatives to resolve that issue, he simply ignores it and states “sorry, this is my wish” with no further clarification.
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)
Seems that he wants pypi and pip to be the exclusive distribution mechanisms for his project. He wants to avoid handling bugs that come from his project being packaged through other means.
He misunderstands how nixos works and suggests that Home Assistant will be able to install his package via pip on nixos.
> He wants to avoid handling bugs that come from his project being packaged through other means.
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.
I’m not sure why there are scare quotes around “his”, the code is the author’s property, it’s just they’ve granted a license for it to be used by anyone.
The scarequotes are certainly inappropriate unless it's CC0 licensed, but you do point out that he's explicitly granted a license "for it to be used by anyone". Which seems... of some relevance here.
Python ambee is a simple client library for a proprietary sass iot service.
I guess they want to control exactly how their users are using their service.
Yet the author is an admin on the HomeAssistant community forum, one of only 6. Presumably his other contributions to the project justify those privileges, and he did not shut down the passive-aggressive thread some nixOs folks started there, it was another admin (the founder of HomeAssistant).
This sucks for nixOs, but it looks like community incompatibility means they won’t be able to support HomeAssistant at all.
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 am not the author so I can only speculate. He's anticipating that they will be distributing an out-of-date package and it's simply another place that has to be synchronized. He's saying that there isn't actually a need to host it elsewhere as it can be installed via pip through pypy (his preferred host) which will have up-to-date code. He doesn't want to get bug reports for outdated code.
I don't have any experience of nix packaging, but I work on a couple of programs when Debian applied some broken patches while packaging, then "we" (upstream) get the bug reports. It's annoying as we don't have any way of fixing it, just have to tell users to uninstall the Debian version.
> 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.
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.)
This is the case with literally every piece of software packaged for linux, it seems that nix is just the first place to attempt to package this. The project looks to only be a week old anyhow.
The reason is the concern that users will confuse issues with the project with issues with how the project is distributed in Nixpkgs. He doesn't want to have to support nixpkgs.
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.
If you don't understand the authors frustration, read Daniel Stenberg blog about what kind of requests he gets about curl. It's insane and ridiculous, not everybody is capable of/wanting to deal with all kinds of shit and hostile users like Daniel.
That's entirely reasonable if it's happened/happening to you AND you have no means to stop it from continuing.
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.
You don't understand the issue then. The author don't want to deal with all kinds of requests unrelated to his own package. NixOS is an operating system, totally understandable he doesn't want to deal with OS issues.
I agree with the point that this is a FOSS, but as author I would be terrified if some downstream users started some mobbing me [1] due to upstream changes as we saw in the FastAPI Pydantic meltdown [2].
that frenck guy actually just comes off as an a-hole. especially with their passive aggressive responses. why are so many software people like this? maybe he should change his license
regardless of the specifics here, stuff like this is liable to pop up a lot in the coming several years while NixOS is gaining more popularity but casual (as in "not willing to put in the effort of supporting off-beat distributions") OSS authors can still reasonably ignore it. the amount of patching that Nixpkgs packagers have to do sometimes is pretty extreme
Generally if the patch is not-specific to nixpkgs, we ask the contributor to upstream the patch, and then we have a `fetchpatch` utility which makes it easy to pull from an upstream source.
I searched their forums and the issues on their core repo on Github, and cumulatively there are 20 issues that contain NixOS, of which some are created by NixOS maintainers themselves.
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.
puh, what is the author an unfriendly dude. I really wonder how his package became so important for home assistant. I hope home assistent sees this and begins to develop a replacement for all of authors stuff.
I would suggest the author of the package use, say, this
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.
Did you catch me before the edit? I remembered right after I clicked "submit" and immediately removed it, ha! You must have seen it right at the right moment.
IIRC he had xscreensaver start spitting out error messages when it was old because Debian generally keeps package versions fixed per release, meaning if someone had a 2 year old but still updated version of Debian it would ship with a 2 year old version of xscreensaver. Jwz was tired of getting error reports for bugs fixed years ago because someone installed a the default "current" version on their Debian based OS.
if you follow an HN link to that site it detects the referrer and shows you something you don't want to see, so it's more than just because jwz doesn't want you to, he actively punishes people who unknowingly click a link that violates his preference.
Sure, it's not like, a law of physics or something, but
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 however is hired by the commercial entity behind Home assistant. And I'm not against making money using open source software. But when you build your company and income on an open source license and the work of others you should respect that license both ways.
This kind of confirms my suspicion that what's really happening here is a commerical project is piggybacking on open source and goodwill to distribute components of their product using community infrastructure.
I don’t really understand the details here. Seems like they disagree about the ease of avoiding it being repacked. Perhaps a good compromise would be for them to collaborate on a solution they’re both happy with. As it is, this conversation looks like: “can you not pls” “too difficult” “no it isn’t” “yes it is” ad infinitum.
He's not interested in that. The NixOS folks asked:
"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.
> a good compromise would be for them to collaborate
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.
This is an interesting example of how social concerns interact with technical concerns in the real world.
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.
I don't see anything wrong here. I think licensing terms should heavily favor authors, because if you're writing FOSS, you're already giving away intellectual property for free.
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.
Contrary to this, I think we do see FOSS authors post every now and then that when their packages explode in popularity, they can't provide meaningful support, and end up closing down their FOSS project instead.
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.
Really seems like you need to respect the author’s wishes here, but the tension between author and community can get complicated with FOSS. Open source is a contract with your audience that the code can be used freely. Authors gain their audience because of that contract, so there’s some obligation for them to respect that. That said, respect flows both ways, and I’ve had FOSS code get repackaged to steal credit which feels like just as much of a violation. (That’s not the issue here but it touches on the same challenge.)
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.
I don’t think its as simple as respect the authors wishes. You are participating in a large OS ecosystem as soon as you become a dependency of another project. Most people don’t care about the package in this case and just want the package that is using it.
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.
> You are participating in a large OS ecosystem as soon as you become a dependency of another project.
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.
Dependencies make this such an interesting challenge. What do you do when a library that’s upstream of 1000 packages with 1000 different authors… goes “rogue?” The friction of forking increases with each downstream you have to coordinate
> (That’s not the issue here but it touches on the same challenge.)
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.
> so there’s some obligation for them to respect that.
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.
Some of the NixOS people tried asking (in, admittedly, a somewhat escalatory and inflammatory way) on the HA forums: the HA founder closed (and hid) the thread, so I don't think they (or Nabu Casa) really care if their deps are OSS or not.
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.
The author’s contractual wishes are specified there. It’s fine for an author to have additional, non-contractual wishes. (Legally, it’s equally fine for someone to follow or not follow those additional wishes.)
I can’t comment on the legal issues but AFAIK you can change licenses with future releases, not retroactively, so while you might be right, software requires support and losing future releases is often close to losing the software entirely.
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 I don't disagree with you, the problem the author is saying is that end users don't realize that, and contact the author directly even when they are using an out-of-date package from a distribution, and the author doesn't have an immediate way to determine whether the problem is with their code at the version they released, or an older packaged version.
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.
As the author says, that can be fixed with a relicensing.
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.
Revoked in the way of changing the license for future releases, he can't retroactively remove the MIT license from previous releases. Revocation isn't the ideal way to frame this.
Both the comments on GitHub, and this thread are an absolutely awful look for open source, and it's feedback like this that drives excellent creators to stop creating open source projects, leaving the entire FOSS ecosystem left with half-assed solutions or hand-off maintainers who can do nothing more than nominal bugfixes once an original author leaves because of harassment.
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.
> You're entitled to nothing when authors write FOSS. They provide it as-is. Take it or leave it.
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?
> 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 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.
The way an author expresses and codifies their "wishes" over redistribution is through a license. If the current license does not accurately reflect the author's "wishes", it should be amended. Otherwise it is bogus to declare that this software is under the MIT license.
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.
This looks like an attempt to ridicule the guy. He’s made a simple request and he doesn’t have to explain himself. The other parties can comply or not, they may ask questions or not, but surely publishing this non-story to HN and have people interpret his actions, fantasize about his understanding of OSS, their social skills etc, and eventually deride him is a bit hostile and immature.
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.
Like his request, the submitter can simply submit this to HN for us to simply look at it and, like the author, we can simply share our thoughts, and everyone is free to think and feel whatever they do. We are human too, social animals and all that.
Are HN readers/commenters known for harassment? How alone are folks supposed to leave him?
I have no answer for your last question, and I don't think there's a well defined line. Maybe the line is that we shouldn't share comment drama. The reality is that these kinds of discussions can lead to bullying, and that's what's not so simple about just discussing issues like this.
Seems like an author that doesn't understand the spirit of FOSS. The nixos team was clearly allowed to use it and include it when asking for some technical merits as to why, and even offering many alternative options to appease the author the author seemed to just childishly stamp their feet and say, "because I said so". Eventually the author took the position of "taking my ball and going home". 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?
When they offered to fork it completely to avoid the issue and he rejected that, it really just looks bad.
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.
From what I can see in the thread (and I'm not very familiar with the tech so I'm working off of inference here) it looks like the library fetching tool is well equipped to fetch the freshest branch from his repository directly. His responses are very minimal but it sounds like he's objecting to older versions of his library being bundled in and causing breakages on the client side - forking would potentially just make this problem worse from his point of view if his primary concern is the fact that users get out of date code - compared to the concern of code maintenance.
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.
8 replies →
IMO, it's worse than that: frenk does seem to understand the history of FOSS distribution. Most Linux distributions included packaged sources for the software. This is no different. They did not point back to the original repo, not to the source control repo. They had rmps or the equivalent.
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,
He strikes me as someone who has been burnt by the packaging issues that have been around in the ecosystem for years.
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.
3 replies →
Some people release something as FOSS but don't understand what that means. We had a developer we worked with at PortableApps.com release his software under a FOSS license. He requested we package it portably in our format and release it. His users and ours were happy.
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.
Fascinating story. I think it's hard to anticipate consequences of actions, for some harder than others.
Yeah, they went above and beyond trying to mollify the original author, in my opinion.
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."
I agree. This is kind of bizarre behavior from someone who is such an important contributor to Home Assistant, a large scale open source platform. I can’t imagine most of the leaders in Home Assistant would share this attitude, but maybe I’m wrong.
Unfortunately, the founder of Home Assistant has acted similarly too. When NixOS maintainers raised concerns, he accused them of having "no intention to contribute anything positively." This was despite NixOS maintainers' best efforts to engage in a civil discussion.
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...
4 replies →
> I can’t imagine most of the leaders in Home Assistant would share this attitude, but maybe I’m wrong.
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...
1 reply →
It seems like the reason is (paraphrasing) "because I can't meet the resulting burden of support."
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?
I guess I've always struggled with this, because this seems like an extremely easy problem to solve.
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.
> 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?
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).
It's just a small dependency for Home Assistant. I don't think the author will receive a lot of reports.
https://github.com/frenck/python-ambee
The project has zero issues right now. I think that is not the real reason.
1 reply →
I lost the blog post I learned this from, but one way to do it is whenever someone opens a PR on a project you don't want to maintain anymore, make them a maintainer!
That way, the project lives on with minimal disruption to its users.
1 reply →
>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?
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...
At least he’s up front honest. Most people just get shitty with you when you volunteer PRs for their project or ignore you I find.
> 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?
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.
I've observed basically 2 sustainable patterns here.
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.
It's not about popularity. Distributions often ship outdated or modified code, link it against unsupported versions of dependencies, etc. When this causes problems users will contact or blame the author of the code, instead of the distribution which broke it.
> It seems like the reason is (paraphrasing) "because I can't meet the resulting burden of support."
Exactly. He made that point a few times, but the replies don't always seem to address the issue he raises.
7 replies →
Sometimes when a package gets very popular other people step up to help, or take over. Other times the maintainer has a mental breakdown or just disappears.
2 replies →
He doesn’t understand the letter of OSS either. Limiting who can distribute a project means it no longer meets the Open Source Definition and is therefore not OSS.
No, he acknowledges explicitly early in the thread that the license allows the code to be redistributed with or without his approval.
5 replies →
?
I think there’s some emotional nuance here. After a certain point he basically said all of his technical justification and the request does boil down to “because I said so and I’m the author.” The Nix maintainers explicitly do not want to respect the author’s wishes (which is fine) but that makes the whole thing turn adversarial because “okay we won’t include it” wasn’t even something the maintainers considered for even a second. It was pretty level headed discussion until it was clear that their only motivation was getting to yes or enough justification to ignore him.
> It was pretty level headed discussion until it was clear that their only motivation was getting to yes or enough justification to ignore him.
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.
The only solution Franck gave is to not re-package for any emotional reason he had. The Nix developers gave their reasons why they need to re-package. Franck just ignored everything and gave no reasons to justify his request.
they have good reason to not not include it.
2 replies →
The broader issue here, again, is that maintaining FOSS software seems to be becoming a shittier and shittier proposition.
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.
Just because you are legally allowed to do so doesn’t mean that you should. Hopefully you have a similar stance towards Amazon’s behavior in the OSS community.
It's not an issue of legally allowed. It's the very spirit of the community that allows for this. The FOSS community has worked very hard to create a system where permission isn't needed because it's already there, baked into the system. So while yes, some large corporations abuse this, I also don't consider Amazon to be part of the FOSS community, and I definitely consider NixOS to be a part of the FOSS community. To declare that you will go so far as changing the license to prohibit certain persons or projects from using your software is an affront to the FOSS community itself. If the whole FOSS community degraded into "It's free for everyone except you and you and you because I don't like you or maybe you're gonna make my life difficult" then we would have no FOSS at all.
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.
If that's the case then it's no longer FOSS.
Except the part you are including a company to "prove" your point when NixOS is a FOSS project and they give their part back to the community.
Reading through all the comments that was my take as well.
None of the alternatives were something like "rename, so it isn't attached to them any more". I understand their issues, at present they can push new releases via pip, with this many nix users could have very out of date packages.
If I understand you, they offered that very thing in https://github.com/NixOS/nixpkgs/pull/126326#issuecomment-86... and it first wasn't answered, and then was dismissed with "This was already answered. Please don't repack my source in this repository was my request. I don't see how your suggestion is changing that."
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.
1 reply →
Legally yes they are allowed and can ignore the author as they like.
They can also act as a bigger person and say "Sure, we understand, respect your wish and will find an alternative."
This is a subdependency of a larger project (homeassistant) so doing so would involve nix maintaining an entirely separate fork of homeassistant, which is a completely unviable ask.
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.
2 replies →
It's being added as a dependency to home assistant, a popular package, so they are pretty much between a rock and a hard place. Ultimately, if the author of the code doesn't want it redistributed by distributions, I assume home assistant will have to remove it from upstream. It might be good for someone to raise the flag with home assistant since this is apparently becoming a point of contention with two different distros now.
2 replies →
What you're describing would be to comply with what are effectively shadow terms in an apparent open source license, which is not something that should be tolerated as it makes a farce of the whole purpose of licenses.
He understands it perfectly. That's why he asked nicely at first. Nixos just "request denied" him after rounds of requests and discussion. With that he's roiled up to change the license to exclude Nixos.
He just doesn't want the extra work to support another distro which would include an outdated version of his package.
It's not because he asks nicely that people have to agree or accept. This is literally the nice guy meme.
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.
1 reply →
I have no specific opinions on the author really, but:
The author states he understands the licensing and the project's rights to use his software earlier in the thread. He was simply making a request.
Again, he stated his reasons in the thread. He didn't want to have to potentially support their repackaged and/or old versions of his software. His software being OSS did not give up his right to make nuanced requests.
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.
What's worse is this frenk guy seems to be the reason his packages are being added to nixpkgs
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!
I’m no expert, but I’m fairly sure that Frenk’s license has to be compatible with home assistance’s license for it to be included. If home assistance has a normal OSS license, I doubt it can use a dependency with a very restrictive license. (Such as one with a list of what can use it!) In other words, I don’t think it’s possible form him to transitively make home assistant’s license more restrictive.
Home Assistant itself uses the Apache 2.0 license, which is pretty permissive. It doesn't impose much requirements on derivative works, so it can use a dependency with a restrictive license without problem.
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).
> Pinning every Python dependency instead of fetching HEAD is how you get local control and security!
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.
> they make sure the user get a specific version that is (hopefully) vetted and know as working properly
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.
2 replies →
Nixpkgs contributor here. One of the misunderstandings by frenck is how Nix operates[0], which is not via mutable site-packages folders but more accurately as an immutable graph structure. What this means is that to have home-assistant packaged properly, we need to also package its dependencies, which includes ambee.
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...
Isn't the argument that HA has this functionality, thus if it cannot download its plugins/manifests at runtime, then it can be considered not fully functional? (Even though Nix users likely consciously trade off that for reproducibility.)
> Even though Nix users likely consciously trade off that for reproducibility.
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.
As I see it, the author want his software to be "de facto" not open source while retaining the Open source label. And he tries to achieve that by appealing to the kindness of the people: "I'm the author, please do like I say...".
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.
It looks like the bigger question here is this:
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?
> Is it the official policy of the home-assistant project that their software should not be packaged by NixOS?
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.
In which case I think that's the story here - this isn't so much about frenck v.s. NixOS as it is about home-assistant v.s. repackaging.
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.
Why is it that projects grant rights to users and then are hostile to us using those rights?
3 replies →
That is what is seems like:
https://community.home-assistant.io/t/consider-to-avoid-addi...
For context, balloob is the founder of Home Assistant
Here's the thread NixOS posted to the Home Assistant forums, "Consider to avoid adding library dependencies from frenck."
https://community.home-assistant.io/t/consider-to-avoid-addi...
Wow, that thread is wild.
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.
> This is the absolute antithesis of the intent of open source.
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.
6 replies →
> What an awful community response.
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.
3 replies →
Are you sure that's NixOS? Perhaps the issue is that NixOS doesn't have an official spokesperson?
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).
Which was closed by the moderator..I tend to side with the author here.
Hey Hacker News,
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.
The more I observe this situation the more I'm fascinated by the dynamic of his releasing an internal dependency to homekit as a "public library" leaning on the public infrastructure provided by python to distribute a dependency that he's actively hostile to anyone else using.
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] - https://pypi.org/policy/terms-of-use/
I find it quite amusing that the package author refuses to act reasonably and states he wishes to spend no time on the project, whilst being pulled further into the project. If he simply willingly engaged with the project owners to resolve the situation he could avoided:
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.
This attitude has done a lot of reputational damage to Home Assistant which is unfortunate.
I am considering moving over to alternative already. I don't want to be dependent on a project that actively dissuades people packaging it up.
Looks like frenck plans to file issues against Fedora too:
> 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...
This will be interesting to see how they will react.
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
It's interesting since from https://github.com/sponsors/frenck#sponsors he pitches:
> 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?
Seems like he understands the “free” in FOSS to mean free as in beer, not as in freedom.
Yeah the fact that the repo's readme starts with links to money begging links just makes this weirder.
Really looks to me that Mr. Nijhof doesnt quiet get what open source is about.
Yeah, while I get the maintainer's point, the conversation rapidly devolved into giving the Nix maintainers a hard time.
I mean, c'mon, Nix is a tiny niche. It's not like the support burden will be colossal.
Plus Nix is a crazy deep rabbit hole. If you're at the point where you're trying to make something work with Nix, you'll know when the problem is upstream and when it isn't.
A very similar thing happened when the folks at flathub tried to package MultiMC. Unfortunately the author threatened to sue for trademark infringement and they backed down.
https://github.com/flathub/flathub/pull/1978#issuecomment-74...
> I'd liken this to rape, actually.
I'm really astonished with this comparison.
Huh, I'd been pretty happily using MultiMC for some time and even thought they were in the right of the Forge dispute. Might have to look for alternatives next time I get back into Minecraft.
Well, Home Assistant's handling of this is well-timed. I was just looking at the possibility of redoing my openHAB config in HA but this makes it really clear I don't want to go within a 150 mile radius of HA.
I've been using HA a lot in the past and written some components. But a while back they moved away from allowing pure YAML configurations and required some components to do setup via the GUI only. So it's not longer trivial to make a immutable deployment of HA since you will always need to manually make adjustments afterwards.
Hah! I guess they don't like the Nix approach on multiple levels :D.
I mean any package team who harasses people exercising rights they've explicitly granted is a bit concerning.
The package author has gone on to open issues for their other Python packages too - https://github.com/NixOS/nixpkgs/issues/created_by/frenck - currently five open (and locked) issues.
"Upset open source developer spams other open source repository"?
Borders on harassment
"Slightly assholic at first sight" kind of tells you all you need to know about how this developer will go about solving community problems.
^ this is actually in the author's github profile. You can't make this shit up.
https://github.com/frenck
> Slightly assholic at first sight Actually a nice guy that just likes to get stuff done. @home-assistant Herder @hassio-addons Creator
Funny that the author complains they have no time to support users, but they have time to waste that of other open source maintainers and users as if the wish to package their Open Source software deserved no respect.
> the author complains they have no time to support users
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.
I can understand the author not wanting to deal with extra noise. But they did try to accommodate them. Forking and changing the contact info is probably the best tactic. The author didn't like that, but is probably the best outcome.
Don't do open source (especially a very permissive licence) if you don't want others using your code as a dependency.
Am I missing something, or is the project in question literally just one week old?
https://pypi.org/project/ambee/#history https://github.com/frenck/python-ambee/commits/main
If the response to someone finding and using your work is the kind of over the top demand to "don't use the thing I just released under a permissive license" with multiple replies that amount to, "Don't use the thing in a way I don't like kthanxbai" how can you depend on it?
The project is written specifically for Home assistant by a core developer, it's not a small time developer who's project got accidentally included in a major project.
1 reply →
> If the response to someone finding and using your work
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.
1 reply →
It was just added to Home Assistant, which is why it was being added to `nixpkgs` now.
It seems that the author has posted again on the github issue after it got unlocked [0].
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...
His About page https://frenck.dev/about/ looks a bit weird after I read that GitHub thread
> I like to give back my knowledge and time to the open source community.
I think this is a cautionary tale about using social media while in a bad mood.
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.
He also opened issues about four of his packages being used in the project. Doesn’t seem like a spur of the moment thing.
I guess it's not his first rodeo, he simply doesn't want to support whatever version is packaged by NixOS.
However the MIT license dictates what can or cannot be done. No need for further drama.
How so?
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.
Except literally the Nix folks were making suggestions to ensure there would be no expectations go support.
Related context:
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.
Is there greater context here that helps explain what's going on? Reading the comments in the thread didn't clarify much for me as someone unfamiliar with NixOS, their apparently unique Python packaging scheme, and Home Assistant.
It sounds like Home Assistant by default pulls the (EDIT: Home assistant specified, not latest) version of the package from PyPI at runtime and loads it dynamically.
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.
Yeah I really wouldn't want to use anything that dynamically pulls a package from PyPI at runtime, because I don't trust this guy not to add a vulnerability to the code at a later point in time.
6 replies →
> It sounds like Home Assistant by default pulls the latest version of the package from PyPI at runtime and loads it dynamically.
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...
His project has zero issues created. It's a pretty small and simple library.
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.
This is not true. Home-assistant does not pull the latest version of packages (for integrations) from pypi. They are tracked in manifest files: https://github.com/home-assistant/core/blob/ae28e4934f6d1cdb...
This sounds like NixOS is not ready to handle this scenario and they are bulldozing the issue to get it included.
2 replies →
I think the greater context is that the Home Assistant developers are somewhat hostile to people running, and especially packaging, their software outside of their own supported methods (which are Docker containers or their own full OS). It's somewhat understandable as it creates a support burden for them, but especially given the enthusiast nature of the community this doesn't seem like a smart decision. There's been some outrage in the community about the developers deprecating platforms before.
> I think the greater context is that the Home Assistant developers are somewhat hostile to people running, and especially packaging, their software outside of their own supported methods..
The person proposing the Nix package is a Home assistant developer afaik, so that would be weird.
2 replies →
He just doesn't want anything of his included in nixpkgs because he doesn't want to deal with anyone opening Github issues against his repos if there happen to be build / installation issues that are coming from some kind of failure in the nixpkgs install / build process.
That's speculative on his part (noone has opened any issues with him, neither coming from nixos nor from any other repackaging).
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.
4 replies →
Also they offered various options to appease the author including code forking and the author rejected them all. Basically the team exhausted all of their options to make this author happy but the author seem not to understand the reality of FOSS. This author shouldn't be in the FOSS if the author is going to roadblock every options despite his licensing explicitly allows including the codes.
1 reply →
I fail to see why the author could not add instructions to their project's issue tracker, something to the effect of
"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."
A lot of people don't RTFM.
I often have a sinking feeling the free software world is going to fall apart because upstream developers don't know what the distro is even for (curation, consistency, etc.), and legacy distro downstream developers haven't kept up with any of the development rends in recent years (good or bad).
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.
> 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
Is home-assistant packaged in any traditional distro like Debian or Fedora? I didn't think so.
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.
2 replies →
The dev deserved to be treated kindly, by default.
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.
This is an extremely odd request for something licensed as MIT.
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...
Totally worth the effort to re-implement/find an alternative when the code in question is so minimal. No need to deal with this guy.
I've seen a similar situation when Ansible were resolving issues with Jinja2 but Ansible contributors simply helped the Jinja contributors to resolve the issue. It wasn't like all the burden was put on the jinja project.
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.
It still takes effort to sort support requests into those he wants to handle and those he doesn't. If he thinks that the manner in which is work is being used is going to bury him with requests, whether he takes them or not, it makes sense to try to avoid the situation altogether.
I don't think there's a way to actually do that with an open source project though.
I think he’s so focused on time management (from his about page), that he is catastrophizing about the future. He also clearly wants the fame from having a library in Home Automation, but doesn’t want to provide any support.
3 replies →
You could put a disclaimer like people on the issue suggested. Nix users are pretty advanced anyway so I doubt he'd get that many useless bug reports.
Can someone elucidate why he is so against "his" code being used in this project?
He says early in the thread:
> 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 mean, yes, but then when the NixOS folks offer something like:
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.
2 replies →
But when suggested alternatives to resolve that issue, he simply ignores it and states “sorry, this is my wish” with no further clarification.
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)
That's an extremely valid concern, but one that seems easily addressed via an FAQ.
"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."
So ye olde "I don't like distros packaging my FOSS project because they won't do it exactly the way I want."
Seems that he wants pypi and pip to be the exclusive distribution mechanisms for his project. He wants to avoid handling bugs that come from his project being packaged through other means.
He misunderstands how nixos works and suggests that Home Assistant will be able to install his package via pip on nixos.
> He wants to avoid handling bugs that come from his project being packaged through other means.
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.
I’m not sure why there are scare quotes around “his”, the code is the author’s property, it’s just they’ve granted a license for it to be used by anyone.
The scarequotes are certainly inappropriate unless it's CC0 licensed, but you do point out that he's explicitly granted a license "for it to be used by anyone". Which seems... of some relevance here.
Python ambee is a simple client library for a proprietary sass iot service. I guess they want to control exactly how their users are using their service.
Yet the author is an admin on the HomeAssistant community forum, one of only 6. Presumably his other contributions to the project justify those privileges, and he did not shut down the passive-aggressive thread some nixOs folks started there, it was another admin (the founder of HomeAssistant).
This sucks for nixOs, but it looks like community incompatibility means they won’t be able to support HomeAssistant at all.
2 replies →
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.
https://github.com/NixOS/nixpkgs/pull/126326#issuecomment-86...
I am not the author so I can only speculate. He's anticipating that they will be distributing an out-of-date package and it's simply another place that has to be synchronized. He's saying that there isn't actually a need to host it elsewhere as it can be installed via pip through pypy (his preferred host) which will have up-to-date code. He doesn't want to get bug reports for outdated code.
This is incredibly legitimate reason. Could these repacking be replaced with some type of just proxy/clone that is still the original source?
3 replies →
I don't have any experience of nix packaging, but I work on a couple of programs when Debian applied some broken patches while packaging, then "we" (upstream) get the bug reports. It's annoying as we don't have any way of fixing it, just have to tell users to uninstall the Debian version.
I mean this very famously happened with OpenSSL - Debian started producing the same keypairs for everyone!
Apparently not, since the author couldn't/didn't want to either.
> 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.
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.)
This is the case with literally every piece of software packaged for linux, it seems that nix is just the first place to attempt to package this. The project looks to only be a week old anyhow.
The package author lays out the reasons in his comments
The reason is the concern that users will confuse issues with the project with issues with how the project is distributed in Nixpkgs. He doesn't want to have to support nixpkgs.
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.
If you don't understand the authors frustration, read Daniel Stenberg blog about what kind of requests he gets about curl. It's insane and ridiculous, not everybody is capable of/wanting to deal with all kinds of shit and hostile users like Daniel.
I understand the worry.
But he hasn't had to face any of that, and a couple different methods to avoid that happening were suggested and rejected offhand.
That's entirely reasonable if it's happened/happening to you AND you have no means to stop it from continuing.
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.
So...don't publish software? That's part of the game, no?
No! You are not obligated to receive support for software just because it was written by someone else.
4 replies →
Maybe it comes with it, but I think you have no obligation to deal with it if you don't want to.
That's not related to this particular issue though.
You don't understand the issue then. The author don't want to deal with all kinds of requests unrelated to his own package. NixOS is an operating system, totally understandable he doesn't want to deal with OS issues.
2 replies →
Do you have a link? I'd love to read this.
For example NASA https://daniel.haxx.se/blog/2020/12/17/curl-supports-nasa/
I think he also posts some of the funny ones on Twitter
That's exactly what came to my mind too. I think the sqlite folks have similar struggles.
except he doesn't have to do anything he doesn't want to. ignore/delete. Problem solved.
God, tiny piece of code. Rewriting would take less time than arguing.
Or just fork it. Obtuse developers getting their projects forked out of their control is a tale as old as FOSS
I agree with the point that this is a FOSS, but as author I would be terrified if some downstream users started some mobbing me [1] due to upstream changes as we saw in the FastAPI Pydantic meltdown [2].
[1] - https://twitter.com/ChristianHeimes/status/13828152605586554... [2] - https://github.com/samuelcolvin/pydantic/issues/2678#issueco...
that frenck guy actually just comes off as an a-hole. especially with their passive aggressive responses. why are so many software people like this? maybe he should change his license
regardless of the specifics here, stuff like this is liable to pop up a lot in the coming several years while NixOS is gaining more popularity but casual (as in "not willing to put in the effort of supporting off-beat distributions") OSS authors can still reasonably ignore it. the amount of patching that Nixpkgs packagers have to do sometimes is pretty extreme
Nothing wrong with patching
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.
Generally if the patch is not-specific to nixpkgs, we ask the contributor to upstream the patch, and then we have a `fetchpatch` utility which makes it easy to pull from an upstream source.
I searched their forums and the issues on their core repo on Github, and cumulatively there are 20 issues that contain NixOS, of which some are created by NixOS maintainers themselves.
I was interested and also searched, here are the results:
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.
French stated he doesn't want to support broken distributions of ambee, like the version in the PR.
Reminds me of this story:
http://wiringpi.com/wiringpi-deprecated/
He claims it's broken without any specifics.
puh, what is the author an unfriendly dude. I really wonder how his package became so important for home assistant. I hope home assistent sees this and begins to develop a replacement for all of authors stuff.
I would suggest the author of the package use, say, this
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 am reminded of jwz, debian, and xscreensaver (Not linking to jwz's blog from HN because... he doesn't want it to be.)
For anyone else interested: http://www.dereferer.org/?https%3A%2F%2Fwww%2Ejwz%2Eorg%2Fbl... (dereferer because jwz is hostile in case your browser sends referer header)
That cracks me up every time
You might want to check what is on the other end of that link when the Referer is HN.
Did you catch me before the edit? I remembered right after I clicked "submit" and immediately removed it, ha! You must have seen it right at the right moment.
What's the story here?
IIRC he had xscreensaver start spitting out error messages when it was old because Debian generally keeps package versions fixed per release, meaning if someone had a 2 year old but still updated version of Debian it would ship with a 2 year old version of xscreensaver. Jwz was tired of getting error reports for bugs fixed years ago because someone installed a the default "current" version on their Debian based OS.
If you link to jwz from HN, his server notices the referer header and serves an image that mocks the HN community
1 reply →
> Not linking to jwz's blog from HN because... he doesn't want it to be
I don't think ... that's how the internet works?
(edit: I mean the "because... he doesn't want it to be" part)
Follow the link and enjoy
https://www.jwz.org/blog/2021/06/to-be-clear-the-whale-did-n...
edit: maybe jwz took the image down?
1 reply →
if you follow an HN link to that site it detects the referrer and shows you something you don't want to see, so it's more than just because jwz doesn't want you to, he actively punishes people who unknowingly click a link that violates his preference.
1 reply →
Sure, it's not like, a law of physics or something, but
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.
It's the exact same issue.
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.
NixOS community offered him multiple alternatives, but he flst out rejected everything.
what a complete moron, acting like a little spoiled punk , they offered to fork it completely to avoid the issue and he rejected still.
Anyone who claims to care about the mental health of open source devs should be on the author's side here
The author however is hired by the commercial entity behind Home assistant. And I'm not against making money using open source software. But when you build your company and income on an open source license and the work of others you should respect that license both ways.
This kind of confirms my suspicion that what's really happening here is a commerical project is piggybacking on open source and goodwill to distribute components of their product using community infrastructure.
I don’t really understand the details here. Seems like they disagree about the ease of avoiding it being repacked. Perhaps a good compromise would be for them to collaborate on a solution they’re both happy with. As it is, this conversation looks like: “can you not pls” “too difficult” “no it isn’t” “yes it is” ad infinitum.
He's not interested in that. The NixOS folks asked:
"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."
> a good compromise would be for them to collaborate
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.
This is an interesting example of how social concerns interact with technical concerns in the real world.
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.
I don't see anything wrong here. I think licensing terms should heavily favor authors, because if you're writing FOSS, you're already giving away intellectual property for free.
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.
Contrary to this, I think we do see FOSS authors post every now and then that when their packages explode in popularity, they can't provide meaningful support, and end up closing down their FOSS project instead.
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.
Really seems like you need to respect the author’s wishes here, but the tension between author and community can get complicated with FOSS. Open source is a contract with your audience that the code can be used freely. Authors gain their audience because of that contract, so there’s some obligation for them to respect that. That said, respect flows both ways, and I’ve had FOSS code get repackaged to steal credit which feels like just as much of a violation. (That’s not the issue here but it touches on the same challenge.)
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.
I don’t think its as simple as respect the authors wishes. You are participating in a large OS ecosystem as soon as you become a dependency of another project. Most people don’t care about the package in this case and just want the package that is using it.
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.
> You are participating in a large OS ecosystem as soon as you become a dependency of another project.
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.
2 replies →
Dependencies make this such an interesting challenge. What do you do when a library that’s upstream of 1000 packages with 1000 different authors… goes “rogue?” The friction of forking increases with each downstream you have to coordinate
> (That’s not the issue here but it touches on the same challenge.)
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.
[1] https://github.com/frenck/python-ambee/issues
The fact that it's a brand new project probably has more to do with the lack of issues.
> so there’s some obligation for them to respect that.
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.
I wonder if the other Home Assistant (https://github.com/home-assistant) contributors know that their dependencies are not open source?
Some of the NixOS people tried asking (in, admittedly, a somewhat escalatory and inflammatory way) on the HA forums: the HA founder closed (and hid) the thread, so I don't think they (or Nabu Casa) really care if their deps are OSS or not.
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.
The author's wishes are formally and legally specified in the copyright license to the code he wrote, which is MIT and allows redistribution.
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.
The author’s contractual wishes are specified there. It’s fine for an author to have additional, non-contractual wishes. (Legally, it’s equally fine for someone to follow or not follow those additional wishes.)
2 replies →
I can’t comment on the legal issues but AFAIK you can change licenses with future releases, not retroactively, so while you might be right, software requires support and losing future releases is often close to losing the software entirely.
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 I don't disagree with you, the problem the author is saying is that end users don't realize that, and contact the author directly even when they are using an out-of-date package from a distribution, and the author doesn't have an immediate way to determine whether the problem is with their code at the version they released, or an older packaged version.
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.
1 reply →
One of the comments:
"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.
8 replies →
This is why we can’t have nice things.
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.
7 replies →
As the author says, that can be fixed with a relicensing.
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.
3 replies →
> Open source is a contract with your audience that the code can be used freely.
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.
The license can only be revoked ex nunc presumably?
Do you have a reference or, more preferably, casserole to share on this point?
2 replies →
Revoked in the way of changing the license for future releases, he can't retroactively remove the MIT license from previous releases. Revocation isn't the ideal way to frame this.
1 reply →
I shouldn’t have used the term “contract” there because I was thinking more about interpersonal obligation than legal obligation.
2 replies →
Do you have case law for that?
Both the comments on GitHub, and this thread are an absolutely awful look for open source, and it's feedback like this that drives excellent creators to stop creating open source projects, leaving the entire FOSS ecosystem left with half-assed solutions or hand-off maintainers who can do nothing more than nominal bugfixes once an original author leaves because of harassment.
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.
> You're entitled to nothing when authors write FOSS. They provide it as-is. Take it or leave it.
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?
> 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 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.
source: https://github.com/home-assistant/core/pull/51645
Does that change what you're entitled to? No.
The way an author expresses and codifies their "wishes" over redistribution is through a license. If the current license does not accurately reflect the author's "wishes", it should be amended. Otherwise it is bogus to declare that this software is under the MIT license.
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.
The authors intent seems to be "don't use rights i have explicitly granted you and which you explicitly have from pypi"
Which is something of a bait and switch for a MIT licenced library
This looks like an attempt to ridicule the guy. He’s made a simple request and he doesn’t have to explain himself. The other parties can comply or not, they may ask questions or not, but surely publishing this non-story to HN and have people interpret his actions, fantasize about his understanding of OSS, their social skills etc, and eventually deride him is a bit hostile and immature.
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.
Like his request, the submitter can simply submit this to HN for us to simply look at it and, like the author, we can simply share our thoughts, and everyone is free to think and feel whatever they do. We are human too, social animals and all that.
Are HN readers/commenters known for harassment? How alone are folks supposed to leave him?
I have no answer for your last question, and I don't think there's a well defined line. Maybe the line is that we shouldn't share comment drama. The reality is that these kinds of discussions can lead to bullying, and that's what's not so simple about just discussing issues like this.
You can be free and not deride anyone, both at the same time
I agree that situations like this are scary, because they can lead to mob mentality. I wonder why you're downvoted for this.