Voting the license move BSD -> LGPL

[Anton-Latukha]

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 is a small step way from marginal idealism of BSD license into realism.
• LGPL gives HNix legal compatibility with Nix - is a huge point and one of the main circumstances - details are uncovered in Legal situation.
• LGPL, just as in Nix case is compatible and permissive for building proprietary business products on top of it.
• Saves the processes from BSD-enabled diversion into a competition of incompatible forks cluster ... Saves from BSD diffusion of efforts. Helps to focus efforts & helps to communicate across the forks.
• Saves both project & community from incompatible secret platform-locked fork winning the BSD race, because of some IT giant with unlimited resources. Those resources are better to be spent on the project, on community development for mutual good to people.
• HNix already has a pretty wide bandwidth of highly skilled people with rights to maintain & merge.
• LGPL saturates the project community & processes so it stays alive & healthy.

• LGPL establishes minimal information & communication process.

  • Patches give information on where and how the project is used. This is important to develop a project, since when there is no information, like currently - the absence of information creates analysis paralysis. The project needs to know its use application & userbase, to be able to prioritize. For example, I heard of some sporadic use/tryout of HNix in some companies, but that is all I know. LGPL would provide more information.
  • If someone uses/deploys HNix on a massive scale - with LGPL - HNix at least would get some sort of notification on it.
  • LGPL helps to establish relationships & collaboration with companies that use the project.
  • Gives the ability for contributors to come, work in the project, get known for their work and meet people from companies and know what companies use the project, which can help them. With this process, contributors can easier get hired & paid for their work & skills.
• LGPL establishes some minimal collaboration rules.
  • It prevents secret proprietary forks, under LGPL they would need to share the code so the public can benefit.
  • Allows moving the question of the morality of immoral secret deployments into the law space. Since if the secret massive immoral project is taking place - then they almost certainly violated LGPL doing that - giving the project an ability to speak, make statements & even have legal process.
  • The fork divergence at least gives notification, people at least meet, have some coordination, and build mutual appreciation. Incompatible forks are Ok, as far as projects at least discuss it, then they can do basic coordination and also know mutual conceptualizations which lead/develop in nearby variations.
  • LGPL establishes HNix as a stable community. We already have a large bandwidth of adequate people with the rights to merge to projects. Better we take actions to prepare to protect this situation, to keep the process democratic.

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.

[Anton-Latukha]

Asking recently active: @layus, @expipiplus1, @sorki, @sjakobi.

Asking initial: @jwiegley, @ryantrinkle, @kmicklas, @mightybyte, @bennofs, @domenkozar.

[expipiplus1]

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.

[domenkozar]

I support this.

[bennofs]

I'm okay with this.

[sorki]

Sounds good to me and thanks for the nice write-up.

[jwiegley]

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.

[Ericson2314]

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.

[Anton-Latukha]

Answering, (sort-of), why legal "rule of thumb" is >50% major vote, why not 100%

