punycode licensing

[Dmitry Belyavsky]

Dear Tim,

Sorry for the delay with the response.

On Thu, Jul 11, 2019 at 2:44 AM Tim Hudson <tjh at cryptsoft.com> wrote:

> On Thu, Jul 11, 2019 at 12:37 AM Dmitry Belyavsky <beldmit at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190804/668e0038/attachment-0001.html>