incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject Re: Confusion over NOTICE vs LICENSE files
Date Thu, 04 Feb 2016 03:13:26 GMT
I can see how a TLP would not be receptive to someone nit-picking their LICENSE/NOTICE files.
Asking for patches, as Marvin suggests, is one approach that might work. Another approach
is for someone with expertise in licensing to approach a TLP and offer to take them through
a licensing review. Of course the TLP is at liberty to refuse, but if they accepted, some
knowledge would undoubtedly rub off. I can speak only for the Calcite project, but I think
we’d be happy to go through such a process every couple of years.

Julian


> On Feb 3, 2016, at 6:32 PM, Marvin Humphrey <marvin@rectangular.com> wrote:
> 
> On Wed, Feb 3, 2016 at 4:01 PM, Justin Mclean <justinmclean@me.com> wrote:
>> Perhaps it's time to ask TLP to review their LICENCE / NOTICE to be a little
>> more consistent with current policy?
> 
> I approached a bunch of Lucene PMC members about this at ApacheCon a couple
> years back and they were receptive to the idea.
> 
> However, I don't think we should approach any other TLPs, to be honest.  A lot
> of the issues we'd like to fix in TLP LICENSE and NOTICE files would improve
> compliance with Apache *policy*, not law.  TLPs are the Board's purview -- the
> Incubator's writ only extends to podlings.
> 
> We can let the Board know that poor TLP compliance with Apache licensing
> policy is complicating our work in the Incubator, and perhaps the Board will
> solicit our help as volunteers to work on that problem.  But I think that if
> an initiative to tackle TLP licensing documentation originates on
> general@incubator, that's asking for trouble.  The last thing we need is
> conflict with the Board over ostensible IPMC overreach.
> 
>> Any suggestion on how we would go about this?
> 
> For any TLP we approach, I think we need to ensure that any proposed revisions
> are real, valuable contributions to the community.
> 
> *   Provide patches, rather than point out flaws.
> *   Explain persuasively and coherently to the PMC why these patches should be
>    applied, while minimizing what we ask of them in terms of review and
>    research.
> *   If possible, provide project-specific improvements which will help the PMC
>    handle licensing better and with less effort in the future.
> 
> We need to bear in mind that we are outsiders while a project's PMC members
> are charged with legal oversight of their project, and that there is generally
> limited energy and patience for dealing with legal stuff.
> 
>> Does the policy need to be made clearer first?
> 
> Yes, I think that's important -- it will help us to persuade PMCs that our
> proposed changes are both correct and worthwhile.
> 
> Marvin Humphrey
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message