Let them eat free fake
January 13, 2022 9:34 PM   Subscribe

Dev corrupts NPM libs 'colors' and 'faker' breaking thousands of apps Developer of open source projects “colors” and “faker” decides to brick his own projects . GitHub has reportedly suspended the developer's account.

Developer Marak sees it as a “ retaliation—against mega-corporations and commercial consumers of open-source projects who extensively rely on cost-free and community-powered software but do not, according to the developer, give back to the community.”
posted by beesbees (134 comments total) 18 users marked this as a favorite
 
Given the last time he was in the news, at least it wasn't actual bombs?
posted by pan at 9:58 PM on January 13 [3 favorites]


Did he only break these libraries for mega corporations? No? Huh.
posted by axiom at 10:03 PM on January 13 [8 favorites]


Link seems busted at the moment, so here it is on archive.fo.
posted by dumbland at 10:17 PM on January 13


I didn’t know he had been in the news prior to this New York man arrested after apartment fire; explosive materials found
posted by beesbees at 10:24 PM on January 13 [3 favorites]


There is some valid beef that Marak bringing visibility to. He is fed up with the divide between OSS workers and creators and businesses that use the work products with no reciprocation.

He also may be suffering from mental health issues, I don't know if these are chronic, acute, etc. No doubt there will be links to an episode that involved a miniMcVeigh explosives situation in his not-isolated home.

Marak has weaponized his code, in a sense - using (and exposing) the delivery vectors that a whole lot of the industry depends on. Many of these downstream projects grab the latest and greatest of all their dependencies, and these pipelines dutifully deploy the boobytrapped code.

But AFAIK these acts are all silly and fixable, and are not architected to grant backdoor access or melt servers. But he has been breaking projects that a lot of downstream products use, and projects where he is not the sole contributor, and booting people with merge permissions I think, which is not great.
It has been interesting to see npm and github react: in one sense this is a malware attack, in another, a repo owner pushing code with his name on it, and not hiding from it. The issues section of the code repos have become rolling debates about his issues and the damage done.

Anyone that depends on colors.js, faker.js, etc., can pin the version to an older one that npm keeps available. Or look for forks like https://github.com/DABH/colors.js.

I use a LOT of OSS code in my life. I patreon some and try to fix bugs here and there but I am nowhere near parity in terms of the benefits I've enjoyed. I have feels about the whole thing. It is amazing to me to postgresql, the languages I like, the libs I like, linux OS, vm platforms, and servers for every protocol are out there, free to use and make things and make a living, maybe make a killing. There are coding-class heros out there making things that are free and good. There are also rent-seekers of every degree, bad actors, google results campers, lots of reasons why we can't have nice things forever without finding a way to pay the pipers.

Best of mental health to Marak and to all who just got shiny new statin prescriptions in response to broken builds.
posted by drowsy at 10:31 PM on January 13 [39 favorites]


Live by the MIT-LICENSE.txt, die by the MIT-LICENSE.txt.
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
[...]
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED
posted by away for regrooving at 10:33 PM on January 13 [27 favorites]


Welp, I might have been too mild in describing the problems the new code is capable of.

"On January 8, 2022, the open source maintainer of the wildly popular npm package colors, published colors@1.4.1 and colors@1.4.44-liberty-2 in which they intentionally introduced an offending commit that adds an infinite loop to the source code. The infinite loop is triggered and executed immediately upon initialization of the package’s source code, and would result in a Denial of Service (DoS) to any Node.js server using it."

https://snyk.io/blog/open-source-npm-packages-colors-faker/

His first move was to publish an empty file I think, but this has escalated since then.
posted by drowsy at 10:44 PM on January 13 [4 favorites]


It may be time to crank out a new version of Business and Economics of Linux and Open Source to include a new form of ransomware: promise to release the source code after a sufficiently large payment is made, but first, give it out for free for a decade, until billion dollar companies unknowingly bake it in as a dependency three layers deep.
posted by pwnguin at 10:53 PM on January 13 [12 favorites]


It's his software, he can do with it what he likes. If you don't like it, get your software elsewhere. Are you somehow entitled to the man's labor and good faith?

It's a little bit upsetting that Github would kill his accounts and revert his changes, but such is the danger of relying on a "free" service.

Just as many people relied on Mr. Squires to not do this, but paid him nothing, Mr. Squires in turn relied on Github not to act maliciously, but paid them little or nothing. And when the "business value" in serving Mr. Squires ran out, they cut him off and reverted his own changes to his own work. It's ugly, and terrible, but also, sadly, entirely foreseeable.
posted by your postings may, in fact, be signed at 11:23 PM on January 13 [43 favorites]


I get that a lot of people are extremely put out by the effects of this, but the principle stands, and it's a principle that history tells us is not shared by large consumers of free-to-them code. They certainly haven't been tasking any of their best-of-the-best people making $400K/yr with figuring out how to give back to these projects. How come npm doesn't have a way to push money at a developer's account whenever a paying-user pulls a new version? Because capital is amoral and why not ride the free pony as long as you can?

The same obligation people interpret to steer the developer's care for a project strangely doesn't create any obligations on the consumer's part. Take take take, and whether a library gets hacked or the developer revolts, someone's gonna feel some pain; you mess with the money bull, you get the horns.

This isn't to say open source should be paywalled, but if your company is profitable on code you're getting for free, you should want to give them money, or their Amazon Wish List, or or or. Figure out a way to ensure your supply chain doesn't take a shit in your Six Sigma punchbowl. Developing any library like this internally would consume at least a few hundred thousand dollars per year in headcount not just to create, but to maintain. Hell, in that way it's a business continuity item irresponsible to neglect.

And GitHub is 110% wrong here, but there's those horns again.
posted by rhizome at 11:36 PM on January 13 [26 favorites]


The thing that amazes me is businesses absolutely get hung up about paying a $20/year licensing fee, said fees discussed in meetings with six company people making $120K a year and a couple of outside consultants at $100/hour. They will do whatever they can to avoid it, up-to-and-including using sketchy alternatives or paying someone internally the equivalent of $10K to cobble together something buggier and less effective. I've been in at least ten of those meetings.
posted by maxwelton at 11:48 PM on January 13 [64 favorites]


To be less flippant, 1) this was a dick move, but 2) this ~ecosystem~ of code that just slurps in the latest version of its dependencies with 0% acceptance testing... paid professional people, what the fuck are you doing?

Subtle holes in dependencies are a hard problem. But infinite loops at init time are not. I realize there's a whole machinery built up here so this is not supported as an individual choice, but fuck me, Github devs lying in ponds distributing JavaScript is no basis for a system of governance.
posted by away for regrooving at 12:05 AM on January 14 [54 favorites]


Maybe one could argue that he decided to use code rather than bombs…
posted by beesbees at 12:14 AM on January 14 [1 favorite]


I am in agreement with the money args and the ecosystem args here. But let's also pour out some for the second developer who did most of the commits in the last three years, who was not in favor of this action, and got locked out after being the primary contributor. Not by forking, which after three years might have withered the original.

I probably want a lot of what Marak wants, and of course the MIT args are undeniable. But one dev tanked a project that he hadn't committed to since 2018, that another dev kept alive. Unless that other dev was paid as work-for-hire, this isn't hitting me as the strongest 'value my output' move.
posted by drowsy at 12:17 AM on January 14 [34 favorites]


Open Source ecosystems are built on trust but they should also be built on vast, wealthy businesses donating back atoms of their wealth to the developers of the free software that they use. It's not even difficult to do - Github has a sponsorship system built in now.

The "What Really Happened to Aaron Schwartz" text isn't a reference to what really happened to Aaron Swartz - it's a reference to a new conspiracy theory that starts off with the belief that Ghislaine Maxwell was a high-level Reddit moderator and which then branches out into fantasy what-ifs involving murderous paedophile MIT staff, spies, links into the wider QAnon nonsense and of course Mossad pulling strings.
posted by BinaryApe at 12:47 AM on January 14 [12 favorites]


Soooo... I guess nobody remembers left-pad?
posted by fnerg at 12:48 AM on January 14 [9 favorites]


Honestly, I kinda hope this sort of thing becomes so widespread that people stop trying to pull in every third party library they possibly can on every project, whether they play nicely together or not. This will solve both the problems of software development being seen as easy and fast (because it'll cease being easy or fast, which means people will have to think about what they're doing more, HOPEFULLY), and the problem of having to work around a million bugs in black box code that you have no control over.

Or it won't, and technology will just get more expensive, and the big 5's stock prices will go up.
posted by fnerg at 12:55 AM on January 14 [5 favorites]


We're all aware that this is some QAnon bullshit, yeah?
posted by prismatic7 at 1:09 AM on January 14 [12 favorites]


Fuck this guy forever for coopting Aaron Swartz to push his conspiracy nut bullshit. This dude isn't some hero fighting corporate greed, he's an abusive asshole and should be shunned.
posted by lazaruslong at 1:26 AM on January 14 [20 favorites]


We're all aware that this is some QAnon bullshit, yeah?

Fortune 500 companies benefiting from the free labor of open source software is also bullshit, your point being ?
posted by Pendragon at 1:39 AM on January 14 [7 favorites]


The way I see it, open source developers who behave as if the act of releasing free software, in and of itself, does imply an obligation to support what's been released have also contributed greatly to the present lamentable state of affairs. So have the many who argue assiduously that such an obligation is not only real but obviously real because actually there's no difference between commercial projects and free ones.

Most free software licenses contain language equivalent to "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED" and it seems to me that if developers are not going to act as if that is actually the case, then they've nobody to blame for any failure to get paid for support but themselves.

To my way of thinking, absolutely reciprocity-free licences like MIT make no sense for projects of substantial size that inevitably will require supporting. I vastly prefer the moral framework of GPLv2, despite the well reported practical difficulties that have been encountered in enforcing its provisions legally.

The main argument against using GPLv2 for pretty much everything is that doing so acts as a disincentive toward widespread uptake of the projects licensed under it, because less restrictive licences will outcompete it in the marketplace. But again, to my way of thinking that's a good thing. An innate desire to see anything, especially one's own output, dominate any given ecosystem is something I interpret as a form of mental illness. The GPL mindset is about promoting cooperation, not competition; niche and interoperability, not dominance and irreplaceability.

That said, the fact that GPLv2 applies to the free software project with more active instances worldwide than any other software project in history - the Linux kernel - suggests that perhaps the uptake disincentive argument is perhaps not as sound as many seem to believe.
posted by flabdablet at 2:41 AM on January 14 [16 favorites]


Github suspending the account over this is particularly interesting to me, since I have code that I have intentionally and publically written to confuse Github's "Copilot" code generator(/theft) engine, such that if it absorbs my code, it will learn to generate infinite loops. My code does not misbehave when used as intended. Github has not suspended my account so far.

Note that a Github suspension can hobble a developer even if, like me, they have avoided becoming locked into using it for their software development. They have manage to entrap the whole industry in many ways.
posted by joeyh at 2:48 AM on January 14 [11 favorites]


The other thing highlighted by the latest instance of blind reliance on npm causing massive inconvenience is that curating a reliable software repository is work that requires a high degree of skill and human coordination to execute well.

I think a lot of people have been lulled into a sense of false security by how well the Debian repository works; very nearly all of what's in it interoperates very nearly perfectly very nearly all of the time, hugely benefiting projects that pull from it like Ubuntu and Mint and Armbian and countless others. And I think a great deal of the credit for that is due to the way the Debian project has from its earliest beginnings paid a lot of attention to the way its own social organization works.

Expecting a randomly curated mess of nightlies like npm to offer anything like Debian's reliability, or a commercial outfit like GitHub to offer anything like its accountability, has always struck me as unrealistic.

QA is hard. Believing that it can just be automated away requires a lot of magical thinking.
posted by flabdablet at 3:07 AM on January 14 [27 favorites]


Mod note: A couple deleted. Be adults, and stop making me work when I'm not supposed to be working.
posted by taz (staff) at 3:30 AM on January 14 [34 favorites]


Fortune 500 companies benefiting from the free labor of open source software is also bullshit

In practice I agree with you. Per the licences, the companies were granted the rights. Similarly "NO WARRANTY FOR FITNESS" etc means that their slurping the latest update with no testing is their own bloody problem. They can't get shitty about that.

I'm sure it sucks for fortune >500, but open source doesn't mean "I get support and shit", it means "this bit of text might be useful to you, or not, who knows? Also use of it creates some obligations". So pin the version that works, and test if you decide to upgrade.

Could've used the ACSL, maybe - but that's not very Q.
posted by pompomtom at 3:57 AM on January 14 [5 favorites]


So not all companies are equally good at this, but y'all know that, like, Google and Facebook DO have large teams of highly compensated engineers working on open source projects right? How many people using colors.js we're also using React, a project which was developed almost entirely by Facebook? How many we're running the code on V8, a JavaScript engine developed almost entirely by Google? How many use Typescript, a JS language extension developed almost entirely by Microsoft?

I agree that maintaining OSS libraries is a thankless task and that we all benefit from this underappreciated work. But honestly, the companies that are the biggest net beneficiaries aren't the big ones, they're the little ones. Not to mention, the (smart) big software companies have internal package managers with security policies that will block them from releasing malicious dependencies, whereas your average startup, non-profit, or civic poject definitely doesn't.
posted by goingonit at 4:18 AM on January 14 [12 favorites]


NPM makes absolutely no sense to me, especially NPM without pinning to specific versions, because I don't trust semantic versioning in public projects.

I don't think people really understand how much of the big open source project are maintained/developed by employees big corporations or financed by those corps, there's always a part of the software ecosystem that you need to be a commodity and they don't mind that their contributions are public since it's not the product they're selling. That's how you get open OSes, open compilers, open web browsers at the scale and complexity we have now.
posted by WaterAndPixels at 4:22 AM on January 14 [6 favorites]


This is a fascinating world that I know very little about.

The thing that amazes me is businesses absolutely get hung up about paying a $20/year licensing fee, said fees discussed in meetings with six company people making $120K a year and a couple of outside consultants at $100/hour… I've been in at least ten of those meetings.

So what were the arguments against paying the $20? It certainly sounds senseless on its face, but if it goes this way over and over again in many companies, my guess is that it isn’t totally senseless. Is it that they’re using $20 bits of code from a zillion different developers, so they’d be putting themselves on a path to pay $20zillion in tiny annual licensing fees? Does paying initiate some kind of legal relationship they want to avoid? What’s the hangup?
posted by jon1270 at 4:28 AM on January 14 [1 favorite]


The hangup is that the bigger the corporation, the more rules about procurement (buying shit) it has. This means requirements that other businesses they buy things from must be compliant to this-or-that ISO standard and/or have this-or-that certification and/or be in this-or-that country or any of dozens of other requirements. If you can't document that all of your procurement satisfies those requirements, then your business may not satisfy the requirements that your customers required you to have.

While using stuff you got for free is just fine and breaks no rules at all.

That's why.
posted by seanmpuckett at 4:46 AM on January 14 [26 favorites]


The "arguments" are that companies don't love spending money, and will absolutely attempt to scrimp and save with tech in ways that are fundamentally irrational.

I, too, have been in those meetings—across several companies, no less!—and I envy your belief that big corporations act with sanity and clarity. Big corporations are as dumb as people, as irrational as any single individual you know. Sometimes, depending on the corporate structure, more irrational, because some company policies prioritize irrational thinking over reasonable logic.

I can't tell you how many times I've gotten out of an hour-long meeting, in which the lowest-paid person was still highly-paid, only to hear someone say: "You know, in the time we spent discussing that, we could have just paid the first 3 minutes' worth of one of our salaries to this company and ended the discussion there." And I guarantee you that virtually every programmer here who's worked for any amount of time at a company larger than, I dunno, 12 people has heard this before, probably enough times that it's a meme to them.

Sometimes, at the grocery store, I find myself staring at two nearly-identical food products, asking myself if I can really justify buying the $6.99 variant when the $4.99 variant is right next to it. A week later, on impulse, I'll get a single box of lukewarm French fries delivered to me, and it will cost me approximately eighty dollars.

That's the hangup. Why should the company with a $50,000,000 profit margin spend $20 when you could pay your programmer $3,000 for two weeks' salary and get her to try and whip it up for free? It's twenty whole dollars! That money doesn't grow on trees!
posted by rorgy at 4:48 AM on January 14 [29 favorites]


I envy your belief that big corporations act with sanity and clarity.

Please, I made no such claim. Corporations often seem much dumber and more irrational than individuals. What I’m suggesting is that there are perverse incentives in play that might very well be stupid, but which can’t be simply shrugged off.
posted by jon1270 at 4:59 AM on January 14 [3 favorites]


Never underestimate simple cheapskatery. I got in close to a full on shouting match over wanting genuine Apple Lightning cables for app development because the Pound Shop equivalent they had for us only worked intermittently. This was in a startup that was spending tens of thousands a month on overseas sales trips.

They were making a personal decision that spending £20 on a cable felt wrong. Nothing more.
posted by grahamparks at 5:02 AM on January 14 [8 favorites]


The thing that amazes me is businesses absolutely get hung up about paying a $20/year licensing fee, said fees discussed in meetings with six company people making $120K a year and a couple of outside consultants at $100/hour… I've been in at least ten of those meetings.

A lot of places I've worked at would have benefited from a "small fries" policy where departments/teams/individuals are allowed to get licenses without too much hassle. And it mostly works if these are all one-offs without possible legal implications, but that can be hard to ascertain at an individual level, hence "the meetings". And once you had the meeting, the guy from procurement decides he'll "negociate a deal", and legal decides to add clauses and at this point you're just wishing the seller would sell it to you with a fake "pizza" invoice cause those are easy.
posted by WaterAndPixels at 5:06 AM on January 14 [10 favorites]


> It's his software, he can do with it what he likes. If you don't like it, get your software elsewhere. Are you somehow entitled to the man's labor...

Absolutely no.

> ...and good faith?

Absolutely yes.

We are responsible for what we put in the world. And we are responsible for what we take. Ken Thompson's "On Trusting Trust" applies here, for sure (I mean, it applies everywhere all the time, but super-especially here). Dude abused the trust of thousands of other people, most especially his co-developers. But if any live products broke because of this, that's because the developers of those products were being reckless. They believed they could be reckless because they count on dependencies not going rogue, so they didn't take necessary precautions.

