On Aug 20, 2015 8:19 PM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote: > > On Aug 20, 2015 7:39 PM, "Alex Harui" <aha...@adobe.com> wrote: > > > > > > > > On 8/20/15, 5:27 PM, "William A Rowe Jr" <wr...@rowe-clan.net> wrote: > > > > >It is generally AL code all the time. I don't know where you invented a > > >'kick-in' concept, but unless the committers are violating their > > >ICLA/CCLA, > > >nothing could be further from the truth. > > > > Committers sometimes make mistakes. IIRC, Justin recently caught a > > mistake where some files accidentally got their non-AL headers replaced > > with AL headers. > > > > Large codebase contributions, especially initial podling code grants might > > be messy as well until scrubbed and approved for an official ASF release. > > I know from experience. > > We don't disagree on this point. Sometimes, they are caught through the release process, or by peer review. Other times, we must retract the claim we offered. > > Nothing changes the fact that code is either offered under the AL 2.0 or another license, unless the author/licensor changes their license retroactively.
Your comment also hones in on the logical fallacy our VP fell into... While it may be true that the ASF granted its own AL 2.0 license to the release package, the ASF is unable to change component licenses in incompatible ways. And the warranty the ASF offers on an inaccurate license claims is - nil - c.f. AL 2.0 However, if our repositories are under another license, that VP needs to make public this information, because I never got the memo, and I must notify friends and the many companies I advise and consult to that they all need to cease looking at the ASF's repositories, and let their respective legal departments each sort this all out, if those repositories are licensed with terms and conditions differing from the AL 2.0.
