On Tue, Feb 21, 2017 at 2:52 PM Roman Shaposhnik <ro...@shaposhnik.org>
wrote:

> On Tue, Feb 21, 2017 at 10:25 AM, Marvin Humphrey
> <mar...@rectangular.com> wrote:
> > On Tue, Feb 21, 2017 at 6:31 AM, John D. Ament <john.d.am...@gmail.com>
> wrote:
> >
> >> So are we saying that the code modifications are sub-licensed? Or
> >> re-licensed?
> >
> > Think of each file as the result of layering changesets on top of each
> > other.  Each changeset has its own copyright holder and each copyright
> > holder grants a license.
> >
> > When all changesets have the same license, then the end product has
> > uniform licensing, even though many entities hold continue to hold
> > copyright.
> >
> > However, it is also possible that changesets may be granted under
> > different licenses -- in which case, the end product has heterogeneous
> > licensing.  It may not be possible to slice up the file into code blocks
> > which are under one license exclusively. Instead, if you want clean
> > divisions by license you have to go back to the changesets.
> >
> > For BSD-2-clause files which came in with MADlib but were not relicensed
> > (because not all authors participated in the SGA), we are saying that
> > changesets submitted after arrival at the ASF shall be under Apache-2.0.
>
> I think we all agree on what's going on and I believe (although correct
> me if I'm putting words in your mouth John) that we all feel the current
> situation with MADlib is NOT against any policy of ASF.
>
>
Not 100%.  We are saying that code modifications should have been under
apache license, but they were still under BSD as of the release from last
year.  Its nothing that I believe would have put the foundation in any
negative situation.


> The real question is how do we communicate it to a downstream consumer.
>
> There are two tools we have: a LICENSE file at the root of the project tree
> and individual license headers in each of the files. Neither of these tools
> are precise enough to address the subtlety that changesets may be granted
> under different licenses. IOW, there's no perfect solution here and we have
> to unblock the podling by making a decision that will be *less* than
> precise.
>
> I really hope we can all agree on that.
>
> Initially, I was very happy with the solution endorsed by Marvin and VP of
> Legal
>     https://s.apache.org/EOT5
> In fact I thought that in conjunction with the statement in LICENSE file
> it would be OK to modify the files and still NOT add ALv2 header (only
> brand new files created throughout the ASF lifetime of the project will
> get the proper AL header).
>
> It seems that this assumption is now being challenged and as such we
> NO LONGER have a path forward for the podling.
>
> John, am I capturing your concerns correctly?
>
>
Yes.  Basically, the notion put forth in the email you linked to is no
longer valid since the podling has modified the code that came in under BSD.

But again, please tell me if I'm misunderstanding the changes that have
gone in.


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

Reply via email to