Minor license issues

[gnzlbg]

While updating #247 I realized that some of the comments have been copy&pasted 1:1 from clang, e.g. in

/// Compares the 8-bit integer elements of two 64-bit integer vectors of
/// [8 x i8] to determine if the element of the first vector is greater than
/// the corresponding element of the second vector.
///
/// The comparison yields 0 for false, 0xFF for true.
#[inline(always)]
#[target_feature = "+mmx"]
#[cfg_attr(test, assert_instr(pcmpgtb))]
pub unsafe fn _mm_cmpgt_pi8(a: i8x8, b: i8x8) -> i8x8 {
    mem::transmute(pcmpgtb(mem::transmute(a), mem::transmute(b)))
}

googling the comment "Compares the 8-bit integer elements of two 64-bit integer vectors of [8 x i8] to determine if the element of the first vector is greater than the corresponding element of the second vector." returns a single result and that's the clang source code.

Since clang is licensed under the University of Illinois/NCSA Open Source License (with portions dual licensed under the MIT License) we should:

• license stdsimd under these two licenses as well,
• add a copyright notice to the readme stating that parts of the code has been derived from clang.

I don't know how this affects including stdsimd in std, but if this is not acceptable we should probably ask for legal counsel if removing the copy & pasted comments would be enough to be safe. Other intrinsics like:

/// Converts a 64-bit vector of 16-bit unsigned integer values into a
/// 128-bit vector of [4 x float].
#[inline(always)]
#[target_feature = "+sse"]
pub unsafe fn _mm_cvtpu16_ps(a: u16x4) -> f32x4 {
    let b = mem::transmute(mmx::_mm_setzero_si64());
    let c = mmx::_mm_unpackhi_pi16(a.as_i16x4(), b);
    let r = i586::_mm_setzero_ps();
    let r = cvtpi2ps(r, mem::transmute(c));
    let r = i586::_mm_movelh_ps(r, r);
    let c = mmx::_mm_unpacklo_pi16(a.as_i16x4(), b);
    cvtpi2ps(r, mem::transmute(c))
}

must do exactly what clang does to generate the same code, which means they are necessarily going to look a lot like clang's implementation:

static __inline__ __m128 __DEFAULT_FN_ATTRS
_mm_cvtpu16_ps(__m64 __a)
{
  __m64 __b, __c;
  __m128 __r;

  __b = _mm_setzero_si64();
  __c = _mm_unpackhi_pi16(__a, __b);
  __r = _mm_setzero_ps();
  __r = _mm_cvtpi32_ps(__r, __c);
  __r = _mm_movelh_ps(__r, __r);
  __c = _mm_unpacklo_pi16(__a, __b);
  __r = _mm_cvtpi32_ps(__r, __c);

  return __r;
}

[GabrielMajeri]

I am not a lawyer, but at least for the code part: as far as I know, copyright applies to code in source form, not algorithms. If we take Clang's implementation and rewrite it in Rust, there is no issue with the licensing, since they can't copyright the steps of the implementation itself.

As for the documentation, I wonder if the LLVM people would be willing to grant us a waiver? Otherwise we will have to rewrite tons of doc comments.

Also, in theory, these doc comments are more or less taken from Intel's software manuals, so I don't know if they are even elegible for copyright. Best consult with a real lawyer on this one before we start ripping out comments.

EDIT: also the *intrin.h headers are licensed under what looks to be a MIT license, so we don't even have to take into consideration the NCSA license, because it does not apply to these files we copied.

[AdamNiederer]

As for the documentation, I wonder if the LLVM people would be willing to grant us a waiver? Otherwise we will have to rewrite tons of doc comments.

I actually linked to the LLVM pages in a few of my doc comments because parapharasing the comments was such a pain. Perhaps we can find a way to re-host llvm's comments in a way which doesn't imply copying (like a script to pull things down from their webpage which runs client-side?)

[gnzlbg]

Perhaps we can find a way to re-host llvm's comments in a way which doesn't imply copying (like a script to pull things down from their webpage which runs client-side?)

We already have a script for verifying the intrinsics against the spec. We can also add a script to verify that the comments map to the clang comments (or some transformation thereof, e.g. from doxygen format to rustdoc).

The comments are not part of the binary library generated by compiling stdsimd, so for the comments at least, we might get away with simply mentioning in the readme that the comments have been extracted from clang, and that they are under the LLVM license.

For the code, even though its translated to Rust, I don't know. I agree that we should ask a lawyer.

Even if we are legally safe, we should still inform the LLVM folks that we are doing this so that nobody gets surprised later on. That will probably require an email to the LLVM mailing list at some point in the future.

What I am going to do is informally contact @chandlerc today, tell him what we are already doing, and what we plan to do. And ask him what he thinks about this and how to proceed.

[chandlerc]

These are legal questions that need to be asked to lawyers and github issues aren't great for that really...

Please send me a private email and I can try to set up a conversation about this. @llvm.org and/or @google.com address preferably here.

[hsivonen]

While at it, it would probably be a good idea to clarify what the language in the README about both MIT and Apache means. I expect it not to mean what it says but to mean "Apache License 2.0 or, at your option, MIT".