[HN Gopher] Licenses alone do not govern behavior in open source
___________________________________________________________________
Licenses alone do not govern behavior in open source
Author : zdw
Score : 81 points
Date : 2021-06-18 19:03 UTC (2 days ago)
(HTM) web link (michaelweinberg.org)
(TXT) w3m dump (michaelweinberg.org)
| AgentME wrote:
| I think one of the most significant things about open source is
| that you're allowed to port it to new platforms. Imagine if you
| were porting some MIT or GPL open source application from Windows
| to Linux, and then the original author of an open source library
| used by the software you were porting told you that they hate
| Linux and don't want you to port their library to Linux. Are you
| obligated to do so and therefore give up on making a direct port
| of the application to Linux?
|
| A lot of people seem to argue that while you're not obligated to
| follow the developer's request, that it's still proper for them
| to make an optional request like that. I still think it's
| improper for the developer to make a request like that without a
| good reason. Imagine instead that you were the author of that
| Windows application, you released it as open source in order to
| guarantee that your code could be used as much as possible, and
| you specifically chose open source dependencies so that this
| could happen and that your entire application would be open
| source. And then you hear years later that your application
| wasn't ported to a new platform because the developer of one of
| the dependencies, that you specifically picked because it said it
| was open source, made a vague request exactly against one of the
| core benefits of open source. You'd feel like that dependency
| author misled you by labeling their work as open source.
|
| Packaging the project in the NixOS repository seems to be
| equivalent to porting it to work in NixOS in the most standard
| way, and as far as I can tell, there's interest in packaging the
| project because it's a dependency of Home Assistant, an open
| source project that people want on NixOS.
|
| I think it's proper for a dependency developer in this situation
| to make requests to change the presentation of the code (like
| that NixOS fork and rename the project so users don't ask the
| original developer for support), but to make a request that
| potentially blocks an open source dependent program from being
| ported to another platform is bad.
|
| EDIT: Even weirder, apparently the developer themself added their
| library as a dependency to the open source Home Assistant
| project, and now after this they're getting in the way of Home
| Assistant being ported to other platforms!
|
| https://news.ycombinator.com/item?id=27506141
|
| >But now that frenk added his code as a dependency, he has the
| right to transitively make Home Assistant un-packagable on NixOS?
| lifeisstillgood wrote:
| I try (tried?) to push for greater FOSS adoption by governments
| (www.oss4gov.org) and it's still a long way off good. One of the
| biggest hurdles was always "support". Purchasers liked OSS but no
| one felt they would get commercial levels of support (a single
| wringable neck if you like).
|
| I think that the best solution to this is to commercialise FOsS
| support - I think that dev shops can select decent FOSS projects
| and provide various guaranteed support - in a common manner.
| Perhaps some kind of licenced or insurance payment.
|
| I can imagine some kind of back payment to the original project -
| it won't be as profitable as software use license but it might be
| enough?
| pabs3 wrote:
| A lot of FLOSS projects have commercial support, and the good
| ones even have an ecosystem of multiple companies who provide
| paid support and also contribute back to the project, for eg:
|
| https://github.com/fossjobs/fossjobs/wiki/resources#freelanc...
|
| That can go wrong when the support companies are doing most of
| the work but not getting much out of it, for example
| Collabora's forking of LibreOffice Online.
|
| https://lwn.net/Articles/833233/
| https://lwn.net/Articles/692871/
| rrdharan wrote:
| That's exactly what TideLift is trying.
|
| https://www.tidelift.com
| nine_k wrote:
| Was / is it not the core business of Red Hat? You can run Linux
| for free, but if you want continued support, you can pay for
| it.
|
| I wonder if something like that is available for front-office
| software, like Libre Office, Odoo, Redmine, etc.
|
| I suppose much of the FOSS support business model has been
| eaten by cloud,providers who offer a lot of such software as a
| service. I still suspect that many government agencies would
| prefer or require on-premises installations.
| pabs3 wrote:
| Various companies do LibreOffice support:
|
| https://www.libreoffice.org/get-help/professional-support/
|
| Probably there are companies for the other projects you name,
| or contracting random developers would work.
| needle0 wrote:
| One advantage of commonly known licenses and their legalese is
| that it allows people who don't speak the same language to still
| collaborate without talking to each other in their non-native
| tongues, through understanding and adhering to the legal code.
| (For commonly used licenses, high quality translations are
| already available). Bringing natural-language "requests" into the
| issue nullifies that advantage and denies casual
| collaboration/use to those who cannot speak the language.
| (Machine translation, even DeepL, is still not good enough for
| language pairs with distant syntax structures.)
| randy408 wrote:
| Not a lawyer, but I _highly_ doubt the MIT license makes any
| difference when it comes to the author's demands in this
| situation, he has moral rights (legal term) to the software.
|
| You can't just make a mess of packaging someone's work and assume
| there's no legal avenue for the author, that's just naive.
| wvenable wrote:
| This is the text of the license (emphasis mine):
|
| "Permission is hereby granted, free of charge, to any person
| obtaining a copy of this software and associated documentation
| files (the "Software"), to deal in the Software _without
| restriction_ , including _without limitation_ the rights to
| use, copy, modify, merge, _publish_ , _distribute_ ,
| sublicense, and/or sell copies of the Software, and to permit
| persons to whom the Software is furnished to do so."
|
| The license clearly and _explicitly_ grants the ability to make
| a mess of packaging the work. One could translate it into BASIC
| and use it to launch rockets at whales in the pacific ocean and
| that would be granted by this license.
| randy408 wrote:
| Moral rights are unalienable in Europe, I'm not gonna quote a
| full paragraph from Wikipedia[1] here.
|
| https://en.wikipedia.org/wiki/Moral_rights
| aethertron wrote:
| Then they're incompatible with FOSS. If someone
|
| - releases code under MIT/GPL/whatever, declaring that
| their work may be changed and redistributed
|
| - then later asserts their moral right to NOT have their
| code changed and redistributed
|
| then they have done a nasty bait-and-switch move. The have
| shown themselves dishonest, and using their software should
| be considered a legally dangerous idea. If their courts
| support their claims then FOSS, as we know it, is unviable
| in that realm.
|
| But this hasn't ever happened, has it? Europe's FOSS
| development activity seems robust enough. But perhaps they
| are legally on a sand foundation...
| randy408 wrote:
| Moral rights are part of the Berne Convention, it's not
| limited to Europe.
|
| This is only an issue when someone 1. is very negligent
| with redistribution 2. has enough negative implications
| for the author to take issue with it.
|
| NixOS is a big, funded project, what's wrong with holding
| them to a standard? If they package it right then moral
| rights wouldn't be an issue for them, it's not exactly a
| legal minefield.
| aethertron wrote:
| >Moral rights are part of the Berne Convention, it's not
| limited to Europe.
|
| Not everywhere has unalienable ones. You can waive them
| in the UK and USA, which is what publishing under a FOSS
| license implies, to an extent.
|
| Anyway, moral rights aren't just about mangling a work.
| It's about mangling work in a way that makes the original
| author look bad. But with software, with the internet, no
| matter how bad the mangling, you can Google the author
| and find, say, his disgruntled Github comments stating
| his disapproval of the changes, so no reputational damage
| should accrue. Moral rights violation: nullified. Eh?
| rcxdude wrote:
| The question then becomes what amounts to 'packaging it
| right' and who is the judge of that? It's certainly not
| so simple as the sole opinion of the author, at the very
| least they would need to demonstrate some damage to their
| reputation or similar.
| shakna wrote:
| > The license clearly and explicitly grants the ability to
| make a mess of packaging the work.
|
| The license _may_, however, moral rights to the software also
| include "right to the integrity of the work", where badly
| packaging the software may actually infringe.
|
| That right isn't something the MIT license can simply
| override or ignore. There are plenty of rights that a person
| _can't_ surrender, based on the originating jurisdiction.
|
| For example, the oft-criticised Unlicense includes this
| statement:
|
| > In jurisdictions that recognize copyright laws, the author
| or authors of this software dedicate any and all copyright
| interest in the software to the public domain.
|
| However, in many jurisdictions that recognise copyright laws,
| the author has an inherit and implicit right to copyright,
| but simultaneously do _not_ have the right to surrender it,
| and cannot dedicate anything into the public domain, making
| said license completely irrelevant.
|
| Just because the legal document says something, doesn't mean
| it can actually do something.
| wvenable wrote:
| Providing a license is not surrendering copyright -- in
| fact, just the opposite. In order for anyone to make a copy
| of a copyrighted work they must have a license to do so.
| The license sets the terms of that copying. This is the
| fundamental aspect all copyright.
|
| I don't see how if the license says that one can modify and
| repackage the work without limitation or restriction that
| the person providing that license can argue for any
| violation of the integrity of work. If they can they
| copyleft is effectively dead.
| dragonwriter wrote:
| > Not a lawyer, but I _highly_ doubt the MIT license makes any
| difference when it comes to the author's demands in this
| situation, he has moral rights (legal term) to the software.
|
| Under what legal theory would moral rights be relevant?
| LIV2 wrote:
| This seems to be a common thing in some OSHW stuff I've seen.
|
| Some people will take your work and sell it for massive markup
| but the support is expected to be provided by the creator (and a
| lot of the issues stem from the fact that these sellers might
| substitute parts for cheaper ones that don't meet some critical
| specs like timing or TTL compatibility for example)
|
| When those creators say they aren't happy with that arrangement
| all they get is abuse - sure everything is legal but it doesn't
| make the behaviour any less immoral or scummy.
| pabs3 wrote:
| Probably the right social norms for OSHW (and FLOSS TBH) would
| start with providing their own support and extend to profit
| sharing.
| grawprog wrote:
| I read through the whole discussion on github. I understand the
| author's concerns and point of view, but his response to the
| NixOS maintainers and way of dealing with the situation was
| completely unreasonable.
|
| The NixOS people seemed willing to work and do what it took to
| make it work, up to and including rewriting the functionality
| using an identical API. The author refused to compromise, discuss
| anything and got fairly hostile and was pretty rude.
|
| It might be slightly more understandable if the author had been
| getting a barrage of complaints from users, but this hadn't even
| happened, he was preemptively assuming(you know what happens when
| you assume things...) it would and refusing to listen to the
| assurances of the NixOS people about taking responsibility for
| this.
|
| All the author really has to do is make it clear somewhere that
| they won't support any users using a non-official packaged
| version of the software.
| jasonlotito wrote:
| This is another case of an open source developer choosing a
| license for personal gain instead of the good of the community.
| People blindly choose MIT/BSD licenses for personal benefit need
| to understand what they are allowing. They reap the rewards with
| recognition, jobs (companies seeing you as an open source
| developer), praise, or in the case of companies, developer
| mindshare. But then someone does something the license allows but
| the author doesn't like, and suddenly the person obeying the
| license is at wrong.
|
| Point is, understand what you are allowing with your license
| choice and accept that you are okay with everything it allows. If
| you don't want to allow something, include it in the license.
| busterarm wrote:
| It's starting to look more and more as the decades pass from when
| these licenses were written that many authors don't understand
| the terms nor the purpose of the licenses they're choosing.
| Applejinx wrote:
| I'm an MIT license software author. I frequently get people
| asking 'I mean to do X thing with your codebase, which is allowed
| under the license: is this okay with you?' and my answer's
| typically, 'Of course, that's why I chose that license in the
| first place'.
|
| I'm also a white guy. Let's imagine what would happen if another
| white guy decided, "I want to make a DAW project that is only
| white guys' code, based on Chris's work as he seems white enough
| to me, and I will promote it through pointing to Chris and
| extolling his racial purity!"
|
| That's substantially more unpleasant (at least to my mind) than
| having an increased support burden, but it wouldn't change my use
| of the MIT license. Instead, what it would mean is this: if
| anybody asked, I'd tell 'em that the project was in compliance
| with the license but the people were absolute bozos and I didn't
| like them or the way they were behaving.
|
| Open source, especially as it leans more permissive, DOES NOT
| imply a support burden or endorsement deal. This is of course the
| BSD non-endorsement clause which is not present in the MIT
| license...
|
| It's a bit like this: my surname is Johnson. That's a pretty
| common name. I can imagine a person who learns this, and then
| goes, "Oh! I know a guy named Johnson. He is your brother! In
| fact I know five guys with the name Johnson. What a great family
| you have! I'll help you by gathering them all together for a
| reunion in your back yard."
|
| That would be dumb, but it would also be not my problem: I have a
| reasonable expectation that, in the context of normal society, I
| could say 'that's a very silly thing and not my doing' and people
| would acknowledge that it's the silly person's problem, NOT mine.
|
| By the same token, I feel confident that society would not tie me
| to a 'Only White Men DAW' using my MIT-licensed code, and lastly
| that the original package author is free to NOT take personal
| responsibility for handholding all possible users of their
| software, even if it's packaged in a large distribution that
| propagates their work farther than they expected.
|
| One possible workaround is what I effectively do with my
| codebase: if it's unwieldy or difficult in some way, and you're
| Free software, lean into that! Let it be known that you're too
| busy doing your part of the work to provide truly great support
| services, and suggest that third parties might step in and do
| their best to take up the slack. Odds are, they won't: but the
| suggestion is truly in the spirit of Free software, in that you
| are providing everything that YOU reasonably can, to anybody who
| would like to extend your work into a more fully developed
| software ecosystem.
|
| If there's a profound need for the type of support services you
| as the author don't feel able to extend to a giant audience,
| somebody WILL provide that support because it'll be much sought
| after and bring appreciation and popularity to the supporter. If
| that sort of popularization is truly important, the support-
| burden provider might end up seeing more in the way of
| donations/recompense than you as the original developer, because
| they'll be the ones directly dealing with the large audience and
| being 'the face' of the software.
|
| Think about what your expectations as a Free software developer
| are, and communicate those. That's all that's needed. Don't
| project onto the license, taking on things that aren't being
| asked of you, and the end result will evolve in a way that is
| strangely personalized to your needs.
|
| Right now I'm watching the evolution of three audio software
| projects: me with the Airwindows DSP codebase, Surge Synthesizer,
| and VCV Rack. Each one has developed a 'style' of interaction
| with society at large around use of the code, but in each case
| the 'style' is quite different. The expectations and 'style' WILL
| be communicated, regardless, and this is why I think it's a
| mistake to do things like request non-inclusion in a distro: that
| developer underestimates the ecosystem's ability to 'read' their
| wishes for how they interact with that system. I don't believe
| they'd get buried under support requests, unless they
| functionally behaved as if they were actually responsible for
| doing that.
|
| The ecosystem will 'read' what you do, not just what you say
| you'd like to do. Working in Free software requires that you're
| honest about what you are and are not offering. I could make my
| life incredibly harder, by putting forth the appearance that I am
| about coordinating and overseeing a whole world of pull requests
| and coordinated derivative projects... diving into stuff that's
| way beyond my ability to keep track of... but since I don't put
| across that appearance, my burden to maintain that is effectively
| zero. Because I'm rigorous about avoiding stuff that I'm ill-
| suited for, I'm not muddying the waters through pretending to be
| competent at it...
| quanticle wrote:
| I think this is a dangerous mode of thinking. The purpose of a
| license is to outline what rights I have with regards to copying
| the software (and redistributing it). If I have the right to do
| something, then I ought to be able to do it, even if you request
| otherwise.
|
| Imagine if some corporation licensed their software with the GPL,
| but then "requested" that you not repackage that software for
| Windows. Would that be a "healthy response" on the part of the
| company? I don't think so. The GPL clearly states that I have the
| right to redistribute modified copies of the software, so long as
| I make my changes available to others.
|
| In this case, the software is licensed under the MIT license. MIT
| is an even looser license than GPL; a redistributor can take the
| software, make changes to it, and redistribute the modified
| version as a _closed source_ binary, so long as they acknowledge
| the original creator. Repackaging the software is clearly within
| the rights of the NixOS maintainers, and they 've chosen to
| exercise their rights as defined by the law. To argue that they
| have some unwritten obligation to respect the wishes of the
| package author subverts the intent of free software, which is
| that the software that runs on my computer is _mine_ , to run
| and/or modify as _I_ wish.
|
| If the package author wishes to restrict his users from modifying
| their software, there is a very simple remedy: release the
| software under a non-free license that restricts redistribution.
| The way they're behaving now is an attempt to eat their cake
| (restrict the way software can be modified and distributed) and
| have it too (get credit for releasing software under a free
| software license).
|
| EDIT: Swapped out BSD in favor of Windows in my first example,
| because it seems that people were getting confused between BSD
| (the operating system) and BSD (the license)
| UncleMeat wrote:
| Yes and no. What is legal, what is ethical, and what is
| socially acceptable are all different things. Licenses only
| cover what is legal.
| soraminazuki wrote:
| I agree. He granted people rights to use and distribute his
| software. It's unreasonable of him to attack people when people
| start using it.
|
| I'm well aware there are some complications with open source
| licensing, in which many businesses profit off free labor
| without giving anything back. However, this isn't what happened
| here. This is a case of _volunteers_ working to ensure that
| Home Assistant would work on NixOS. The upstream author came
| anyway and demanded that NixOS not use his software, refusing
| reasoned dialogue and instead throwing thinly veiled insults.
|
| If many consider this acceptable, then the _purpose_ of open
| source licensing would become moot. I 'm glad this doesn't seem
| to be the case here.
| Proven wrote:
| > I'm well aware there are some complications with open
| source licensing, in which many businesses profit off free
| labor without giving anything back.
|
| How is that a "complication"? That's exactly how it's
| supposed to work - it's gratis and you may be able to
| "profit" (benefit) from using it for free.
| II2II wrote:
| If it was a dangerous mode of thinking, then any request of
| support from the author is also a dangerous mode of thinking.
| After all, from the MIT license: 'THE SOFTWARE IS PROVIDED "AS
| IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED'.
|
| The author simply made a request, with the full realization
| that it was nothing more than a request given the license they
| had used. They are also far from the only only one to exhibit a
| similar attitude. I recall GNU being antagonistic about the
| distribution of Emacs under Windows in the past. Given their
| association with the GPL, that antagonism can be viewed as more
| of a statement than a request.
| geofft wrote:
| Right - there's two parts of "open source" as the term is
| commonly used, open source as in the license, and open source
| as in the community.
|
| We look skeptically on companies whose "open source"
| involvement involves dumping code that works for them and not
| accepting contributions or responding to questions and not
| participating in upstream communities. We talk about being a
| good open source citizen because we have an analogy to the
| real world, where being a "good citizen" is more than merely
| following the law. We have opinions about codes of conduct
| (whether for or against) even though those don't affect the
| license at all. We talk about an open source sustainability
| crisis even though all the code that's been released so far
| isn't danger of disappearing.
|
| Maybe we need another term for it, but for now, the term as
| it is used in practice both refers to the licensing regime
| and the community and culture around it. The idea that
| projects have maintainers in the first place and aren't just
| released anonymously to the commons, and moreover that it's
| reasonable to contact the maintainer if you have a problem to
| report or an improvement to suggest, is a significant part of
| what defines the open source _community_ , even though the
| term "maintainer" appears in no license (except the LaTeX
| one, which adds some obligations around non-maintainers
| marking modified copies which is called out in the DFSG as a
| compromise not to be encouraged).
|
| Frankly, it seems to me that the author in question just
| wants to stick by the license: they want to release the
| software and not be contacted about it by people who receive
| it from redistributors. That seems reasonable to me, in the
| abstract. The hard part is reconciling that with the norms of
| the community.
| jltsiren wrote:
| There is no such thing as _the_ open source community.
| There are many overlapping communities, with a great deal
| of variation in culture and norms. Research code is a good
| example of this, because the academia is full of niche
| groups with varying aims.
|
| In computer science, a lot of open source code is written
| for other researchers in the same subfield. Some degree of
| support is expected, as long as the request is related to
| research (and the original developer has not left the
| academia). Requests from people who just want to use the
| code feel awkward and out of scope.
|
| Many bioinformaticians write software for actual users.
| Inexperienced ones may read about a fancy new algorithm,
| find the implementation, and try to use it in their
| project. Confusion (and sometimes even conflict) ensues
| when they find that the proof-of-concept implementation
| from a CS researcher is not appropriate for real use. On
| the other hand, there are many unwritten rules about
| modifying and redistributing somebody else's code. Research
| is all about ideas, and building upon them without
| crediting the original authors clearly and visibly violates
| academic integrity.
| m463 wrote:
| I remember RMS saying that GPL software allows you to USE the
| software for any purpose. It just governs how you redistribute
| it, so you pass on the same freedoms you enjoy to others.
| wumpus wrote:
| [Because of the edit above, my comment is no longer relevant.]
| bramblerose wrote:
| "BSD" can refer to the BSD license, but I think the poster is
| referring to the operating system here.
| MattGaiser wrote:
| I think that is what he meant. What happens when someone
| created GPL software and then does what this developer does,
| which is pressure others not to freely use it?
| quanticle wrote:
| The intent behind my comment and the two examples was to
| explain that there really isn't any nuance or controversy
| here. Any attempt to inject controversy, by saying that the
| NixOS packagers have some kind of obligation to the original
| package author because he asked nicely is inherently against
| the intent of free software, which is that once I have the
| program running on my system, it's mine to modify and
| redistribute as I please. Sure, the package author can "ask
| nicely" that I don't redistribute, but I believe in the four
| freedoms of the FSF, and by golly I'm going to exercise them.
| [deleted]
| soraminazuki wrote:
| From the looks of it, the upstream author didn't ask nicely
| too, honest questions from NixOS maintainers were
| immediately met with mockery.
| wumpus wrote:
| It would be nicer if you had marked your edit where you
| made it; it took me a while to notice the postscript. Also,
| you could have mentioned that you made an edit in your
| reply. Thanks. I hope next time turns out better.
| abdullahkhalids wrote:
| Look, human society is complex with millions of moving parts.
| Every law that has ever been written has winners and losers,
| because it abstracts away many of the details of human behavior
| and buckets them into simple categories. But just because a law
| has been written in a particular way, doesn't mean that we
| forget the intent behind the law, which probably wasn't to have
| these winners and losers, but it was the best law we could
| write.
|
| People respond to this conundrum in at least two ways. One way
| is, let's specify even more complex rules and regulations that
| takes care of the weird cases. The bad thing about this is that
| it increase compliance costs for everyone, and it only takes
| care of some cases and never all of them. The other way is to
| recognize that it's impossible to write perfect laws, so we
| should take some liberty in interpreting them on a case-by-case
| basis. The bad thing about this approach is that there is
| always uncertainty about how your particular case will be
| interpreted.
|
| Usually, both approaches are taken (legislators write ever more
| complex laws; judges show compassion or come down hard). And
| this is the correct way to go about it, because it usually
| allows for fewer winners and losers. But you are advocating
| that the second way be never practiced, and I don't think
| that's a good approach.
|
| Law is code. And like any piece of code, always has bugs, that
| need to worked around in the short term, before they are fixed.
| jraph wrote:
| We are not in unhandled situation territory here though. The
| license explicitly gives rights the author does not want to
| be used.
| Nursie wrote:
| Law is not code, it is little like code, it is interpreted in
| the light of circumstance and applied inconsistently. It's
| very variable and relies on humans, who can show forgiveness
| and compassion.
|
| (Sorry, but of a bugbear with the 'code is law' crowd...)
| pjc50 wrote:
| Law is _a_ code. https://en.wikipedia.org/wiki/Code_of_law
|
| (but yes this is mostly a pun and the code is law people
| are dangerously self-blindfolded)
| abdullahkhalids wrote:
| That's pretty much what I said. Attempting to treat law as
| a perfect bug-free code is a fool's errand.
| yawaramin wrote:
| Your comment can be copied verbatim into any thread about OSS
| licensing and seem vaguely relevant. What are you trying to
| say specifically about OP?
| smokey_circles wrote:
| There is no such thing as the spirit of open source. This is a
| stand-in for an actual argument that bridges the gap between your
| own philosophy and the reality of maintaining a project.
|
| However, if you were so inclined to believe otherwise, please
| explain to me how that spirit of open source would not have
| simply dictated that either the project get rebuilt from scratch
| or simply cloned before inclusion?
|
| It's not hard to recognise the human problem and try to work with
| that. Instead: We find braindead allegiance and arrogance
| throwing shit on either side of the fence.
|
| The open source community is in trouble if this is the direction
| we're moving in
| MattGaiser wrote:
| I would rather that norms not be injected where they do not need
| to be. The problem is that norms are often unclear, applied
| unequally, deter otherwise worthwhile things from being done,
| often exist for little reason other than "everyone else does it",
| and often could be eliminated with by explicitly writing more
| accurate rules.
|
| How many companies would be deterred from adopting open source if
| they saw it as a reputational risk in case the original
| developers decided that their particular use case was "not what
| was wanted"?
|
| I used to work for the government, where they require long
| support times. Someone randomly deciding to change a licence as
| they didn't really mean what the licence said in the first place
| would be a huge problem.
| dalbasal wrote:
| IMO, this is impossible.
|
| Even really formal rules systems like law need a lot of
| interpretation (eg courts/judges) to bridge the gap between
| abstract and particular, and to adapt to culture.
|
| Even so, explicit laws and contracts can never really cover
| everything, for example, in employer/employee relationships,
| business/consumer relationships, etc. A more subjective
| cultural layer does most of the work. It's not as enforceable
| as the explicit, contractual layer.
|
| This example is, IMO, pretty normal and OK. There is the
| explicit license, which governs the legal side. There's the
| unenforceable request, which can still be made. There's
| recourse, relicensing. There is a subjective layer, which is
| what this article is doing. Should X have honoured the request?
| Was it ok for Y to make the request? Was reliscencing against
| the spirit of open source?
|
| We need the whole package. Society can't be written down,
| because we don't really have the full spec. Explicit, legible
| rules are important, but they're a cornerstone and a fall back.
| soneil wrote:
| I'm not sure "norms" are avoidable. How many posts do we see to
| various github issues where people haven't been "delighted"
| with the maintainer's response?
|
| We are highly defensive of the rights that floss/copyleft
| licences grant us, but highly dismissive of the "no implied
| warranty" verbiage that goes with them. That appears to be this
| maintainer's issue.
|
| And it does come at a cost. There's a very strong chance his
| next project won't be floss/copyleft.
| philprx wrote:
| Ok, maybe I'm super wrong here, if so just indicate it (kindly
| ;-) it seems to be hot in these threads ;-) ).
|
| Here it is:
|
| It seems to me the root cause has nothing to do with openness and
| FLOSS and licensing:
|
| It seems to me it has to do with NixOS has a technology
| architectural choice of "fixing" dependencies in a way that's
| more costly (fox NixOS package maintainers) to maintain to the
| latest version of each package, that the dependency package
| author doesn't like that because NixOS therefore keeps older
| packages, and therefore will create problem down the line.
|
| Am I wrong?
|
| PS: I usually take the analogy with noisy neighbours and the
| architect. Some neighbours end up in fight because of noises in
| another neighbour's flat. In the end, nobody goes to the
| architect and building company complaining that the walls are too
| thin. Yet they fight on the downstream problems. Good thing: In
| software we can fix things more easily than in hardware ;-) Here
| it seems it's a fight on a downstream fight on a tech
| architecture choice.
| soraminazuki wrote:
| From the looks of it, the upstream author was against
| downstream packaging of any sort. It's not any particular
| problem that caused him to attempt to prevent NixOS users from
| using his software.
|
| But anyways, existing packages tend to be easier to maintain on
| NixOS because of rich tooling around the Nix ecosystem. Most
| importantly, they have automated workflows for checking and
| updating upstream sources[1], and it can be merged without
| problems most of the time. There's also lots of effort around
| preventing regressions too, and packages are tested as part of
| the automated workflow. It's also easy to check out the changes
| yourself, because you can just "git pull" and test the changes
| locally without interfering with your existing installation, a
| feature unique to Nix.
|
| The upstream author's claim that NixOS was not bothering to
| update his packages are simply not true. That was just him
| being incendiary and disrespectful[2]. NixOS was using the
| exact version required by the latest version of Home Assistant.
| And he very well should've known that because he happens to be
| a major Home Assistant contributor. If anything, data shows[3]
| that NixOS is one of the most up-to-date distros out there.
|
| [1]: https://github.com/r-ryantm
|
| [2]: https://github.com/NixOS/nixpkgs/pull/126326
|
| [3]: https://repology.org/repositories/graphs
| kosinus wrote:
| Yes, Nix is a little more strict in this regard, when seen as a
| package manager. But regardless, the author also mentioned he
| took issue with Fedora packaging, so is more interested in
| limiting distribution channels in general.
| cbsmith wrote:
| This is not a complicated issue. Open source affords one twins
| one might think as undeniable, but that doesn't mean authors have
| no voice. It just means that voice isn't backed by people weapons
| and military training with the express authority & purpose to use
| all of the above.
|
| The idea that the author's voice deserves to be heard and
| considered is essential to a vibrant community.
|
| Authors living and dying by their communities' perception and
| response to hear ideas/opinions _is_ the point.
| cbsmith wrote:
| This is embarrassing. Autocorrect changed "rights" to "twins",
| "their" to "hear", and somehow dropped "with" entirely from
| "people with weapons". :-(
| solidasparagus wrote:
| This article passes over the tone of the communication, which was
| really the driver for most of the discussion in that thread. Many
| people had sympathy for the situation, but many also had problems
| with the way the creator approached the discussions. The comment
| that is specifically quoted about "not understanding the spirit
| of FOSS" wasn't even about asking to have a package excluded, it
| was about the refusal of the dev to engage in any sort of
| discussion and just the overall unhelpful attitude he took (which
| the dev improved upon in later communications).
| zargon wrote:
| I get the feeling that the demand to have such a conversation,
| at the whim of downstream, is a significant part of the burden
| the author wished to avoid. At least it would be for me in his
| position. I may express a preference and desire not to be
| forced to expend the (considerable) effort to find words to
| defend it to the satisfaction of some third party (who may
| never be satisfied).
| [deleted]
| solidasparagus wrote:
| But downstream didn't demand anything. AFAIK there was no
| communication until the dev asked for it to be removed, they
| asked why, and he said the equivalent of "just do what I
| say", which obviously didn't get him anywhere.
|
| And the public opinion was really only against the dev
| because he was being intentionally difficult while the NixOS
| people were bending over backwards to look for a mutually-
| satisfying solution. It would have been a non-story if the
| dev hadn't been a bit of an ass in public forums.
| zargon wrote:
| > But downstream didn't demand anything.
|
| As you described above, they damanded a conversation about
| why he was making the request he did. They couldn't just
| acknowledge that he had a request and choose to respect it
| or not when it was clear he didn't want to talk about it.
| Instead they dragged him into a huge spectacle. Even after
| they closed the issue on their side, (other?) NixOS people
| went to endlessly harass him on the home assistant forums.
| squiggleblaz wrote:
| > As you described above, they damanded a conversation
| about why he was making the request he did.
|
| They didn't demand a conversation. They continued a
| conversation. If he doesn't want to engage in discussion
| with them he shouldn't have.
|
| > They couldn't just acknowledge that he had a request
| and choose to respect it or not when it was clear he
| didn't want to talk about it.
|
| They were trying to arrive at a compromise. This is
| usually regarded as part of good faith negotiations.
| Trying to describe this as "dragging him into a huge
| spectacle" is quite shocking to me. Do you genuinely
| believe that if a person says "please do not distribute
| my package" the only reply to that thread should be one
| that says "we will remove it" or "we will not remove it"
| and then the thread should be closed?
|
| > Even after they closed the issue on their side,
| (other?) NixOS people went to endlessly harass him on the
| home assistant forums.
|
| I don't think this is an accurate description of that
| thread, but indeed, I think opening that thread was an
| example of poor judgement. A threat to make a certain
| library proprietary during a heated discussion is
| something that might be reconsidered or it might be a
| bluff. It should be confined to the negotiation unless it
| comes to fruition.
| SuperSandro2000 wrote:
| > NixOS people went to endlessly harass him on the home
| assistant forums.
|
| That is just a lie and not what happened.
| ninjin wrote:
| Not sure if I agree with "NixOS people went to endlessly
| harass him" unless there is another thread apart from
| this one [1]. Mic92 is clearly well across the line
| stating that "to keep the home-assistant free-software it
| would be better not increase the reliance on his
| projects", but for example SuperSandro2000 and blaggacao
| are certainly not harassing unless you deem any action
| rather than accepting frenck's request harassment. The
| whole exchange also seems to have lasted for about three
| hours. It could (and should) probably have been avoided,
| but let us not blow a brief interchange on a public
| e-mail list out of proportion.
|
| [1]: https://community.home-assistant.io/t/consider-to-
| avoid-addi...
|
| Personally, I probably would have sided with jtojnar that
| cited Debian's policy to drop packages when the
| relationship to the upstream is beyond repairing [2].
|
| [2]: https://github.com/NixOS/nixpkgs/pull/126326#issueco
| mment-86...
| MattGaiser wrote:
| But then it should be licenced so that people downstream
| don't think they can use it. The conversation was because the
| guy stuck a sign saying "anyone can use this for whatever
| reason" and then was unhappy at people doing just that and
| wanted them to just accept that.
| zargon wrote:
| He made it known that he had a preference about the usage
| of his library that wasn't codified in the license, while
| also acknowledging the rights he had granted by using the
| license he did.
|
| He may or may not have had reasons for making it MIT. There
| aren't really standard licenses for situations like this.
| Using a non-standard license has its own problems. He may
| not have anticipated getting the attention it did. Or
| whatever other reasons. I don't think it's necessarily easy
| to anticipate all future situations and codify them into a
| license ahead of time. He may change the license going
| forward as a result of this and that is fine too.
| abdullahkhalids wrote:
| Just to add on, the license is for the current and past
| versions of the program. Distributing a program as FOSS
| is not a promise that the author will continue to improve
| the software, or that future versions will also be FOSS.
|
| So, I think it's reasonable to suggest that "hey I can't
| maintain this software if you include it in your
| distribution because of the added workload".
| yjftsjthsd-h wrote:
| > So, I think it's reasonable to suggest that "hey I
| can't maintain this software if you include it in your
| distribution because of the added workload".
|
| Plausibly, but AFAIK this author (and certainly this
| package) has never received a bug report from a NixOS
| user.
| jchw wrote:
| I don't agree that social pressures to conform to unwritten rules
| are in the spirit of open source, nor is asking maintainers to
| treat your project different from 60,000+ other packages.
|
| In fact, not all of the packages in Nixpkgs are even open source.
| Even more in fact, Nixpkgs doesn't even redistribute packages
| directly - there are caches, but the core thing that is provided
| is a manifest.
|
| What we have here is not an open source problem. What we have
| here is a social problem that happens to regard a project that is
| open source. Outside open source, people who are concerned about
| distribution for one reason or another certainly exist - in the
| past, asking people to not repost their downloads and instead
| link to their pages, pleas that often went unanswered due to the
| ruthless desire to share information freely online, licitly or
| illicitly.
|
| Tying this into support is totally moot. First of all, that
| impacts any free as in beer software equally; on NixOS
| especially. Secondly, the connection to FOSS being unsustainable
| is not warranted here in my opinion. Home Assistant is a highly
| visible project that appears to have a couple different
| approaches to monetization. It isn't exactly the unsung hero of
| the open source ecosystem as a whole. Thirdly, there is no
| obvious specific event that spurred this all on, so it's not
| clear this was the motivation. Finally, the NixOS maintainers
| seemed willing to go different lengths to try to satisfy this
| support angle and were swiftly shut down with the author acting
| increasingly more impatient, seeming to not understand why they
| are trying.
|
| And that caused pressure to the NixOS maintainers. Who are
| volunteers on an open source project who are _trying to not break
| their own users by removing or stalling a popular package they
| already had_ [1]. The whole conversation looked very stressful
| and one-sided.
|
| I can't say exactly what happened here, but I hate the framing
| that suggests this is a healthy direction for the open source
| community. It feels like we're setting up for a world where,
| counterintuitively, a ton of expectations are hoisted on you if
| you release open source software. Like do I have to check with
| all of my upstreams that vendoring my dependencies doesn't upset
| them? The second and third order effects here do not sound
| tenable to a healthy community. Licenses are meant to encode
| expectations in a tangible way; that this is _imperfect_ is
| obviously clear when you consider peoples abject reactions to
| things like the SaaS loophole - it reflects a place where a
| mismatch occurred.
|
| This really isn't that. This is more like something that could
| actually just be encoded into the license but isn't. That's a
| problem. Because if they are successful, this sets a bad
| precedent. It smells an awful lot like distributing software
| under one license but stipulating additional things on top. Taken
| to its extreme, it could start to smell an awful lot like shared
| source but with the legal benefit of being able to rely on
| software whose licensing wouldn't permit such a combination.
|
| And that's just it. Open source is an asset and a strong brand. I
| think when bootstrapping, a lot of people see the benefits as
| hard to ignore, and maybe make the choice despite that it may not
| truly align with their personal views and attachments to
| projects. It's really the same thing when it comes to a lot of
| the open source debates lately; it feels like an increasingly
| large amount of people want the control that you have with closed
| source, while maintaining the branding benefits and assets opened
| up by being "open source." I can't pretend to know what the
| motivations for this whole debacle were, but the author actually
| did suggest they would simply move the dependency to a shared
| source license and add an exemption for home assistant. In
| actuality, there is nothing wrong with this, so as long as it
| doesn't trample on any license obligations elsewhere. I and many
| others are not suggesting you are morally obligated to use open
| source licenses or anything like that.
|
| But I think if you do use open source licenses, while you aren't
| particularly obligated to do anything, you are also not
| particularly owed anything. I really, really, really think it
| needs to be kept that way.
|
| [1]: https://github.com/NixOS/nixpkgs/commit/bacbc48c
| oarsinsync wrote:
| I agree with the point of your argument, and everything you've
| said, except:
|
| > who are trying to not break their own users by removing or
| stalling a popular package they already had
|
| I don't believe this is true. I believe the author asked to not
| be included before the change got merged. After the PR got
| closed, the maintainer from nixos took the conversation to the
| homeassistant forums, where someone seemingly representing
| nixos indicated that packaging homeassistant was a relatively
| new effort.
| jchw wrote:
| If that is true I apologize, however when the issue blew up I
| looked and it did appear that home assistant was already used
| by Nix users. If I get a chance before the edit window I will
| take a look and adjust this point accordingly.
|
| edit: I looked into it and it appears home-assistant has been
| packaged in Nixpkgs since at least January 2018. I'm keeping
| this statement as-is. (Also, to clarify to anyone reading
| this, the PR that spurred this on was one for a _dependency_
| for home-assistant, not home-assistant itself, but the author
| of the dependency is one of the top contributors to home-
| assistant.)
| Fuzzeh wrote:
| "The creator expressed these concerns by way of a social request
| instead of a legal threat because part of living in society is
| being able to resolve disputes without going to court."
|
| Is simply not true. The creator made a social request because
| there was no way a legal challenge could succeed, not because
| they wanted to avoid court.
| hbbio wrote:
| I have the impressions that, in some ways, we are reaching the
| limits of the open source model. I am not saying this light
| heartedly, I built a fair share of open source software myself.
|
| The situation is complex since many different types of
| contributions exist ranging from two extreme positions:
|
| 1. A company or startup following the "open source business
| model" publishes a complex piece of open source software, trying
| to get adoption while the company lives off VC money - planning
| later to sell services (hosted SaaS, support, etc.) and/or extra
| features for the product.
|
| 2. An individual writes a small library or tool in his/her free
| time, publishes it on GitHub and then forgets about it. But it
| may still get traction because it is useful.
|
| It is a gradient of several variables: type of entity, intended
| purpose of publishing and expected return, short/long-term
| commitment, etc. that lead to different situations.
|
| For some, especially if we account a growing social factor in,
| there may be better solutions that open source (as OSI defined).
| For instance, an independent developer writing an important
| library should get a share of the business use/revenue,
| especially if a set of companies that were not involved in
| writing it end up seizing most of the enterprise business around
| it.
|
| Something like "public source", i.e. source available but not
| free to use under any condition may be an answer in some cases.
| type0 wrote:
| > A company or startup following the "open source business
| model" ...
|
| Yes, it's the case that open source isn't and can't be a
| business model in itself
| ozim wrote:
| I think there should be something like "Private copying levy"
| but for open source developers that create useful libraries.
|
| My example would be cURL. Car makers have it incorporated in
| their software and well I don't think any of those car makers
| was going to Daniel to buy that piece of software or
| contributed back to the project.
|
| For "private copying levy" I don't really agree all poets
| should take cut because there is no demonstrable evidence that
| someone is using their work, so they would receive money for
| nothing.
|
| While open source developers can demonstrate that their
| software is used by those companies to build products and
| people use their work while using products.
|
| https://en.wikipedia.org/wiki/Private_copying_levy
|
| https://daniel.haxx.se/blog/2018/08/12/a-hundred-million-car...
| ahepp wrote:
| Isn't this problem easily and simply solved by dual licensing
| GPL/commercial?
|
| If Daniel wanted something in return for his code, he should
| not have MIT licensed it. I don't mean that in a snarky way,
| I just don't see what more there is to say on the matter.
| shakna wrote:
| It took Daniel 937 days to get a visa [0] to _visit_ the US.
| I don't really see the US ever being interested in the
| contributions of a particular software, like cURL, to their
| industries as a whole. Any levy to support it would be fought
| at every level.
|
| [0] https://daniel.haxx.se/us-visa.html
| ozim wrote:
| This cURL is just a single example, and as Daniel is
| Swedish then that would be on Sweden to introduce such levy
| and pay it out to him.
|
| But as other example if someone would be US national and
| contributed to OpenSSL project, he should get some payment
| for that.
|
| This would possibly fix quite some issues with OSS funding
| and contributors burnout. Because there are real examples
| of big corporations taking advantage of open source code
| without paying anything. Unfortunately OSS contributors are
| quite small group so their votes are not something that
| would make government take them seriously. But their work
| is proven to be important for society and that should be
| taken into consideration.
| pjc50 wrote:
| > as Daniel is Swedish then that would be on Sweden to
| introduce such levy and pay it out to him.
|
| That just makes the situation even worse; it would be
| painted (with some justification) as wrecking the Swedish
| domestic software industry.
| syshum wrote:
| Increased use of copyleft license would be a solution.
|
| Over use of MIT license, and the focus of open source dev tools
| only is the root of the problem
|
| We need open source SOFTWARE. not libraries and tooling
| pjc50 wrote:
| > For instance, an independent developer writing an important
| library should get a share of the business use/revenue,
| especially if a set of companies that were not involved in
| writing it end up seizing most of the enterprise business
| around it.
|
| But then it won't be adopted.
|
| The modern OSS infrastructure is, for better or worse, a
| product of being both transactionless and frictionless. You can
| use such software without round-tripping a conversation, and
| you can do it without money changing hands - which, for
| businesses, means you can use it without fighting your internal
| purchase process.
|
| The fantasy of taking a revenue split and distributing it over
| everyone mentioned in your transitive dependencies is just
| that: a fantasy. It can't happen that way in a modern business
| culture. Try to enforce it and businesses will just go back to
| buying single vendor stacks
| ako wrote:
| This. Enterprise Developers use opensource because it
| empowers them to choose the right compone nts without
| involving an entire purchasing organization. And why pay for
| software if there's no support organization with support
| contracts and SLA's?
| wvenable wrote:
| > Something like "public source", i.e. source available but not
| free to use under any condition may be an answer in some cases.
|
| What would be the purpose of this? If the source is available
| but can't be used then there is no reason for the source to be
| available. No one can do anything with that source.
|
| The library in question is already released "without warranty
| of any kind, express or implied". If the author is burdened by
| support that they explicitly don't need to provide then the
| answer is to not provide that support. They are under no
| obligation to do so. Asking to limit the distribution of their
| product after explicitly licensing it to allow for distribution
| "without restriction" and "without limitation" is just plainly
| the wrong approach.
| hbbio wrote:
| There are a lot of purposes.
|
| 1. Being able to modify it, which was the original intent of
| RMS. Of course, such a public license would allow users to
| modify it and even to distribute their modifications for
| others, as long as they adhere to the rest of the original
| software license.
|
| 2. Being able to audit it. Either from a security perspective
| (crypto software, online service, etc.) or just for a
| safety/quality audit.
|
| 3. Being able to build it for a platform of your choosing,
| especially later in time.
| ako wrote:
| I was under the assumption that RMS's main purpose was to
| protect the users, and especially their ability to use it
| in a future where the author was no longer maintaining it,
| or was focused on different features than required by the
| user.
|
| In this case, RMS would be more concerned with nixos's
| freedoms rather than the package author's.
|
| Anyways, that is my assumption, I might be wrong...
| hbbio wrote:
| In 1980, Stallman and some other hackers at the AI Lab
| were refused access to the source code for the software
| of a newly installed laser printer, the Xerox 9700.
| Stallman had modified the software for the Lab's previous
| laser printer (the XGP, Xerographic Printer), so it
| electronically messaged a user when the person's job was
| printed, and would message all logged-in users waiting
| for print jobs if the printer was jammed. Not being able
| to add these features to the new printer was a major
| inconvenience, as the printer was on a different floor
| from most of the users. This experience convinced
| Stallman of people's need to be able to freely modify the
| software they use.
|
| https://en.wikipedia.org/wiki/Richard_Stallman
| _flux wrote:
| "Source available" is still useful if the product in question
| is a library; the source can often answer questions about how
| to implement certain things, even if you cannot change
| anything. Source available may also enable you to debug from
| your code to provider code, as well as compile with different
| compiler options for better debugging or tracing experience.
|
| For end-user applications it makes no difference.
| _emacsomancer_ wrote:
| I suppose it could make a difference for end-user
| applications for concerns about privacy/security. As I
| recall, tarsnap is "source available" for these sorts of
| reasons.
| quanticle wrote:
| Exactly. The remedy for the original package author is to put
| up a banner on their project that says, "I will not be
| answering questions about my package on NixOS because I
| disagree with how NixOS packages my library." Failing that
| they could release their project under a non-free license
| that restricts redistribution in a way that excludes NixOS.
|
| I don't understand what their intent was in requesting that
| the NixOS packagers voluntarily give up rights that the
| author had explicitly granted them, via the MIT License.
| squiggleblaz wrote:
| > Failing that they could release their project under a
| non-free license that restricts redistribution in a way
| that excludes NixOS.
|
| He wasn't happy with Fedora doing it either. It's a matter
| of redistribution, not a matter of NixOS.
|
| > I don't understand what their intent was in requesting
| that the NixOS packagers voluntarily give up rights that
| the author had explicitly granted them, via the MIT
| License.
|
| The author isn't proposing software that a person might use
| to solve a problem. He's part of a project (Home
| Automation) that provides a service, and writes tools to
| that end. People who fundamentally see themselves as
| providing a service prefer precisely specified, first party
| dependencies. They see GNU/Linux distributions (which
| connect users and developers - or alternatively stand
| between users and developers) as dead ends and irritations.
|
| He was saying "if you want to use this, go knock yourself
| out" but he's also saying "please don't get in between me
| and my clients".
| MaxBarraclough wrote:
| > If the source is available but can't be used then there is
| no reason for the source to be available. No one can do
| anything with that source.
|
| It's certainly not the equivalent of Free Software, but there
| would still be some things you could do. You could study the
| source to learn from it, to check for security issues, or to
| check for malware.
|
| In the FSF's terminology, you wouldn't really have any of the
| Four Freedoms, but you'd have a fraction of Freedom 1.
| enriquto wrote:
| i'm sure we had a name for that, "coopie-lept" ,
| "copiiiehlift", "cuuu..." please help me
| badsectoracula wrote:
| Copyleft certainly is not "source available but not free to
| use under any condition".
| d110af5ccf wrote:
| A common solution to this is dual licensing. The project gets
| open sourced under a strong copy left license (ie GPL or AGPL).
| Then you offer a commercial license for closed source usage.
|
| The downside is that this greatly complicates project
| stewardship. You can no longer accept contributions to the
| version you maintain without a CLA. Related, if someone forks
| you can no longer incorporate any of their changes unless you
| track them down and convince them to sign a CLA or otherwise
| license their changes to you.
|
| It should work well if you were already planning to do
| everything yourself. You get to sell your work while also
| allowing the open source ecosystem to benefit from it free of
| charge.
| ThrowawayR2 wrote:
| > " _Something like "public source", i.e. source available but
| not free to use under any condition may be an answer in some
| cases._"
|
| A term for this exists already:
| https://en.wikipedia.org/wiki/Source-available_software
|
| > " _For instance, an independent developer writing an
| important library should get a share of the business use
| /revenue_"
|
| No matter how much people try to avoid saying it, this is
| simply a proprietary license, albeit one that happens to
| provide source. All the downsides of a proprietary license are
| there: the user having to pay for it, having to legally
| evaluate and accept the terms of the license, and having to
| monitor for license compliance. Beyond that, the author
| themselves have to build an organization around accepting
| payments (internationally even), handling taxes on revenue,
| undertaking legal action against violators, and be bound by
| legal requirements, such as fitness for merchantability and
| export restrictions. None of these things can be avoided so
| they are now playing a game that the proprietary software
| vendors are literally structured around winning.
| jankotek wrote:
| OS author also distributes, maintains and supports project. Just
| compiling some opensource projects (Firefox, Chromium) is very
| complicated.
|
| I am not sure what happened here. But if large project would use
| outdated or broken version, author may get bombarded with support
| requests for problem, that was solved years ago.
| busterarm wrote:
| I would like to argue the direct opposite conclusion of the
| title.
|
| License, alone, governs behavior in open source. The terms and
| the guidelines of the OSD matter. If you are trying to enforce
| behavior that is counter to the guidelines of the OSD then we are
| no longer talking about open source software.
|
| Your software should then be publicly derided for abusing an open
| source license.
| mpfundstein wrote:
| completely off topic but why in gods name is he using they as a
| pronoun for Frenck who is clearly identifiable as a male...? i
| dont get it. is there some holy quest out there to just
| ungenderfy everything just for thr sake of it?
| redis_mlc wrote:
| Correct, "they" is now often used when an author hasn't
| confirmed the preferred pronoun of the author.
|
| See also:
|
| - birthing persons = moms
|
| - founding fathers = founders
|
| - amen = awomen
|
| - history = herstory
| sascha_sl wrote:
| Maybe you should be a little less presumptuous, technically
| nobody is "clearly identifiable" as anything. What you're
| applying here is a shorthand.
| mpfundstein wrote:
| look at Frencks github. if he identifies as female, ill eat
| my socks
| sascha_sl wrote:
| I don't doubt it, but not making unnecessary assumptions is
| still nice. You know, as a general rule. Also, there are
| people who are neither.
|
| (Just preempting: I'm not interested in discussing the
| validity of non-binary people, please don't write an essay
| about evil gender ideology under my comment)
| mpfundstein wrote:
| i dont care about gender stuff. i use they also if
| unknown. but using they if subject is clearly male just
| strikes me as wrong
| neilv wrote:
| I said something slightly similar once. A little weirdness was
| going on, in a niche platform community, so a while ago added a
| statement on a Web page that listed my packages for it:
|
| > _If you 'd like to put modified copies of my packages in public
| Git repos, or otherwise distribute them, I'd appreciate you
| reaching out to me. The license very intentionally gives you the
| right to modify and distribute, but [niche project] is a small
| and cooperative world right now, and it's better for everyone if
| we coordinate._
|
| One of incidents that prompted this _wasn 't_ compliant with the
| licenses, but I thought I'd leave it at the above.
|
| Back to TFA, I'm somewhat sympathetic to the developer there, not
| wanting to get support requests, etc., for problems caused by a
| packager, and this is a problem that, say, distros normally have
| to address.
|
| (And I've seen it addressed badly, such as a third-party setting
| up a bug-reporting system for my upstream packages, which gave
| the appearance of being the official way to report bugs, but... I
| didn't know about it, I didn't get notified when people made bug
| reports there, no one was handling those reports, and, when I
| eventually stumbled upon the reports, the mechanism didn't have a
| way to contact the submitter for more info. The bad mechanism was
| just sitting out there, wasting submitters' time, and sabotaging
| success of the project. Then, when I explained to the party
| running it that it was hurting the project and contributors, they
| refused to make it opt-in or let me opt-out. I think this is just
| one example of the kinds of time-suck that you see after
| contributing to open source for a while, and which might not be
| obvious to people until they've seen it or heard about it.)
|
| That said, while I think the developer in TFA is fine in saying
| that they'd prefer a package they develop not be included in some
| other thing, or perhaps explains why and asks for changes in how
| that's done to not hurt the developer's work... they have to be
| aware that, at least in US culture, their request (like mine, in
| a different situation) is orthogonal to the license, and is a
| cooperation "ask".
|
| There's some value in having terms clearly communicated (such as
| with licenses). And when you give a license, if you're going to
| ask for a restriction on what you already gave in the license,
| you're taking away some of the value of licenses.
|
| Considering this an "ask" is even more appropriate -- but not
| limited to -- cultures/subcultures that might consider "whatever
| is legal" (or "whatever you can get away with") the sole
| consideration.
| eliah-lakhin wrote:
| Why not just simply write a new type of License that would
| explicitly ban organizations and entities from using the work in
| any forms, but, in contrast, would grant large possibilities to
| use the project for individuals for free?
|
| Such approach is no doubt contradicts FOSS principals, but I
| don't see how else we can defend ourselves from the business
| exploitation these days.
|
| In addition, I would also explicitly state in such License, that
| the author preserving exclusive rights of the work. To keep an IP
| in hands of it's creator. When one keeps exclusive ownership
| rights, it could be clearer how to defend them in the legal
| field, rather than something developed by uncertain set of
| contributors.
|
| GPL and other FOSS licenses were initial designed for crowd
| development. But let's face the truth, a lot of nice software
| projects are practically developing by individuals exclusively.
| Their authors don't really require crowd contribution even for
| maintenance. Yet, society(by "society" I mean independent
| programmers and individual users, not corporations) can still
| benefit from using of their work.
|
| It's a common practice in many other fields of creativity. We
| rarely see books, visual art creations, scientific articles, etc
| made by crowd. And there are many examples of outstanding works
| made this way. And all that works are quit well defended by just
| normal Copyright laws. So, why shouldn't we, the programmers,
| avoid such obvious and well defined practice?
|
| Of course, FOSS could still be applied for large infrastructure
| things. Such as Linux maybe, or Wikimedia. Crowd development is
| beneficial in many aspects, but individual creativity is not
| crowd development. So, my point is that individual authors just
| shouldn't adopt FOSS licenses by default.
| andybak wrote:
| I develop for myself, for a loose collective, for clients and
| for my own company. I rarely know where the boundaries are
| myself. CC-NC is ambiguous enough that I avoid it. I have no
| idea how an "individual use only" license would work but I
| suspect I would give it a wide berth.
| quanticle wrote:
| The specific example at hand is that the author of python-ambee
| requested that NixOS maintainers not package their library,
| because they disagreed with the approach that NixOS was taking.
| The NixOS maintainers responded that they have the rights to do
| so under the MIT license, _and the original author agreed that
| they did so_. The original author then continued to request
| that NixOS not repackage their software, even though they
| themselves had given the NixOS packagers the right to do so (by
| selecting the MIT license for their software).
|
| I'm not sure how your solution addresses this scenario. Of
| course the author could have written a license that restricts
| redistribution to channels that meet their criteria. But they
| didn't do so. They chose to use a standard free software
| license instead. I fail to see how the creation of yet another
| non-free license would solve the scenario of the author
| understanding that they've given away certain rights via their
| license agreement, and then expecting people redistributing
| their software to voluntarily give those rights back with
| nothing in compensation.
| eliah-lakhin wrote:
| Talking about this specific case. I might be wrong here, but
| as far as I understand if the license does not state that it
| is non-revocable(which MIT doesn't explicitly state), it
| means that it could be revoked by the copyright owner.
|
| So, basically the owner can just revoke MIT license, and then
| replace it with something different.
|
| > that they've given away certain rights via their license
| agreement
|
| The license agreement normally should outline a procedure of
| revocation and termination of the license for applicants. And
| it should be a part of the agreement. This is pretty much
| normal practice in many proprietary licenses. And, in my
| opinion, is certainly morally fair considering that software
| distributed free of charge by the author.
| quanticle wrote:
| _Talking about this specific case. I might be wrong here,
| but as far as I understand if the license does not state
| that it is non-revocable(which MIT doesn 't explicitly
| state), it means that it could be revoked by the copyright
| owner._
|
| A similar case was raised with regards to the Artistic
| License in Jacobsen v. Katzer [1]. In that case, the US
| Federal Circuit held that the license could only be revoked
| unilaterally if nothing of value had been exchanged between
| the parties. The open source software was held to be
| something of value, and thus the license was held to be
| irrevocable without consent of both parties.
|
| I'm not a lawyer, but it seems to me that this ruling would
| apply equally to other licenses that don't have an explicit
| revocation clause, like the MIT license.
|
| _The license agreement normally should outline a procedure
| of revocation and termination of the license for
| applicants. And it should be a part of the agreement. This
| is pretty much normal practice in many proprietary
| licenses._
|
| Yes, that is one of the ways that proprietary licenses
| distinguish themselves from free software licenses.
| However, in this case, it seems like the author of the
| package wanted to have the benefits of a free software
| license (i.e. lots of people will use their software)
| without the downsides (i.e. people might use my software in
| ways that they don't like and don't agree with).
|
| [1]: https://scholar.google.com/scholar_case?case=177761825
| 741712...
| pessimizer wrote:
| It might be more precise to say that "licenses do not govern all
| behavior in open source." But the flip side of that
| acknowledgment should be to notice that while obedience to
| licenses is governed by force of law, all other behavior common
| open source is essentially _ungoverned_ , or governed in an
| arbitrary, self-appointed fashion.
|
| There's this tendency in permissive open source to reify "social
| norms" into their own sort of law, and then indict people based
| on the violations of them (as they are defined by the speaker.)
| Social norms are a survey of behavior, not an enforcer of
| behavior. I may not feel good going against the wishes of the
| author of a piece of software that is under a permissive license.
| If enough people feel like me, honoring that sort of request from
| an author may become a "social norm," especially if people who
| agree with me start to punish people who don't agree with me, and
| that creates a pressure for people who don't agree or are neutral
| to conform to avoid being shunned. This is where actual
| _government_ is introduced, in the people who refuse to hire,
| work with, or do business with other people.
|
| That's fine, but if you're going to use your authority and
| autonomy to enforce your arbitrary moral rules, you shouldn't be
| surprised when massive and massively powerful corporations use
| their authority and autonomy in the way they see fit. You don't
| shun Amazon, Amazon shuns you.
|
| That's why there's an advantage in encoding whatever moral stance
| you want to take into your license, and in confederating with
| others who share your beliefs (as explicitly stated in the
| license) in order to form a more powerful unit. Then the courts
| can defend you against Amazon, and a side effect will be that
| there will be even more power as a community to promulgate your
| extra-license norms.
|
| Also, well-governed GPL within a community isn't incompatible
| with secret sauce. Dual-licensing schemes give the power to
| create good businesses, through exchange of permissive
| relicenses, subsidy and mergers. We just have to be creative
| about it.
|
| If a walled-garden, curated experience can be an advantage in the
| market, there's no reason you can't create one with GPL'd
| software, cross-licensed permissively, where the authors,
| developers, marketers and salespeople get paid. Just uphold the
| philosophy that you're not going to restrict people's access to
| and ability to modify their own devices, or use incompatibility
| to create a moat between yourself and competitors. If possible,
| encode it in the permissive license. That doesn't mean that you
| have to recommend that people modify their own devices, or that
| you have to distribute code, or even make it at all easy to do.
| If people do modify their own devices or software, it doesn't
| mean that you can't void their warranty or cut them off from your
| cloud services. If you notice a player out there doing a good job
| of modifying your devices or software, bring them inside to do
| it, giving your users less reason to stray.
|
| Apple and Google built their businesses on a mix of permissive
| open source, proprietary bits, and exclusive services. The same
| can be done with a mix of GPL, relicensed GPL to permissive
| licenses with proprietary bits included, and exclusive services.
| The difference is that the GPL software commons will be built up
| during the process, and the use of that GPL software will be an
| advantage the small confederating players will have over the
| massive multinationals.
| eptcyka wrote:
| I don't believe Frenck's claim that there ever was a burden by
| nixOS users laid upon the HA community. Regardless, pulling out
| the rug from under a lot of users who will then just repackage HA
| anyway is not something a distribution would do. Once a package
| is in a repo and people rely on it, it's not easy to remove it.
| Adding to that, having a conversation and just making the same
| blunt demand without responding to honest proposals about how to
| mitigate the undisclosed issues that packaging the plugin for
| NixOS are two completely different things.
| breck wrote:
| Licenses are for losers. Any half brain can figure out from first
| principles there can be no such thing as stealing ideas, and
| ideas are not property.
|
| Time to amend the U.S Constitution and liberate ideas and people.
|
| http://www.breckyunits.com/the-intellectual-freedom-amendmen...
| vmception wrote:
| I like the direction you're thinking
| busterarm wrote:
| While we're at it, coordinated vulnerability
| disclosure/responsible disclosure is also for losers. If
| you're white hat, just publish ASAP.
|
| Full disclosure is the only way. Bug bounty programs are a
| trap.
| grayhatter wrote:
| wow, that response was needlessly cruel... I assume you're just
| having a bad day, so I hope you feel better soon mate. Good
| luck!
| breck wrote:
| Licenses are for losers. Remember that kids.
|
| If you want to do big things in this world, run with the
| SciHubs and the PirateBays and the PublicDomainers. Flip the
| bird at the academics publishing junk behind paywalls crowing
| about licenses.
|
| The ones who matter set their ideas free. Been that way for
| thousands of years.
|
| (GPL was an amazing hack, but the next step is to finish the
| job, abolish IS laws, and bury for good the idea of needing a
| license to use your mind)
| nine_k wrote:
| If all licenses are for losers, do you suppose GPL to be
| also for losers?
| breck wrote:
| Yes, IF thought of as a long term solution, and not a
| stop gap.
| jchw wrote:
| My reading of their PoV is more one against IP itself as
| a concept, and by proxy, licensing software as a concept.
| In that case, GPL is interesting since the stated goal of
| copyleft is to basically use the copyright and IP law
| system against itself.
|
| While I don't personally subscribe to IP anarchy, and I
| think that it is not being conveyed with an ideal level
| of tact, I do think it makes mostly logical sense.
|
| Deep down, from a purely ideological standpoint, most
| computer science minded people can probably understand IP
| anarchy. It's sort of the other side of the "what color
| are your bits?" post. I still think the world is better
| off with some forms of IP, even if we're all well-aware
| that the copyright and patent laws have been perverted in
| most places.
| smokey_circles wrote:
| I suspect we've forgotten what the original reason for
| intellectual property laws were and that was rampant theft.
|
| "But you can't steal an idea"
|
| The world was built by good ideas and bad implementation,
| so I guess we are gonna disagree here.
| WesolyKubeczek wrote:
| Sadly, it's another case of some software author having a prima
| donna complex.
|
| NixOS is quite a niche distribution. Of the comparatively small
| overall number of users, the number of those that are going to
| use his library, is an even smaller subset. A small subset of
| them will have a bug to report, and a smaller number of them yet
| will take it to the upstream.
|
| So the author makes a fuss about getting drowned in maybe 1.5
| people creating three requests in 5 years. Doesn't compute.
| Complaining about burnout long before you burn out?
___________________________________________________________________
(page generated 2021-06-20 23:01 UTC)