Comment by sneak
5 years ago
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.)
Unless your non-contractual wishes are directly contradictory to your contractually stated wishes, and you actively harass the maintainers of a project that very politely choose to decline your non-contractual wishes.
To be fair, you should not have used "legally" in the sentence above. So there's the license, there's the author's wish, and there's the other party's wish, and both wishes are equally valid, they don't have to agree at all, what matters is the license.
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.
It used to be that distro users did indeed open bugs against their distro, and then the distro package maintainer would triage them and forward them upstream as necessary.
I don't know when precisely that stopped happening. Perhaps when OSS became more commonly hosted on sites like GitHub that have more easily-approachable issue trackers, users became more savvy about talking to upstream directly.
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.
The Nix maintainers asked very nicely whether there was a specific reason and whether they could work with the author to solved it. The author just said "no, just don't include my stuff", which he technically didn't have the right to say after releasing the code as FOSS.
You can't demand respect from the Nix folks after disrespecting them by telling them to do something "just because".
Honestly, I think the best solution in this case is to fork his repo from a version still under the MIT license and work with home-automation to replace their dependency.
5 replies →
If you follow the thread all the way down (and elsewhere, e.g. HA & Fedora communities), you'll see that the author does not seem to truly hold to his own statement that he "cannot stop [them]", and proceeds to attempt to bully them into compliance (despite many efforts by them to come to a compromise that may suit him)
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.
> The project could have pinned the version and downloaded from pypi rather than repackaging.
It couldn't, since Nix is a package manager and will only download things from its repository. It can't access the internet otherwise.
That is not quite right. NixOS can download files from the internet during build time for example to get the source code and you can even disable downloading things form the cache. It would be technically possible to download files at runtime but that does not align well with the reproducible goal and would also require some hacky patching.
It was asked if using PyPi as the source was acceptable in one of the PR comments: the author just said no.
https://github.com/NixOS/nixpkgs/pull/126326#issuecomment-86... says why pinning and pulling from pypi wouldn't work
What you are proposing doesn’t work with nix packaging
And that is the point: a nix problem becomes his problem all of a sudden.
1 reply →
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.
> As the author says, that can be fixed with a relicensing.
But he cannot retroactively remove MIT license. Changing license will only affect newer versions afterwards.
> If the source owner has a polite request
If this is your definition of polite so be it. I think it's quite unfriendly. Asked for a valid reason he basically says "because I want it".
If he want's them to remove it even though they have the right to use it he should at least explain why (or not publish MIT in the first place). His only argument is that he will get support requests, but he could just ignore them...
He's complaining about a support burden, and near as I can tell, his repository has literally zero issues on his GitHub issue tracker as of this writing, so the corpus of nixos users who have submitted issues is exactly, well, zero.
I'm not exactly sure who's being a "pain" in this case outside of the potential future concern that someone might wrongly blame him for package failures via nixos which is packaging it as an upstream dependency of home-automation.
I think I'd be more concerned about the latter's users!
On the other hand, frenck started by saying "anyone can do X", followed by saying, "please don't do X", and then "Ok, I'll take my marbles home."