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: 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/