Re: punycode licensing

[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

[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

[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.

SHA-256 assembly language optimization

[Paul Sheer]

Hello,

I'd like to ask about improving SHA-256 performance:

I see on this page,

https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/sha-256-implementations-paper.pdf

Intel gives a reference implementation of SHA-256 for its own processors.

How is OpenSSL's implementation related to that implementation?
Is there much opportunity for improvement?

I assume the person who wrote the current OpenSSL assembly probably
looked into every avenue for improvement of performance, but just in
case, I feel I should ask.  Can it get much faster?

Thanks

Paul

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

[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: Vote FYI: Remove function codes from error reporting functions as per PR#9058

[Richard Levitte]

The vote closed today, with the following result:

+1: 4
 0: 3 (where one is a -0)
-1: 0

The vote passes.

Cheers,
Richard

On Thu, 04 Jul 2019 18:01:59 +0200,
Richard Levitte wrote:
> 
> topic: Remove function codes from error reporting functions as per PR#9058.
> comment: Discussed in
>  
> https://mta.openssl.org/pipermail/openssl-project/2019-June/001426.html
> Proposed by Richard Levitte
> opened: 2019-07-04
> closed: -mm-dd
> 
> I will follow up with the tally when the vote is concluded.
> 
> Cheers,
> Richard
> 
> -- 
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/