Re: [hsa merge 08/10] HSAIL BRIG description header file

[Richard Biener <richard dot guenther at gmail dot com>]

On Fri, Jan 15, 2016 at 2:18 AM, Ian Lance Taylor <ian@airs.com> wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
>
>> On Wed, Jan 13, 2016 at 06:39:33PM +0100, Martin Jambor wrote:
>>> the following patch adds a BRIG (binary representation of HSAIL)
>>> representation description.  It is within a single header file
>>> describing the binary structures and constants of the format.
>>>
>>> The file comes from the HSA Foundation (I have only added the
>>> HSA_BRIG_FORMAT_H macro and check and removed some weird comments
>>> which are not present in proposed future versions of the file) and is
>>> licensed under "University of Illinois/NCSA Open Source License."
>>>
>>> The license is "GPL-compatible" according to FSF
>>> (http://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses)
>>> so I believe we can have it in GCC.  Nevertheless, it is not GPL and
>>> there is no copyright assignment for it, but the situation is
>>> hopefully analogous to some other libraries that have their upstream
>>> elsewhere but we ship them as part of the GCC.
>>>
>>> In the previous posting of this patch
>>> (https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00721.html) I have
>>> requested a permission from the steering committee to include this file
>>> with a different upstream in GCC.  I have not received an official
>>> reply but since I have been chosen to be the HSA maintainer, I tend to
>>> think there were no legal objections against HSA going forward,
>>> including this file.
>
> Martin, could you ask the HSA Foundation or AMD or whoever if there is
> any way they could remove the second requirement of the license?  It
> adds yet another case where anybody distributing GCC has to list yet
> another copyright notice.
>
> Barring that, I would personally prefer that you write your own version
> of this header file, defining the constants and structs that you need.
> That's basically what we've done for ELF and COFF and Mach-O, several
> times over.  For example, libiberty/simple-object-elf.c.

Not sure how that would end up with sth that is not considered a derivative
(esp. if not clean-room "duplicated" from other available documentation).

So if that's ok then it must be ok to basically strip the license and put ours
on it doing some formatting / re-ordering (or renaming).

That said - stupid copyright stuff (for something that is maybe not
even copyrightable).

Richard.

> Barring that, I agree with Jakub that this looks like something that
> should go in the top-level include subdirectory rather than the gcc
> subdirectory.
>
> Ian