Currently all LLVM ebuilds specify a single license. However, the license file in projects lists additional third-party components using different licenses. We should probably list all we're using in the LICENSE field. Any help would be appreciated. Besides, since prefix wants to keep old LLVM versions around, we probably need to update licenses there as well.
Ok, so for LLVM the following additional licenses apply: 1. googletest (BSD) is used for unit tests -- do we specify licenses for stuff at build-time at all? 2. OpenBSD regex files -- https://github.com/llvm-mirror/llvm/blob/master/lib/Support/COPYRIGHT.regex. I don't know if we should add a copy of that license, or e.g. make 'rc' license more generic. 3. pyyaml tests use MIT license. Again, do we specify this? 4. ARM backend -- https://github.com/llvm-mirror/llvm/blob/master/lib/Target/ARM/LICENSE.TXT. Again, this is similar to a few licenses but not exactly the same. Probably needs to be added. 5. MD5 code -- public-domain.
For clang-tools-extra, there's also https://github.com/llvm-mirror/clang-tools-extra/blob/master/clang-tidy/cert/LICENSE.TXT. Not sure if it's something needing mentioning in the LICENSE field.
Additional notes: a. compiler-rt needs to be || ( UoI-NCSA MIT ); b. libomp needs to be || ( UoI-NCSA MIT ) with additional thingies from Intel & ARM.
Slightly off-topic… If we’re planning to *really* dig into searching the appropriate licenses, I’d suggest setting up a FOSSology instance as for more complex projects it’s much more efficient (and exact) than manual digging. https://www.fossology.org/
(In reply to Michał Górny from comment #1) > 1. googletest (BSD) is used for unit tests -- do we specify licenses for > stuff at build-time at all? IMO only licenses for installed files need to be specified. > 2. OpenBSD regex files -- > https://github.com/llvm-mirror/llvm/blob/master/lib/Support/COPYRIGHT.regex. > I don't know if we should add a copy of that license, or e.g. make 'rc' > license more generic. We have some precedents where "rc" is used in spite of a different copyright holder, e.g. sys-libs/glibc and app-accessibility/festival. So just use "rc" here. But yes, the license file could be changed to say: * Copyright <year> <name of author>. All rights reserved. > 3. pyyaml tests use MIT license. Again, do we specify this? See 1. > 4. ARM backend -- > https://github.com/llvm-mirror/llvm/blob/master/lib/Target/ARM/LICENSE.TXT. > Again, this is similar to a few licenses but not exactly the same. Probably > needs to be added. Sigh, why do people keep inventing their own licenses? Can't they just use Apache-2.0? So yes, this needs to be added ("ARM-LLVM" as name?). @Licenses team: Can this be included in the MISC-FREE group? > 5. MD5 code -- public-domain. (In reply to Michał Górny from comment #2) > For clang-tools-extra, there's also > https://github.com/llvm-mirror/clang-tools-extra/blob/master/clang-tidy/cert/ > LICENSE.TXT. Not sure if it's something needing mentioning in the LICENSE > field. That doesn't concern distribution of the software, so no. (And IMHO it is outright stupid.)
ffa7003 sys-libs/compiler-rt-sanitizers: Allow alternative MIT license cb65bb5 sys-libs/libomp: Add missing licenses, #598106 2b6918d sys-libs/compiler-rt: Allow alternative MIT license 22e688f sys-devel/llvm: Add missing licenses, #598106 845f33e licenses: Add LLVM Software Grant license necessary for LLVM b89d386 licenses/rc: Blank out the copyright holder name
(In reply to Ulrich Müller from comment #5) > > https://github.com/llvm-mirror/llvm/blob/master/lib/Target/ARM/LICENSE.TXT. > > @Licenses team: Can this be included in the MISC-FREE group? Reopening because this question need to be answered still. Clauses 1 and 2 of LLVM-Grant are very similar to clauses 2 and 3 of Apache-2.0.
*** Bug 602562 has been marked as a duplicate of this bug. ***
Do I understand correctly from #602562 that it's fine to add it to @MISC-FREE?
(In reply to Michał Górny from comment #8) > Duplicate of this bug: 602562 Right, thanks. (I vaguely remembered that we had discussed this but couldn't find it.) (In reply to Michał Górny from comment #9) > Do I understand correctly from #602562 that it's fine to add it to > @MISC-FREE? Done now, since no objections have been raised since more than a month.
