Dear Tim, Sorry for the delay with the response.
On Thu, Jul 11, 2019 at 2:44 AM Tim Hudson <t...@cryptsoft.com> wrote: > On Thu, Jul 11, 2019 at 12:37 AM Dmitry Belyavsky <beld...@gmail.com> > wrote: > >> Dear Tim, >> >> Formally I am a contributor with a signed CLA. >> I took a code definitely permitting any usage without any feedback, >> slightly modified it (at least by openssl-format-source and splitting >> between header and source), and submitted it as my feedback to OpenSSL. >> >> I still think that it will be a good idea if Adam signs the CLA, but if >> he declines, we still have a correct interpretation. >> > > In your ICLA it contains the instructions you have to follow (reproduced > here to save you time): > > 7. Should You wish to submit work that is not Your original creation, You > may submit it to the Foundation separately from any Contribution, > identifying the complete details of its source and of any license or other > restriction (including, but not limited to, related patents, trademarks, > and license agreements) of which you are personally aware, and > conspicuously marking the work as "Submitted on behalf of a third-party: > [named here]". > > > Your current PR at https://github.com/openssl/openssl/pull/9199 does not > actually do this - basically you have to have punycode.c, punycode.h in a > separate submission not intermixed with anything else. > > The reason for not intermixing the code should be pretty clear - as we > need to know which parts belong to someone else and aren't covered by your > ICLA and which parts are - with no possibility of confusion. > > You would also need to include the *license* that those files are under > which you have not done so - which according to the RFC is: > > Regarding this entire document or any portion of it (including > the pseudocode and C code), the author makes no guarantees and > is not responsible for any damage resulting from its use. The > author grants irrevocable permission to anyone to use, modify, > and distribute it in any way that does not diminish the rights > of anyone else to use, modify, and distribute it, provided that > redistributed derivative works do not contain misleading author or > version information. Derivative works need not be licensed under > similar terms. > > Separately, Rich Salz indicated he had email from the author with respect to > being willing to license under the Apache License 2.0 which you would need to > get directly from the author (or Rich would need to be the submitter). Only > the author (actually copyright owner) can change the license terms of code > they create. This isn't about the license. > > You really should reach out to the author to ask if he is willing to sign an > ICLA - that is the normal steps involved. > There is nothing particularly onerous in the ICLAs - they are basically there > to provide certainty and a legal background for the project to be able to > provide the code that it does. > > You should also note that the license noted in the RFC misses many of the > provisions within the ICLA and within the Apache License 2.0 itself and is > incompatible with the Apache License 2.0 because it contains restrictions and > conditions beyond those stated in this license. > > After all the work that the project did to be able to move to its current > license (and a lot of that work was Rich Salz's efforts) it is important that > we maintain the foundation of the clear license terms for the entire code > base. > > Unfortunately, the author of the code did not respond to my letter in which I asked him whether he agrees to sign the ICLA and close the discussion. Do I correctly understand that for now, the best solution is just reimplementing the punycode encoding/decoding myself to avoid all the conflicts? It's a solution I do not like, but if OMC insists, I will do it. Thank you! -- SY, Dmitry Belyavsky
