On 2016-11-10 20:34:47, Dave Airlie wrote:
> On 11 November 2016 at 13:26, Jordan Justen <jordan.l.jus...@intel.com> wrote:
> > On 2016-11-10 17:45:10, Dave Airlie wrote:
> >> From: Dave Airlie <airl...@redhat.com>
> >>
> >> I just noticed the new vulkan headers changed a prototype,
> >> so I've decided to import them and fix the drivers to use the
> >> new API.
> >>
> >
> > The new header is Apache licensed. I know that the FSF says Apache is
> > not compatible with GPLv2 code.
> >
> > https://www.gnu.org/licenses/license-list.en.html#apache2
> >
> > I think GPLv2 code can include "system library headers" under
> > non-GPLv2 compatible libraries, so this should be okay for GPLv2
> > licensed code. For example, GPLv2 code can include stdio.h, even if on
> > some systems the stdio.h may have a non-GPLv2 compatible license.
> >
> > Is that correct?
>
> I'm not sure we care or can do much about it. Khronos picked the header
> license, and we need to build our drivers against it.
I don't think that is true. If it is an issue, then someone can file a
bug against the spec on github. They changed it from an MIT like
license, so why couldn't they change it again if there was a need to?
I don't think they would want to prevent GPLv2 based Vulkan
applications.
> I'm not sure distros should be picking this up from us and not from
> Khronos directly in any case.
I guess it is possible. I know they will sometimes get the GL/ES
headers from mesa.
> So I suppose it's fine under a system library header issue wrt
> GPLv2.
Ok. I guess I was hoping you might have a more definitive feeling on
it. ("Yes, of course it works that way! Duh." :)
I just wanted to raise the issue to make sure no one thought it might
be an issue. If no one comes back with a concern, then we probably
have nothing more to do.
-Jordan
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
