Re: punycode licensing

[Dmitry Belyavsky]

Dear Tim,

Sorry for the delay with the response.

On Thu, Jul 11, 2019 at 2:44 AM Tim Hudson  wrote:

> On Thu, Jul 11, 2019 at 12:37 AM Dmitry Belyavsky 
> 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

Re: punycode licensing

[Dmitry Belyavsky]

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.

On Wed, Jul 10, 2019 at 1:43 PM Tim Hudson  wrote:

> Previous assertions that if the license was compatible that we don't need
> a CLA in order to accept a contribution were incorrect.
> You are now questioning the entire purpose of contributor agreements and
> effectively arguing they are superfluous and that our policy should be
> different.
>
> You are (of course) entitled to your opinion on the topic - however the
> project view and policy on this is both clear and consistent even if it is
> different from what you would like to see.
>
> If someone else wants to create a derivative of the software and combine
> in packages under other licenses (Apache License or otherwise) without
> having CLAs in place then that is their choice to do so as long as they
> adhere to the license agreement.
> Again, all of this is use under the license. What our policies cover is
> for contributions that the project itself will distribute - and entirely
> separate context for what others can do with the resulting package.
>
> The CLAs are not the same as code being contributed under an Apache
> License 2.0.
> There are many sound reasons for CLAs existing, and discussion of those
> reasons isn't an appropriate topic IMHO for openssl-project.
>
> Tim.
>
>
>
> On Wed, Jul 10, 2019 at 8:08 PM Salz, Rich  wrote:
>
>> Thank you for the reply.
>>
>>
>>
>> *>*The license under which the OpenSSL software is provided does not
>> require "permission" to be sought for use of the software.
>>
>> See https://www.openssl.org/source/apache-license-2.0.txt
>> 
>>
>>
>>
>> Use, as defined by the license, doesn’t just mean end-users, and it is
>> not limited to compiling, linking, and running executables.  A recipient
>> can make derivative items, redistribute, and so on. All of those things are
>> what OpenSSL would do if it “took in” code into the source base.
>>
>>
>>
>> So why does the project require permission from other Apache-licensed
>> licensed software? In other words, why will the project not accept and use
>> the rights, covered by copyright and license, that it grants to others?
>>
>>
>>
>

-- 
SY, Dmitry Belyavsky

Re: punycode licensing

[Salz, Rich]

I will take the hint and stop commenting on this thread.

Re: punycode licensing

[Tim Hudson]

Previous assertions that if the license was compatible that we don't need a
CLA in order to accept a contribution were incorrect.
You are now questioning the entire purpose of contributor agreements and
effectively arguing they are superfluous and that our policy should be
different.

You are (of course) entitled to your opinion on the topic - however the
project view and policy on this is both clear and consistent even if it is
different from what you would like to see.

If someone else wants to create a derivative of the software and combine in
packages under other licenses (Apache License or otherwise) without having
CLAs in place then that is their choice to do so as long as they adhere to
the license agreement.
Again, all of this is use under the license. What our policies cover is for
contributions that the project itself will distribute - and entirely
separate context for what others can do with the resulting package.

The CLAs are not the same as code being contributed under an Apache License
2.0.
There are many sound reasons for CLAs existing, and discussion of those
reasons isn't an appropriate topic IMHO for openssl-project.

Tim.



On Wed, Jul 10, 2019 at 8:08 PM Salz, Rich  wrote:

> Thank you for the reply.
>
>
>
> *>*The license under which the OpenSSL software is provided does not
> require "permission" to be sought for use of the software.
>
> See https://www.openssl.org/source/apache-license-2.0.txt
> 
>
>
>
> Use, as defined by the license, doesn’t just mean end-users, and it is not
> limited to compiling, linking, and running executables.  A recipient can
> make derivative items, redistribute, and so on. All of those things are
> what OpenSSL would do if it “took in” code into the source base.
>
>
>
> So why does the project require permission from other Apache-licensed
> licensed software? In other words, why will the project not accept and use
> the rights, covered by copyright and license, that it grants to others?
>
>
>

Re: punycode licensing

[Salz, Rich]

Thank you for the reply.

>The license under which the OpenSSL software is provided does not require 
>"permission" to be sought for use of the software.
See 
https://www.openssl.org/source/apache-license-2.0.txt

Use, as defined by the license, doesn’t just mean end-users, and it is not 
limited to compiling, linking, and running executables.  A recipient can make 
derivative items, redistribute, and so on. All of those things are what OpenSSL 
would do if it “took in” code into the source base.

So why does the project require permission from other Apache-licensed licensed 
software? In other words, why will the project not accept and use the rights, 
covered by copyright and license, that it grants to others?

Re: punycode licensing

[Tim Hudson]

On Wed, Jul 10, 2019 at 1:58 AM Salz, Rich  wrote:
> Thank you for the update. This brings to mind a few additional questions:
>
> 1. Does other code which is copyright/licensed under the Apache 2 license
also require CLAs?
See points 1-3 of previous email. CLAs are required for anything
non-trivial.

> 2. Does other code which is in the public domain also require CLAs?
See points 1-3 of previous email. CLAs are required for anything
non-trivial.

> 3. Does OpenSSL expect that anyone using OpenSSL and bundling it with
Apache 2 software must first ask the project for permission?

That is an entirely separate question and all the project states is the
license under which we offer the software.
That question can be more broadly worded as "Does OpenSSL expect that
anyone using OpenSSL must first ask the project for permission?"

The license under which the OpenSSL software is provided does not require
"permission" to be sought for use of the software.
See https://www.openssl.org/source/apache-license-2.0.txt

So in short the answer is "no" because the software is under a license that
doesn't require permission to be sought for its use.

> 4. Assuming #1 is yes and #3 is no, can you explain why there is a
difference?

Because 1 and 2 are about *contributing *code that the project then offers
under a license, whereas 3 is about *using* the produced code under its
license.
They are completely different contexts (one in-bound, one out-bound).
And they are completely different entities (1&2 are about requirements
the *project
*places on contributions, and 3 is about requirements the license places on
*users* of the software).

Tim.

Re: punycode licensing

[Short, Todd]

This is the second time, that I'm aware of, that the wording of the CLA has 
prevented a PR from being accepted.

While this won't help the first case I'm aware of, perhaps there needs to be an 
exception/special-case in the CLA for code in RFCs, or other similar 
publications, where the author is basically saying "you can use this". The 
motive of the author may very well be done at the point of RFC publication, and 
has no interest in personally submitting the code to every open source project 
that may want it. As far as the authors are concerned, putting it into the RFC 
is sufficient.

--
-Todd Short
// Sent from my iPhone
// "One if by land, two if by sea, three if by the Internet."


On Jun 24, 2019, at 5:42 AM, Salz, Rich 
mailto:rs...@akamai.com>> wrote:


  *   Unfortunately, the issue isn't the compatibility of the license - they do 
indeed look relatively compatible to me - and the discussion on this thread has 
so far been about that.
  *   However the contributor license agreement requires that the copyright 
owner grants such permission - it is the fundamental basis of contributor 
agreements.

Yes, compatibility is important. CLA’s are required only for new code 
contributed to the project, not for code incorporated from elsewhere.  So if 
it’s compatible, CLA’s are not required.

At least, that was the position of the project and its former counsel during 
the first two years of relicensing.  Perhaps the OMC should raise this issue 
with current counsel if they disagree, but from the public statements on this 
list, it seems all but one agree.

As an aside, I’ve contacted the author and am having a productive exchange.  
Dimitry has seen the emails.

Re: punycode licensing

[Salz, Rich]

  *   Unfortunately, the issue isn't the compatibility of the license - they do 
indeed look relatively compatible to me - and the discussion on this thread has 
so far been about that.
  *   However the contributor license agreement requires that the copyright 
owner grants such permission - it is the fundamental basis of contributor 
agreements.

Yes, compatibility is important. CLA’s are required only for new code 
contributed to the project, not for code incorporated from elsewhere.  So if 
it’s compatible, CLA’s are not required.

At least, that was the position of the project and its former counsel during 
the first two years of relicensing.  Perhaps the OMC should raise this issue 
with current counsel if they disagree, but from the public statements on this 
list, it seems all but one agree.

As an aside, I’ve contacted the author and am having a productive exchange.  
Dimitry has seen the emails.

Re: punycode licensing

[Viktor Dukhovni]

On Thu, Jun 20, 2019 at 03:39:10PM +0100, Matt Caswell wrote:

> PR 9199 incorporates the C punycode implementation from RFC3492:
> 
> https://github.com/openssl/openssl/pull/9199
> 
> The RFC itself has this section in it:
> 
> B. Disclaimer and license
> 
>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.
> 
> Which is quite confusing because on the one hand it places a requirement on
> redistributed derivative works:
> 
> "provided that redistributed derivative works do not contain misleading author
> or version information"
> 
> and then on the other hand states that derivative works are free to licence
> under different terms:
> 
> "Derivative works need not be licensed under similar terms"
> 
> It seems to me that the above gives us the ability to just relicense this 
> under
> Apache 2 and incorporate it. But I'm not entirely sure.

I'd be comfortable with relicensing under Apache, while clearly
indicating the provenance of the code, and indicating that the
file is also available under the original terms.

-- 
Viktor.

punycode licensing

[Matt Caswell]

PR 9199 incorporates the C punycode implementation from RFC3492:

https://github.com/openssl/openssl/pull/9199

The RFC itself has this section in it:

B. Disclaimer and license

   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.

Which is quite confusing because on the one hand it places a requirement on
redistributed derivative works:

"provided that redistributed derivative works do not contain misleading author
or version information"

and then on the other hand states that derivative works are free to licence
under different terms:

"Derivative works need not be licensed under similar terms"

It seems to me that the above gives us the ability to just relicense this under
Apache 2 and incorporate it. But I'm not entirely sure.

Thoughts?

Matt