6 ms·

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 con

by pfraze 5y 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.

sneak 5y 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.
- sokoloff 5y ago
  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.)
  - lucideer 5y ago
    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.
  - npteljes 5y ago
    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.
- pfraze 5y ago
  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.
- reidjs 5y ago
  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.
  - StavrosK 5y ago
    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".
    - Zancarius 5y ago
      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.
      - stavros 5y ago
        You don't have to fork, you can just use that release. You just can't use any subsequent releases, but neither can HA.
      - fmajid 5y ago
        He is a HomeAssistant community admin and they took his side, this is a case of two FOSS communities with irreconcilable differences.
        Zancarius 5y ago
        Interesting! Thanks for the insight! I think you're right. This is largely a difference of opinion. It's a shame it couldn't have worked out better.
- geofft 5y ago
  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.
  - Arnavion 5y ago
    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.
- prepend 5y ago
  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.
  - bogota 5y ago
    What you are proposing doesn’t work with nix packaging
    - turbinerneiter 5y ago
      And that is the point: a nix problem becomes his problem all of a sudden.
      - Dylan16807 5y ago
        It's a packaging problem in general, and packaging is pretty important. And "becomes his problem" isn't right either. If he wasn't upset by normal packaging then there wouldn't be a problem at all.
  - StavrosK 5y ago
    > 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.
    - SuperSandro2000 5y ago
      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.
- groby_b 5y ago
  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.
  - Zancarius 5y ago
    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!
  - randomNumber7 5y ago
    > 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...
  - mcguire 5y ago
    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."
bitwize 5y ago
> 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.
- pfraze 5y ago
  I shouldn’t have used the term “contract” there because I was thinking more about interpersonal obligation than legal obligation.
  - thesuperbigfrog 5y ago
    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.
    - user5994461 5y ago
      FYI that clause is void in civil law (most of Europe), you cannot waive away responsibility. Additionally, the license is a contract (license don't exist as a separate category like in the US), the "[...] WHETHER IN AN ACTION OF CONTRACT" is particularly misplaced.
- pbhjpbhj 5y ago
  The license can only be revoked ex nunc presumably? Do you have a reference or, more preferably, casserole to share on this point?
bogota 5y ago
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.
- pfraze 5y ago
  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
- aequitas 5y ago
  > 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.
  - sterlind 5y ago
    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.
  - ticviking 5y ago
    Why publish it on the common infrastructure of python instead of some homeassistant project specific infrastructure then?
kissgyorgy 5y ago
> 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.
Zancarius 5y ago
> (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 https://github.com/frenck/python-ambee/issues
- ticviking 5y ago
  The fact that it's a brand new project probably has more to do with the lack of issues.
mcguire 5y ago
I wonder if the other Home Assistant (https://github.com/home-assistant https://github.com/home-assistant) contributors know that their dependencies are not open source?
- throwaway84576 5y ago
  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-adding-library-dependencies-from-frenck/315185 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.

by pfraze 5y ago

sneak 5y 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.

sokoloff 5y ago
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.)
- lucideer 5y ago
  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.
- npteljes 5y ago
  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.
pfraze 5y ago
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.
reidjs 5y ago
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.
- StavrosK 5y ago
  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".
  - Zancarius 5y ago
    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.
    - stavros 5y ago
      You don't have to fork, you can just use that release. You just can't use any subsequent releases, but neither can HA.
    - fmajid 5y ago
      He is a HomeAssistant community admin and they took his side, this is a case of two FOSS communities with irreconcilable differences.
      - Zancarius 5y ago
        Interesting! Thanks for the insight! I think you're right. This is largely a difference of opinion. It's a shame it couldn't have worked out better.
geofft 5y ago
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.
- Arnavion 5y ago
  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.
prepend 5y ago
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.
- bogota 5y ago
  What you are proposing doesn’t work with nix packaging
  - turbinerneiter 5y ago
    And that is the point: a nix problem becomes his problem all of a sudden.
    - Dylan16807 5y ago
      It's a packaging problem in general, and packaging is pretty important. And "becomes his problem" isn't right either. If he wasn't upset by normal packaging then there wouldn't be a problem at all.
- StavrosK 5y ago
  > 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.
  - SuperSandro2000 5y ago
    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.
groby_b 5y ago
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.
- Zancarius 5y ago
  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!
- randomNumber7 5y ago
  > 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...
- mcguire 5y ago
  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."

bitwize 5y ago

> 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.

pfraze 5y ago
I shouldn’t have used the term “contract” there because I was thinking more about interpersonal obligation than legal obligation.
- thesuperbigfrog 5y ago
  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.
  - user5994461 5y ago
    FYI that clause is void in civil law (most of Europe), you cannot waive away responsibility. Additionally, the license is a contract (license don't exist as a separate category like in the US), the "[...] WHETHER IN AN ACTION OF CONTRACT" is particularly misplaced.
pbhjpbhj 5y ago
The license can only be revoked ex nunc presumably? Do you have a reference or, more preferably, casserole to share on this point?

bogota 5y ago

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.

pfraze 5y ago
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
aequitas 5y ago
> 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.
- sterlind 5y ago
  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.
- ticviking 5y ago
  Why publish it on the common infrastructure of python instead of some homeassistant project specific infrastructure then?

kissgyorgy 5y ago

> 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.

Zancarius 5y ago

> (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 https://github.com/frenck/python-ambee/issues

ticviking 5y ago
The fact that it's a brand new project probably has more to do with the lack of issues.

mcguire 5y ago

I wonder if the other Home Assistant (https://github.com/home-assistant https://github.com/home-assistant) contributors know that their dependencies are not open source?

throwaway84576 5y ago
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-adding-library-dependencies-from-frenck/315185 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.