I’m not naive; a license is as effective as pissing in the wind if you don’t have the means to enforce it. Still, any recommendation on licenses to make it as difficult as possible for people like Palmer Luckey or dtolnay to benefit from it, in general??
Permissive is good, I don’t care whether it matches a libertarian definition of “open”.
Nobel Laureate economist #Angus#Deaton has delivered a ferocious rebuke to his own profession, saying economists have failed to understand that ⭐️capitalism is about power.⭐️
Deaton lobs a series of truth bombs at his own profession, the result, he says, of “changing my mind, a discomfiting process for someone who has been a practising economist for more than half a century”.
These include:
🔸“We have largely stopped thinking about #ethics and about what constitutes human #well-#being”.
🔸If “economists should focus on efficiency and leave equity to others, to politicians or administrators… 🔹the others regularly fail to materialise🔹, so that when efficiency comes with upward redistribution
— frequently though not inevitably
— our recommendations become little more than a #license for #plunder”.
🔸“#Historians, who understand about contingency and about multiple and multidirectional causality, often do a better job than economists of identifying important mechanisms…”
🔸Far from being “a nuisance that interfered with economic (and often personal) efficiency”, #unions “once raised wages for members and nonmembers, they were an important part of social capital in many places, and they brought political power to working people in the workplace and in local, state, and federal governments.
🔸Their decline is contributing to the falling wage share, to the widening #gap between executives and workers, to community #destruction, and to rising #populism.”
🔸“I am much more sceptical of the benefits of free trade to American workers and am even sceptical of the claim, which I and others have made in the past, that globalisation was responsible for the vast reduction in global poverty over the past 30 years”.
🔸Immigration contributes to inequality.
But Deaton’s main point is a recognition of how #power distorts #policy:
“Our emphasis on the virtues of free, competitive markets and exogenous technical change can distract us from the importance of power in setting prices and wages, in choosing the direction of technical change, and in influencing politics to change the rules of the game.”
How is this very post licensed and how would you know? Do #Mastodon instances dictate a #license on users posts? Is there a way for me, the #author, to assign one and pass the information through the #fediverse? Do I give away my #copyright in the moment, I press on "Publish!" below? (Or press C-c C-c in #Emacs#mastodonEl?) Can I limit #distribution e.g. to notforprofit entities? (Not that I wanted to. At least not now.)
The #FOSDEM fringe event #FOSS#license and #security#compliance tools yesterday was great! The room was filled with energy and knowledge and the willingness to improve things. Many concrete ideas to follow up on. #SBOM all the things!
❝Today, thanks to Android and ChromeOS, Linux is an important end-user operating system. But, before Linux, there were important Unix desktops, although most of them never made it. …❞
I don't understand Wikipedia's article Comparison of machine translation applications. Under "license" a lot of them just says SaaS. But Software as a service is not a license, it's a business modell or mode of distribution, right? It could be free with the AGPL license, for example, or proprietary. Both can be SaaS, that doesn't tell you anything about their license?
How is the #AntiCapitalist Software #License different from other licenses?
Most existing licenses, including free and open source licenses, consider qualities like source code availability, ease of use, commercialization, and attribution, none of which speak directly to the conditions under which the software is written.
The ACSL considers the organization licensing the software, how they operate in the world, and how the people involved relate to one another." https://anticapitalist.software
Even if you’re a developer with legal leanings like me, you probably haven’t given much thought to the warranty disclaimer and the liability disclaimer that appears in almost every Open Source licence (see sections 14 and 15 of GPLv3). This post is designed to help you understand what they are, why they’re there and why we might need stronger defences in future thanks to a changing legal landscape.
History: Why no Warranty or Liability
It seems obvious that when considered in terms of what downstream gets from Open Source that an open ended obligation on behalf of upstream to fix your problems isn’t one of them because it wouldn’t be sustainable. Effectively the no warranty clause is notice that since you’re getting the code for free it comes with absolutely no obligations on developers: if it breaks, you get to fix it. This is why no warranty clauses have been present since the history of Open Source (and Free Software: GPLv1 included this). There’s also a historical commercial reason for this as well. Before the explosion of Open Source business models in the last decade, the Free Software Foundation (FSF) considered paid support for otherwise unsupported no warranty Open Source software to be the standard business model for making money on Open Source. Based on this, Cygnus Support (later Cygnus Solutions – Earliest web archive capture 1997) was started in 1989 with a business model of providing paid support and bespoke development for the compiler and toolchain.
Before 2000 most public opinion (when it thought about Open Source at all) was happy with this, because Open Source was seen by and large as the uncommercialized offerings of random groups of hackers. Even the largest Open Source project, the Linux kernel, was seen as the scrappy volunteer upstart challenging both Microsoft and the proprietary UNIXs for control of the Data Centre. On the back of this, distributions (Red Hat, SUSE, etc.) arose to commericallize support offerings around Linux to further its competition with UNIX and Windows and push it to win the war for the Data Centre (and later the Cloud).
The Rise of The Foundations: Public Perception Changes
The heyday explosion of volunteer Open Source happened in the first decade of the new Millennium. But volunteer Open Source also became a victim of this success: the more it penetrated industry, the greater control of the end product industry wanted. And, whenever there’s a Business Need, something always arises to fulfill it: the Foundation Model for exerting influence in exchange for cash. The model is fairly simple: interested parties form a foundation (or more likely go to a Foundation forming entity like the Linux Foundation). They get seats on the governing board, usually in proportion to their annual expenditure on the foundation and the foundation sets up a notionally independent Technical Oversight Body staffed by developers which is still somewhat beholden to the board and its financial interests. The net result is rising commercial franchise in Open Source.
The point of the above isn’t to say whether this commercial influence is good or bad, it’s to say that the rise of the Foundations have changed the public perception of Open Source. No longer is Open Source seen as the home of scrappy volunteers battling for technological innovation against entrenched commercial interests, now Open Source is seen as one more development tool of the tech industry. This change in attitude is pretty profound because now when a problem is found in Open Source, the public has no real hesitation in assuming the tech industry in general should be responsible; the perception that the no warranty clause protects innocent individual developers is supplanted by the perception that it’s simply one more tool big tech deploys to evade liability for the problems it creates. Some Open Source developers have inadvertently supported this notion by publicly demanding to be paid for working on their projects, often in the name of sustainability. Again, none of this is necessarily wrong but it furthers the public perception that Open Source developers are participating in a commercial not a volunteer enterprise.
Liability via Fiduciary Duty: The Bitcoin Case
An ongoing case in the UK courts (BL-2021-000313) between Tulip Trading and various bitcoin developers centers around the disputed ownership of about US$4bn in bitcoin. Essentially Tulip contends that it lost access to the bitcoins due to a computer hack but says that the bitcoin developers have a fiduciary duty to it to alter the blockchain code to recover its lost bitcoins. The unusual feature of this case is that Tulip sued the developers of the bitcoin code not the operators of the bitcoin network. (it’s rather like the Bank losing your money and then you trying to sue the Mint for recovery). The reason for this is that all the operators (the miners) use the same code base for the same blockchain and thus could rightly claim that it’s technologically impossible for them to recover the lost bitcoin, because that would necessitate a change to the fundamental blockchain code which only the developers control. The suit was initially lost by Tulip on the grounds of the no liability disclaimer, but reinstated by the UK appeal court which showed considerable interest in the idea that developers could pick up fiduciary liability in some cases, even though the suit may eventually get dismissed on the grounds that Tulip can’t prove it ever owned the US$4bn in bitcoins in the first place.
Why does all this matter? Well, even if this case resolves successfully, thanks to the appeal court ruling, the door is still open to others with less shady claims that they’ve suffered an injury due to some coding issue that gives developers fiduciary liability to them. The no warranty disclaimer is already judged not to be sufficient to prevent this, so the cracks are starting to appear in it as a defence against all liability claims.
The EU Cyber Resilience Act: Legally Piercing No Warranty Clauses
The EU Cyber Resilience Act (CRA) at its heart provides a fiduciary duty of care on all “digital components” incorporated into products or software offered on the EU market to adhere to prescribed cybersecurity requirements and an obligation to provide duty of care for these requirements over the whole lifecycle of such products or software. Essentially this is developer liability, notwithstanding any no warranty clauses, writ large. To be fair, there is currently a carve out for “noncommercial” Open Source but, as I pointed out above, most Open Source today is commercial and wouldn’t actually benefit from this. I’m not proposing to give a detailed analysis (many people have already done this and your favourite search engine will turn up dozens without even trying) I just want to note that this is a legislative act designed to pierce the no warranty clauses Open Source has relied on for so long.
EU CRA Politics: Why is this Popular?
Politicians don’t set out to effectively override licensing terms and contract law unless there’s a significant popularity upside and, if you actually canvas the general public, there is: People are tired of endless cybersecurity breaches compromising their private information, or even their bank accounts, and want someone to be held responsible. Making corporations pay for breaches that damage individuals is enormously popular (and not just in the EU). After all big Tech profits enormously from this, so big Tech should pay for the clean up when things go wrong.
Unfortunately, self serving arguments that this will place undue burdens on Foundations funded by starving corporations rather undermine the same arguments on behalf of individual developers. To the public at large such arguments merely serve to reinforce the idea that big Tech has been getting away with too much for too long. Trying to separate individual developer Open Source from corporate Open Source is too subtle a concept to introduce now, particularly when we, and the general public, have bought into the idea that they’re the same thing for so long.
So what should we do about this?
It’s clear that even if a massive (and expensive) lobbying effort succeeds in blunting the effect of the CRA on Open Source this time around, there will always be a next time because of the public desire for accountability for and their safety guarantees in cybersecurity practices. It is also clear that individual developer Open Source has to make common cause with commercial Open Source to solve this issue. Even though individuals hate being seen as synonymous with corporations, one of the true distinctions between Open Source and Free Software has always been the ability to make common cause over smaller goals rather than bigger philosophies and aspirations; so this is definitely a goal we can make a common cause over. This common cause means the eventual solution must apply to individual and commercial Open Source equally. And, since we’ve already lost the perception war, it will have to be something more legally based.
Indemnification: the Legal solution to Developer Liability
Indemnification means one party, in particular circumstances, agreeing to be on the hook for the legal responsibilities of another party. This is actually a well known way not of avoiding liability but transferring it to where it belongs. As such, it’s easily sellable in the court of public opinion: we’re not looking to avoid liability, merely trying to make sure it lands on those who are making all the money from the code.
The best mechanism for transmitting this is obviously the Licence and, ironically, a licence already exists with developer indemnity clauses: Apache-2 (clause 9). Unfortunately, the Apache-2 clause only attaches to an entity offering support for a fee, which doesn’t quite cover the intention of the CRA, which is for anyone offering a product in the EU market (whether free or for sale) should be responsible for its cybersecurity lifecycle, whether they offer support or not. However, it does provide a roadmap for what such a clause would look like:
If you choose to offer this work in whole or part as a component or product in a jurisdiction requiring lifecycle duty of care you agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your actions in such a jurisdiction.
Probably the wording would need some tweaking by an actual lawyer, but you get the idea.
Applying Indemnity to existing Licences
Obviously for a new project, the above clause can simply be added to the licence but for any existing project, since the clause is compatible with the standard no-warranty statements, it can be added after the fact without interfering with the existing operation of the licence or needing buy in from current copyright holders (there is an argument that this would represent an additional restriction within the meaning of GPL, but I addressed that here). This makes it very easy to add by anyone offering, for instance, a download over Github or Gitlab that could be incorporated by someone into a product in the EU.
Conclusion
Thanks to public perception, the issue of developer liability isn’t going to go away and lobbying will not forestall the issue forever, so a robust indemnity defence needs to be incorporated into Open Source licences so that Liability is seen to be accepted where it can best be served (by the people or corporation utilizing the code).
Open source licences are one of those cans of worms I mostly try to avoid. Except it really annoys me when I want to borrow some code and I can't work out what the licence is.
If you're writing sample code or something small, you should include a #licence. However which to use? One of the *BSD or MIT licences is usually a good choice (but be careful which version!), they place minimal requirements on you. However the requirement to include a copyright notice is just annoying for everyone involved (when the code is small). Android Toybox (https://en.wikipedia.org/wiki/Toybox) solved this with the Zero-clause BSD licence (aka #0BSD); it is a modification of the ISC license, not a BSD one, but the name doesn't matter really.
While 0BSD may not be perfect, I believe it (or MIT-0, which is nearly identical) achieves the best balance of all the "do what you want" licences. I'm mainly talking about "small" pieces of code here; for larger projects it's understandable the licence choice is more nuanced and you may want Apache, #GPL, etc. This is not legal advice. Talk to a lawyer if in doubt.
I don’t know what to think about it. Yes, it’s incredibly hard to create a business and a market when making everything open source. I’m not familiar with this new license and I don’t know if that’s a valid move or not.
Good&Evil is a classic altrock album by Tally Hall, and now, for something completely different, JSON
How should LICENSE relationships be?
Hello,...