[Mesa-dev] [PATCH] vulkan: import latest public vulkan headers + and fix drivers.

[Jordan Justen]

On 2016-11-10 20:34:47, Dave Airlie wrote:
> On 11 November 2016 at 13:26, Jordan Justen <jordan.l.justen at intel.com> wrote:
> > On 2016-11-10 17:45:10, Dave Airlie wrote:
> >> From: Dave Airlie <airlied at 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