Licenses alone do not govern behavior in open source
michaelweinberg.org
michaelweinberg.org
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'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.
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.
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.
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.
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.
(Sorry, but of a bugbear with the ‘code is law’ crowd…)
(but yes this is mostly a pun and the code is law people are dangerously self-blindfolded)
The complexity of moral issues is that they are hard to define. And lawyers hated it.
So the only way to solve this problem would be to use the Open Source License that please you with its worst possible usage scenario.
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.
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
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.
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.
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.
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.
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…
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.
For end-user applications it makes no difference.
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.
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.
Yes, it's the case that open source isn't and can't be a business model in itself
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
Somewhat similar to Unreal Engine Model?
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...
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.
That just makes the situation even worse; it would be painted (with some justification) as wrecking the Swedish domestic software industry.
"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.
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.
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.
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.
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.
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.
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.
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.
[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#issuecomment-86...
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.
That is just a lie and not what happened.
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.
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 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?
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.
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
https://www.libreoffice.org/get-help/professional-support/
Probably there are companies for the other projects you name, or contracting random developers would work.
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/
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.
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?
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.
His day job must suck, yeah.
> 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.
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?
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.
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
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.
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.
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.
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.
> 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.
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.)
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).
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.
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.
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.
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=177761825741712...
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…
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.
my answer is a good one, he released open source with a license, their fork would not generate work for him which was his main concern.
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
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.
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...
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.
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 _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.
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.
Under what legal theory would moral rights be relevant?
Time to amend the U.S Constitution and liberate ideas and people.
http://www.breckyunits.com/the-intellectual-freedom-amendmen...
Full disclosure is the only way. Bug bounty programs are a trap.
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)
"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.
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.