As I keep saying, yes it is possible to create something similar to a webapp that is Free software. [0]
But, let's take a look at the actual technologies behind the "web":
1. A naming system/transport protocol
2. A document markup language
3. A virtual machine for sandboxed code.
(2) is user-friendly (PoLP). But creating a Free app implies ignoring the defining "web" features of (1) and (3)!
If a single user is the only one accessing a given name, then that naming system has basically been made irrelevant. (If multiple users are accessing a given name, then per HTTP only one is in control of that name, and thus we deviate from free software).
If a user controls updates to the code and (in theory) audits it, then the primary purpose of the sandbox (executing random third-party specified code) is gone. The battle-hardened sandbox is nice for security, but the functionality is otherwise indistinguishable from any other language.
Why should such an app be called a "webapp" if it does not utilize most web features?
> based on your previous statements you're assuming a multi-user registration model with a centralized database you find on every commercial site which is a pre-requisite to monetization
I am not assuming this - I am noticing that a large majority of released projects are. Either due to lack of developer thought about repudiating "web" assumptions, or deliberate corporate "free-washing".
Platform defaults end up defining the culture of a platform. A good question to ask yourself - if you were designing a Free calculator app and wanted to show a friend, would you send them the files you're editing and they'd set it up on their own httpd to try it out, or would you end up sending them a URL to your server and thereby undermine their freedom?
[0] Although as I've said, many of those PHP etc apps are not actually Free - for instance the blog platforms.
> If a single user is the only one accessing a given name, then that naming system has basically been made irrelevant.
No. It's not irrelevant at all. It's how you "execute" that specific software. It serves the same purpose as a filename for a binary on a filesystem.
> If a user controls updates to the code and (in theory) audits it, then the primary purpose of the sandbox (executing random third-party specified code) is gone.
No. An audit is never perfect and that even assumes you perform one. While I frequently modify the software I utilize, I almost never audit the entire codebase, so a sandbox is quite useful.
> if you were designing a Free calculator app and wanted to show a friend, would you send them the files you're editing and they'd set it up on their own httpd to try it out, or would you end up sending them a URL to your server and thereby undermine their freedom?
I did just that. I sent them a URL. Here's the rub, it's a purely front-end only web app. No backend. That means their browser downloads the entire codebase instantly. The codebase is easily accessed, saved, and modified by them, if they want to.
The calculator was possible over a decade ago. With some of the stuff hitting JavaScript within the last few years, you can literally build anything you want in that fashion. Games, communication apps, etc.
> The codebase is easily accessed, saved, and modified by them, if they want to.
This is harder than it already being local, or apt-get install turning into apt-get source. Likely, if they find your app interesting they will keep using it directly from your URL and end up at your mercy.
And that's the crux of my point - the assumptions of the platform are at odds with software freedom. Not in a way that is incompatible - as this is computing, we are always free to ignore the properties an abstraction provides and build a completely new one over it.
Your argument is analogous to a C programmer insisting that if one just follows the rules, C is just as expressive and safe as a higher level language. People are not perfectly rigorous, and the properties of the basic abstractions matter.
"Web" implies executing code off of a third-party server. Yes, there is a pathological case of having your own server (and that may become more popular one day), but that does not change the term's current wider definition and the general culture around it.
> This is harder than it already being local, or apt-get install turning into apt-get source. Likely, if they find your app interesting they will keep using it directly from your URL and end up at your mercy.
You have the same issues with the centralized package distribution system you're pushing? You're reliant on a 3rd party. How many apt-get the source? Saving source on a front-end web app is as simple as clicking "Save As" in the browser and you get the bonus of not having to compile anything. It'll just work.
> Your argument is analogous to a C programmer insisting that if one just follows the rules, C is just as expressive and safe as a higher level language.
Not quite. You're simply not seeing the levels of abstraction present in your ecosystem because you're used to them. Centralized repositories, binaries, toolchains, etc.
> "Web" implies executing code off of a third-party server.
If you follow this logic, your apt-get example is executing binaries off a 3rd party server. You sure you want to go there?
Yes, I'll happily go there - it's a flaw. I'm not "pushing" apt, I used it as an example with a slightly better way of handling source. At this point, I probably should be running Gentoo/Nix/Guix (but I should also be running Qubes) but my investment in Debian has been too compelling. I'm well aware of sticky path dependence retarding progress, which is exactly why I'm nonplussed about working around the base assumptions of the "web" to make free software.
But, let's take a look at the actual technologies behind the "web":
1. A naming system/transport protocol
2. A document markup language
3. A virtual machine for sandboxed code.
(2) is user-friendly (PoLP). But creating a Free app implies ignoring the defining "web" features of (1) and (3)!
If a single user is the only one accessing a given name, then that naming system has basically been made irrelevant. (If multiple users are accessing a given name, then per HTTP only one is in control of that name, and thus we deviate from free software).
If a user controls updates to the code and (in theory) audits it, then the primary purpose of the sandbox (executing random third-party specified code) is gone. The battle-hardened sandbox is nice for security, but the functionality is otherwise indistinguishable from any other language.
Why should such an app be called a "webapp" if it does not utilize most web features?
> based on your previous statements you're assuming a multi-user registration model with a centralized database you find on every commercial site which is a pre-requisite to monetization
I am not assuming this - I am noticing that a large majority of released projects are. Either due to lack of developer thought about repudiating "web" assumptions, or deliberate corporate "free-washing".
Platform defaults end up defining the culture of a platform. A good question to ask yourself - if you were designing a Free calculator app and wanted to show a friend, would you send them the files you're editing and they'd set it up on their own httpd to try it out, or would you end up sending them a URL to your server and thereby undermine their freedom?
[0] Although as I've said, many of those PHP etc apps are not actually Free - for instance the blog platforms.