Comment by pfraze
5 years ago
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.
yeah, to me it seems a bit like someone contributing a driver to Linux and then throwing a fit when they see someone patching it downstream.
Why publish it on the common infrastructure of python instead of some homeassistant project specific infrastructure then?
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.)
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".
6 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.
1 reply →
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
2 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.
> 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."
> 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?
> Do you have a reference or, more preferably, casserole to share on this point?
Are you by any chance a Firefox user and you have auto-correct enabled?
I'm guessing that because of "casserole", which is what Firefox corrects to if you accidentally double the 's' in 'caselaw'. Chrome goes for "casual", and Safari goes for "caselaw".
1 reply →
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.
Yes, he can, because of the way contract law works.
In order for a contract to be valid, and enforceable on both sides, there has to be an offer, acceptance, and consideration. No consideration (payment), no contract, and the open source license reverts to what is known in law as a bare license. Bare licenses can be revoked at any time, at will, by the licensor, regardless of any promises made by the licensor to respect the license in perpetuity. (You can always tell a squatter to leave your property, regardless of how permissive you've been in the past.) This includes revoking the license to software downloaded under an open source license for which the licensee has given no consideration.
I shouldn’t have used the term “contract” there because I was thinking more about interpersonal obligation than legal obligation.
There is no obligation: legal, interpersonal, or otherwise.
Only the license terms that the software is released under matter.
Most FOSS licenses include disclaimers like: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."
If you did not pay the author for support, they do not owe you anything.
If they choose to provide support or fix reported bugs, that is their choice.
The NixOS team can use the code regardless of the developer's wishes if the license allows it.
If the developer chooses to not support the software on NixOS or change the license, that is their choice.
1 reply →
Do you have case law for that?