It's available to _see_, but not to "prepare, compile, and test Derivative Works of the TSL Licensed Software Source Code" in a production environment, as per your license's clause 2.1 (d). That's a pretty big departure from open-source; and a bit discouraging for use by non-mega-cloud business interests too. One of the important reasons I personally use and support open-source is the freedom to not only inspect (which the TSL provides) but to also not have to ask someone else and wait on them to make any changes I need to the software I use. Any chance the TSL can be modified to include this freedom too?
Note that I am not arguing for OSS licences, but something like the Commons Clause (use freely, even for commercial use, repair as you wish, just don't sell) seems much more suitable for such cases imho. It protects the business from cloud providers, while still offering some basic protections to the users. This... doesn't.
I don't think Java would have gotten anywhere if not for the fact that most of the source code was available. Trying to divine information about Windows from the header files was excruciatingly painful.
Being able to step into the code and figure out why it doesn't like 0 in the third argument was a massive boost to my efficacy as a coder. I could add a guard and then file a very precise bug report to get the issue fixed.
“Sell” ...a product or service whose value derives, entirely or
substantially, from the functionality of the Software.
Still, I for one applaud you for this step. We need better non-OSS licenses and it's good to be having this discussion.
That said, I think a lot of this discussion misattributes the frequency of behaviors. For example, I bet the percentage of organizations that modify the source code of open-source databases like MySQL or Postgres before using them production is some tiny tiny fraction of 1%. While on the other hand, a huge fraction of TimescaleDB users (and MySQL/PG users) use it to build external-facing services and products that they in turn sell to their customers. So it was especially important to us that folks felt confident in their ability to use TimescaleDB in commercial settings.
Anyway, thanks for the thoughts.
Just to clarify: while the percentage of those who exercise this particular freedom (modifying the source and then using it in production) is probably very very small, it is an important freedom to have for a much bigger part of customers. It is an insurance policy that gives users confidence that Timescale Corp will not become user hostile - or if it does, it is still possible to make critical security fixes until a more permanent solution is found.
But I do understand it is difficult to find a solution that would please everyone. I am very curious if you will manage to find a more generic solution to this problem. :) Good luck!
The freedom-to-modify-and-use and the right-to-repair argument are not restricted to "before using them in production".
The original intent of this clause was so that we wouldn’t have to support modified versions that were deployed to production. (As pointed elsewhere, we provide a lot of free support in Slack .)
But that clause was written 1.5 years ago, and a lot has changed since then. There’s an internal debate right now on whether we should remove this restriction.
So thank you for asking this question!
_You_ may not have, but plenty of us have. Although, it's not as important when or how many times one has _needed_ to exercise one's freedoms, as it is to have them. But yes, plenty of us open-source users and supporters have exercised this very freedom. In fact, quite a lot of open-source contributions happen _because_ of this freedom: someone has an itch, they scratch it, and _then_ they upstream it.
2. I have to hope upstream accepts my change at all.
3. I have to give up the rights to my change if upstream accepts it at all.
High risk of vendor lock-in, and no right-to-repair.
> However, the issue is that companies are not able to ...
That's fine. I'm not asking any company to do something. I stating my reasons why I can't use what the company is offering. It sounds like what the company wants is to not license the code, but to sign a contract with me for a service. Would you sign a contract you don't like?
The problem isn't that changes can be upstreamed. The problem is that that is a necessary pre-condition before I can even use them.
In addition, what I say in my comment beside yours remains valid.
All the things you listed are foundational pieces of technology that are incredibly risky+costly to swap out, so if you needed to, there's an option to continue with a fork. If the thing is popular enough, there's a good chance a community-driven effort will pop up, you can find consultants to work on code for you, or even a new company will form around it, letting you continue working on your core product (mostly) uninterrupted.
Zero plans, but this also applies if a company like ours were to ever pivot/shut down: we as copyright holders can just relicense _all_ the code to be more permissive / dual licensed / etc, which is not the case for projects where individuals hold copyright over merged contributions. (Note the opposite is not true: we can't "unrelease" versions of the code already released under a more permissive license, such as how most of our code-base in Apache 2.)
In short, I understand your point, but I think there are actually multiple sides to this issue as well.
What you're saying here is that you have the ability to "give away" things that you own. Sure, but everybody has that. Even if you did not have all the copyrights to yourselves, you could relicense your portions and others could relicense their portions and others still could just replace the remaining portions with new code. In fact, this is precisely how OpenSSL recently relicensed itself completely.
Sure, what you claim you're adding here is a bit of convenience, but it's just that. When compared to the possibility that your company could "pivot/shut down" _without_ doing anything to the code, it's convenience-for-you vs. risk-for-your-customers.