Hacker News Reader

Comment by kstoneman | Hacker News Reader

Seems like OpenSSL should focus on fixing their code instead of risking the alienation of past contributors. I wonder if this is to satisfy some of the big donors who want to fix OpenSSL but won't until the license is changed. I know I'd be pissed if I had contributed and then got an email saying no response implies agreement.

View on HN

I think with any larger scale open source project looking to change license they basically have to assert that no response implies agreement because of the amount of people that have contributed over time and things that this leads to, such as the probability that at least one of them might have died or otherwise have become unreachable since when they contributed.

However they might have instead used some of the donor money to hire someone to do a clean-room re-implementation of the functionality for which they couldn't get the original author's blessing to change the license of. This might have been the more respectful thing to do perhaps.

If they don't do it, and just take the code someone else contributed to the project under a different copyright notice and put it under Apache 2.0, does that mean I can fork, say, Firefox or gcc and slap an MIT copyright on the source code if not all of the contributors reply to my email asking them if they agree to it?

If no, then what percentage of contributors need to agree? Or do I need to rewrite all of the code that I get noes for?

Anyone with a potential copyright claim on the source can take legal action if they believe that their rights have been violated. If you object to OpenSSL relicensing and have contributed to it, you can sue them if they go through with it. Likewise, if you violate the license of any other software project, that project can sue you. OpenSSL is betting that the vast majority of contributors will agree, and that the rest will either not care or won't sue, and if someone does sue they're hoping that person's contributions are minimal enough that they can be removed from the codebase.

The problem is that this can happen at anytime. As a user of OpenSSL, I have no guarantee that a contributor won't, at some point in the future, decide to sue over this. Once that happens, I would have to remove their contributions from my copy [0], or risk being sued. Further, if enough time passes, and there are contributions under the new license, I would have to comply with both licences (which are incompatible).

The core problem here is not that they are changing the license. It is that it is now not clear what license is actually in effect; and it could very possibly end up being both.

The upside to this is that no one enforces these licenses anyway.

[0] Which might be a bigger deal in other contexts, for a security library, I should be staying up to date anyway.

Your Firefox fork could take inspiration from the relicensing process Mozilla followed last time. ;-)

https://www-archive.mozilla.org/MPL/relicensing-faq.html

Reply on news.ycombinator.com