incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: IP Clearance terms
Date Fri, 13 Jan 2017 05:36:45 GMT
On Thu, Jan 12, 2017 at 7:52 AM, William A Rowe Jr <>

> On Thu, Jan 12, 2017 at 6:06 AM, John D. Ament <>
> wrote:
> > IMHO, IP Clearance in of itself is confusing.  For software being
> > relicensed (under an SGA) it shouldn't be needed.
> Well, it is needed, even where that devolves to "has all SGA paperwork
> for this incoming contribution and corresponding ICLAs been received
> and acknowledged?"
> > In addition, like any other podling coming in, work may be needed
> > to generate a valid release from the donation.  It may not just work.
> That is independent of the IP Clearance. It's the same issue as any
> brand new work created here by committers with ICLAs. Nowhere
> does the ASF enforce 'code quality' or similar metrics. If it doesn't
> build, it's open source, so just reassemble all the pieces.
This may be showing some of the issues with the template; the terms are
confusing and/or incorrect.

For example, looking at it more deeply, the template contains three

1) Identify the codebase.  Looking at that term, I would think it's a
natural first step that involves identifying which code is going to be
imported into the ASF repository. Instead it's talking about trademarks.
2) Copyright.  As a term that's simple, but too simple given we have no
copyright-only paperwork.
2i). The section then goes on to suggest that rights are transferred to the
ASF (very misleading), and says "It is only necessary to transfer rights
for the package, the core code, and any new code produced by the project.",
which is gobbledegook. The words package, core and new code produced by the
project are all undefined and vague.
2ii) A second section checks that the files have been updated to reflect
the 'new ASF copyright'; which is also inaccurate and misleading.
3) Verify distribution rights.  Sounds interesting.
3i) The first section is to check all active committers have a signed CLA
on record. Fair enough. Perhaps a better fit for section 2; if I had a
belief that section 2 should stay :)
3ii) A reminder about the possibility of CCLAs with average wording (for
example, it doesn't say who may require this). This probably speaks to
inadequate documentation elsewhere (on the CLA page?) and is not something
we should have as an explicit check.
3iii) On to one of the ones that started the thread; a compatibility check
for any non-Apache licensed content within the project.
3iv) And the other; basically the same compatibility check with a
limited/similar but not the same approach.

The paragraph that comes after does a fair, though hand-wavy job, or
summarizing the above:

"Generally, the result of checking off these items will be a Software
Grant, CLA, and Corporate CLA for ASF licensed code, which must have no
dependencies upon items whose licenses that are incompatible with the
Apache License."

Also noting that item 3 in the process says that a software grant is
required (bad name imo to use the word 'grant', we really need to fix
that). Which then talks about 'the traditional License Agreement', which is
very vague, or a CCLA Schedule B, which given we don't require that
committers have CCLAs signed is probably not something we should propose as
an equal.

Basically this line, and therefore the entire page, assumes that an
incubator project is a code donation from a corporation.


I was surprised to see nothing here on the process for who to get ICLAs
signed by. Only those becoming committers, or any previous contributors
(and how to determine which contributors). It also should, as a page,
consider whether having the code previously under Apache 2.0, or a category
A license, implies a different process.

I saw you were working on policy cleanup John - could I take a stab at a
rewrite of this, or is it a) got a lot of historical debate I've missed
that I should learn about or b) something you're already working on?



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message