Anyone debating that it's not has a screw loose.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495721#17
The follow on questions on that thread seem to be fairly hypothetical handwringing, and something I’d expect the FSF to submit an amicus brief, giving their fairly reasonable FAQ answers, if it ever did show up in court. Given that the GPLv3 (and its derivative, the AGPLv3) allow for up to thirty days to remedy shortcomings, your source code being unavailable for a few hours while GitHub is down seems like a non issue.
I am a proponent of software freedom, and resultantly I view the AGPL as nonfree.
Freedom includes freedom to have privacy. Not distributing any software, my privacy should not be violated.
Running an ASP off a private fork is not "loophole", any more than, say, using free software to make missiles or killing machines.
I feel like the AGPL is just anticapitalist fist-shaking.
You have that. The AGPL provides rights to _users_ of your software; that's it, no one else. If _you don't provide_ the modified software to someone, they can't demand your private patches. No one can "bring down the machinery of state copyright enforcement" against you, unless you interact with them first and provide them your modified software and they use it.
And even when you do that — when you provide your software to someone — they still can't demand that you "publish" your private patches. Only that you give to _them_ the modified software under the same rights that you received the original software. Only to _them_, not the public. No publishing required. _They_ are free to publish the software they received, of course, as were you when you first received the original software; but you aren't obligated to publish it.
----
The only difference between AGPL and GPL is that the definition of what constitutes "distribution" of software is extended. The AGPL changes only "distribution" and nothing else in the GPL.
Depending on the software, according to the author of said software, it can be. I'm not saying this is the case for all software, but for some kinds of software it makes sense.
> Running an API business shouldn't force me to distribute anything to anyone.
"Running an API business" does not "force" you to "distribute anything to anyone". Using software that was clearly meant, by its author, for the provision of a service and licensed as such to you is what requires you to do anything. And the AGPL is very tame at that:
1. you don't have to distribute non-AGPL3 and non-GPL3 code;
2. you don't have to distribute to just about anyone, only your users; and
3. you don't have to distribute anything _you haven't modified_.
----
If you were given the freedom to modify a software, then not providing users of this modified software the same freedoms you received is loss of software freedom, don't you see?
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.
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.
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.
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.
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?
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.
We actually designed the Timescale License to be _less_ restrictive than AGPL. It contains no virality. It just prevents public clouds from offering TimescaleDB-aaS.
Timescale license does not provide that, so obviously it's more restrictive than even the most viral of open source licences.
To be specific, the sentence "the customer is prohibited, either contractually or technically, from defining, redefining, or modifying the database schema or other structural aspects of database objects," spits in the face of all the ideals of open source. I can respect your decision to choose such a license, there are understandable practical arguments for that, but I can't respect you calling that open source - if you consider that users should be restricted with what they can do with their data schemas, if you include an explicit anti-user-freedom clause, legally mandating software developers to be hostile to their own users - then at least have the guts to openly say that you are against open source (because of all the valid reasons you have, I'm not denying that, you don't have a duty to be pro-open-source), instead of misleadingly labeling your license as such.
The sentence you quote is actually meant to -technically- establish a basis for what it means for somebody to run/offer TimescaleDB as part of a value added service (very much allowed) versus a company like AWS offering TimescaleDB purely as a DBaaS offering (not allowed).
There are many, many thousands of companies that use or embed TimescaleDB as part of their service or product offerings, serving huge numbers of customers. We're extremely supportive of their ability to do so. We have no "enterprise features" that are excluded or held back only to paid users.
What we aren't supportive of is AWS running "TimescaleDB-as-a-Service" as part of AWS RDS. Because we know they do that!
The clause you are quoting helps define some of the legal nuances how we get there, ideally in ways that an engineer would understand. In particular, what it means to be a value added service/product versus just "TimescaleDB-as-a-Service".
The alternative legal formulations of this can be found in, e.g.
- Confluent Community License ("Licensee is not granted the right to, and Licensee shall not, exercise the License for an Excluded Purpose. For purposes of this Agreement, “Excluded Purpose” means making available any software-as-a-service, platform-as-a-service, infrastructure-as-a-service or other similar online service that competes with Confluent products or services that provide the Software.")
- Polyform "Shield" License ("Any purpose is a permitted purpose, except for providing any product that competes with the software or any product the licensor or any of its affiliates provides using the software.") https://polyformproject.org/licenses/shield/1.0.0/
These are all getting to similar places, but just putting more emphasis of the legal definition of "competition", which we thought would frustrate engineers with its vagueness.
That restriction makes the license not Open Source. Open Source licenses MUST allow anyone to run the software, for any reason, by definition. Even "as-a-Service". It's a perfectly fine restriction to have, but it shouldn't be called an Open Source license.
(Timescale engineer here)
While AGPL is a value-add for many, TSL isn't as ambiguous in some regards and provides a lot of nice "we won't sue you for this" clauses for users. Clear communication regarding its FOSS status will only help!
That's why Open Source came up in the first place - pointing out that one of the basic reasons for the Timescale license to exist in the first place is to restrict one of the major reasons Open Source licenses exist.
There were also no claims about whatever definition of restrictive you were using. It was just a short statement that the Timescale license was designed to be less restrictive than the AGPL. You can't really be that surprised when somebody comes along and starts judging it by Open Source standards after that, can you?
Comparisons to Open Source and discussions of the pros and cons of both approaches are, of course, fair.
I think Timescale employees should remember to preface "This is our belief on the definition of restrictive" when describing the license as more open than open source licenses, given much of the community might disagree (sometimes vehemently) about that take.
Incidentally, that clause exists as a clear line for value added products and services. Some companies have a restriction that says, "You can't compete with us." That approach struck us as arbitrarily blurry. We took a clear approach that says DML (inserting, querying data) is permitted, but not DDL (creating tables). Again, this is to clearly restrict TimescaleDB-aaS providers and not other companies building true value added products / services on top (e.g., IoT platforms, SaaS companies).
Why not toss in an AGPL license option? You wouldn't be discounted off-the-bat by folks like me. I build open source. Timescale is not open source. Timescale won't mix with GPL code. I use plenty of GPL code. GPL/AGPL are known quantities. Your license requires legal review.
As a footnote, I do pay for hosted versions of most of the databases I use.
> TimescaleDB is a relational database for time-series, with some features licensed under the Apache 2.0 License but many of the features you know and love are licensed via the Timescale License (including continuous aggregates, compression, data retention policies, actions, multi-node, and more). The "Apache 2.0" version of TimescaleDB offered by Microsoft, Digital Ocean, and others includes only the features in the Apache license. The Timescale License prohibits cloud providers from offering the "community version" of TimescaleDB-as-a-service.
But I don't find any links to download the Apache 2.0 version, there or elsewhere…
By the way, I really hope you guys are able to strike a deal with the cloud providers for them to re-sell Timescale Licenses, so people can get all the great features and pay you without having to add a new vendor relationship!
Re: Apache 2.0 only version, it is on our Github readme (but yes, probably could be made more prominent):
Apache-2 licensed binaries can be built by passing -DAPACHE_ONLY=1 to bootstrap.
It's ubiquitous ("it's me, not you"), but I hate it.
I'd much rather get a straight "no."
To answer the non-answer: I don't want a crippled version of the product with features held back for paying customers. I don't know which other features will be held back in the future, or what the evolution of the system will be. My expectation is that at some point, I'll need e.g. features to comply with a law like GDPR, and some critical feature may be withheld in an attempt to monetize me.
When that happens, I end up in limbo.
With a half-open-source project, what do you do? Do you fork the system and build the feature yourself? It will never move into mainstream since it undermines your revenue source. Do you maintain a fork? No one will use your fork over mainstream and you have competing communities. Etc.
Having built systems which have been used and maintained for decades, those sorts of considerations matter much more for picking a long-term viable solution than which technology happens to be ahead this year. I'm not saying you're going to burn me (and usually by the time this happens, you've been acquired by Oracle like Java, went bankrupt and got picked up by vultures, like SCO, hired a massive number of mediocre people, like Google), but if you make a dozen decisions like this, someone WILL burn you, and that WILL cost you more than the other 11 decisions combined.
Make it easy on customers like me.
Heads up: calling out the virality of copyleft licenses as a "restriction" is a common tactic used by the anti-FOSS brigade — this includes the likes of Microsoft under Steve Ballmer that famously called the GPL "a cancer". So it seems like you're re-using old FUD tactics, even if you don't intend to.
Putting that aside, what you claim also happens to be an established point of argument that has been already heavily debated upon in the FLOSS community, specifically by the permissive licenses' side; and they actually have some truth to the claim. Your claim, instead, is nowhere near as strong as theirs.
Permissive licenses take away virality, sure, but add little-to-no restrictions of their own. Your license, OTOH:
1. Doesn't take away nearly as much virality — Derivative Works of code under the TSL are still subject to the TSL; and
2. Adds its own set of restrictions — quite a few of them, actually.
----
If your argument was that you "designed the Timescale License to be less restrictive than AGPL _specifically on the question of virality_", you'd be right. Because the TSL also adds a bunch of restrictions, your original claim does not quite stand up.
And to those who keep downvoting my comments simply because they don't agree with them - I always welcome thoughtful discussions. :-)
edit: And FWIW, I have dropped this claim from the post with a note, especially since it was not my point anyways.
AGPL is somewhat controversial, but the reasoning for AGPL to exist is chiefly to protect the end user's rights, however misguided that may be in your opinion. In this case Grafana presumably retains the copyright to these programs, so presumably they are not beholden to these restrictions in any way. On the other hand, though, it does mean that other providers will have to distribute their patches back to the community, which is pretty much the entire goal of copyleft open source in the first place.
In any case, this is, in my opinion, a lot better than SSPL or the Timescale license.
[1]: https://www.processmechanics.com/2018/10/18/the-server-side-...
edit: wording regarding AGPL was changed, because the claim that considering AGPL as not open source is “somewhat controversial” isn’t quite accurate; it’s more correct to say the license itself is simply controversial.