Ideally the Javascript would be freed, but making it optional might be a more feasible goal.
Ideally the Javascript would be freed, but making it optional might be a more feasible goal.
It's not clear to me why I shouldn't tolerate closed-source Javascript that I can nonetheless inspect, archive, and edit on my own machine, but I should tolerate a closed-source SaaS backend that I can't inspect, archive, or edit.
Of course proprietary software limits freedoms, but does it limit freedom more than serverside logic? There are equal legal restrictions on both codebases, but I can't even exercise fair-use freedoms with code that I literally can't touch.
Maybe I'm atypical because I work with Javascript a lot, but I don't think it's that hard to read minified JS. Modern browsers have a lot of tools to help with that -- you can set breakpoints on DOM manipulations, you can autoformat the code so it's not just a jumble of text -- you can even pause execution and add custom code to functions that can do additional logging or subvert existing behavior.
And because the industry is at least somewhat focused on minimizing bundle size, it's pretty uncommon outside of captchas for me to see obfuscated code -- most of the time, you'll only be dealing with minification.
I don't know how WASM is going to affect this -- I suspect it'll be more problematic. But I manipulate minified JS all the time. It's a very 'inspectable' language, for lack of a better term.
I suspect that's hyperbole; browser inspection tools are really good, and I regularly inspect and edit minified code. Even outside of the browser, I've patched and fixed bugs in minified 3rd-party dependencies where I didn't have access to the source code. It takes a little while to untangle the code, but it's not hard -- just time consuming.
I don't want to dismiss people who struggle with that, but I also don't think I'm that special or amazing of a coder. If I can do something, odds are pretty good that other experienced programmers can too.
But, given a choice between serverside code that you absolutely can't inspect no matter what, and a binary blob that you can read with a bit of extra work, wouldn't you prefer the binary blob?
Where serverside logic is concerned, it doesn't even matter if the underlying code is Open Source. I still can't inspect the instance and tell if it's running the correct code, or what its parameters are.
Mobile gui's without javascript would be horrendous. On top of that, that's the platform you're minifying for.
I don't minify javascript to hide what's running, I minify it because a 3KB file is a lot less to download than a 12KB file.
So what? You design an entirely new language that: A) Can't be minified (How?) B) Has to be open source C) Can't be obfuscated (virtually impossible to prevent)
I'm sorry, but the stance is kinda dumb.
But if the firmware isn't modifiable by anybody (including the manufacturer) because the capability to update it was never built in the first place, then no capabilities are being withheld from the users of that product.
Distribution rights are a lot clearer with firmware on the device and a driver in code.
With firmware on the card, the interface between the kernel and the card is likely to be more well defined and thus easier to replace either side.
The idea behind 'free' software was that you should have access to/control of the software running on your devices, not everyone else's. It was originally a pragmatic solution to a problem, not an abstract ideology that it's morphed into for some.
[1] It's up to the business in question to care about the software running on their computers.
He'd push for AGPL for that. Also Stallman doesn't like SaaS: https://www.gnu.org/philosophy/who-does-that-server-really-s...
For some, open source software isn't just seen as a "nice to have", but the only way to avoid a society where freedoms are limited by dependence on software which works against us by design.
Even if nearly everyone uses GPL for their JavaScript, you still need to go through this process for every site that may use non-free software, which is a royal pain.
Perhaps a "better" solution is to fight to have browsers check the license of JavaScript before loading it (either prompt the user, or have a browser setting for acceptable licenses), but that's a much harder battle than promoting JavaScript-less web pages, especially since the user has control of blocking JavaScript today.
https://www.gnu.org/software/librejs/
https://www.gnu.org/software/librejs/free-your-javascript.ht...
It can be a bit fickle. I recently tried to make code comply with it and it didn't initially work because I was using a non-standard version of the ISC license with one different word.
Dropping JS will just lead to a lot of non-free software written in [something else]. It's not like non-free software will suddenly stop existing. You're not banning English because of the content that might use it.
There must be a better approach to this than "I'm not running any code because some of it may be non-free".
With JS enabled any site could potentially run non-free code so this has no benefits. As far as I can tell the proposed solution wasn't to develop some tech that ensures (somehow) that all functionality JS provides is transferred to something "free-only" but rather to give up that functionality entirely. That's not a solution, that's just running away from the problem.
There's no fix for criminal activity on the internet (objectively worse than non-free code) and yet I don't think anyone (RMS included) is proposing to sever the connections just to make sure they don't accidentally encounter such activity. The more radical comparison would be "bad stuff" in society and completely isolating yourself from it.