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)
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.
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.
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.
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.
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.
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.
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…)
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.
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.
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?
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.
> 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
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?
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.
> 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.
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.
> 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".
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.
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.
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.
Which would be fully served under a "public license" too! As I wrote earlier, users should be able to distribute their own modifications as they wish, provided the end user abides to the original license (including when required a payment).
In origin stories, RMS never mentioned access to the software had to be free (as in beer) or that everybody else should get it for free too.
"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.
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.
> 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.
> "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.
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.
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.
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.
"We are going to tax Microsoft, Apple an Google for using Open Source software created by Swedish developers and pay money collected to those developers"
as "wrecking the Swedish domestic software industry"?
I would say it would make more Swedish people interested in writing software and getting back value that BigCorps are stealing from Sweden.
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.
Daniel is doing quite well I believe as he manages to get some money from corporations. I gave him as an example of ubiquitous code used by huge corporations, mostly without paying for it.
So don't fixate on single person, take look from a perspective.
What is the article about?
It is about contributor that does not want his code to be included somewhere and licensing does not work for him.
So earning money on OSS is also not *simply solved* by dual licensing GPL/commercial. There are multiple reasons why not.
Corporations or companies can't just simply pay some random dude from the internet and often they will just not even think about it. But they can simply use OSS code as easy as downloading it form github.
Running a company to chase those corporations down, well that is not something you want to spend time on.
Setting up legal entity for most projects will not even make financial sense.
That levy fixes that and fixes problem of setting a company by OSS contributors as they would be paid just like artists in "levy" scheme.
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.
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.
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.
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.
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.
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).
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).
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.
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.
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.
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].
> 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.
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.
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.
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".
> 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.
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?
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.
I should have been clearer - in my head I meant software that is specific to government - so I want to see FOSS versions of building licensing applications, or road maintenance gazetteers, or databases of voters, or fleet management applications for refuse collectionnlorries or ...
There is a world of software (usually 50% of GDP) that only gets spent by government - it should be free (libre) and it needs creating, distributing and supporting
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:
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.
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.
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?
> Complaining about burnout long before you burn out?
One issue that many of us face in OSS is that it's a side project. If a developer is burnt out by their day job, or some other aspect of life, then their tolerance for pushy maintaners drops to zero even if they still occasionally unwind by working on the project.
As far as I can see, it's his job and not a side project anymore. His LinkedIn lists him as full time developer on HomeAssistant, and elsewhere I've heard Nabu Casa is sponsoring him.
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.
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.
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!
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.
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.
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.
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.
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.)
"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.
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.
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.
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.
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.
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.)
> If users experiencing issues with [the package], they will knock on my door. And I’m not willing to support that or accept that burden.
It is one reason (not the only reason) why I prefer licensing that does not require attribution. Unfortunately, all licensing (other than public domain equivalents) seems to require attribution.
The warranty disclaimer is also important for this reason too. You can still accept bug reports and questions and that stuff, although doing so should not be required. You should not necessarily expect the author of any computer program (open source or not) to accept such questions and reports; it is up to them to do so (and may charge money to do so, or it may be free of charge).
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.
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.
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.
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).
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.
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…
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.
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)
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
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.
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.
"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.
- 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...
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.
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.
>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?
> 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.
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.
> 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?
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)
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.
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)