https://github.com/haskell-nix/hnix/issues/919#issuecomment-830571216 > > 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. The problem can be reformulated as: "How is it possible to do diplomatic/any decision process when some people who contribute to the contry/community do not agree with diplomatic action." 100% view yields complete paralysis. In practice, something was neede to solve that paralisys situation, that is why legally major vote is used as baseline concept. For example, in governmental procedures the quorum and amounts are more determined for all actions, in military actions, stakeholders in the business - correspond to a particular majority vote, but IT Open Source is still not fully formed procedures & legal grounds. Most relicensing happens by a major vote: https://en.wikipedia.org/wiki/Software_relicensing. In studying relicensing question, saw info on a lot of different migrations, not aware of examples of big projects doing 100% migration, that is ideal to strive to or to say it is an idealistic view, but from information seen that practically the major vote holds enough legal power. The process should respect the code author's opinions. If someone would request to actively withdraw their contributions, would understand that and would need to manage that. But, obviously, would mention that feels like a kind of a trick to do, because post factum it is an easy thing. We do not need to go far. For example - Nix relicensed (GPL -> LGPL), and Nixpkgs. Of course, for things like Nixpkgs, it is hard to find proper all embodying license. People here participated in Nixpkgs relicensed when it was had ~800 contributors. Of course, some of 800 people were not reached. BTW forgot what license it was, currently do not even know what Nixpkgs license is, probably the implicit one, but that is an understandable compromise and a tangent. Otherwise, if people go for 100% view - public projects would be set in stone and no public project would be able to adapt to anything. For example, we even can go further & ask, does the programmer taken all agreements to all changes of code of the other programmers? For example, also, the view does not put what to do with [thanatosensitivity](https://en.wikipedia.org/wiki/Thanatosensitivity), if someone who contributed the code, sorry for my English, groaks, it is hard to deliver letters to the other side of the grass & even if reached - it is hard to receive a legally interpretable response. That requirement would stasis any public projects forever, public works wouldn't be able to adapt to anything. Even external de jure processes & laws change by major vote & some compromise processes. To say, the view itself kills off own projects in the long run. That is why legally it is not possible nor reasonable to construct such laws. And the law writing & courts tend to conceptually operate not on literary readings/execution, but the realism understanding & morality just as well. As said, the relicensing procedures are not fully legally normalized/formalized, yet, but from practical uses, information read counting legal advice - it would not be 100% view because of its impossibility to get realized on many fronts, it would be a grade of a major vote, just as in all other comparable areas and other legal processes would be added to it, as to in Linux Kernel. So that processes from being seen as separate parts to be able to transcend to be a public process. We believe we talk in the context of US law, but I live in UA personally, so all this, in reality, is pretty vague, humanitarian, and on good terms. `>50%` is what makes voting decisions legally liable, it is what used in practice by majority of the projects. But the more & more careful the better.

[Anton-Latukha]

Replying to hard linking & dynamic linking in the scope of LGPL

https://github.com/haskell-nix/hnix/issues/919#issuecomment-831001389 > 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. Such tecnical questions are not how law operates. Derivative work is viewed regardless of them. The same code can be compiled both as dynamic- and as hard-linked, that binary compilation detail does not turn work form legality from normal to suddenly a derivative work. If linkage was a factor then dynamically linked code also has a table that links to the library anyway also. When LGPL is the weakest well-known license we have & it was created clearly with a purpose to support libraries and it has a more precise definition of linkage and derivative work. If one uses HNix library as a package - that is undoubtedly the right use. Reading in-depth the info on the question - it currently seems that linkage in precisely GPL-license case is still a grey area, as in GPL-v3 it is still stated vaguely and broadly.(http://mediatechlaw.mstreetlegal.com/2014/04/25/open-source-dynamic-linking-and-licensing-consideration-for-developers/) Texts mention LGPL being understandable and concentrate on GPL, while [page 12 last paragraph](https://openaccess.city.ac.uk/id/eprint/12602/1/McDonagh%20-%20FOSS.pdf) mentions: > Works statically linking to the Library fall out of the scope of the LGPL until they are compiled with the ‘Library’. As far as I read lawyer advice on those questions, type of software linking was explained to be completely a technical details question, that is irrelevant to legality and not reviewed in the court. In other words, the legal definitions of what is modification & "derivative work" are not connected in any with how compilation happens. I have IT&OS lawyer as a friend, thou as professional they bear responsibility for any advice given, so paid contract is needed to correspond with him, and I do not have those resources. +==== That is also why LGPL-v3.0+. Since looking at the processes zeitgeist: * cloud & Free Software; * relicenses of a lot of known projects; * interaction of proprietary & open project models; * so far there was just a handful of FSF protection cases; * but since the activity, soon there would be more cases to both sides, and since US law is precedential, that is where the legal reading would be established/standardized. * Also note that FSF took the opportunity to dethrone RMS & in that time talked to be more supportive of the businesses, service creation, money-earning. It seems FSF actively works to give strictly defined licenses & their use. In other words LGPL suits for library use, and next versions probably would clear out the safety fears. And the `+` of the licance allows to normalize the work in the project now & in meantime of development & bussiness interest - to switch to next generations of license introduced, that would clear-out the grey areas so Library license can be used as one.

[Ericson2314]

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.

[jwiegley]

@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?

[Ericson2314]

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.

[layus]

Hi, I am open to any change in license, and I have little understanding of the stakes at hold :confused: .

[mightybyte]

I am also not interested in using or contributing to an hnix fork licensed under LGPL.

[Anton-Latukha]

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.

[Anton-Latukha]

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.