punycode licensing

Tim Hudson tjh at openssl.org
Tue Jul 9 08:25:42 UTC 2019


>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 <tjh at openssl.org> 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 <paul.dale at oracle.com>
> 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 <kaduk at mit.edu> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20190709/92a50883/attachment-0001.html>


More information about the openssl-project mailing list