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

Is this really an issue in practice? For libraries (react, jquery) that can’t be used on their own as a product, a lot are adopting MIT. For a “service” - mongodb, redis, rabbitmq, Kafka, Postgres, etc. I have never run into an issue where I would be comfortable modifying something, rebuilding source and deploying into production.





> I have never ...

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


Is that not possible under this license, to upstream a change? It sounds like you can’t put the change into production without it first being accepted, but not that you couldn’t contribute in other ways. I get the spirit of your argument. However, the issue is that companies are not able to make open-source compatible, permissive licenses that allow commercial use due to the new reality that creating a service and supporting a product are the main moneymakers. The code is not itself valuable to them but it is valuable as a holistic system because it’s an already built and adopted and production ready standardization of an idea.

1. I have to wait until upstream accepts it before I can use my own change in my own production.

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?


I run a bunch of forks in production that the maintainers didn't want to merge in. Then they made breaking changes... Software doesn't necessary need to be updated all the time. Adding more features often make the program slower and break stuff, the hardest part of dev is to say no to new features, its much easier to implement new features then solving though problems.

Absolutely possibly to upstream changes. People have, and we welcome contributions:

https://github.com/timescale/timescaledb/blob/master/CONTRIB...


> Absolutely possibly to upstream changes.

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[0] beside yours remains valid.

0: https://news.ycombinator.com/item?id=23275370


It's also a hedge against the company/project shutting down or pivoting in a radically different direction than you want.

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.


A slightly different perspective of our licensing/copyright approach is there isn't confusion about ownership, so if we were ever to decide on a more permissive license, we have the clean ability to do so.

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.


This cuts both ways. MongoDB Inc., back when MongoDB was AGPL-only, wouldn't accept contributions without copyright assignment, which allowed them to go proprietary when they did.

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.




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

Search: