2 ms·
An open source project can (and some do) require copyright assignment such that there is a single owner who can re-license at will. It's a fair thing to do: wo
by cryptonector 8y ago
An open source project can (and some do) require copyright assignment such that there is a single owner who can re-license at will. It's a fair thing to do: would-be contributors know this is happening and can choose to not participate.
I have no objection to owners taking a codebase proprietary. It doesn't change the fact that earlier versions stay open source and third parties (including the community) can still fork them if they want to. That's because have no objection to proprietary codebases to begin with, even though I appreciate open source, use open source, and prefer to make my code open source.
Open source is not an end for me, but a means to: a) establish/burnish the authors' reputations, b) benefit from third parties' contributions in-kind. Monetization is not so much dependent on whether a codebase is open source or proprietary, nor on its license, but on the codebase's value (to others) including the value of future development on that codebase.
Monetizing infrastructure software can be very difficult, especially when it is a commodity, but SQLite3 has succeeded at that https://news.ycombinator.com/item?id=17819950 https://news.ycombinator.com/item?id=17819950
- Sir_Cmpwn 8y ago>An open source project can (and some do) require copyright assignment such that there is a single owner who can re-license at will. It's a fair thing to do: would-be contributors know this is happening and can choose to not participate. I spoke directly to this point in my article, grep for "CLA". >but SQLite3 has succeeded Note that SQLite3 succeeded and is open source.
- cryptonector 8y agoYes, I thought both of those points were clear enough. The first I wanted to make here in the comments, and the second I thought I mentioned SQLite3 is in the public domain...
- XiZhao 8y agoI think inverting the power structure between maintainers and contributors is good for openness. The tradeoff here is it makes the project harder to govern and maintain, which an have its own unintended consequences.