In npm you can specify a range of version numbers for your dependencies. In a large enough project dependent on dozens of external resources (and the hundreds of sub-dependencies, in aggregate, that those resources will use), it's the only sane way to ensure you can keep up to date on the effort of thousands of developers pushing feature updates and bugfixes every day for the code you use -- if one of your dependencies goes bad (or rogue), it's just another in-progress bug from the perspective of your own project. But when it's time to ship, if you don't lock down those dependencies your work is at risk in all kinds of terrible ways. (And yesssss it is possible for the version number of a dependency to tick over in the time between signing off on the QA version and compiling the release version.)
posted by at by at 5:18 AM on January 14 [11 favorites]


I went and grabbed the last legitimate version of colors.py from github, and used "git blame", a tool that determines authorship of files line by line.

Marak is not the top author of colors.js by line overall, it's a different github account (plus a number of more minor contributors). So, just by virtue of having the code associated with his github username, he's a minority contributor with the ability to pull the rug out from under a bunch of overworked software engineers .. ultimately just to peddle some harmful qanon nonsense.

At the outset I had a tiny bit of compassion for Marak, but no longer. There might be meaningful collective action for Free and Open Source authors to undertake against abusive corporations, but this ain't it.
posted by the antecedent of that pronoun at 5:27 AM on January 14 [14 favorites]


> It may be time to crank out a new version of Business and Economics of Linux and Open Source to include a new form of ransomware: promise to release the source code after a sufficiently large payment is made, but first, give it out for free for a decade, until billion dollar companies unknowingly bake it in as a dependency three layers deep.

Didn't Oracle do effectively this on acquiring MySQL (via Sun) and Innobase?
posted by at by at 5:31 AM on January 14 [3 favorites]


Oh, and the file that lists the other software within the npm ecosystem that colors.js depends on ("package-lock.json") contains more lines than color.js has actual javascript code in lib/ (950 lines vs 800 lines). The useful core of colors.js is probably about 100 lines, the rest is things like 'show text in unreadable color stripes'.
posted by the antecedent of that pronoun at 5:37 AM on January 14 [1 favorite]


This is making me think, somewhat tangentially, of all the artists and chess players turning to NFTs despite the societal and environmental cost just because of their desperation to be paid something, anything, for all of the work they've put in and value they've created. It's a reminder that The Market often rewards people who capture it rather than people who create value for it.
posted by clawsoon at 5:37 AM on January 14 [4 favorites]


In npm you can specify a range of version numbers for your dependencies.

And you'd better specify it explicitly for every project in entire subdependency graph for each of your explicit dependencies as well, because trusting other projects you depend upon to have done that for you is unsafe.

And you'd better allocate enough time to get this done, because sometimes a project somewhere in that graph will start to require some minimum version of something that a lot of your pinned versions of other projects can't use, and you'll find yourself needing to do huge amounts of testing all at once.

There really is no one-and-done way to handle these things.

Didn't Oracle do effectively this on acquiring MySQL

They certainly tried, but the mariadb fork put paid to their shenanigans pdq.
posted by flabdablet at 5:38 AM on January 14 [8 favorites]


Free as in beer, free as in speech, free as in puppy, free as in bomb.
posted by clawsoon at 5:39 AM on January 14 [5 favorites]


It's a reminder that The Market often rewards people who capture it rather than people who create value for it.

Another way to express the same idea is that the values of any market are, to a very good first approximation, identical to those of the largest participants.

Free as in beer, free as in speech, free as in puppy, free as in bomb

Or free as in Willy, where the whale jumps the shark.
posted by flabdablet at 5:42 AM on January 14 [2 favorites]


Free as in thread.
posted by clawsoon at 5:42 AM on January 14 [1 favorite]


Are you somehow entitled to the man's labor and good faith?

To my way of thinking, building software on the basis of what you're entitled to is doing it wrong. What you're entitled to doesn't matter for shit; what matters is what you can get, as anybody who has ever attempted to use their theoretical entitlement to support from Microsoft for problems with anything MS has ever sold will attest.
posted by flabdablet at 5:50 AM on January 14 [3 favorites]


This guy sucks but it's just another example of the complete catastrophe that is the npm ecosystem where pulling in 5 packages means you end up with 1000 other dependencies, often the same package in different versions. By the time I moved into web app development it was already like this and everyone just acted like this is the way it's supposed to be, but it immediately struck me as complete madness. If it takes a qanon weirdo having a break with reality for something to change? Who am I kidding, there's millions of lines of code out there built on this foundation of sand, nothing will change
posted by dis_integration at 5:54 AM on January 14 [10 favorites]


It's his software, he can do with it what he likes.

It's not his software, though.

