punycode licensing

[Tim Hudson]

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.

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190711/711d1666/attachment.html>