Do you consider it a problem? If not, why not? If so, what other than the AGPL do you propose to fix it?
Do you consider it a problem? If not, why not? If so, what other than the AGPL do you propose to fix it?
I really think the whole AGPL is simply sour grapes, because most GPL-using businesses have not figured out how to become profitable. ("open source is not a business model.") The anti-corporate, anti-business types see people exercising their software freedoms and using free software to make money, and think it's a problem that needs to be stopped.
It's interesting that TPTB have ruled such "ethical source" licenses as nonfree - you're not allowed to restrict Freedom 0 to say that users aren't allowed to, say, use the software to produce bombs. That's not a free software license.
Using it to generate revenue however, is seen as a "loophole" to be "closed".
I don't see a license that forbids the generation of revenue by selling access to a service API using a private fork as any less nonfree than one that forbids the production of bombs.
However, because you can only access their fork of a GPL project over the internet, there is no requirement for them to provide users the source code of software they're using (which is based on software developed by other people under the social contract of the GPL). Thus users are using software which is technically free software but they have no mechanism by which to excerise any of their freedoms nor even see the source code of a program they use purely because the protocol used to display the interface is HTTP rather than X (yes, it's also not running on the same computer, but from a user's perspective it doesn't matter if it runs on your computer or not -- they are using and depend on the program, even if it happens to be running on a different computer).
Do you agree that this scenario is a problem, and the GPL is not helping to solve it? If so, then you now understand the reason behind the AGPL and how it is clearly in line with the spirit of free software. If not, then I'm not sure you fully buy into the concept of user freedom. User freedom is a holistic thing, it isn't a technical definition that cares about specific implementation details.
I would argue this is a bigger issue than tivoisation, because at least with tivoisation you can at least get the source code (even though you cannot use your freedoms on the hardware you bought). In this SaaS scenario, you can't even see the source code of software you are using.
Something entirely different is happening when I'm running software on my computer, using it to provide i/o services to you, and when I provide software to you to run on your own computer.
One is a service, the other is a product. The hypothetical LibreOffice fork, with their private modifications on their own private computer, is entirely within the bounds of reason to keep those modifications private and generate revenue with it, if people want to pay them for the services they provide with it.
It's no different than me using LibreOffice to produce private documents, which I then use to generate revenue for my business. My customers have no right to access my private documents that I use to provide that service: source code is no different.
I think you're getting caught up in the "on their own private computer" part. There is a clear distinction between using a piece of software and providing a service by which other users make use of the software by proxy. In the first case, you are not acting as a proxy for other users to run the software.
> It's no different than me using LibreOffice to produce private documents, which I then use to generate revenue for my business. My customers have no right to access my private documents that I use to provide that service:
It is incredibly different, so much so that I'm not sure you've understood my hypothetical.
> source code is no different.
If you were using it purely for yourself, yes. But in the hypothetical the business is providing the ability for other users to use the software by proxy. They aren't using the software themselves and then
As a final point, consider that these days a regular user might not know whether the software they run is actually locally running on their computer or is a SaaS application where the code happens to reside on a different machine. How they use the software is no different in either case -- so why should they have different concepts of what freedoms they have? For an ordinary user there is no practical distinction between software they use on their computer versus software which is provided over the internet -- hence why I said that the only real difference is that the "display protocol" for the application is HTTP not X.
Further: If we think about cloud-based AGPL apps: For the most part we are talking about web-apps, which, in most cases, will always include JavaScript running on the user's host. Does FSF or AGPL have anything to say about this source? I ask because I am thinking deeper about your idea: What if the not-so-LibreOffice was nothing more than compiled into WASM (WebAssembly) and run in your browser... so the "server" (SaaS) was doing nothing except serving a huge binary that you run locally in your JavaScript VM. Plus, the compile from C/C++ into WASM could reasonably obfuscate the original source. I do imagine a future where lots of commercial apps are nothing more than C/C++ compiled into WASM then run through a browser. This would provide some source code privacy (that vanilla JavaScript cannot provide today) and reduce the burden of installation issues.
I never knew how much I can't stand "free" software types until today.
The AGPL does not "forbid the generation of revenue". There exist revenue-generating services powered by AGPL software.
> Nothing is being used improperly or against the spirit of free software when software freedom is exercised (by a service provider)
If that exercise of software freedom hampers an end-user from exercising their software freedom, then that's pretty clearly "against the spirit of free software".
> forbids the generation of revenue by selling access to a service API using a private fork
That's the thing - "software freedom" is being applied to software that you have no reasonable expectation of having access to:
1) you didn't write it
2) it hasn't been provided to you
3) it's running on someone else's computer
There is no reasonable basis for claiming that you have the "freedom" to access information in someone else's computer that you have nothing to do with. That's actually a privacy violation.
There's a clear distinction between sending someone a file that represents computer software (source or object code) (a product) and sending someone the output of a calculation you have been requested to perform (a service).
The distinction is meaningless to the user in the example your parent cites.
4) You're using it.
----
> access information in someone else's computer that you have nothing to do with.
1. "nothing to do with" is an absolute claim. Your line of argumentation has been heavily reliant on absolute statements, refusing to understand nuance.
2. If the user truly had "nothing to do with" some information on some computer, the AGPL places no requirement for them to be provided access to that information.
3. Interacting with a service provided by a software != having "nothing to do with" said software.
----
> ... claiming that you have the "freedom" to access information ...
For the last time, that is not how the AGPL works. I strongly urge you to go and actually read it, or even https://writing.kemitchell.com/2021/01/24/Reading-AGPL.html
Now, on to the specific rebuttal: The AGPL does not _force_ a user upon you, the service provider. It does not grant the user any "freedom" to access any information, let alone arbitrary information. It cannot even be used by a user to force themselves on you.
----
> That's actually a privacy violation.
By your line of reasoning, you have violated my privacy by way of your writing showing up on my computer. Do you see the absurdity in that?