Heya Ryan, On Mon, Jun 18, 2018 at 2:39 PM Ryan Blue <rb...@netflix.com> wrote:
> > we have allowed (and IMO should continue) podlings to have licensing > issues during their incubator releases > > Thanks for pointing this out, Greg. I wasn't aware of this and have always > had releases fail when we discover licensing issues. I think there's a > significant risk of license problems, so I had assumed we would require a > thorough scrub before the first release. > > What's the argument for finishing this work before graduation rather than > first release? Isn't the release a product for which the ASF is legally > responsible? Given that we fail releases for known license issues, > shouldn't we also be more careful when we know there are likely to be > issues? > This is why incubator releases have a disclaimer. It gives them time to work through dependency and licensing issues, even while they're testing their release process with our KEYS and distribution framework. So the "argument" is simply to allow the podling to multitask, rather than gate one of their activities. When you really want to lift the cover, there isn't a problem if a podling releases (say) a hard LGPL dependency. That's just a policy choice of the Foundation, to avoid such dependencies. We don't like it, and maybe some messed up licensing downstream, possibly, for somebody to tease apart. But historically, the Incubator has let these issues slide for a while, yet gate on graduation. I also feel that podling releases are in a grey area, that don't truly have the full backing of the ASF (thus the disclaimer, and them not being a TLP; although technically the Apache Incubator is the stand-in PMC behind the release). Cheers, -g
