www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Bundling and LICENSE
Date Wed, 06 Apr 2016 06:52:31 GMT
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?
2) If yes, what actions could realistically be taken against the ASF
and/or the RM?
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?

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