On Fri, Jan 15, 2016 at 11:14 AM, Martin Jambor <mjam...@suse.cz> wrote: > Hi, > > On Thu, Jan 14, 2016 at 05:18:56PM -0800, Ian Lance Taylor wrote: >> Jakub Jelinek <ja...@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. > > I will raise this with the HSA PRM group and perhaps there is a slight > chance that they will change this in the upcoming version of HSAIL. > But it is not going to happen soon enough. > >> >> 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. > > Well, if we have done something like this before, I can go through the > exercise of copy'n'pasting everything from the PDF specification, if > that allowed us to "own" the file and put it under GPL 3. But I must > say I do not know. > > It is going to be a bit tedious job (and it would be good to double > check I made no mistakes somehow) but it is certainly doable. I guess > I will embark on it after going through the rest of the review (unless > someone here tells me I should not, that is). > >> >> 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. > > Even if I "create" a copy of our own? But sure, no problem.
Btw, in the mean time we can also not ship the header and check for its presence (thus require the user to install it in his system or drop it in-place like isl/gmp). So it shouldn't block the patches if we add a configure check for it (HSA needs to be enabled with a switch anyway). Richard. > Martin
