Hacker News new | past | comments | ask | show | jobs | submit login

This. I don't care if I can see the source code if I can't actually _do_ anything with it. If I can't run my modifications in production, it doesn't guard me against vendor lock-in and it doesn't give me the right-to-repair. So what's the benefit?

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

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.


Yep. I have had the same experience since the .NET ecosystem open-sourced.

We did consider the Commons Clause when investigating our own licensing approach, but ended up concluding that its definition of "Sell" were actually much vaguer than we felt comfortable with:

  “Sell” ...a product or service whose value derives, entirely or 
  substantially, from the functionality of the Software.
I realize that opinions might differ, though.

But then you have put a limitation on use in production instead of sell? Commons Clause might be (too?) vague, but the concept is imho more fair to end users.

Still, I for one applaud you for this step. We need better non-OSS licenses and it's good to be having this discussion.


I appreciate the discussion here, and as mentioned elsewhere, this has been good motivation for us to revisit this clause in the Timescale License, as a bit has changed since we released it in 2018.

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.


I agree with the thoughts on discussion and appreciate that you are taking the time to answer this thread!

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!


> modify the source code ... before using them production

The freedom-to-modify-and-use and the right-to-repair argument are not restricted to "before using them in production".




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: