Re: punycode licensing

2019-08-05 Thread 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

2019-07-10 Thread Tim Hudson
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.

Tim.


Re: punycode licensing

2019-07-10 Thread Viktor Dukhovni
> On Jul 10, 2019, at 10:37 AM, Dmitry Belyavsky  wrote:
> 
> 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.

Your ICLA does not cover code for which you as an individual are
not the copyright holder.  Merely having license to *use* the code
is not sufficient to make license assignments to the project.

I think we have two possible paths forward:

1.  The copyright owner signs an ICLA

2.  The OMC votes to accept *this particular* code (which published
under a permissive license in an RFC, and widely used) without
an ICLA.

Perhaps 2 is the best way forward, but for the record the outcome
is not *automatic*.  It requires an explicit decision to accept
the specific contribution in question.

-- 
Viktor.



Re: punycode licensing

2019-07-10 Thread 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

2019-07-10 Thread Salz, Rich
I will take the hint and stop commenting on this thread.


Re: punycode licensing

2019-07-10 Thread 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

2019-07-10 Thread 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

2019-07-10 Thread Salz, Rich
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?
  2.  Does other code which is in the public domain also require CLAs?
  3.  Does OpenSSL expect that anyone using OpenSSL and bundling it with Apache 
2 software must first ask the project for permission?
  4.  Assuming #1 is yes and #3 is no, can you explain why there is a 
difference?




Re: punycode licensing

2019-07-09 Thread 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

2019-07-09 Thread Tim Hudson
>From OMC internal discussions:

For all contributions that are made to OpenSSL there are three
circumstances that can exist:
1) the contribution is considered trivial - no CLA required
2) the contribution is non-trivial and the copyright is owned by the
submitter (or by the company they work for) - ICLA (and CCLA) required
3) the contribution is non-trivial and the copyright is owned by someone
other than the submitter and the copyright owner acknowledges that the
submission is on their behalf - ICLA (and CCLA) from the copyright owner
required.

Our CLA policy and the CLA documents themselves operate to cover
contributions as described above and the CLA policy itself notes no
exceptions for contributions outside of these circumstances.
The only mechanism for a contribution to be accepted that does not meet the
CLA policy is if the OMC votes to explicitly accept a contribution without
a CLA as a special exception to the CLA policy.

Notes:
a) the OMC has not to this date voted to approve inclusion of any
contribution without a CLA in place since the CLA policy was established in
June 2016;
b) the OMC does not currently have a policy to allow exceptions to the CLA
policy based on the license terms of a contribution

Thanks,
Tim.


On Fri, Jun 21, 2019 at 4:24 PM Tim Hudson  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.
>
> Both the CCLA and ICLA make that exceedingly clear the contributor
> (individual or company) is "*the copyright owner or legal entity
> authorized by the copyright owner*" and the grants in the CLA are not
> grants that the notice in the RFC provide.
>
> In this case, the person who raised the PR is unable to meet those
> requirements (please do correct me if I am wrong on that) and as such their
> contribution is unable to be accepted.
>
> Tim.
>
>
> On Fri, Jun 21, 2019 at 12:12 PM Dr Paul Dale 
> wrote:
>
>> It seems okay from here too.
>>
>> Pauli
>> --
>> Dr Paul Dale | Cryptographer | Network Security & Encryption
>> Phone +61 7 3031 7217
>> Oracle Australia
>>
>>
>>
>> > On 21 Jun 2019, at 11:59 am, Benjamin Kaduk  wrote:
>> >
>> > On Thu, Jun 20, 2019 at 12:27:38PM -0400, Viktor Dukhovni wrote:
>> >> 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
>> >>>
>> >>
>> >> 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.
>> >
>> > Me, too.
>> >
>> > -Ben
>>
>>


Re: punycode licensing

2019-06-24 Thread 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

2019-06-24 Thread 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

2019-06-20 Thread 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

2019-06-20 Thread 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