1. a developer of a bunch of popular #npm packages publishes new, intentionally broken versions of them as he doesn't want to support for-profit companies with his free work;
2. NPM *reverts* the packages to older versions against developer's wishes;
3. GitHub *blocks* the developer for acting "irresponsibly".
Both npm projects were published under the MIT license. Publishing them under the #AGPL would make Big Tech not touch it with a ten foot pole, while allowing other free software projects to still use them.
When publishing a project, consider using AGPL. I use it for basically all my public code.
Just to be absolutely clear, as @Gargron noted in a separate thread, this is absolutely shitty of the developer to pull the rug from under everyone (including plenty of FLOSS projects, I'm sure) using his npm packages. A breach of trust indeed.
But for me it is also worth noting GitHub blocking a developer for changes made by him to his own projects.
@gargron @rysiek If you don't want to support BigTech, then don't use "permissive" licenses. Use AGPL. The problem is: Most people don't understand Copyright and licences. So they find their way to choosealicense.com which is curated by Microsoft Github. It prominently advertises the MIT licence with "I want it simple and permissive". This phrase sounds fair and good to most people. But permissive actually means "I permit BigTech to run their profit-driven thing with my code".
@t0k @ffeth @Gargron that's all correct. In practice, though, Big Tech will do anything they can to keep away from AGPL'ed code, as exemplified by Google's internal policies banning their employess and contractors from even having AGPL'ed code on their work laptops:
> Do not install AGPL-licensed programs on your workstation, Google-issued laptop, or Google-issued phone without explicit authorization from the Open Source Programs Office.
@rysiek @ffeth @gargron I wonder if that's not somehow part of a smear campaign against the #AGPL. Because technically, I see no problem for Google if its employees use some AGPL program on their laptops. They don't run publicly accessible services from their laptops.
To me feels like it's more about fighting the AGPL in general because it's bad for them. Imagine all FOSS would be AGPL: BigDisaster for BigTech.
But the other, probably *more* important part is *legal risk*. The developer might not even notice that certain functionality is provided by an AGPL-licensed lib. Or, that certain products of AGPL'ed programs were checked into the work repository.
So they prefer to "play it safe" and ban developers from having any AGPL tools on their workstations.
> Imagine all FOSS would be AGPL: BigDisaster for BigTech
Wasn't there talk of putting this “you must distribute even if over a network” AGPL thing into what would become the GPLv3? Obv that was not included in v3, hence why AGPL was created. It's a shame they didn't do that (maybe GPLv4 🤔), and instead put something against “Tivo-ization” which in retrospect was almost pointless...
AGPLv3 requires a program to offer source code to “all users interacting with it remotely through a computer network.” It doesn’t matter if you call the program a “client” or a “server,” the question you need to ask is whether or not there is a reasonable expectation that a person will be interacting with the program remotely over a network.
E.g., if I modified an AGPL browser and used it to chat with you via some website, would I need to offer the source code of my modifications to you? However, based on the previous opinions of the FSF (https://web.archive.org/web/20100630185154/https://www.gnu.org/licenses/gpl-faq.html#AGPLv3ServerAsUser ), the intention is likely no.
This wouldn’t stop me from licensing client code as AGPL, especially since it’ll likely prevent any google employee from ever using it.
🤔 The OSI (& term “open source”) was created to be “business friendly Free Software” so obv. they'd never adopt that approach.
The #FSF/“Free Software” have always tried to distance themselves from Open Source, so “going full commie” (your words) *could* be a way to do that. 🤔
(But, given how the FSF stuck with RMS, I doubt FSF would change at all that way, so alas I don't think this'd happen)
@emacsen @ebel @jollyrogue When I was reading the ethical licenses I was thinking "this doesn't seem very ethical".
For instance, a license which compels you to obey labour laws in your area. Often the labour laws are not that great, having been comprehensively trashed by successive administrations over decades. Strictly observing the labour laws may require you to do unethical things, such as opposing strikes which the government does not approve of or has declared to be an "illegal gathering". It may require you to inform authorities about unauthorized protests, and so on.
@bob very much this.
Additionally, they further fracture the commons of libre code. And that plays right into the hands of Big Tech and the like.
@bob Likewise, I'm also a little uneasy with “You must uphold human rights” because Ireland used to have a constitutional “right to life of the unborn”, i.e. an anti-abortion amendment (thankfully repealed in 2018). Anti-abortion campaigners claimed they were upholding human rights.
Since I'm pro abortion rights, how would that licence work in that environment?
Still, I think it's good that someone is trying something...
@clacke @ebel @jollyrogue the most promising direction i've seen is Kleiner's proposal of copyfarleft (Peer Production License, for ex, https://wiki.p2pfoundation.net/Peer_Production_License) and venture communism, which differentiate along class lines. This means full FOSS rights for workers and #coops and licensing terms for organizations exploit other people's labour (pay to use). Not foss, yes, argues for the need to go beyond foss. http://telekommunisten.net/the-telekommunist-manifesto/
@zeh ah yes, “copyfarleft”! I forgot about that term.
I _really_ like that it's not commerical-vs-noncommerical, but instead democratic-vs-nondemocratic orgs. I'm fine with commerical stuff
@zeh Creative Commons has some “non-commerical” licences (-NC), but I wish there was a “democratic only” version (-DO?). I'm more OK with some solo person making money from my thing, or the BBC making money with it, but not so OK with some shareholder owned medacorp...
@gargron @rysiek The #AGPL actually does allow BigTech to run your code. Also it allows to do so for profit. But it requires sharing derivative work as soon as a user interacts with it. This means: Services built on AGPL code *must* be open-source.
The usual BigTech companies will not touch the code because the are inherently not ready for ethical business models.
Companies with ethical business models like Nextcloud have no problem running AGPL code.
@ArneBab @gargron @rysiek Like it :) I was always looking for better terms. "Permissive" is misleading and "Copyleft" is not self-describing. Laypeople won't understand it. So you have a nice-sounding word against gibberish. That's quite a bias.
I was sometimes using "forever-open" and "temporarily-open". Strictly speaking not correct but more descriptive.
"Vogelfrei" is quite precise XD.
Moral should stand above the law.
And the world would be beautiful if rules would not be necessary.
Unfortunately we are humans.
There can't be freedom without rules because there is never 'no rules'.
More generally, the freedom you demand is the 'freedom of the strongest'. Without rules, the strongest will make the rules. With humans, this leads to dictatorship.
If you don't want to support BigTech, then don't use (any other) licenses. Use AGPL.
( If you don't want to support BigTech, then don't use "permissive" licenses. Use AGPL. (...) permissive actually means "I permit BigTech to run their profit-driven thing with my code")
I can't believe I'm agreeing with gargle-on.
I release my shit under the GNU GPLv3-only.
NPM was absolutely right to roll back the packages. Github was absolutely right to b& the developer and lock out changes, at least temporarily.
What's the operative difference, between what dude did here, and putting in a crypto miner, or backdoor, ssh key stealer, or password stealer, or crypto wallet stealer, or generic remote access tool?
The correct move was to hold back updates, and *maybe* release them under a new license.
@rysiek While GH obviously has the right to continue publishing an older version of the software, I wonder whether they retain the right to publish it *under the developer’s username*? That seems like something that should be covered by their TOS but perhaps they missed it?
@rysiek if a developer is pushing changes or code clearly meant only to break things reverting and blocking are absolutely the right thing to do
This feels like the freezepeach argument, context matters
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!