I don't have a problem with the terms of their license. Use whatever license you want — just don't call it "open source"!
From the blog post... This is problematic:
> open-source in spirit
It ain't. It is firmly in the spirit of "source available" licenses, which have a decades-long history and almost all of which do the same thing this license does: impose a field-of-use restriction to limit commercial competition.
https://en.wikipedia.org/wiki/Source-available_software
By corrupting the term "open source", they are leeching off of the goodwill created by the Open Source movement, and they shouldn't expect people to stop complaining about it until they stop.
This "it's not open-source unless you allow Amazon to profit from your charitable work" is horse hockey. I don't care if this is how a hardliner sees it. Linguistics is descriptive, not prescriptive, and this is important enough that I support the migration of "open-source" to include these restrictions. Which, as they point out, affect none of the people using their code, and only the corporations (not people!) who would abuse the goodwill created by the Open Source movement.
Well, "we" in the Open Source movement decided that it means not restricting what users do with their code.
I don't understand what's so hard about this. Overwhelmingly, the biggest players in the Open Source ecosystem have consistently been saying, "call it whatever you want, just be clear that you're not the same as us." And the response from a lot of people has been, "no, you have to let us call ourselves the same as you."
Source Available has been a term for a really long time, and its generally understood what it means, and plenty of people use the term with plenty of good will. This shouldn't be a controversy, it's such a straightforward, easy concession. There's nothing wrong with being Source Available.
So why do we need to come up with a new term that describes the freedoms we've been consistently preaching for decades just because a couple of for-profit companies want the good will that we've generated? This isn't language evolving over time, it's people outside the community trying to decide how we're allowed to define ourselves within in the community.
Yes, language is descriptive, but that doesn't mean you can just redefine anything you want any time you want. Even more than that, the fact that language is descriptive does not mean it's a bad thing for communities to try and publicize and preserve the descriptive language that already exists. Open Source advocates are hardliners on this issue specifically because we recognize that language is descriptive, and that our ability to preserve the meaning of the words that describe our community is dependent on us taking the time to educate and correct people who are genericizing those terms.
The terms might be superficially similar to some F/OSS licenses, but the reason it fails to meet the OSI or FSF definitions is precisely that it's spirit is diametrically opposed to F/OSS
The "GPL" is way more onerous. You see, one can only be truly unrestricted by being restricted into taking certain actions. Nothing Orwellian to see here.
I fear we're letting perfect be the enemy of the good here, and letting the FOSS ecosystem wither and lose incalculable value by letting trillion-dollar corporations exploit the hard work of people for free. If the choice is between "cheap Timescale on AWS run by Amazon" and "slightly less cheap Timescale on AWS run by Timescale", I'll take the latter.
I think banning FAANG from competing with the single source of revenue these FOSS companies have is a small price to pay to ensure a thriving FOSS ecosystem, and I think insisting on absolute freedom is killing the ecosystem.
Some people feel just as strongly about imposing field-of-use restrictions to exclude military entities as you do about excluding "trillion dollar companies". Others feel strongly about excluding all commerical usage.
But "Open Source" means no field-of-use restrictions — so although any of you are free to craft your own licenses excluding X, Y, or Z, you don't get to call those licenses "Open Source".
> I fear we're letting perfect be the enemy of the good here, and letting the FOSS ecosystem wither and lose incalculable value by letting trillion-dollar corporations exploit the hard work of people for free.
No economic value is lost. Timescale is free to publish their own software offings with their own licensing; those offerings merely exist outside the Open Source ecosystem.
Open Source is plenty successful. It does not need to destroy itself in order to encompass all things.
Besides, "letting trillion-dollar corporations exploit the hard work of people for free" is what Open Source has always done. Everybody gets to use it for free — trillion dollar corporations, governments, religious organizations, activists, convicts... everybody!
Sounds like public domain. What’s the difference between the two then?
Public domain, other than by copyright expiration or (in the US) federal government creation is actually not clearly possible to create in a legally unambiguous way in many regimes with automatic copyright and no direct provision for unilateral transfer to the public domain; the most permissive open source licenses approximate it while providing better legal clarity.
Open source licenses often seek to protect the originator from liability they might otherwise incur from chain-of-commerce relationships, making it safer for them to make the software available without fee, and to prevent misattribution of origin. Other open source licenses, while not having field of use limits, seek to assure that derivatives are also offered on similarly-free terms. There's quite a variety, within the bounds of certain essential guarantees that are central to the common value proposition.
(Of course this is a somewhat cynical view, and this isn't even getting into the other costs associated with second hand furniture -- anything with upholstery carries a risk of containing mold or vermin and you may need to pay more to get it cleaned/sanitized)
But disallowing such field-of-use restrictions is exactly what makes open source collaboration between otherwise competing companies possible. It is a fundamental difference between Open Source and Source Available licenses.
While Google may have done it to make their own Cloud offering better, it ultimately has succeeded in saturating the container compute market and with their own success has brought plenty of competition.
They succeeded quite well in that.
>The right to study the code running on your hardware, the right to make modifications to it, the right to distribute those modifications.
Description of the license from the linked articles:
> Rights still disallowed under Timescale License:
> No right to distribute modified Source
> No right to distribute modified Binaries, unless as part of a Value Added Product
I'm very confused on how you're reconciling your stated view on the definition of open source and the directly conflicting text of this license.
Open source is a well-defined term with a well-defined meaning. In fact, it was coined precisely because "Free Software" was considered to be too ambiguous.
Words have meaning. You can't just change the meaning of a well defined term to suite your views.
Wouldn’t it grant “the right to study the code running on your hardware, the right to make modifications to it, the right to distribute those modifications” and provide protection from FAANG profiting without reciprocating, while being OSI and FSF approved?
What everyone seems to miss here is that the GNU Affero General Public License offers the ability for people to make that choice. Cloud providers would be forced into an ugly situation if almost every single XaaS codebase switched to AGPL. Their business model depends on being able to make minor investments to provide things people want as a service and not share it with the community.
However, if the AGPL was normalized and used more often, cloud providers would be in a situation where they'd either have to A) build everything of theirs on their own if they don't like the license or B) use the software people want, release their improvements back to the community, and everyone benefits.
It's amazing how everyone has forgotten why Linux won over all the other server, mobile, and edge platforms, and is slowly inching to dominate everything else. The terms underlying most of the core Linux system software, including the kernel obviously, require things incorporating it to be released with usable sources to the public. That is what enabled individuals to sustain a project and make it into the successful juggernaut it is today.
But because Google has managed to poison the well with AGPL, we're in a situation today where "business-friendly" permissive licenses like the Apache Software License are used and companies are surprised when they get sucked dry by cloud providers abusing the properties of that license.
Companies building open source software should expect one of two things: money or code. Both are intrinsically quite valuable to them, and they should take care to nurture that those are the two valid options.
I am personally currently unaware of any AGPLv3 licensed software in use in an AWS service. That said, I would be skeptical of advice to use AGPLv3 due to any particular organization's current policy on the license.
Regarding Presto, work on the service includes changes that should go upstream. For the changes that are appropriate for upstream (e.g., ones that are generally useful, not only of benefit or interest to AWS), PRs are sent. For example: https://github.com/prestosql/presto/pulls?q=is%3Apr+author%3...
Practically speaking, it is difficult to maintain a development branch of any software project with sufficient change velocity if you have a goal of continuing to integrate improvements from the upstream version.
I think there's a serious amount of FUD around it. I suppose it's because of how rare it is. With more usage, it would probably bee seen as less dangerous.
See also [2]
I hope in the future the Elastic, TimeScale, Confluent and any other "fuck Amazon" license could be merged into one and kind of standardized on as many freedoms as possible, while keeping AWS out of it.
This kind of "screw the big guys" is something I can totally get behind -- power to them for setting the terms of their relationship with them but it's not and shouldn't be open source. And that should be okay. The right to run a piece of software for any purpose whatsoever is fundamental to the spirit of open source.
That's like trying to describe a nectarine without talking about peaches or plums. You could do it, but you could communicate more effectively if you could make comparisons to the most similar well known concept.
They are somewhat careful to make the distinction and refer to it as source available, open source in spirit, etc. I think that's fine and legitimate communication.
Source available is a less controversial term, but it's also less descriptive. It can be a wide variety of software licenses. Whereas open source is much closer to this license. I don't see the problem here, how would you communicate it if you worked in their marketing department, if you're being honest?
I'd emphasize that both an "Open Source" offering and a more complete "Permissive Source Available" offering were available. The goal would be to contrast the source-available offering favorably with closed-source proprietary offerings, rather than to invite, needlessly, a possibly unflattering comparison with Open Source.
But how about just not picking a fight with the Open Source community?
The argument over field-of-use restrictions is anything but new, so going in with the notion you're going to either win everybody over or that people are going to quietly roll over is foolish.
The other possibility is that you deliberately pick a fight with the Open Source community for the sake of publicity. Some marketers are cynical enough to do that, but I'm not — and Timescale are not taking a combative approach and don't seem to be either.
But people really ought to know by now that attempting to coopt the term "Open Source" is certain to provoke an infuriated and vocal response. This latest wave has been going on for what, a year or two by now?
That's not meaningful; there's a reason why the FSF and OSI have very similar criteria that end up being essentially identical in practical application; the value associated with F/OSS isn't on a smooth continuum that varies with proximity to those definitions, there's a very sharp cliff near the edge and this is outside of it.
That other actors are free to commercially exploit, including offering SaaS versions without restriction, the software is a major benefit against vendor lock-in for users, even if they have no desire to exercise that freedom directly, and has important effects on building a diverse, invested community around a piece of software. Restricting this to allow rent extraction, while not unethical (outside of, e.g., the ideological framework of the idealistic Free Software community, as opposed to the F/OSS for pragmatic reasons communiry) in the same way other proprietary-licensed commercial software is not unethical, does not even approximate the value of F/OSS.
Vendors can keep having proprietary rent-protection licenses, they just need to stop trying to convince the Open Source community that they are somehow pragmatically equivalent to Open Source. They aren't, even approximately, and critically that is the entire reason that vendors choose them, so they need to stop the dishonest sales pitches.
But it is nearly functionally identical, that's the fact of the matter. It's open source with one tiny restriction that matters to nearly nobody. That sounds pragmatically equivalent to me, from the definitions of those words. I find your claim more dishonest than theirs on that basis. You're trying to say it's a far cry from open source, and that's just not the case.
No, its not. Its superficially similar (in much the same way that, say, the Constitution of the USSR was superficially similar to a liberal democratic constitution), but not having key commercial uses reserved for a rent-seeking copyright owner is central to the function of F/OSS.
> It's open source with one tiny restriction that matters to nearly nobody.
It matters to lots of people; sure, very few people are likely to directly exercise it, but that others are free to exercise it is central to the value proposition of open source for other users.
Open source is a philosophy which I have always admired and it motivated my way of thinking. But I can not accept that a few large corporations want to apply their monopoly and scale to single handedly reap the benifits.
Stopping them is vitally important to preserve those exact freedoms that open source gives us.
The Open source movement was not created in an environment where there was such massive centralisation of computing resources and their financial implications. How do you know if the Open source movement itself wouldn't have started differently in an environment like today's?
> It ain't. It is firmly in the spirit of "source available" licenses
Let's put a few more of the OP's words around that:
> a source-available license that was open-source in spirit, but
https://en.wikipedia.org/wiki/The_Free_Software_Definition#T...
https://en.wikipedia.org/wiki/Debian_Free_Software_Guideline...
The litmus test has always been: "while you may not want your software used in a weapon of mass destruction (or other purpose you don't agree with), it is not free software / open source unless it can be used for that purpose" ... those are items #5 and #6 in the DFSG guidelines.
While Mr. Torvalds may have been a much richer man if he prohibited "Linux as a Service", it was the unrestricted freedom given by the GPL which allowed companies like Amazon/AWS to use Linux in the first place.
They're not Open Source. They're not Free Software. Being part of those communities requires following the norms of those communities.
Of course, a big portion of our code is licensed under Apache 2, which clearly does qualify.
From the Timescale License, for example:
https://www.timescale.com/legal/licenses#section-0-backgroun...
Thanks!
My only nitpick is the repeated statement of:
> a source-available license that was open-source in spirit
Which, um, it's not. I understand you're trying to thread a needle here and protect your business but it's not following the "spirit" of the community. You're removing a rather fundamental freedom by introducing your own license. That's rather antithetical to the whole idea of Open Source
The TSL actually lets you do a lot - almost anything, really. It's an open source license (I even used little o's!) that is designed to only prevent cloud providers from selling TimescaleDB as a service.
I can't help but wonder if they're using the phrase "open source in spirit" to leech the branding of open source (while ironically treating other companies as leeches).
The established meaning is “any non-F/OSS licenses that nevertheless provides free access to source code, which may or may not also provide some usage rights”
TSL is exactly that.
There might be some utility to a name for a new subcategory of source available, but it's not meaningfully similar to open source since it remains, ultimately, a traditional, rent-protection proprietary license. The fact that current market conditions give a very particular rent-extracting opportunity that the vendor wants to protect and the vendor focussed rent protection where the most value is...is not unusual, even if the exact current valuable rent-extraction opportunity is different than it was even a few years ago.
It doesn't really - it's been used to describe a pretty broad range of licenses. "Source available" means you can read the source but do not have all of the rights you'd get from an open source license. Which is the case for TSL.
A dedicated term probably makes sense. Some other licenses in this space have used terms like "fair licenses".
Which community are you speaking for here? "Free Software" or "Open Source"? They are separate communities with a long history of rivalry between each other.
https://www.gnu.org/philosophy/open-source-misses-the-point....
https://en.wikipedia.org/w/index.php?title=Open_Source_Initi...
When you're talking about the licenses I think it's great that you've introduced the talking points of "right to repair/improve" ... that's something which is guaranteed via DFSG (b/c you can do what you want with it), but it's great to see it called out as a more fundamental concept expressed in "non-legalese".
You're also looking at "protections" which could be called out as: "the protection from $CLOUD_PROVIDER taking our work and using it to strangle our company and the people who made it" ... probably with a different wording though.
Have you considered writing down a set of principles / protections which you could rally other businesses around as well? Something like the DFSG guidelines, but organized around protecting potential revenue streams?
What would it look like if you had another option / logo on the creative commons license picker? (ie: "$NO + $CLOUD + $MONEY")... https://creativecommons.org/choose/
What would your "Timescale Monetizeable Source Available Guidelines" look like, and could they be expressed as snappily as you've expresed "Right to Repair" and "Right to Improve"?
If you have no interest in building a business around your product, because it's a labor of love or not central to your company, then by all means use a FOSS license. Apache 2 is a great choice.
I wonder if the new license allows us to offer services on top of TimescaleDB in a multi-tenant setting. GitLab.com has metric monitoring https://docs.gitlab.com/ee/operations/metrics/ and we're considering using TimescaleDB to store these. We would not offer direct access to the database.
The relevant section in the license https://www.timescale.com/legal/licenses seems to be the prohibition to "provide any form of software-as-a-service or service offering in which the TSL Licensed Software is offered or made available to third parties to provide time-series database functions or operations, other than as part of Your Value Added Products or Services".
I'm not sure if metrics count as time-series database functions or operations.
https://www.timescale.com/legal/licenses#section-3-10-value-...
On its face, it sounds like your use case is totally allowed under the TSL (and in fact, since the TSL was initially launched in Dec 2018). We have plenty of users who build commercially-available monitoring products/services on top of TimescaleDB.
Happy to help if you'd like - our engineers are always available in our Slack Channel: https://slack.timescale.com/
UPDATED: Ha! I didn't realize I was responding to the CEO of GitLab. =)
It doesn't really matter what is opined outside of the agreement, and from this conversation, it doesn't seem crystal clear one way or another whether Gitlab's use would be considered value-added or not.
So, do you want to be a developer, project-manager, CTO, or CEO who has to determine if your use of TimescaleDB is considered value-added or not?
Also keep in mind, that to really make this determination requires a court case around the specifics of your usage and situation.
And what if they get a SCO Unix style CEO someday?
I hope we can find a better way as developers and technologists to express whether you can use software like this without vague promises that you won't be litigated, or your use case is probably not in violation of the license.
https://www.timescale.com/legal/licenses#section-3-10-value-...
3.10 "Value Added Products or Services" means products or services developed by or for You that utilize (for example, as a back-end function or part of a software stack) all or parts of the Timescale Software to provide time-series database storage and operations in support of larger value-added products or services (for example, an IoT platform or vertical-specific application) with respect to which all of the following are true:
(i) such value-added products or services are not primarily database storage or operations products or services;
(ii) such value-added products or services add substantial value of a different nature to the time-series database storage and operations afforded by the Timescale Software and are the key functions upon which such products or services are offered and marketed; and
(iii) users of such Value Added Products or Services are prohibited, either contractually or technically, from defining, redefining, or modifying the database schema or other structural aspects of database objects, such as through use of the Timescale Data Definition Interfaces, in a Timescale Database utilized by such Value Added Products or Services.
1. Is the service other than primarily a database storage service? [Yes]
2. Does it offer substantial value over a database and is it offered/marketed for a key function other than a database? [Yes, it is a monitoring system, not a database system]
3. Are users of the monitoring system prevented from defining schema and accessing database DDL? [Yes]
Of course, we _very much_ welcome feedback how to make it clearer or more explicit. Our goal is _not_ to create uncertainty.
Most people don't seem to realize that the idea behind this kind of legalese is to prevent companies like amazon from offering something like "elastic timescaledb" which is mostly an operated timescale service, eating TimescaleDB's (the company) revenue stream. Or similar things happening in either Google cloud or Microsoft Azure.
I can't really blame for that.
For Timescale this may not be as relevant, but I do wonder how a license like this would be applicable to systems like Salesforce, which allows you to define a schema of custom fields, or for someone using an Entity-Attribute-Value type of schema. What is a database operation - is summing over a dimension a database operation? Where does data end and schema begin? These licenses are entering uncharted territory.
That's actually one of the reasons we tried to frame it in terms of interfaces as well.
(Thanks for the question/interest!)
The parent poster was asking about "well, isn't it an issue with your TSL definition of 'DDL schema access' if you can store data in JSON or EAV so it doesn't have a 'fixed schema'", and my answer is: No, that's fine.
Just like it would be fine for you to store or use binary/blobs/arrays/whatever. We've seen some crazy/cool use cases like developers storing binary 3D lidar data in TimescaleDB.
In fact, with these "right-to-improve" changes, you could even modify the database to embed custom logic inside TimescaleDB to handle your protobuf format (as opposed to UDFs or application code), and it would still be permitted.
Or just pay for their managed service, you probably don't want to be fiddling around with hosting the database yourself. At least everywhere I've worked we used RDS for precisely that reason.
I don't have a dog in this fight, so to speak, as I'm not a user of Timescale. All I'll say is that I hate to see license proliferation in general, and I don't think people should refer to things as "Open Source" if they aren't using an OSI compliant license. To me, if I see a project that's using anything other than a well known, well understood, OSI sanctioned license, I get the heebie-jeebies - because I don't know what the license permits. And I don't want to invest time trying to understand the nuances and ins-and-outs of every random project specific license that comes along.
So props to Timescale for making what appear to be improvements to their license. But I'll always advocate using an off-the-shelf license when/where possible. shrug
That's why you read it...
Of course I could just "wing it", read through it, and work off my layman's interpretation and hope for the best. Or.. I could choose to stick to well understood and well known licenses that already exist.
In this case though, TimescaleDB has blog posts that describe the license in very plain language, and provide clear examples of what you can and can't do - you can basically do anything except provide it as a service. No need to "wing it".
For those people who use Timescale and really like it, and are willing to read and understand this license and then use it, I say "Great!" But in general I find license proliferation to be undesirable and would generally encourage organizations to use standard licenses.
I do think there is a need for a TSL-like license though, and I think the solution is a new type of widely accepted and understood license, rather than individual companies inventing their own TSL-like licenses.
I have no idea how that could actually come to be though.
People can't start using licenses if you don't first write them.
That said, given that they're following a more-or-less "open core" model where there's a clearly FOSS portion (Apache 2) and some non-FOSS extra features on top, I don't think that this is going to be a practical barrier. It looks like the Apache 2 portion of Timescale is substantial enough that you can package it in Linux distros and use it. So in this particular case, I think it doesn't matter whether the rest of it is technically "open source" - it very clearly isn't going to be accepted by Linux distros, and it very clearly is fine for its intended users, and both of those are okay.
You can package debs or rpms for easy install, host them on a server (or set up an apt/rpm repo) just fine even if they're not FOSS.
I have absolutely no doubt that a small but vocal minority will remain unsatisfied. I'm not surprised by this move, as there was barely anything left in the Enterprise license anyway. Personally, I think this is a great move, and one that should in theory leave that vocal minority with very little to actually grumble about.
My concerns related to the "right-to-repair" / "right-to-improve", and with vendor lock-in. These changes address my concerns handily.
It's almost as if the, in practical terms, near-identical standards of the OSI and FSF weren't just picked haphazardly from the air, but actually reflect the result of a thorough and detailed consideration of what features are necessary to unlock the value that OSI pursues mainly from a pragmatic angle and FSF pursues mainly from an ideological angle, and that all the elements of that standard I react in a way that there is a crisp rather than smooth falloff in achieving the sought-after value when not all the criteria are met.
> Really the only practical limitation that I can see now is if you're AWS you can't launch a competing service with Timescale
Preventing competitive services is the same thing as protecting lock-in and rent extraction. Now, that is a central purpose of copyright and the traditional focus of proprietary licensing, so that’s not a novel focus of licensing at all. It is, however, directly opposed to the central purpose and value of F/OSS to end-users as well as downstream developers, both from a pragmatic/economic and ideological perspective.
> That's a glaring short-coming of FOSS licenses
No, it's the central purpose and value of F/OSS licenses. It's a shortcoming from the perspective of prospective rentiers, sure, but that's not an incidental side effect unrelated to why F/OSS is sought by those who seek it; freedom from rentiers is the whole point.
All that is fine and dandy- it is clear that Timescale is open-core, with an Apache-licensed core and proprietary components, just like gitlab and other products. (Timescale is a bit more generous with their proprietary code, though, so that's nice).
I will stick with strongly favoring building on open source code, myself, despite this generous offer of no-fee license to use their proprietary software.
It restricts Customers from going to a Timescale-as-a-Service provider, but I don't see how it restricts the Customer from contracting to have a third-party support the Customer's Timescale installation (or to make changes to the codebase as a work-for-hire).
I agree w/ your assessment of their new license insofar as it being proprietary. Their old proprietary license made the product unacceptable for my use, but I am comfortable with the limitations to my rights with the new proprietary license. It has enough "right-to-repair" and ability to avoid vendor lock-in to make me feel comfortable that I could maintain a private fork of my use case was dependent on their software.
Edit:
My first paragraph was a quick-and-dirty. The child post is absolutely right. The license restricts Customers from providing Timescale-as-a-Service services.
The only restriction is that you can’t (necessarily) provide TSAAS for free. To me that’s free as in speech but not free as in beer, and is well within my personal understanding of “free software”. As the saying goes, the right to speech doesn’t imply the right to be heard; likewise, the right to inspect and modify software doesn’t necessarily imply the right to profit from it.
I don't believe Timescale is Free software or Open Source. It's proprietary source-available software. I wish all software was Free software, but I don't have the fortitude to restrict the software I use to only Free software. Timescale is "Free" enough with this license that I'd consider using it in my personal workflow, or in a business environment.
If these terms are acceptable to you, that is great, but I find the unpalatable for core infrastructure I would be investing substantially to build on top of.
What's interesting though is that businesses seem to be unable to initiate that progress on their own. You need those vocal FOSS people for that, who will tirelessly drag technology towards an ideal we'll never reach... but nobody else will get the ball rolling. FOSS as the basis for entire ecosystems of businesses that would have never existed without it makes total sense, but no business will create it out of thin air. I think this gradual opening up like with TimescaleDB is simply an effect of the wind blowing in that direction. Few will be going full speed, but nobody wants to be left behind.
Then use AGPL?
But the cloud vendor's efforts aren't typically with the software itself -- they often run the open-source version unmodified -- but rather with the operations and systems around the software.
Mongo's SSPL was trying to block this case by forcing folks to open-source all their surrounding infra (which likely AWS would never do), but at least for now, the SSPL was not accepted as an Open-Source License by the OSI.
Also, I'd argue that efforts like the SSPL are actually trying to "backdoor" the goal of "cloud protection licenses" in the first place. They are trying to bake-in a poison pill that the cloud vendors won't want to do, as opposed to having a clause that just directly speaks to the stated goal.
I personally feel like the spirit of OSD9 is primarily about not affecting unrelated programs. I think it'd be reasonable to affect related programs. I think the current version of SSPL oversteps wildly in that regard, but I feel like it could be pared back to something that would be consistent with what I'd consider to be the spirit of OSD9 (and the rest of the OSD), while still doing what it seems like the SSPL is trying to do.
In doing so, I'd focus on "such that a user could run an instance of the service using the Service Source Code you make available", and drop all the specific service examples in favor of something like "any software you have made the Program depend on, such that the Program lacks some functionality compared to your service if that software is not present (even if you have made the Program support running without that functionality)". That would be broader than the comparable boundary of the AGPL, but much narrower than the current SSPL, insofar as it would only cover things the Program has been modified to depend on, rather than surrounding hosting infrastructure.
In any case, I don't think it very likely that MongoDB would be willing to make such changes, but if they did, I think it'd be possible to arrive at a license that would pass the OSD.
Sure, but if the problem is "leeching off their software without paying for it", then being obligated to share their changes should fix the "leeching" bit. I mean, is Amazon leeching off Linux by shipping it on all their devices?
If much of the future is cloud, then getting the hyper-scalars to contribute occasional patches doesn't solve the problem of competition.
That's reflected in our post:
Some may ask, “Why create a new license - why not just compete
with public clouds by just providing the best product experience
on a level playing field?”
The problem is that the playing field is far from level.
Today, the public cloud vendors (Amazon, Microsoft, Google)
are trillion dollar corporations – the largest companies in
the world – and have a myriad of advantages that arise from
that size, including market position, pricing power, deep
balance sheets, and (what many have even called) unfair
business practices. They lock large customers into prepaid,
discounted, multi-year enterprise-wide agreements, and give
startups $100,000s of free credits.
But I think that the tech and innovation ecosystem would be much for the worst if everybody else is hamstrung when competing in the cloud, or else just have to go fully closed source and proprietary.
This is my main problem with this type of licenses, none of them really seem to have any interest in actually getting the public cloud vendors to compete or buy services or contribute (financially or otherwise) to the upstream project. It just perpetuates the problem because now your company is the one doing it by telling customers they have to sign your agreement and can never buy from any other vendor. I'm sorry if this is an overly negative assessment but I just can't see it as much more than passing the buck when there is no attempt at reciprocity, through copyleft or through some other means. (As much as I had criticism of the SSPL, at least it tried to have this)
If you're going to tell me your company is actually worth a trillion quid and can really compete with AWS then I would see your point, but otherwise I can't see a way that this is going to make the market better for anyone besides the other small fraction of companies that have come up with similar ideas of banning Amazon. (Full disclosure: I'm in the same boat and I personally refuse to purchase any products or services from Amazon, but I acknowledge I'm in the severe minority)
where the authors are hiding the implementation
from public scrutiny
Linux has an entirely different scenario for the economics around it, so from the "does this work financially" perspective the comparison isn't all that helpful.
Anyway, here's the link to license pointers in github, and you can find all code there:
https://github.com/timescale/timescaledb/blob/master/LICENSE
Source code in this repository is variously licensed under the Apache License Version 2.0, an Apache compatible license, or the Timescale License.
All source code should have information at the beginning of its respective file which specifies its licensing information.
* Outside of the "tsl" directory, source code in a given file is licensed under the Apache License Version 2.0, unless otherwise noted (e.g., an Apache-compatible license).
* Within the "tsl" folder, source code in a given file is licensed under the Timescale License, unless otherwise noted.
When built, separate shared object files are generated for the Apache-licensed source code and the Timescale-licensed source code. The shared object binaries that contain `-tsl` in their name are licensed under the Timescale License.I do wonder, in a non-free world like that, if we'd have a higher proportion of "tech giants" still in the "making software" space instead of being so advertising-centric with Google, Facebook, etc's, main revenue streams.
Still seems like a serious issue to me.
Edit: to qualify what I just said... I obviously only mean that IF their license doesn't also allow distribution of patch files. You can be OSI compliant and not allow distribution of the modified source as a "whole" so long as you allow distribution of the patches needed to get to the modified source. I didn't notice at a brief glance where the "new" (or old) Timescale license falls on this point.
Which is fine, proprietary licenses are a valid option. Just don’t pretend it's almost open source. It's a source-available proprietary license designed to prevent the kind of exclusionary rent-extraction whose absence is central to the value proposition of open source.
I wonder if Commons Clause was just too early?
Don't forget that Timescale can alter the terms of their license at any time. That's the material difference from an OSI-approved license.
Here's the relevant term of the TSL Agreement. Emphasis mine:
> (c) Distribution of Source Code or Binaries in Standalone Form. Subject to the prohibitions in Section 2.2 below, a license to copy and distribute the Timescale Software source code and binaries solely in unmodified standalone form and subject to the terms and conditions of the most current version of this TSL Agreement.
The modified agreement shall govern any new version of the TSL Licensed Software
(and all its constituent source code and binaries) that is officially released as
a complete version release by Timescale on or after such Posted Date.
The point remains that there's nothing to protect users from changes in licenses like the TSL. It's possible with FOSS licenses provided you own all copyrights but much less likely.
If you're calling your potential licensees leeches, you probably don't have Open Source in mind.
One of the things that Timescale License does (similar with Elastic, Confluent Community, etc.) is to define a "Value Added Service", and basically say you can utilize/distribute the database as part of a SaaS service or product provided that it's a Value Added Service/Product, and basically just isn't offering the (in our case) "TimescaleDB-as-a-Service".
Then it becomes a bit of reading the actual definition in the license. In our case:
https://www.timescale.com/legal/licenses#section-3-10-value-...
Unlike the other licenses, we tried to couch part of this definition is specific details that engineers could understand, e.g.
"(iii) users of such Value Added Products or Services are prohibited, either contractually or technically, from defining, redefining, or modifying the database schema or other structural aspects of database objects, such as through use of the Timescale Data Definition Interfaces, in a Timescale Database utilized by such Value Added Products or Services."
So basically one important test would be: if your SaaS service is defining the data schema, indexes, etc., all good. If your users have arbitrary DDL access to the database and do this all themselves, that would "classify" as a "database-as-a-service" offering under this definition.
There are probably other business models one could try to protect. The basic idea I think is give as much freedom as possible while also providing some protection for specific use cases that allow the creators to be compensated for their work. It benefits nobody if you create a wild west of freedoms that deny creators a way to finance their work.
That's both a practical limitation and a serious criticism of a company that markets itself as open source.
I'm curious to see if some vocal people here will still not be satisfied with anything short of a OSI-approved FOSS license. Really the only practical limitation that I can see now is if you're AWS you can't launch a competing service with Timescale by leeching off their software without paying for it. That's a glaring short-coming of FOSS licenses that really should be addressed. Until then I expect this kind of almost-FOSS license to become more popular in the future. We're seeing it from many of the recently founded open-source companies in the cloud era.