Closed Anton-Latukha closed 3 years ago
Asking recently active: @layus, @expipiplus1, @sorki, @sjakobi.
Asking initial: @jwiegley, @ryantrinkle, @kmicklas, @mightybyte, @bennofs, @domenkozar.
To change the license, we need to get >50% of the agreement in contributors.
Are you sure you don't need to get the consent of everyone whose code is to be relicensed?
FWIW I don't mind my contributions being relicensed to any OS license.
I support this.
I'm okay with this.
Sounds good to me and thanks for the nice write-up.
I do not like the LGPL license, and it would make hnix unusable to me in any of my professional contexts (should I ever choose to do so), since my employers forbid the use of LGPL licensed material.
I believe in freedom for both users AND contributors, and I chose BSD because it supports the widest range of contribution and use.
While I like the spirit of the LGPL I am worried that abiding by it with a non-LGPL downstream means disabling all inlining / not including any unfoldings in addition to dynamic linking. That can be a little tricky and cause annoying performance problems that cannot be solved without breaking modularity.
Oh hmm https://www.gnu.org/licenses/lgpl-3.0.en.html is a much shorter and simpler addendum than v2, and the section "Object Code Incorporating Material from Library Header Files." seems pretty clear that templates of any size are fine with attribution and a license copy. I no longer see a problem with cross module inlining as the unfolding in the hi
file is pretty darn close to a C++ template in a header.
@Anton-Latukha The beauty of open source is that you can do as you wish. Those, like myself, who cannot use hnix in LGPL form will then need to switch to a permanent fork and use that for our projects. So really, the question is whether this change will have real benefits for you as an active maintainer of this repository. Will it increase the number of contributors? The number of users? Its use by other projects? If the answer to those questions is a resounding yes, then you should switch for the sake of the project's future. But if not, it's worth asking why we should consider a switch at all. What is the motivation?
Yeah while I am no longer worried about the linking and inlining, loosing @jwiegley (edit and @mightybyte) to a fork would be a huge bummer.
Hi, I am open to any change in license, and I have little understanding of the stakes at hold :confused: .
I am also not interested in using or contributing to an hnix fork licensed under LGPL.
Ok. Sorry, I became seeing that in the landscape, maybe a BSD license is paradoxically a strong point, also it would be aggressive to treat John's response as an equal part of a numerical sequence. After a live discussion currently I lost interest in license change. Anyone can pursue it if they want.
Also due to the existence of Nix as an LGPL boundary.
Nixpkgs migrated back in a day to MIT license: https://github.com/NixOS/nixpkgs/blob/master/COPYING
& Nixpkgs license would stay constant, and Nixpkgs going to always be. & at the same time, it is and going to always be a strong structural axis of all tooling & systems, so all Nix tooling nevertheless has an implicit requirement to converge onto Nixpkgs, in that & presence of Nix as LGPL - it is possible to use a counterpoint to draw some strongpoints from the current license. Can be said Nixpkgs gives LGPL property to HNix for free (well, a relaxed one), while keeping current ones, but nevertheless would note - it is only due to the external environment.
But if no one changes license now - later it would be increasingly impossible, so we are making an end decigion now.
Proposing to switch to LGPL-v3.0+, to be legally compatible & comply with Nix (LGPL-v2.1+) requirements.
BSD license shortcomings in the current context
When I hear the comparison of freedom to a beer, I cringe. To put more properly: BSD license view of freedom is a marginal-anarchistic "free as in chaos, we don't care, everything allowed & let the strongest wins, we limit own liability here".
But that has a severe hidden problem. Freedom that does not protect itself is not freedom. Which wants freedom but does not care to keep it - is like a body that does not want immunity.
We are not living in idealo-simplistic world where only order exists, chaos exists just as well if we believe in Gödel's incompleteness theorems.
BSD license - by itself allows all kinds of chaos, harm & exploitation being done to the project, community & processes.
When the project is of interest to strong 3rd parties and being weak itself, BSD license - invites trouble to the project.
BSD would've been great in a world where there no aggressiveness. But the world is not just butterflies.
Aggressiveness is the elimination of freedoms. Management of freedoms is the essence of all strategies. Aggressive entities search those who do not protect freedoms & establish their regime. Kyiv, Ukraine, has quite a large body of scientific evidence, called history. Let's note for example a fact that the word "slave" is formed from "Slav". Secondly, slavery in Eastern Europe currently paused after 1974 USSR passport reform implemented in 1976. In Ukrainian history numerous times it was paid in blood with millions of people because the majority of people do not protect freedoms. It induces/ed all kinds of vicious circles. That is why I can’t understand the "free as in beer" phrase. & The projects are just small countries.
HNix, GHC, or Nix - are different "countries", and have different contexts.
That the freedoms should be protected, is well established: from tao/Heraclitus unity of opposites, the concept of "State of nature", Simone de Beauvoir's "Ethics of ambiguity" [1] [2] is the main work, Erich Fromm [1].
BSD license gives all freedoms to unknown 3rd parties, and in doing that - restricts & complicates processes of itself, of own work & project. BSD license tips over the balance to 3rd parties. There is an argument that by giving out freedom you never run out of it. Really? By giving everyone freedom to do with oneself anything? Where to start, there are numerous variants. Under any pressure, BSD license result is that HNix community & maintainers get severely limited in making decisions, by the private businesses entities. Since project decisions now need to be made to "somehow preserve collaborative process with business parties that are interested & permitted to own the product & compete". In that way, 3rd parties would always have collaboration as a hostage, when they received everything for free. Under the BSD license, the maintainers & volunteers get pressure from the community to work for free to support specifically incompatible forks and work for free more just because community can choose diverged fork. Most people are Ok to switch to more closed projects with proprietary licenses or control. In HNix case when business incentives arrive BSD license brings just moral exploitation to maintainers, which become slaves to own moral responsibly & to what 3rd party businesses nearby do and pull the strings.
Under the DevOps-Cloud pressure. IT giants are known to care only about cloud profits. They do not care about HNix as a project nor about proper open & democratic community and freedoms. "If they do not respect them itself" (as "themselves legally permitted this").
BSD license lives no incentive for big business giants to collaborate with one another or the team of a project. Since the difference in size & resources - the community team management of a project is seen as just an obstacle towards doing what they want, the main aim is always - in seizing the market for profits. And Nix IT ecosystem is a market, cloud market.
Since BSD license does not encourage collaboration, and allows all competitive games - game would fall quick from collaboration into much less efficient competitive games which due to complete lack of rules would be utterly destructive, creating a cluster ... of incompatible forks (a situation that in itself implodes on itself, tanking all the cluster at once), diffusing the efforts, requiring more work per project because of multiplication of efforts, multiplying the requirements to support the fork cluster, & stopping the collaborations, if not because the fork is "to diverge", on diverge - incompatibility & so the competition.
The outcome of such BSD game can be predicted. It is like if one sits at the table and starts to play a chess game. But with the IT giant, the most powerful rich monopolistic entity. Player 1 has oneself & 16 standard pieces, all it does, moves, processes, is seen, since its play is possible only in the open. Player 2 has infinite resources, on influence, advertising, lawyers. It also as wishes has an infinite supply of chess pieces to put on the board. Adversary chess pieces are not seen as they are completely in darkness by the protection of the proprietary license (BSD license allows to just relicense into any license), the judge permitted "business secret" so the opponent is cloaked with darkness. Opponent pieces give a closed source code under Omertà-like NDA. Since you do not know where the opponent pieces are and what pieces are - the chessboard is covered in darkness overall. If in that game maintainers of a project say "it is atrocious" & flip the table and walk away - the adversary won the game. If the first player continues to play - the adversary wins by just repeating "hardcode the features" - which has a side effect of attracting the audience & giving more profit to the business & the audience applying more pressure on Player 1. In economic terms that set of things has a name of aggressive "Adverse selection". BSD license allows any amount of adverse selection & exploitation of itself done towards itself. LGPL at least curbs that exploitation enthusiasm a bit. In HNix case with a BSD license, under pressure & forks - has an outcome that already most rich, by not collaborating in any way, just wins, now in this field also, & owns the product & the process. In the HNix case, the "BSD license outcome" is measured in the degrees of non-independent, non-openness, non-collaborative, non-democratic, hardcoded privately owned result. This is what induced the request to change the license, & to have the motivation to continue the work.
Personally, do not want to take any part in any side of the Tanenbaum MINIX BSD Intel CPUs-like stories. Those stories define abusive relationships.
Personally, do not want to contribute the most valuable in a lifetime: life, time & effort - as a gift of the poor man in a trap to a random powerful rich victim-blaming entities that would profit from it. That does not smell right. Companies are made more powerful and have more rights and their rights are more privileged than the people. BSD license is very exploitable. While a majority of those exploits can be prevented by a tiny move now. I want to protect the freedoms, team structure & processes we have, to be able to continue to grow the processes.
LGPL license strongpoints in HNix case
LGPL establishes minimal information & communication process.
Legal situation
Current state of HNix & due to Nix license also seems to yield the need to being licensed GPL-like.
:wink: There may be places where HNix inside may have some use of Nix as a source code which then seems to legally require HNix to be licensed GPL-alike. :wink:
Creator of Nix holds other legal rights also, he has a Ph.D. written on the topic. As an inventor of Nix - he may/should have some patents on the technology, LGPL grants patent use rights. BSD license does not grant patent use. I know a thing or two about licensing, but when Nix license gives patents use, but HNix uses the BSD license, especially in the current situation - I do not know what happens under the BSD license, with patent use requirements, but as BSD license for sure, not passes-through from the Nix the patents use legality to the HNix users. Those are nuanced legal questions outcomes of which vary on the country.
Proposing BSD -> LGPL because of the number of beneficial factors that LGPL brings to Haskell-Nix while also legally protects the available freedoms of the project.
Thank you all, palls, for collaboration in the project and for taking a look at this.
To change the license, we need to get >50% of the agreement in contributors.