Jira not required. Note though that 'category B' is currently under a Weak Copyleft section, so this means adding a new FAQ rather than simply adding the license to the current category B list. While Luis said the FSF said it was mildly copyleft, I'm not seeing a clear copyleft statement in the license. I assume it's in one potential reading of:
"The licence and distribution terms for any publically available version or derivative of this code cannot be changed. "
That seems to me less midly copyleft and more either 1) a no sublicensing term or 2) a vague copyleft term that could be either GPL or MPL in its desired scope. #1 would seem to place it in its own special situation while #2 would place it in Cat X.

If #1: Could you draft the proposed language for that FAQ here (or on a JIRA)?

Given there's only the one known product under OpenSSL/SSLeay, my recommendation would be to limit the FAQ to the product rather than the license as a whole. Similar to how the old JSON question was listed. Plus a link to the license :) https://www.openssl.org/source/license.html


On Tue, Nov 29, 2016 at 4:56 PM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:

This seems most accurate by my reading, but will let it hang out there a solid 72 hrs before resolving. Is a Jira ticket strictly necessary or can the response be added to the FAQ doc based on this thread?

On Nov 28, 2016 12:38, "Sam Ruby" <rubys@intertwingly.net> wrote:
On Mon, Nov 28, 2016 at 1:07 PM, Luis Villa <luis@lu.is> wrote:
> On Mon, Nov 28, 2016 at 9:10 AM William A Rowe Jr <wrowe@rowe-clan.net>
> wrote:
>> 2. The primary objection/exception for OpenSSL/SSLeay would
>>    appear to be the advertising clauses. However, SSLeay contains
>>    a rather unique and tricky exception written with good intentions
>>    (similar to 'good not evil')
>>    https://www.openssl.org/source/license.txt
>>  * The licence and distribution terms for any publically available version
>> or
>>  * derivative of this code cannot be changed.  i.e. this code cannot
>> simply be
>>  * copied and put under another distribution licence
>>  * [including the GNU Public Licence.]
>> This appears to make creation of a AL derived work near-impossible
>> (focusing on the first sentence alone.)
> To be clear, the problem with the JSON license is that it discriminates
> against particular types of use, which has never been acceptable in FOSS
> licenses. The OpenSSL license is definitely poorly drafted, but it does not
> discriminate in the same way.
> OpenSSL is either a mild copyleft (essentially FSF's interpretation,
> suggesting Category B) or merely makes explicit what is implicit in all
> permissive licenses, including Sec. 4 of the Apache license (suggesting
> Category A). I'm not familiar enough with the (long) history here to really
> know the author's intent, so I can't help categorize it into A/B/X, but in
> either case, it isn't directly comparable to the JSON situation.

I'd suggest category B.  Apache License is explicitly sublicenseable;
openssl is explicitly NOT sublicenseable.

One consequence of that is that the Apache License, version 2.0 is
(one-way) compatible with GPL v3, but openssl is not.  That pretty
much rules out category A.


- Sam Ruby

To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org