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

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: