Package is incorrectly licensed Apache/MIT

[brson]

libm is derivative of musl, which is MIT licensed, so this source code should also be MIT licensed. Cargo.toml though says "MIT or Apache-2.0". As suggested by the "or", I don't believe it is ok to remove the MIT license and instead apply the Apache license, when the original source is explicitly MIT only.

I am not entirely confident about how the "or" relationship, and adding more restrictions via apache, interacts with the original work though. The obviously correct thing to do is to remove the Apache license and preserve the license of the original work.

[workingjubilee]

The Expat ("MIT") License explicitly includes the power to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the usual conditions.

That is how people can relicense Expat Licensed code as proprietary.
The original notice must remain, of course.

Unless I'm missing something, Apache 2.0 does not grant any power that the Expat License does not grant and imposes some additional restrictions besides, so it is a subset of the Expat License's permissions, and thus fully covered by the sublicensing claused.

[gnzlbg]

@brson

ibm is derivative of musl, which is MIT licensed,

Are derivative works required to maintain the original license ? libm is a rewrite of musl in Rust, that's derivative work, but with substantial changes.

[workingjubilee]

I believe the answer would be "No", on reflection, because asserting it must be is like asserting that because, hmm, E.L. James' 50 Shades of Grey is Twilight fanfic with the serial numbers rubbed off, that Stephanie Meyer is entitled to royalties. Notably, no one has tried to pursue this case, in spite of the means and motive being present.

On the other hand, Marvin Gaye's estate vs. Robin Thicke and Pharrell Williams.
So, that is a question best answered by a lawyer.

[Lokathor]

Glancing through this blog post, which was written by a lawyer who is not our lawyer, the MIT license doesn't appear to enforce that the derivative work is also MIT licensed the same way that (for example) GPL does.

[infinity0]

Additionally, all the .rs files have, and only have, Sun Microsystems copyright headers with a custom license like this:

 * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
 *
 * Developed at SunSoft, a Sun Microsystems, Inc. business.
 * Permission to use, copy, modify, and distribute this
 * software is freely granted, provided that this notice
 * is preserved.

This clearly does not directly apply to the rust code, and it is permissive enough that you as the derivative author are OK to relicense the rust version as Apache/MIT. However, can you please add yourself (and the new license) to these copyright headers to make this clear? The fact that Sun Microsystems is the only copyright entity mentioned in this file, is confusing one of our copyright reviewers at Debian and slowing down the acceptance of this crate into Debian.

[infinity0]

As discussed here and here onwards the Sun copyright does apply to the comments that have been copied verbatim from Sun's code, but their copyright does not apply to the Rust code as that is a translation.

[brson]

From reading the above links I still believe that this software must retain the MIT license. Claiming that it can be distributed as either MIT OR Apache is not correct.

It's pretty clear:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

[infinity0]

A translation is a derivative of the original work, and under the MIT license does not have to be licensed with the same license. In other words, the rust code is not "the Software" referred to by your quote.

[tyt2y3]

I also have the same concern. I am porting code from projects written in other languages, and they are in MIT or BSD. Am I allowed to integrate the ported code into my 'MIT or APL 2.0' rust crate? Or actually it should become 'MIT and APL 2.0'? Or I should explicity move the code out to another crate? It's nice to have a recommended practice here.

[joshtriplett]

While the MIT license (as a permissive license) does allow using the code in a project under a different license (e.g. MIT OR Apache-2.0), that doesn't remove the requirement to preserve the original license text and copyright notices.

On balance, I think it's appropriate to preserve the original copyright notices and licenses for any and all code this was based on, both in the sources and in a file like https://github.com/rust-lang/rust/blob/master/COPYRIGHT . I don't think it's worth trying to make a case for some of those copyrights/licenses not applying; we should just preserve all the notices.

So, I don't think the license on this package is incorrect; the issue is just that some copyright/license notices need to be preserved that weren't. Adding those notices should address this issue.

[hsivonen]

Now that crates.io supports parentheses, the correct expression, (Apache-2.0 OR MIT) AND MIT is possible. That is: Recipients need to comply with Apache-2.0 OR MIT due to the parts that are original to this crate AND they need to comply with MIT due to the MIT-only parts originating from elsewhere.

I suggest putting (Apache-2.0 OR MIT) AND MIT in the crate metadata and doing what @joshtriplett suggested in the previous comment:

On balance, I think it's appropriate to preserve the original copyright notices and licenses for any and all code this was based on, both in the sources and in a file like https://github.com/rust-lang/rust/blob/master/COPYRIGHT .

[andrewjradcliffe]

As @joshtriplett and @hsivonen eloquently state, the important aspect is preservation of copyright/license notices. As an example which deals with many of the same thorny questions, openlibm's license does a nice job of clarifying the sources, licenses thereof, and, in particular, the meaning of derivative work within the context of a math library that draws upon sources such as fdlibm and freebsd.

A quick comparison of things like lgamma_r -- musl and openlibm and [here] (https://github.com/rust-lang/libm/blob/master/src/math/lgamma_r.rs) -- illustrates the literal nature of many translations. There is nothing wrong with translations (e.g.), but one should endeavor to give credit to the creator of the algorithm. This likely means that FDLIBM and the FreeBSD sources need to be acknowledged explicitly, rather than only in the files themselves. More clarity is preferable here, as a perusal of the files in this library indicate that it draws upon many existing works.

[Lokathor]

Is there any way to make whatever we do here bubble up into core? My concern is basically "what the heck license file does a programmer need to distribute with their Rust lang hello-world program?". I don't expect that to all be solved in this issue in the libm repo, but it's something to keep in mind i think.

[tgross35]

#317 contains an update to the licensing in this library to MIT AND (MIT OR Apache-2.0). In short, this means that:

1. Users of this library must agree to the MIT license present in the original musl implementations
2. We will be able to derive from other MIT-only libraries, e.g. CORE-MATH
3. Contributors to this library agree to release their code under both MIT and Apache-2.0