[eliah-lakhin]

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.

[quanticle]

The specific example at hand is that the author of python-ambee requested that NixOS maintainers not package their library, because they disagreed with the approach that NixOS was taking. The NixOS maintainers responded that they have the rights to do so under the MIT license, and the original author agreed that they did so. The original author then continued to request that NixOS not repackage their software, even though they themselves had given the NixOS packagers the right to do so (by selecting the MIT license for their software).

I'm not sure how your solution addresses this scenario. Of course the author could have written a license that restricts redistribution to channels that meet their criteria. But they didn't do so. They chose to use a standard free software license instead. I fail to see how the creation of yet another non-free license would solve the scenario of the author understanding that they've given away certain rights via their license agreement, and then expecting people redistributing their software to voluntarily give those rights back with nothing in compensation.

[eliah-lakhin]

Talking about this specific case. I might be wrong here, but as far as I understand if the license does not state that it is non-revocable(which MIT doesn't explicitly state), it means that it could be revoked by the copyright owner.

So, basically the owner can just revoke MIT license, and then replace it with something different.

> that they've given away certain rights via their license agreement

The license agreement normally should outline a procedure of revocation and termination of the license for applicants. And it should be a part of the agreement. This is pretty much normal practice in many proprietary licenses. And, in my opinion, is certainly morally fair considering that software distributed free of charge by the author.

[quanticle]

Talking about this specific case. I might be wrong here, but as far as I understand if the license does not state that it is non-revocable(which MIT doesn't explicitly state), it means that it could be revoked by the copyright owner.

A similar case was raised with regards to the Artistic License in Jacobsen v. Katzer [1]. In that case, the US Federal Circuit held that the license could only be revoked unilaterally if nothing of value had been exchanged between the parties. The open source software was held to be something of value, and thus the license was held to be irrevocable without consent of both parties.

I'm not a lawyer, but it seems to me that this ruling would apply equally to other licenses that don't have an explicit revocation clause, like the MIT license.

The license agreement normally should outline a procedure of revocation and termination of the license for applicants. And it should be a part of the agreement. This is pretty much normal practice in many proprietary licenses.

Yes, that is one of the ways that proprietary licenses distinguish themselves from free software licenses. However, in this case, it seems like the author of the package wanted to have the benefits of a free software license (i.e. lots of people will use their software) without the downsides (i.e. people might use my software in ways that they don't like and don't agree with).

[1]: https://scholar.google.com/scholar_case?case=177761825741712...

[andybak]

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.