> Most companies (including open-source companies) actually have both open-source and proprietary software, but the proprietary software is often hidden inside private repos. The difference with Timescale is that we have made the source code for our proprietary software available (on Github), even allowing users to modify it (eg "right to repair), and made all of our software free (ie no paid software features).
So I personally like your company, but I find these sorts of marketing speak responses obnoxious. Your communications strategy here is causing brand harm, not benefit.
1) You have an open source core, with proprietary components.
2) Open source adopters get a crippled product.
3) You have a custom license for the proprietary components, which is designed to allow people to make some use of those, but is poorly-written ambiguous (preventing many types of commercial use), non-open-source compatible (preventing integration into open source projects), and requires a lawyer to review (preventing integration by smaller projects).
This feels like your Achilles' Heel.
Troll Tech tried to go down this line for years, with their QPL license. And they even had sane messaging, where whenever I read your messaging, it feels weaselly, and it changes week-to-week. Still, they didn't really take off until they went with a licensing system customers could trust and understand.
The standard dual-license model would be AGPL and commercial (or GPL+commercial).
* Most open source developers won't mind (or even notice) licenses, so long as their open source and have the nice OSI and FSF logos.
* Most commercial companies won't mind paying $$$.
Commercial customers treat you like Microsoft. Open source developers treat you like community members. Hybrid customers are okay too; if I'm working on a piece of BSD code, I can use the AGPL license on your code, while commercial users of my code can buy a commercial license from you.
And if you insist on the crazy custom license, figure out the messaging. This was better than what I read before. "Proprietary with a public repo" makes more sense than previous messaging which sounded like open source but wasn't. At that point, at least the license overdelivers rather than underdelivers. I still trust that at some point, as an adopter who can't or won't use those components, they'll become increasingly mandatory if you ever fall on hard times. The problem is still that it makes it sound like you have open source and proprietary products. You don't. You have a product with open source and proprietary components, a confused freemium model, and not something I'd ever use without consulting a good lawyer, who in turn would tell me to stay away.
There are many other good models. You could go in the other direction and close up a bit too.
The response didn't seem marketing heavy at all and directly addressed all of the points...
I see posts like yours all the time - attacking companies who believe in open source but know that the existing situation can and will lead to abuse by huge players in the market. It sounds like they have a very happy medium.
I find posts like this very frustrating because you almost never see the same kind of standards for proprietary software. People get less pushback for closed source than they do for "90% open, with restrictions on the last 10%".
As for AGPL dual license, have you tried selling AGPL software before? Even dual licensed, you've just added a massive roadblock - and it's no better than a custom license anyways, since it implies one.
Not to mention you've completely broken any path from "I'm a free user" to "I'm a paying user" - someone has to decide upfront to pay. Given that this is the most significant "win" for open source software (try before you buy, easy to inspect and get started with) it's kind of ridiculous how often I see it suggested.
Let's say I work for a company willing to pay for software. I have a hackweek where I want to try out TimescaleDB, in a world where it's AGPL or, upon payment, dual licensed. That's now dead in the water - I can't use it, AGPL is banned at every company I've worked at and we're not going to pay for me to try it out for a hackweek project.
> You have a custom license for the proprietary components, which is designed to allow people to make some use of those, but is poorly-written ambiguous
I disagree with both the tone and content of your whole comment, but this bit in particular stood out. I'm a very happy TimescaleDB user, and I really like the company and community around it too. Also, support on Slack is amazing and they are always responsive on GitHub. And of course, I have read the license - to me, it's easy to read, and the intent is very clear. I see no ambiguity.
The intent is pretty clear. Unfortunately, the actual legal language is as clear as mud:
"that does not expose or give access to, directly or indirectly (e.g., via a wrapper), the Timescale Data Definition Interfaces or the Timescale Data Manipulation Interfaces to any person or entity other than You or Your employees and Contractors working on Your behalf"
If I have a system, and it has an AJAX API, at what point am I violating this? Virtually every system I build provides customers with access to data via some API which uses "SELECT, INSERT, UPDATE, and DELETE" "via a wrapper." I have no intent of competing with TimescaleDB for hosting, but it's hard to argue that data interface don't provide some form of access to Timescale Data Manipulation Interfaces "via a wrapper."
"the customer is 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"
I won't even begin to get into this one.
If you build on this kind of legal language, you're taking on a legal liability the size of a moon crater.
The first line you quote is in a section defining rights for Internal Use (Section 2.1.a) If you are providing access to your customers, it's not internal use.
The second quote is about providing access to customers (Section 2.1.b). Note it certainly allows SELECT, INSERT, UPDATE, DELETEs (those are DML operations), it prohibits you from allowing customers to do things like `CREATE TABLE` (those are DDL operations).
This is our approach to define what it means to provide "TimescaleDB-as-a-Service" from a more technical perspective, that hopefully a developer can grok, as opposed to just stating something about "you can't compete", which is open to broader interpretation.
I think you've done a very good job of doing something which a developer will grog.
I think you've done a very poor job with doing something which a court will grog the same way.
I think that's where the astronomical potential liability comes in with respect to using your product.
A lot of 2.1.a versus 2.1.b will hinge on details of how a court will read ambiguous language like "not primarily database storage or operations products". I assume you wanted to say "not primarily database storage or database operations products." However, it could just as easily read "not primarily operations or database storage products." At that point, "operations" has broadly different meanings (e.g. business operations?).
And aside from that, if I'm making a medical database product, is that primarily "database storage?" Probably.
The problem with ambiguous legal language is that:
1) You, or a vulture successor, can plausibly sue anyone who does just about anything.
2) If we assume you vulture successor has a 20% chance of winning $20 million, the outcomes is a $4 million settlement.
Which is why good lawyers avoid it. The whole document is just bad legal language.
But even if it was GOOD legal language, it wouldn't matter. The difference between a custom-form license and a standard OSI license is that competent customers need to spend a few grand on legal fees before they use yours.
I understand what you're trying to do, but every other organization that went that way eventually went with a standard license. You'd be better off doing likewise. Or if you really can't, you're better off working to make a community-recognized standard form license which is used by enough products that it has a standard, common, recognized legal understanding.
I know the risks of the AGPL, and where it will or won't hurt me. I don't know the risks of your license, except that they're obviously huge.
Realize you might not be comfortable with the license.
For others, I can share at least that it was drafted by some of the most experienced copyright & IP counsel there is, including with significant open-source licensing experience.
But anyway, we're providing it as free software, so if you don't feel comfortable with it, you are certainly free to use our Apache-2 version. Cheers!
Terms-of-service and Facebook's employment agreement were generally drafted by experienced counsel. That means they do a good job of protecting the person on the opposite side of the table, not of protecting me.
And the term isn't "free software." It's "freemium software."
It's exactly this sort of comment which makes me distrust TimescaleDB.
I don't know about the US specifically, but here in Europe the courts take a dim view of trying to weasel around wording when the intent is clear - if the intent is clear, that's the most import thing.
Even with the EU, there isn't a "here in Europe." Europe has common law jurisdiction, like Ireland, and civil law jurisdictions, like France, and there isn't uniformity.
I don't know about civil law jurisdictions, but in the US, this license is a liability bomb.
So I personally like your company, but I find these sorts of marketing speak responses obnoxious. Your communications strategy here is causing brand harm, not benefit.
1) You have an open source core, with proprietary components.
2) Open source adopters get a crippled product.
3) You have a custom license for the proprietary components, which is designed to allow people to make some use of those, but is poorly-written ambiguous (preventing many types of commercial use), non-open-source compatible (preventing integration into open source projects), and requires a lawyer to review (preventing integration by smaller projects).
This feels like your Achilles' Heel.
Troll Tech tried to go down this line for years, with their QPL license. And they even had sane messaging, where whenever I read your messaging, it feels weaselly, and it changes week-to-week. Still, they didn't really take off until they went with a licensing system customers could trust and understand.
The standard dual-license model would be AGPL and commercial (or GPL+commercial).
* Most open source developers won't mind (or even notice) licenses, so long as their open source and have the nice OSI and FSF logos.
* Most commercial companies won't mind paying $$$.
Commercial customers treat you like Microsoft. Open source developers treat you like community members. Hybrid customers are okay too; if I'm working on a piece of BSD code, I can use the AGPL license on your code, while commercial users of my code can buy a commercial license from you.
And if you insist on the crazy custom license, figure out the messaging. This was better than what I read before. "Proprietary with a public repo" makes more sense than previous messaging which sounded like open source but wasn't. At that point, at least the license overdelivers rather than underdelivers. I still trust that at some point, as an adopter who can't or won't use those components, they'll become increasingly mandatory if you ever fall on hard times. The problem is still that it makes it sound like you have open source and proprietary products. You don't. You have a product with open source and proprietary components, a confused freemium model, and not something I'd ever use without consulting a good lawyer, who in turn would tell me to stay away.
There are many other good models. You could go in the other direction and close up a bit too.