Re: IP Clearance terms

[John D. Ament]

On Sat, Jan 14, 2017 at 12:51 AM Henri Yandell  wrote:

> On Fri, Jan 13, 2017 at 4:46 AM, John D. Ament 
> wrote:
>
> >
> >
> > - Its not usual for a podling to receive a subsequent donation.
> >
>
> Doesn't the IP Clearance also cover the initial codebase review? Or is
> there a very similar page that's covering that?
>

No.  There's a box on the page "This form is not for new projects."  We
rely on the SGA to identify the initial source and mentors to review what
gets pushed into the repo.  I'll point out two projects where this process
has been problematic:

- Groovy
- MADLib

John


>
>
> > - I hate that the IPMC is responsible for all TLPs IP Clearance.
> >
>
> Agreed. The Incubator shouldn't be the general source for instructions on
> bringing in a piece of code.
>
> Hen
>

Re: IP Clearance terms

[Henri Yandell]

On Fri, Jan 13, 2017 at 4:46 AM, John D. Ament 
wrote:

>
>
> - Its not usual for a podling to receive a subsequent donation.
>

Doesn't the IP Clearance also cover the initial codebase review? Or is
there a very similar page that's covering that?


> - I hate that the IPMC is responsible for all TLPs IP Clearance.
>

Agreed. The Incubator shouldn't be the general source for instructions on
bringing in a piece of code.

Hen

Re: IP Clearance terms

[John D. Ament]

On Fri, Jan 13, 2017 at 12:36 AM Henri Yandell  wrote:

> On Thu, Jan 12, 2017 at 7:52 AM, William A Rowe Jr 
> wrote:
>
> > 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
> 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?
>
>
Go for it.  IP Clearance is way down on my list because:

- Its not usual for a podling to receive a subsequent donation.
- I hate that the IPMC is responsible for all TLPs IP Clearance.

John


> Thanks,
>
> Hen
>

Re: IP Clearance terms

[Henri Yandell]

On Thu, Jan 12, 2017 at 7:52 AM, William A Rowe Jr 
wrote:

> 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
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

Re: IP Clearance terms

[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.

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

Re: IP Clearance terms

[John D. Ament]

IMHO, IP Clearance in of itself is confusing.  For software being
relicensed (under an SGA) it shouldn't be needed.  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.

So i'd actually prefer to just drop the two bullets and not add anything.

On Thu, Jan 12, 2017 at 1:24 AM Justin Mclean 
wrote:

> Hi,
>
> > * Check and make sure that all items depended upon by the project are
> > compatible with the license guidance given here:
> > http://www.apache.org/legal/resolved.html
>
> Dependancies are often seen as external so perhaps “all items contained in
> or depended upon by the project” would be better?
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: IP Clearance terms

[Justin Mclean]

Hi,

> * Check and make sure that all items depended upon by the project are
> compatible with the license guidance given here:
> http://www.apache.org/legal/resolved.html

Dependancies are often seen as external so perhaps “all items contained in or 
depended upon by the project” would be better?

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org