3 ms·

> Most companies (including open-source companies) actually have both open-source and proprietary software, but the proprietary software is often hidden inside

> 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.

staticassertion 5y ago
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.
GordonS 5y ago
> 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.
- woofie11 5y ago
  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.

staticassertion 5y ago

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.

GordonS 5y ago

> 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.

woofie11 5y ago
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.