On Thu, Jan 12, 2017 at 7:52 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Thu, Jan 12, 2017 at 6:06 AM, John D. Ament <johndam...@apache.org> > 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 sections: 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? Thanks, Hen
