www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Bundling and LICENSE
Date Wed, 06 Apr 2016 15:16:37 GMT
Responding as an long(ish) time member...

On 06/04/2016 07:52, Alex Harui wrote:
> I may respond to the points below in a later post, but maybe these
> questions will give me the information I am seeking.
> 
> 1) Is the ASF and/or RM liable if a release contains third-party content
> that has a compatible top-level documents but reportedly contains content
> that isn't Category A?

The purpose of the PMC holding the release vote is to make the release
an act of the foundation. This makes the foundation, rather than the
individual RM, liable if there are issues.

Whether there is any actual liability is going to depend on the exact
circumstances.

> 2) If yes, what actions could realistically be taken against the ASF
> and/or the RM?

Realistically, the first step is likely to be a polite request to fix
the issue which the ASF would, of course, comply with (assuming the
issue was valid).

The worst case first step is a formal communication from someone's lawyer. The end result
is the same as the polite request. It is worth noting the only instance of this I am aware
of started off with the ASF being accused of copying code. Amusingly ( on hindsight at least)
it ended up with an acknowledgement that actually they had copied the code off us and changed
the license header in breach of the ALv2.

While in theory the first step could be a lawsuit, that never happens since lawsuits are the
most expensive way to resolve the issue for all concerned. 

> 3) Does the ASF want its PMC members to not trust the top-level documents
> of third-party packages and try to find errors in those packages?  I'm not
> sure other communities would welcome having the ASF and its PMC members
> build a reputation for exposing Licensing and Notice and other issues
> without becoming involved in those communities in a more long-term way.
> Is the next step to also start looking for patent infringements as well?

I think it is perfectly reasonable to trust the L&N you find but that doesn't mean you
can turn a blind eye if you spot something that looks odd. Some folks will want to check in
more detail than others and that is fine.

Mark

> 
> Thanks,
> -Alex
> 
> On 4/5/16, 8:08 AM, "Mark Thomas" <markt@apache.org> wrote:
> 
>> With my board hat on.
>>
>> On 05/04/2016 08:08, Alex Harui wrote:
>>> Trying to collect all three responses into one place:
>>>
>>> I understand the process states that there is no such thing as a veto,
>>> and it is nice to know in the case of a missing NOTICE that we can keep
>>> on going.  But for other concerns like finding a CC-NonCommercial
>>> license inside a third-party package that is supposedly MIT licensed, or
>>> a potential ECCN issue, can any PMC member in good conscious not vote
>>> –1?  What would be the board response if the board was notified that
>>> certain PMC members decided to continue to vote +1 despite knowledge of
>>> such issues?  That's why these things are effective vetoes in our
>>> community.  We've been told there is a risk of severe action by the
>>> board.
>>
>> I don't want to get in to 'what if...' scenarios. Each L&N issue is
>> different and needs to be looked at individually.
>>
>> I will say the following: I would not support the board taking 'severe'
>> action over a genuine mistake made by a PMC trying to do the 'right
>> thing' for the project and the foundation. And I don't think any of the
>> other directors would either.
>>
>>> Mark suggests that L&N issues should be found by watching the commits.
>>>  A former mentor also suggested the same, but unfortunately, our
>>> reviewers haven't followed such advice.
>>
>> If there is a real concern regarding L&N files, why not organise a
>> review ahead of the next release? Get the community going over
>> everything in detail and document anything that is unusual so you have
>> something to point to if a question arises in the future.
>>
>>>  One thing I've pondered
>>> changing that might make things better for our community is to impose a
>>> "deadline" by which L&N issues must be found, otherwise PMC members
>>> could still vote +1 and such L&N issues could be dealt with for the next
>>> release.  In our community, we have a "last call" before we start
>>> putting RC's up for vote, and normally there are two weeks or more
>>> before the RC is posted, so maybe the rules would be:
>>>
>>> L&N issues must be found within two weeks after "Last Call" or two weeks
>>> after the commit, whichever is later.
>>
>> I don't like this. When an issue is discovered is a vanishingly small
>> factor in how to respond to it. The severity of the issue is far more
>> important.
>>
>>> L&N issues found in third-party bundles must be addressed first in the
>>> upstream package before we change our L&N,
>>
>> s/must/should/ and that seems like a good general guideline to follow.
>> But only a guideline.
>>
>>> and the person who found the
>>> issue is responsible for following up with the upstream community.
>>
>> I don't think this. It strikes me as a thinly veiled attempt to stop
>> people reporting L&N issues. L&N issues are the responsibility of the
>> entire PMC.
>>
>> The issue appears to be L&N issues being raised at the last moment
>> during a release. When a project releases early and often this should
>> really only be an issue once. Subsequent releases shouldn't have any
>> issues since they were all cleared up in the previous release.
>>
>> It is human nature to leave things until there is a hard deadline so, as
>> frustrating as this might be, it is one of the things you just have to
>> get used to as an RM (and yes, it has driven me nuts in the past).
>>
>>> Also, I've been pondering the notion that portions of README,
>>> RELEASE_NOTES, LICENSE and NOTICE content could be posted on the project
>>> website instead of packaged in the release.  Each release would have its
>>> own folder of content on the project's web site.  For example:
>>
>> Projects are free to do what they like with README and RELEASE_NOTES.
>>
>> LICENSE and NOTICE must be included in the release. This is a hard
>> requirement set out in the ASF release policy. In theory you can ask the
>> board for an exception but I don't see it being granted.
>>
>> Mistakes happen. If a mistake is found in a LICENSE or NOTICE file after
>> a release the only expectation is that it is corrected for the next
>> release. If the error is particularly serious that may trigger the need
>> for a new release.
>>
>> Having some form of on-line errata, known issues or similar would be
>> great but isn't a requirement.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@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