incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <>
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.


> On Feb 3, 2016, at 6:32 PM, Marvin Humphrey <> wrote:
> On Wed, Feb 3, 2016 at 4:01 PM, Justin Mclean <> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message