Colors, at least, was released under the MIT license. (The license file has been removed from Faker, so I don't know what license it uses.)

That makes it everyone's software. If he didn't want people using the fruits of his labor under those terms, then he shouldn't have released them under that license.

You don't get to say "I abdicate ownership of this and give it freely to the world", and then later say "actually, I changed my mind – this is mine".

It's only "his" software in the sense that he's the original author and primary maintainer. GitHub lists 44 contributors to the project. (But none of them have any right of ownership over the project, either – because, again, they've all been working under the MIT license.)

Are you somehow entitled to the man's labor and good faith?

Labor? Of course not. As far as I'm aware, no one forced Marak to work on this project. He did it of his own free will, and released it freely to the world.

Good faith? I mean – yeah, absolutely. I feel like I'm entitled to good faith from everyone, at all times. (And that they, in turn, are entitled to good faith from me.) The alternative is to say that Marak is entitled to act in bad faith, when the caprice strikes him.

It seems to me that any OS license includes the implicit assurance that you won't update the software in a way that deliberately sabotages the people to whom you have freely given it.

This is a dick move. It will create a minor headache for the Big Tech Fat Cats that he claims to be targeting. The people who will suffer the most, and who will have to mop up the mess (i.e., developers in the trenches), probably never had any practical alternatives.

Heck, they probably never even knew that their project was using these particular packages (because they were only installed as dependencies of some other package). Even if Marak did have a legitimate grievance here – surely it's only with projects which depend directly on Colors and Faker?

Or am I now responsible for vetting every package in my dependency tree, in order to ensure that...well, to ensure what, exactly? Colors and Faker include explicit declarations – the license files – saying that I'm allowed to use them, with zero financial obligation to anyone.

But people seem to be arguing that I can't take those license files at their word – that I owe some additional, unspecified responsibility to Marak before I can ethically use "his" packages. And that he's therefore justified in this sabotage, because users of "his" packages have failed that responsibility.

Let's assume, for the moment, that this is a legitimate position to take.

If I truly owe something to the maintainers of a given package, above and beyond what's stated in the license file – then I don't want to use that package, for reasons both ethical (I don't want to fail that responsibility, whatever it is) and practical (I don't want to mop up the mess when the maintainers retaliate in this Totally Justifiable fashion).

My question: how do I determine which packages really are FOSS, as stated in the license file – and which ones are subject to this additional, unspecified responsibility?

Sorry, but this is nonsense.

I don't object to the notion that for-profit organizations should provide more support for OSS. In fact, I agree with it. But this is a completely shitty and misguided way to make that point.
posted by escape from the potato planet at 6:05 AM on January 14 [24 favorites]


In theory, Github could be paying developers based on the popularity of their projects.

Or America could have a more robust social safety net.

Or a law could be passed to make corporations pay for free ("as in speech") software that they use.

Or there could be free software funding from the government the same way that there's arts funding.

Any other ideas?
posted by clawsoon at 6:05 AM on January 14 [4 favorites]


your postings may, in fact, be signed: It's his software, he can do with it what he likes. If you don't like it, get your software elsewhere. Are you somehow entitled to the man's labor and good faith?

Very true -- and yet I bet that the changelog.txt didn't include a mention of an unavoidable, deliberate infinite loop. :7)

--

It grinds my gears how much free labor went -- and still goes -- into making the Internet work, and yet only some of the people involved get paid (much less get rich).

More specifically, the original authors of, e.g., curl and openssh and Apache Tomcat should be farting through silk, considering how widely their software is used to make money for other people -- who don't pay a fair share of that money back to the devs.
posted by wenestvedt at 6:09 AM on January 14 [6 favorites]


escape from the potato planet: It seems to me that any OS license includes the implicit assurance that you won't update the software in a way that deliberately sabotages the people to whom you have freely given it.

I just re-read the MIT license, and I don't see that in there at all. I agree that this is a jerk move, but the license is very explicitly "anything at all can be done to this software" and "fuck you if you think you're owed anything if using this software harms you."

But that same license also doesn't give him much recourse against Github grabbing control of that copy of it from him.
posted by clawsoon at 6:13 AM on January 14 [5 favorites]


There is definitely a lot of overhead involved in identifying and funding open source developers. You have to figure out who gets what and why, track people down (often you have nothing but a defunct email address to go on), deal with grumpy devs who think that they deserved a cut, etc. Companies understandably don't want to deal with the headache.

The thing about large companies, though, is that they already deal with wiggly regulatory compliance bullshit all the time. Why not this? Because they're not legally obligated to do so, of course, but they can completely afford to. A company that can hire a full time sushi chef for its cafeteria can absolutely hire someone to make disbursements to open source developers.

Back in the 90's, Red Hat sent invitations to every open source developer whose source they were using (that they could identify) to participate in their IPO. My brother got one of these and made a reasonable sum. There was a fair amount of contention at the time due to some people feeling left out, headaches with qualified investor status, etc., but the point stands that there is no reason that the most valuable companies that have ever existed on the face of the earth can't do this. Let's say you identify two thousand open source developers who have written software you rely on. And you give them $10K each. That's twenty million dollars! A lot of money! Almost a fraction of a percent of Amazon's quarterly profit.
posted by phooky at 6:16 AM on January 14 [5 favorites]


I have been poking around trying to figure out Github's role in this. I think what happened is that the code changes and the rants together first smelled like the account got hacked and owned and maliciously pushed. Once it was known that the repo owner was doing the owning, I think it has been business as usual.

For instance, the "666 to Infinity" loop problem, github did not police that one.

NPM might be a different story, still digging.

So I'm not ready to dump on Github for this yet... and Microsoft, if you are listening, I do pay for your Office 365 family plan for the four days a year a need it, but I use VSCode 365 days a year, which makes me feel less foolish. So it would be great if you protect that product and its own freestyle contrib community for a long while.

Owning Github doesn't resolve the all the inequities, but at least here a large player is allowing/subsidizing the rest of us for part of our work, giving a channel for payment, etc.

That said, @flabdablet, I appreciate your Debian comments a lot, and others here. Getting a lot out of this thread.
posted by drowsy at 6:21 AM on January 14 [1 favorite]


A bit more of his story at Hacker News. Sounds like he felt he was very specifically screwed over recently:
Since no one seems to be interested to pay for work offered for free, Marak launches SaaS of the tool as fakercloud.com, which is a popular strategy and sometime can actually work.

Unfortunately, according to Marak[1], engineers from Retool copy the SaaS platform and launch it as a part of Retool. Marak realising what has happened offers the CEO of Retool to sell the fakercloud.com to them. The CEO ghosts Marak...
posted by clawsoon at 6:24 AM on January 14 [4 favorites]


It seems to me that any OS license includes the implicit assurance that you won't update the software in a way that deliberately sabotages the people to whom you have freely given it.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED

Emphases mine. Lots of folks seem to misunderstand these words, maybe because overexposure to Microsoft EULAs has conditioned us all to have our eyes glaze over instantly at the sight of all-caps text. The entire obligation to decide whether or not any given release is fit for purpose is on the receiver; none of it is on the giver.

People who just assume that anything they pull from npm will work without thorough acceptance testing are doing it wrong, despite the fact that this is almost universal practice.

This is a dick move.

For sure.
posted by flabdablet at 6:27 AM on January 14 [11 favorites]


I’m harvesting credit card numbers and passwords from your site.
"I’m afraid it’s perfectly possible to ship one version of your code to GitHub and a different version to npm."
posted by JoeZydeco at 6:47 AM on January 14 [6 favorites]


I think focusing on the developer is not super useful.

The problem is that the way people use NPM is fucking bonkers. I am continually floored that people build, like, actual production software using some wacky dependency-management system that automatically pulls in new versions of dependencies from the Internet and deploys it to prod... do you even test, bro? What the ever-loving fuck?

My dudes, if some poor software developer (who you do not employ, and owes you absolutely jack shit) having a bad day can take down your whole "enterprise" application, you have a problem for sure, but your problem is not that developer. The problem is that you suck, and should step away from the computer, stand in the corner, and think about what you did.

Because this guy modifying his code to create an infinite loop? That's one of the best case scenarios! If your critical web app shit the bed in production, you should immediately cut him a check and say "thanks", for pointing out your horrendously flawed development and release process. He could have done something much more subtle and much more malicious, and probably made a bunch more money than the zero dollars he was receiving. He just pointed out a massive software supply-chain attack vector that you probably didn't even know you had.

Good christ. God save us from web software "development".
posted by Kadin2048 at 6:49 AM on January 14 [41 favorites]


I’m harvesting credit card numbers and passwords from your site.

Funny that he literally used the example of adding pretty colours to the console...
posted by clawsoon at 6:55 AM on January 14 [1 favorite]


Kadin2048: ...if some poor software developer (who you do not employ, and owes you absolutely jack shit) having a bad day can take down your whole "enterprise" application, you have a problem for sure...

And regardless of whether the developer in question is unskilled or malicious, the consequences are pretty much the same. *cough* Log4J *cough*
posted by wenestvedt at 6:55 AM on January 14 [4 favorites]


What about those of us who aren't writing "enterprise" software or "critical web apps"? Who are just maintaining shitty CMS websites ? With no say in the development and release process? With whatever resources our employers deign to make available to us? Do we suck too?

This kind of thing has actually affected my projects, like, twice in my (20+ year) career. Worst case scenario: one of our shitty CMS sites is down for a while, while we fix it. Lives are not at stake. To protect against this rare circumstance would not be worth the cost for us.
posted by escape from the potato planet at 7:01 AM on January 14 [1 favorite]


Obligatory XKCD

Well - npm is the epitomy of the rise of current startup culture madness... "move fast and break things..."

I find it mind-boggling that few teams are pinning their dependencies and then performing QA/security reviews of library updates.

My prediction: Like "left-pad", this will not be the last time this occurs.
posted by rozcakj at 7:07 AM on January 14 [2 favorites]


The idea that warranty / fitness for use disclaimer in an EULA conveys impunity for intentionally wrongful acts is laughable.

If someone lost money off this, a tort lawsuit would have a very good chance to prevail. Bad enough, and a malicious mischief prosecution with a bit of jail time and fines wouldn't be unlikely. If there were a demonstrable objective to force people to buy an uncorrupted version of the package from him, or people were physically hurt or endangered (e.g., if the package corruption caused health or safety applications to fail), felony counts and real prison time would be in play.
posted by MattD at 7:10 AM on January 14 [2 favorites]


And let's not forget that the real power to wield the law rests in the extremely wealthy, not in those whom they decide to sue, no matter the merits of the case. If any random person pisses off someone with a rabid lawyer on leash, there's not much they can do about it but wail. The only thing stopping this from happening more than it does (and it happens a lot) is bad publicity.

If someone decides to crucify this idiot in court as an example to the rest of the giving-stuff-away-for-free chumps, I'm not sure there'd be much of an outcry. You need a large upwelling of public sympathy to change entrenched systems. And waving a qanon wingnut flag around is not how you get it.
posted by seanmpuckett at 7:21 AM on January 14 [2 favorites]


Supply chain attacks are the new buffer overflow.
posted by flabdablet at 7:22 AM on January 14 [7 favorites]


You need a large upwelling of public sympathy to change entrenched systems. And waving a qanon wingnut flag around is not how you get it.

The fascists are betting you're wrong.
posted by flabdablet at 7:24 AM on January 14


Supply chain attacks are the new buffer overflow.

And maybe the new propaganda of the deed?
posted by clawsoon at 7:38 AM on January 14


The Copyleft hand of darkness.
posted by nickggully at 7:41 AM on January 14 [2 favorites]


or people were physically hurt or endangered (e.g., if the package corruption caused health or safety applications to fail), felony counts and real prison time would be in play

Can I get a citation? It seems to me that the developer of free software, who has not made any guarantees about that software, and enters into no contract with any other developer or user, owes no duty of care to anyone and would not be liable for damages. But I am not a lawyer - I'd love to hear from one.
posted by Popular Ethics at 7:45 AM on January 14 [6 favorites]


I think that software that has hidden dependencies on the ongoing goodwill and participation of many anonymous people, and pulls in changes to dependencies without actual testing, sucks. That just seems like bad software design.

Whether you, as a developer who has potentially produced such things, suck? I think that's best as an introspective question. If you're a software developer, and all the software you produce sucks, I'd imagine that to be an uncomfortable exercise. Certainly, a lot of people just cash their paychecks and move on with their lives. Whether you want to do that sort of thing is a personal decision. (There are, perhaps regrettably, no real professional ethical standards for software development. I would hope that a civil engineer, if asked to build a bridge with totally inadequate tools and no process controls, in a way they knew was going to yield an unsafe result, would refuse rather than just invoking the Yuppie Nuremberg Defense.)

But hey—I have written some shitty code, and I have watched great developers write shitty code. A team that I led was once escorted off the premises (like one step short of the FBI perp-walk) by a client because we blew up their production database during a migration. Shit happens.

This tweet is highly relatable.

The approach I have usually seen taken to dependency management in non-trivial software projects is by using a local artifact repository. Nexus is the one I have the most experience with. (Verdaccio is apparently popular for web development in JS it seems like?) But the general idea is that you have all your development environments, builds, etc. point to the local artifact repository, and not to public sources on the Internet. If you need a new dependency, you add it to the repo (generally in a team environment there is some sort of review/approval process) and make it available that way. And from the perspective of an individual developer, it greatly speeds up their workflow by eliminating hits to public repositories all the time (the repo acts like a caching resolver, if it's set up to allow that).

That, or something like it, probably needs to be considered the "standard of care" for professional software development at this point.
posted by Kadin2048 at 8:11 AM on January 14 [13 favorites]


But the general idea is that you have all your development environments, builds, etc. point to the local artifact repository, and not to public sources on the Internet. If you need a new dependency, you add it to the repo (generally in a team environment there is some sort of review/approval process) and make it available that way

I am genuinely surprised this is not the common practice (I have never developed web apps, only desktop apps). How the hell can you do any quality control if you could end up with a different piece of software every time you click build? (Or am I misunderstanding the process?)
posted by Popular Ethics at 8:15 AM on January 14 [4 favorites]


Kadin2048: That, or something like it, probably needs to be considered the "standard of care" for professional software development at this point.

On the flip side, all of the major software vendors want you to keep automatic updates on all the time because people are very bad at manually updating when critical security updates are needed.

Having read a lot of opinions here and elsewhere, I've concluded that this is one of those no-right-answers situations. You open yourself up to security vulnerabilities by updating automatically, and by not updating automatically.
posted by clawsoon at 8:19 AM on January 14 [6 favorites]


I'm gonna nth the other developers in this thread saying that npm's approach to development has always seemed insane to me, as someone who started programming very young and always specifically liked how few dependencies you need to get most systems up and running.

I typically program within one fixed backend environment. That leans on a single add-on JavaScript library. If I want to get fancy, I add one thing on top of CSS that makes my styling a little nicer. When I was younger, I'd hear about people using two JavaScript libraries and go: wow, check out the fancypantses over there.

Obviously that's a little exaggerated, but it was wild when I went from working for a small service-provider company to doing "cutting-edge" agency work and was informed that the new fad was to install ten different layers of development platform before touching a single line of code. Stacks have gotten insane! And dependency library trees are utterly bugshit. Sometimes I find myself trying to install a script that does a simple function, and find that it's trying to download something ludicrous like 1.3 gigabytes worth of dependency scripts. But because that's such a common practice, I feel like devs don't notice it sometimes, because everything else you want is going to try and install the same 1.3gb worth of insane dependency bloat.

Leaving aside whether the guy in question did something acceptable ("yes and no") or whether Github was unethical in reverting his changes ("yes and no"), it feels like this approach to development benefits large companies that can afford teams of developers just to maintain this elaborate architecture, and forces smaller groups or solo devs to keep tabs on a system that's just too grandiose and too sprawling for one individual to responsibly keep tabs on. I know it's laughably late to be like "Hey, I think programming was better when it empowered individuals more," but I can't help but notice that npm, which is maintained by GitHub, which is owned by Microsoft, feels like a pretty damn Microsoftian attitude towards technology and end users, even if the end users in question here are the ones making software and not just the ones consuming it. And it's wild to me that we've found a way to make code itself bureaucratic.
posted by rorgy at 8:22 AM on January 14 [9 favorites]


On the flip side, all of the major software vendors want you to keep automatic updates on all the time because people are very bad at manually updating when critical security updates are needed.

This is only in an unmanaged environment. In a managed environment such as a workplace with a Nexus repository, you're supposed to have someone whose job it is to sanity check updates before letting them loose in the repository.
posted by NoxAeternum at 8:26 AM on January 14 [5 favorites]


I currently do numerical computing in Python for a living. Everything I build has a pinned list of requirements and any changes are peer reviewed. Services are deployed in containers that have the bare minimum of dependencies installed. All production packages are stored in our local Artifactory instance. We have hooks in our local GitHub install to flag any pull request that lowers test coverage. The CI/CD pipeline will fall over if the tests don't pass.

Any outward-facing project more serious than hobbyist level shouldn't be randomly pulling in new code. But hey, JavaScript bros gonna bro.
posted by kersplunk at 8:31 AM on January 14 [9 favorites]


Seems to me the only obvious thing is that all of these affected places have no concept of QA/CI/Testing or test/production and regardless of all the other things going on.... It's their own fault due to their own incompetence.

Y'all should try Raku :) dependencies can be specified to crazy levels of specificity (you could actually use the same named module with the same version but two different authors at the same time should you so desire) and OMG shoot me now, the library modules and such your system uses are in a friggin' BLOCKCHAIN.

I seriously can't imagine not having a 'make test' phase before sending something into production.
posted by zengargoyle at 8:32 AM on January 14


On the flip side, all of the major software vendors want you to keep automatic updates on all the time because people are very bad at manually updating when critical security updates are needed.

I think there's a qualitative difference between keeping Windows Updates turned on, which presumably come only from Microsoft and with the imprimatur of a $2T company, versus writing code that pulls in a rats' nest of libraries written by (and can be updated by) thousands of random individuals for whatever reason they might want to, and may or may not see their users as a perfectly good substitute for running tests.

And lots of companies don't even trust Microsoft to do that. I have been mercifully Windows-free for many years (which basically results in me managing my own workstation at my own risk) but many companies don't let their employees' machines just update every Patch Tuesday automatically. They go through the Windows version of a private Nexus, where the admins can (in theory) review, test, and approve updates before releasing them out internally. See WSUS.
posted by Kadin2048 at 8:34 AM on January 14 [1 favorite]


Can GitHub tell the difference between:

1. A hacker breaking into my account, damaging the function of code in a widely-used repository, and publishing a spiel of polarizing nonsense in it; and, to

2. Me having a mental breakdown, damaging the function of code in a widely-used repository, and publishing a spiel of polarizing nonsense in it?

I have assumed since this news broke that GitHub treated this as a defacement incident and reversed the defacement and sent an “It looks like you’ve been hacked; would you like help with that?” email to the repo owner. It doesn’t look like GitHub has confirmed that yet, and the code owner seems busy trying to execute on something like scenario #2, but certainly I can’t fault GitHub for initially reacting as if it was scenario #1, if that’s how they read the tea leaves at the time.
posted by Callisto Prime at 8:34 AM on January 14 [3 favorites]


This is only in an unmanaged environment. In a managed environment such as a workplace with a Nexus repository, you're supposed to have someone whose job it is to sanity check updates before letting them loose in the repository.

I've worked in more than one company which had what you might generously call a "semi-managed" environment. A developer built something for them; that developer is no longer around; what they built just works most of the time so they just use it.
posted by clawsoon at 8:35 AM on January 14 [3 favorites]


How the hell can you do any quality control if you could end up with a different piece of software every time you click build? (Or am I misunderstanding the process?)

Sadly, no you're not.

If you're going to go this route, the safe way to do it is to replicate something like Debian inside your own organization. Instead of relying on a huge uncurated slew of random npm packages published directly by their authors, you need to set up a bunch of internal repositories for your own devs to pull their dependencies from.

The Debian model filters code from upstream through three repos: Unstable contains software with only enough work done to package it up into Debian's format, Testing contains packages that have been in Unstable for at least two weeks without accumulating showstopper bug reports or depending on stuff that isn't already in Testing, and Stable is a snapshot of Testing taken after pausing all imports from Unstable for long enough to reduce the outstanding bug count to QA-acceptable levels. So Stable always consists of a set of packages that have been thoroughly vetted for clean interoperability and correct function, most of which are many releases behind the bleeding edge of upstream.

If I were running a dev shop that relied on npm, that's a model I'd certainly be implementing in-house and paying competent QA devs to maintain for me.

A perceived need not to manage this kind of thing in-house is exactly why so many organizations prefer to rely on commercial packages that come with support contracts included in the licence fee, or on open source packages curated by somebody willing and demonstrably able to support what they've curated for a fee (the latter was Red Hat's original business model).

The move fast and break things cowboy faction, on the other hand, gives no shits about software quality and never has done. And because they're cheaper, they're responsible for a quite disturbing amount of what all of us interact with every day.
posted by flabdablet at 8:49 AM on January 14 [9 favorites]


The move fast and break things cowboy faction, on the other hand, give no shits about software quality and never have done. And because they're cheaper, they're responsible for a quite disturbing amount of what all of us interact with every day.

Is this Gresham's Law for software?
posted by clawsoon at 8:53 AM on January 14


Sort of a Gresham/Sturgeon combo, I think.
posted by flabdablet at 8:55 AM on January 14


Surprised no one has brought up SysJoker, a recent multi-platform malware reportedly propagated via npm packages.
posted by gwint at 8:56 AM on January 14 [1 favorite]


FWIW, the faceless corp I work at keeps a local copy of every code dependency, and updating any outside drops means pulling the changes into the local repos, checking that all of the tests pass, and getting a code review (often very cursory) for the change.

Which is to say, the bigger and more robust the corporation, the less likely out is that an action like this has any effect whatsoever. It really is just dicking over the little guy.
posted by kaibutsu at 8:59 AM on January 14 [2 favorites]


I found the above comment by your postings may, in fact, be signed odd, so similarly:

It's GitHub's platform, they can do with it what they like. If you don't like it, distribute your software elsewhere. Are you somehow entitled to GitHub's labor and good faith?

It's greatly upsetting that Mr. Squires would sabotage his projects and commit bad-faith changes, but such is the danger of relying on a "free" library.

Just as many people rely on GitHub for software development, but pay them nothing, GitHub in turn relied on Mr. Squires not to act maliciously, but paid him little or nothing. And when Mr. Squires violated the GitHub TOS ("collaboration only works when our users are able to work together in good faith") the "business value" in serving Mr. Squires ran out, they cut him off and reverted his own changes to his sabotaged work. Mr. Squire's behaviour is ugly, and terrible, but also, sadly, entirely foreseeable.
posted by Dez at 9:09 AM on January 14 [1 favorite]


You open yourself up to security vulnerabilities by updating automatically, and by not updating automatically.

This sounds from a flyover like a throw-up-hands situation, but on the ground it's not. Good practice is to do both 1) check new versions of dependencies before inflicting them on your users, 2) have the capability to update urgently when vulnerabilities are disclosed.
posted by away for regrooving at 9:53 AM on January 14 [2 favorites]


FWIW, the faceless corp I work at keeps a local copy of every code dependency, and updating any outside drops means pulling the changes into the local repos, checking that all of the tests pass, and getting a code review (often very cursory) for the change.

Something like 15 years ago a friend of mine worked for a company that made core network routers that ran a custom OS based on some BSD variant. Most if not all of his job was tracking and merging changes from the source OS and knowing when not to merge them. Companies that take this seriously really take it seriously.
posted by fedward at 10:04 AM on January 14 [5 favorites]


escape from potato planet, you are wrong on the internet. MIT has both the 'as is' clause and the 'fitness' clause.

if you want to blindly integrate updates, seems risky to me.

under MIT, you're totally free to fork and maintain it yourself if you want warranty and fitness.

dude pushed to his own repo. not his problem if you don't run regression tests in your devops.

// -----------------

he might be an asshole and unhealthy and an amateur bombmaker. but he's not wrong about authorship under MIT.
posted by j_curiouser at 10:05 AM on January 14 [2 favorites]


also, github is wrong. when this dustup started, i read their entire tos, community standards, and acceptable use.

dude is in the clear.

the problem is, he's been inconvenient and expensive.

all the whiners should step back and consider why 'risk mitigation' is a concept in the profession.

"we were really hoping the next free update wouldn't break our multi-million dollar investment." yeah, well.
posted by j_curiouser at 10:11 AM on January 14 [2 favorites]


also, github is wrong. when this dustup started, i read their entire tos, community standards, and acceptable use.

I'd be very surprised if they don't have a "Github reserves the right" clause in there somewhere which basically says they can cut you off any time they want.

And... of course they do:
GitHub has the right to suspend or terminate your access to all or any part of the Website at any time, with or without cause, with or without notice, effective immediately. GitHub reserves the right to refuse service to anyone for any reason at any time.
posted by clawsoon at 10:17 AM on January 14 [7 favorites]


Taking the legalism of the MIT license to cover you for blame on deliberate breakage is the "I told you I was an asshole on our first date" of software development.

Whether you can be successfully sued is its own question. Unlikely in the U.S. but IANAL. Some jurisdictions limit disclaiming the implied warranty more than others.
posted by away for regrooving at 10:24 AM on January 14 [5 favorites]


he's not wrong about authorship under MIT

The best case interpretation of events here is that he published code under the MIT license and then was incensed to the point of a temper tantrum because people used it in accordance to the license (which, again, he freely chose).

I would argue he in fact is very wrong about authorship under MIT.
posted by a faithful sock at 10:25 AM on January 14


If anybody has an argument against GitHub that doesn't boil down to "I have the right to use your service in any way I choose, up to and including abuse" I'd like to know what that is. Because GitHub's a private company and they can't be compelled to enable abuse based on some sort of technolibertarian claim to free speech, especially when their terms of service say they can terminate accounts arbitrarily, never mind for cause.
posted by fedward at 10:25 AM on January 14 [5 favorites]


people used it in accordance to the license

part of that is 'fork and maintain if this is important enough to you'.

I'd be very surprised if they don't have a "Github reserves the right" clause in there somewhere which basically says they can cut you off any time they want.

you are correct. but he didn't violate any enumerated 'rule'.


thanks, I'm out! unit test your shit in ci/cd peeps!
posted by j_curiouser at 10:32 AM on January 14 [1 favorite]


part of that is 'fork and maintain if this is important enough to you'

Sure, but you're eliding the fact that the reason he pulled this stunt wasn't because he was angry nobody forked and maintained the code themselves, but because he believed he was somehow owed something above and beyond what the license he freely chose entails.

All this talk about how companies are dumb if this hurts them is a distraction. Can he do this? Sure. Should nobody criticize him as being at best a complete asshole and at worst actively malicious? Abso-fucking-lutely not.

I support open source software. I like that many companies also support open source software. I think more support for it would be good. But, the idea that a person publishing something under a permissive license is owed some sort of ill-defined, nebulous "other" support OR ELSE is some gross, gross shit, and pretending that this is about anything other than that only serves to harm the perception of the open source community.
posted by a faithful sock at 10:40 AM on January 14 [9 favorites]


So can Github say that by kicking him out and reverting the commit they've effectively forked the code, which they're allowed to do according to the code license?
posted by clawsoon at 10:53 AM on January 14


Some jurisdictions limit disclaiming the implied warranty more than others.

Pretty sure that any such implied warranty applies only to goods offered for sale, not merely left lying about where people who might be interested in them can find them.

The conflation of these quite distinct ideas is the root of the assumed obligation to support what's released, both on the part of hard-done-by developers and that of users. It's a mistake. Don't do that.

When somebody tells you in so many words that they're offering no assurances that the software they're releasing will actually do what you want it to, believe them.
posted by flabdablet at 12:06 PM on January 14 [1 favorite]


So, to recap, some rules for using software:

1. Don't use closed source software provided by third parties because you can't inspect it for flaws and a third party may not be vigilant enough for your business;
2. Don't use open source software provided by third parties because potential malice is right there in the license and the amount of vigilance required to protect you from it is greater than the value that software provides to you;
3. Did we mention that almost all software, both open and closed source, has dependencies you can't see, making the amount of vigilance required grow exponentially?

Got it.
posted by fedward at 12:25 PM on January 14 [9 favorites]


4. Don't use devices with software inside, because by design you can't change the software inside even if you want to.
posted by the antecedent of that pronoun at 12:43 PM on January 14 [4 favorites]


>So can Github say that by kicking him out and reverting the commit they've effectively forked the code, which they're allowed to do according to the code license?
Section D-4 of their Terms of Service were used to justify feeding the whole swathe of code into Machine Learning training for code completion called CoPilot, so their understanding of the language may not be what you think they mean by "you licence us this code so we can run the service."
posted by k3ninho at 12:44 PM on January 14 [4 favorites]


Pretty sure that any such implied warranty applies only to goods offered for sale, not merely left lying about where people who might be interested in them can find them.

I'm pretty sure that courts do consider offering something for free to be offering it "for sale", because to not do so would be to open a massive gaping hole in the concept of liability. Also, courts tend to take a very dim view of intentially malicious acts as well, so saying "I said you can't trust me" is not going to save you.
posted by NoxAeternum at 1:18 PM on January 14 [2 favorites]


5. Don't roll your own software, because the problem you're trying to solve has almost certainly been solved better already.
posted by mcrandello at 2:01 PM on January 14 [3 favorites]


6. Avoid infinite loops.
posted by fedward at 2:50 PM on January 14 [6 favorites]


7. Avoid software.
posted by axiom at 3:43 PM on January 14 [1 favorite]


I mean sure, keep adding rules, but nothing after #5 will be evaluated at runtime.
posted by fedward at 3:54 PM on January 14 [3 favorites]


8. COMEFROM 5.
posted by sainttoad at 4:20 PM on January 14 [7 favorites]


I wouldn't be at all surprised to discover that COMEFROM is part of the Ethereum smart contract spec.
posted by clawsoon at 4:22 PM on January 14 [1 favorite]


Ultimately, this is about the value of implied social contracts: they are worth the paper they’re written on.

A traditional paper contract lays out terms and penalties, etc. that everyone has explicitly agreed to before signing and can be enforced i n court. There are huge bodies of law and traditions backing them, with very real penalties.

Social contracts, on the other hand, require that somehow everyone just sort of magically agrees and if they don’t, there’s no real way to enforce them with the same kind of pain of a paper contract. Ethics and morals just don’t carry the same kind of weight that actual laws do.

If you want to profit from software, you have to charge for it and set up contracts, etc. and not just assume everyone will value it as you do. If it’s free, someone will exploit it to profit from your labor.

On the user end, never, ever trust automagic for any reason whatsoever, even if it’s your own mother, because someone, somewhere, will screw things up, accidentally or intentionally, and you will get burned.
posted by JustSayNoDawg at 4:35 PM on January 14


If you want to profit from software, you have to charge for it and set up contracts, etc. and not just assume everyone will value it as you do. If it’s free, someone will exploit it to profit from your labor.

This reminds me of the WEIRD studies where they found that this is a very culturally-specific thing. In gift cultures, the person giving stuff away for free is the one profiting from the system, so, for example, people playing the Ultimatum Game from those cultures are more likely to reject offers that are too generous. They don't want to be exploited by accepting too much free stuff.

And, of course, gift culture ideas inspired some of the early proponents of free and open source software. Turns out the rest of our culture didn't go along with it, though, so faker.js does not pay the very-much-not-gift-culture rent.
posted by clawsoon at 4:45 PM on January 14 [4 favorites]


I think it's a blinkered classism that conceives of an act of sabotage as someone being an asshole. We need people in society who are willing to make these transgressions, to break things when deemed necessary. The idea that this violates GitHub's rules is missing the forest for the trees, this was a singular act of protest against GitHub's culture in its entirety and thus transcends any attempt to make sense of his act as being inside the framework of GitHub. It is a conceit to assume GitHub's implicit ideology is valid in the first place, which is exactly what an angry, transgressive act like this seeks to overturn. It is because society, and in particular American society, is so embedded in this technofeudal mindset that reactionary acts of sabotage must be condemned and focused on, rather than understood.
posted by polymodus at 12:02 AM on January 15 [1 favorite]


A very related twitter thread from SwiftOnSecurity:
Corporate purchasing and policies make funding open source Literally Impossible. Nothing’s going to change until you make them pay you.

Someone filed a bug?
Support contract.

Someone wants a feature?
Support contract.

It’s literally easier to pay you $1500/yr than $25 once.
posted by lazaruslong at 1:52 AM on January 15 [5 favorites]


I think it's a blinkered classism that conceives of an act of sabotage as someone being an asshole.

It's not Marak's act of sabotage that makes him an asshole -- it's like, everything else about the dude. He's a bomb making QAnon grifter coopting the death of Aaron Swartz to push his garbage conspiracy theories. This is not the anti-corporate hero you're looking for.
posted by lazaruslong at 1:56 AM on January 15 [8 favorites]


Is there a software license that bans commercial use?
I know it wouldn't be considered "free as in freedom" software, but I'd love to have something like Creative Common's Non-commercial Share-alike license but for code.
posted by a complicated history at 7:01 AM on January 15 [2 favorites]


I can see no reason why source code couldn't be released under that actual license, and since an executable binary compiled from a given source certainly counts as a work made by remixing, transforming, or building upon that source, any binary so compiled regardless of who did it would presumably be restricted by the same terms.
posted by flabdablet at 7:07 AM on January 15 [1 favorite]


Is there a software license that bans commercial use?

gpl1 requires licensing fee for commercial use. i think it also requires publically publishing your mods/usage.

which is why some shops avoid gpl1 like the plague.
posted by j_curiouser at 11:44 AM on January 15 [1 favorite]


I think it's a blinkered classism that conceives of an act of sabotage as someone being an asshole […] this was a singular act of protest against GitHub's culture in its entirety and thus transcends any attempt

It's a blinkered anticapitalism that refuses to see this as somebody being an asshole and instead looks for some other post-hoc justification. The dude poisoned the well, his protest missed its mark, and a bunch of bystanders had to deal with consequences. Where was the transcendence? I'm just not seeing it.

The anti-Assange propaganda really did a number on Liberals.

Sometimes the enemy of my enemy is not, in fact, my friend.
posted by fedward at 11:45 AM on January 15 [4 favorites]


In gift cultures, the person giving stuff away for free is the one profiting from the system

There have to be a lot of other steps in here to come out even, let alone ahead, in labor or resources. A big implicit "eventually". Mediated through care in old age, or weight in discussions of governance, or good fostering for your children, or getting a chunk of unpredictable resources when you didn't get lucky. Status alone is no better than thoughts and prayers or noise at 7pm or whatever. Cf. Ostrom and??

I've been thinking about superb programmers I knew in the 80s-90s and which of them produced stuff enormous numbers of people voluntarily use and which of those people got rich and, while there's not terrible correlation, a lot of the big money is really indirect. Stock or options in companies that don't have control over the code in question, sometimes even non-tech companies. QUANGO-ish jobs that paid in travel and free time and next-job status.

This might be the best we can do -- even within a company there's rarely an objective measure of "whose code was most valuable?" -- but it can't guarantee to reward all useful labor. (As do gift cultures, AIUI, The Warden etc.) So some people are going to be unfairly unrewarded and more of us are going to feel unfairly unrewarded.

Hence Patreons and support contracts and Substack and ??. And also spite in the ecological sense.
posted by clew at 1:43 PM on January 15


Politics is the art (or the science, I forget) of temporary alliances.

Corporate purchasing and policies make funding open source Literally Impossible. Nothing’s going to change until you make them pay you.

Someone filed a bug?
Support contract.

Someone wants a feature?
Support contract.

It’s literally easier to pay you $1500/yr than $25 once.


Currently. I saw that thread, but with that many eyes there was no way I was going to attempt to make this point 280 characters at a time:

So many companies either made a big deal about or currently employ the former beneficiaries of policies to only hire "the best of the best," companies that have made literal fucking $trillions using free software. The top 100 graduates of the top 10 schools every year, I think Zuckerberg said once. What has it gotten us? Is what we have now the best of what the best of the best can do? To not invent a way to tweak capitalism and technical interactivity to make the open source that they were benefiting from the entire time work to benefit its contributors? Ah, but micropayments were stabbed in the crib (I suspect because there were so many carpetbaggers arriving in tech 20-25 years ago from traditional finance and communications who only knew how to think in terms of retail, subscriptions, and ads, and they filled the startup executive vacuum in the first dotcom era).

Thus it fell to a disgraced visionary to attempt some methods of alternative payment models that result in what I think of as The Carob Internet. Still the point has to be made with extremely controversial methods to which there are pre-circled wagons waiting to discredit in order to avoid discussing the issue. Take the author out of the story and what do we see as cause and effect? Big dollars getting woken up on the wrong side of their Scrooge McDuck beds of money.
posted by rhizome at 2:00 PM on January 15


Do you think npm should have introduced micropayments per... package? Execution?
posted by clew at 2:27 PM on January 15


Thus it fell to a disgraced visionary

That's... one way to try and rehabilitate Brendan Eich while simultaneously pre-poisoning the well by claiming any displeasure is "pre-circled wagons waiting to discredit in order to avoid discussing the issue".

Like, even if you go "Sure, he hates gay people, but that was a decade ago, he's surely more quiet about it now", it's not like he's stopped being a jackass since.

There's discussion to be had about open-source funding, and I'm no booster of megacorps, but Eich's vision of the future isn't one I can sign on with.
posted by CrystalDave at 2:48 PM on January 15 [2 favorites]


Thus it fell to a disgraced visionary to attempt some methods of alternative payment models that result in what I think of as The Carob Internet. Still the point has to be made with extremely controversial methods to which there are pre-circled wagons waiting to discredit in order to avoid discussing the issue.

Sorry, but it's a good thing to tell homophobic bigots to fuck off and never return.
posted by NoxAeternum at 4:42 PM on January 15 [4 favorites]


Do you think npm should have introduced micropayments per... package? Execution?

Sure, something like that, maybe dependent on a commercial-user flag. I'm definitely not a top 100 student from a top 10 school and I'm sure the implementation could involve some hairy details, but I figure they went to such good schools in order to learn how to work on difficult problems.
posted by rhizome at 6:19 PM on January 15


And really, maybe not even micropayments, since a Fortune 500 company is absolutely valuing the library-builder's work at more than a penny per git pull.
posted by rhizome at 6:25 PM on January 15


According to Slashdot, Github has restored his account and he has removed faker.js from Github.
posted by clawsoon at 9:05 PM on January 15


This is not the anti-corporate hero you're looking for.
The anti-Assange propaganda really did a number on Liberals.

I'm not entirely sure what your point is supposed to be, but I'm not a liberal. If you could say what you mean with words instead of some snide insinuation, that would be lovely.
posted by lazaruslong at 11:08 PM on January 15


Sure, but you're eliding the fact that the reason he pulled this stunt wasn't because he was angry nobody forked and maintained the code themselves, but because he believed he was somehow owed something above and beyond what the license he freely chose entails.

This is a tension at the core of so many creative fields and everything else, really. When you put something into the world, you have to come to grips with the fact that someone might benefit from it more than you do, and some people have a really hard time with that.
And there are, of course, so many examples of people who will run roughshod over fields where there is a culture of performance or sharing at the core. (And there will always be people who think the right rules, or micropayments, will be the solution. I remain unconvinced.)
posted by jimw at 10:41 AM on January 16 [1 favorite]


And there are, of course, so many examples of people who will run roughshod over fields where there is a culture of performance or sharing at the core.

Aye, culture versus law. I'm sure I would throw a few rhetorical bombs if Metafilter were sold to the Metaverse, even though I have no legal stake in it.
posted by clawsoon at 10:45 AM on January 16 [1 favorite]


I guess that means that yes, ads, subscriptions, and retail are the best of what the best of the best can do. They get houses out of it either way anyway, so why even put any thought into it, or consider it a problem.

We should then get used to these pranks happening in the future and stop complaining about them. There's no ethical consumption under capitalism after all, so this is one way that can play out as far as volunteer projects that capitalists rely on. The Fortune 500 should realize that eventually they'll be taxed one way or another.

They're probably lobbying to criminalize this kind of thing now.
posted by rhizome at 7:00 PM on January 16


Do you think npm should have introduced micropayments per... package? Execution?

Ugh. We don't need some sort of crazy micropayments scheme to fix this. The problem has already been solved elsewhere, at least for values of "solved" that prevent your computer from getting bricked by somebody having a temper tantrum / mental health breakdown / owing their bookie $5k. You test the fucking code before you deploy it.

This is why projects like the Linux kernel, or even big-name distributions like Debian, have fairly extensive processes for pushing out changes from upstream developers through some sort of review, into releases, and then to end users. It's not fast, but it weeds out the obviously dumb regressions, and it gives users some basis for trusting that the software does what it says on the tin. Are those processes perfect? No, absolutely not, as the long list of zero-days and CVEs will attest to. But they're a hell of a lot better than nothing, which is apparently a common model for web apps for some reason?

I don't really understand the history of NPM and why people use it like they do. The whole thing looks totally bananas to me, and the more I look into it, the more secure I feel in that judgment. Not only are you going to have situations like Squires, who suddenly decided he wanted to take his ball and go home, you also have people who are actively mendacious and will put backdoors and other shit into upstream code if someone isn't constantly keeping an eye on things. This was script kiddie level stuff, by comparison.

If you haven't already read it, the link posted by JoeZydeco earlier, "I’m harvesting credit card numbers and passwords from your site. Here’s how", is pretty sobering stuff.
posted by Kadin2048 at 7:27 PM on January 17 [4 favorites]


I don't really understand the history of NPM and why people use it like they do.

I wasn't kidding when I described supply chain exploits as the new buffer overflow. People use npm like they do for the exact reasons C doesn't do bounds-checking on array indexing: speed, convenience, simplicity of design.

Making things as simple as possible and no simpler is the essence of elegant design, but the software industry is chock a block with people who have apparently forgotten about the second part.
posted by flabdablet at 5:33 AM on January 18 [2 favorites]


It's not Marak's act of sabotage that makes him an asshole -- it's like, everything else about the dude. He's a bomb making QAnon grifter coopting the death of Aaron Swartz to push his garbage conspiracy theories. This is not the anti-corporate hero you're looking for.

It's a blinkered anticapitalism that refuses to see this as somebody being an asshole and instead looks for some other post-hoc justification. The dude poisoned the well, his protest missed its mark, and a bunch of bystanders had to deal with consequences. Where was the transcendence? I'm just not seeing it.

He didn't poison the well, the well poisoned itself. If you can't change the frame and resort to demanding perfectionism out of acts of sabotage of course you won't see the point that GitHub is a power dynamic. An individual who obviously acted out of sabotage is just an individual, they don't need to be an angel or a hero to criticize GitHub's response. It is clear from such responses that by narrowly making it an individual problem (he is an asshole, wow, so impressive an analysis) rather than consider and problematize the power relations and class/institution fragility, I don't know, I just think those are illustrative of the blinkered responses I was pointing out.

Throughout history conservative people have continually said that activists who sabotaged things were screwing things up for everyone else. It's sophistry.
posted by polymodus at 5:14 PM on January 18


I have to think that the idea that GitHub is acting just fine here is a significant reason why Microsoft bought them.
posted by rhizome at 5:29 PM on January 18 [1 favorite]


We should then get used to these pranks happening in the future and stop complaining about them.

As long as IP is beholden to capitalism, there will be the reactionary disgruntled. The people who don't understand this will complain. Zizek thinks that this techno exploitation of the intellectual commons will be one of the great problems of our times. RMS had a solution, but the line of unethical consumption that Free Software draws has been too radical for most to accept. And so when the exploited and the precarious and the excluded act to subvert this digital social order--without necessarily them having much class conscious understanding of what they are angry about--the status quo will try to blame them.
posted by polymodus at 5:32 PM on January 18


If you can't change the frame and resort to demanding perfectionism out of acts of sabotage of course you won't see the point that GitHub is a power dynamic. An individual who obviously acted out of sabotage is just an individual, they don't need to be an angel or a hero to criticize GitHub's response.

As it's been pointed out earlier, the enemy of your enemy is, until proven otherwise, your enemy's enemy and nothing more. Defending people on the basis of "well, they're opposed to what I'm opposed to" is a very good way to sign on to things that you don't want to. The point about Assange made earlier illustrates the point - the fact that he was defended after being outed as a rapist and a right wing Russian catspaw did harm the antiwar left, and trying to call all that "propaganda" was a bullshit dismissal meant to dodge the question of why his valorization continued after who he was came out.

Nobody is demanding "perfection" - they're pointing out that turning right wing conspiracy theorists into the face of your movement might do more damage than support.

RMS had a solution, but the line of unethical consumption that Free Software draws has been too radical for most to accept.

Stallman's "solution" was the cult of the amateur writ large, to return programming to a hobby and end it as an industry. And he was not subtle about this - he literally spelled this out in several of his writings! So yeah, it was rejected because it was also class warfare (because amateurism is by definition class warfare.)
posted by NoxAeternum at 7:06 PM on January 18 [1 favorite]


Stallman's "solution" was the cult of the amateur writ large, to return programming to a hobby and end it as an industry

and yet there are many developers making their living by maintaining and extending Linux, a project released under one of Stallman's licenses.

None of the GPLs prohibit selling the software that's released under them, and there is nothing in any of them that would stop an organization paying developers to write code. What they *do* effectively prohibit is implementing trade secrets in the form of GPL-licensed software.

Notably, that prohibition didn't stop Red Hat from releasing Red Hat Enterprise Linux and making good money off it by providing contractually enforceable guarantees as to its performance, despite the free availability of many distros built from the same source code but offering no such guarantees.

And there is no way that Red Hat would ever have been able to sustain its business without paying good money to the skilled devs it employs to keep its guarantees from bringing it undone.

Stallman, as I read him, has never been about making amateur developers the only developers. The GPLs are an attempt to stop closed-source software dominating the landscape to such an extent that amateur development goes altogether extinct, at which point mystery meat in secret sauce would become the only available meal. Not at all the same thing.
posted by flabdablet at 8:35 PM on January 18 [3 favorites]


and yet there are many developers making their living by maintaining and extending Linux, a project released under one of Stallman's licenses.

Specifically the GPLv2, a license that he grew to feel was ineffective, resulting in the GPLv3 - which has been a dead letter, especially after the failed attempt to incorporate the Affero clause (requiring release of code when one uses GPL code in their runtime) into it.

None of the GPLs prohibit selling the software that's released under them,
Explicitly, no. But the fact is that the GPLs have a clause that says that selling GPL code requires surrendering the right to sell the code, effectively poisoning the well for sales of GPL software.

What they *do* effectively prohibit is implementing trade secrets in the form of GPL-licensed software.
Except that they don't (see: PageRank), hence the existence of the Affero variants, and the attempt to incorporate them into the GPLv3.

Notably, that prohibition didn't stop Red Hat from releasing Red Hat Enterprise Linux and making good money off it by providing contractually enforceable guarantees as to its performance, despite the free availability of many distros built from the same source code but offering no such guarantees.

And there is no way that Red Hat would ever have been able to sustain its business without paying good money to the skilled devs it employs to keep its guarantees from bringing it undone.

Which sounds great until you realize that not every sort of software can (or should) work under that model. And as I pointed out above, the GPL has a clause meant to poison the direct sale of software.

Stallman, as I read him, has never been about making amateur developers the only developers.
Then, at least in my opinion, you didn't read him close enough, because I can recall reading pieces of his where he explicitly said this was his intent - turn programming into a hobby so that people would redirect their professional efforts elsewhere. Not to mention the actual origin of the GPL (not the bullshit printer driver story), where the company that extended his LISP interpreter refused to surrender the work they did to him when he demanded it because he had created the base code, and then proceeded to re-implement the features they created in his own code out of spite. There's also how he prevented the modularization of GCC specifically to inhibit the ability to develop plugins as well.
posted by NoxAeternum at 9:55 PM on January 18


Without denigrating his past contributions, I don't think RMS or his views are really representative of, or even relevant to, the modern open source community.

There has long been an ideological split in the community between two major camps, which I'll call the "ideologues" and the "pragmatists".

RMS is one of the original ideologues: to him (from what I can tell), the goal is the total democratization of computing, with the ideal end-state being one where there's basically no commercial software in the shrink-wrapped-box sense, and everyone has the ability to modify (or pay someone to modify) their software for their particular needs. The GNU Project is/was a means towards this end: a way to break the licensing stranglehold that AT&T in particular held over academic computing (in 1984 they were the Big Bad; Microsoft not really having entered the scene yet), and ensure via the copyleft license that it could never be rebuilt in the future.

But in the past few decades the community has basically been driven by the pragmatists: people who just want access to really good software and see community-driven development as the best way to accomplish that, and the GPL has the biggest community around it. Linus Torvalds has been very outspoken over the years that his choice of the GPL for the Linux kernel wasn't driven as much by ideological concerns as it was by a desire to get it in front of the largest number of developers so it could be improved. The end goal is high-quality software; the license—arguably the whole community—is a means to that end.

Today, I think the overwhelming majority of Free Software users are driven by pragmatic concerns rather than ideological ones. Linux is popular because it offers a value proposition that's very hard to beat. That value proposition arguably exists because of the license, but the license isn't the main attraction. The capabilities provided for the cost are.

Stallman's "solution" was the cult of the amateur writ large, to return programming to a hobby and end it as an industry

It's been a while since I've read RMS' manifesto, but I'm not sure I buy this. But his intent doesn't really matter; history has shown that the GPL doesn't prevent people from making money by developing software. Copyleft licenses make it intentionally hard to build a business like AT&T or Microsoft, where you build software on spec and then sell many copies of it, like you're turning out injected-molded widgets in a factory. This "industrial model" of software relies on strict licensing to create artificial scarcity and create value in individual copies of the same software, but very little of that value actually accrues to individual developers. Someone writing code at Microsoft doesn't get paid that much more than someone writing custom business logic (of which there is a lot more, in terms of lines of unique code, than shrinkwrapped software; it's just largely invisible), and it's unclear that the demand for software development labor would be that much less in an all-FOSS/all-GPL world than it is now.
posted by Kadin2048 at 9:32 AM on January 20 [1 favorite]


Stallman's "solution" was the cult of the amateur writ large, to return programming to a hobby and end it as an industry

Hot-rodding is a hobby that shares a lot of features with open source programming, but it's still the hobby and there are a zillion businesses making parts and tools to feed that hobby, not to mention the professoinal hot-rod builders that A&E or whatever cable TV station has shown all of us.

Restoring a 1949 Packard is a hobby, making a reproduction gas cap for it is (almost always) a business, but doesn't have to be. Lowering the standard for GPL compliance from ideology to pragmatism is how we get things like the Right to Repair movement. Camel's nose, etc.
posted by rhizome at 11:52 AM on January 20


« Older 1st Sedition Charges for January 6, 2021...   |   Signature’s Stephen Sondheim tribute concert to... Newer »


You are not currently logged in. Log in or create a new account to post comments.