www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <apache....@gmail.com>
Subject Re: Podling releases and ASF policy
Date Sat, 22 Jun 2019 02:08:18 GMT


> On Jun 21, 2019, at 6:29 PM, Justin Mclean <justin@classsoftware.com> wrote:
> 
> HI,
> 
> Thanks for your response.
> 
> In general that's exactly the same as the IPMC currently votes with the exception of
the following:
> - inclusion of compiled code
> - category X dependancy
> - inclusion of category X source code
> 
> Which are currently treated as blockers by the IPMC.

Which is some progress.
> 
> I see a contradiction here:
> 
>> Blocker: Must be fixed and then revote:
>>> 
>>> - 3rd party Category X or Category B bundled code licenses not listed in LICENSE
> 
This case is where there is Category B or X that is in the release but not listed in LICENSE.
> 
> With:
> 
>> Issue: Release then file a JIRA to fix before next release
>>> 
>>> - Included compiled code (which is Category B/X) [3]

This is the case where Category B or X code is included and properly listed in LICENSE. 
> 
> As I can’t see anyone listing a Category X license in LICENSE.

This is a difference between Incubator releases and TLP releases. Clearly a TLP will not release
with a Category X license listed. But if a podling wants to get a release out while they sort
their Category X license issues, I can see this happening.

> Including Category X code is a common reasons releases get -1 votes, putting a category
X license in LICENSE has only happened a couple of times, so it’s unlikely someone would
include GPL code and put the GPL license in LICENSE. It's more common that they include GPL
code and don’t mention it in LICENSE or realise that it cannot be included.

I agree, but putting it in LICENSE satisfies the legal requirements of the license while still
allowing the podling to continue to resolve their issues. I agree it's not ideal but we should
allow it as long as it's fixed before graduation.
> 
>>> Except for some people, who think that most things should be allowed, there seems
to be general agreement in the IPMC on this list, except for allowing compiled code or having
a category X dependency in a podling release.
>> clr: this statement is a bit ambiguous
> 
> The only things that in general IPMC people don’t seem to agree on is having a category
X dependancy or allowing compiled code in a release which this currently thread is suggesting
to allow. (If we put aside the the everything is allowed position.)

Good. Let's focus on this one. Maybe VP Legal can weigh in on this. 

Assuming that it's ok with VP Legal, will the IPMC have an issue (assuming that it is well
documented)?
> 
>>> Votes on releases on the IPMC general list also confirm this. Some people have
expressed the view that as long as it is legal it is allowed, but it unclear if that means
full compliance with 3rd party licenses or not. In a few cases, things from this list have
been allowed with permission from V.P legal / V.P incubator.
>> clr: I think we all agree that getting special permission should be a last resort
because by definition it delays a release
> 
> Yep that’s currently the case. The cases when it been asked for has been having a category
X dependancy or inclusion. I’m not sure what other situations would require it if theses
things are allowed.

Sounds like we're closing in on this. 

Best,
Craig
> 
> Thanks,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
> 

Craig L Russell
clr@apache.org


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


Mime
View raw message