3 ms·

They could also just ask the authors of individual patches to contribute them under LibreSSL's license too.

• avar 10y ago
  You also need the permission of all the authors of the code those patches are based on, because almost all new patches are inevitably derived work of the existing codebase. It's not practical unless you can maintain a near-100% approval rate from all OpenSSL contributors that their patches are dual-licensed.
  • caf 10y ago
    If the patch is applicable to the LibreSSL codebase, then that implies it's only derived from the pre-fork code.
    • cbr 10y ago
      Let's say you have: OpenSSL: foo1(): bar() foo2(): bar() LibreSSL: foo1(): bar() Then someone realizes foo2 needs to call baz: foo2(): bar() + baz() This isn't relevant to LibreSSL and so isn't ported: no problem. Then someone else realizes that the foo2 change should also apply to foo1: foo1(): bar() + baz() While this patch will apply cleanly to LibreSSL, the idea that after calling bar() you should call baz() is something they figured out in OpenSSL, and is plausibly a derivative work of OpenSSL. The more copy-and-pasty the change is, the easier it is to be in a situation where a patch that would apply cleanly to pre-fork code would actually be dependent on post-fork code.