Ensure attribution of code adapted from Scala standard library

[DavidGregory084]

On #4185 @smarter raised concerns about importing code into cats that is based on code from the Scala standard library.

However as @satorg pointed out there is already code in cats which is adapted from the Scala standard library, e.g.

https://github.com/typelevel/cats/blob/fe40bc2b4961386d829c0dd594af9bd80941947d/tests/shared/src/test/scala-2.12/cats/tests/compat/SeqOps.scala

https://github.com/typelevel/cats/blob/fe40bc2b4961386d829c0dd594af9bd80941947d/kernel/src/main/scala-2.13+/cats/kernel/compat/HashCompat.scala

We should ensure that the correct attribution notices are added to such code and that the redistribution requirements for that code are met.

On #4185 it was discussed that we should include the Apache license at the root of the cats repo, and add attribution notices to each file based on the scala/scala NOTICE file, as well as ensuring that the licences key of build.sbt is updated to include the Apache 2.0 license.

I don't know if that is enough to ensure that we are doing the right thing so hopefully someone else will chime in. 😛

[rossabaker]

This is not legal advice, but I'm an old remix artist. My derived works have been called "useless" and "shitty", but never "non-compliant"!

4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

• You must give any other recipients of the Work or Derivative Works a copy of this License; and

In http4s, we have a licenses/ folder to include the license of any derived works. Cats already has a COPYING file. Putting the Apache License in either place should satisfy this requirement.

• You must cause any modified files to carry prominent notices stating that You changed the files; and
• You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

sbt-header ignores a second header. I put a second block header in derived works. Something like this should satisfy both of the above:

/*
 * Copyright (c) 2022 Typelevel
 * 
 * MIT blah blah blah
 */

/* This file is derived from http://github.com/scala/scala/blob/v2.13.8/src/main/scala/Original.scala
 * Modified by Typelevel for redistribution in Cats.
 *
 * Copyright EPFL and Lightbend, Inc.
 *
 * Scala
 * Copyright (c) 2002-2022 EPFL
 * Copyright (c) 2011-2022 Lightbend, Inc.
 *
 * Scala includes software developed at
 * LAMP/EPFL (https://lamp.epfl.ch/) and
 * Lightbend, Inc. (https://www.lightbend.com/).
 *
 * Licensed under the Apache License, Version 2.0 (the "License").
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

I just inlined the NOTICE above. http4s has an extensive NOTICE file, but that's more of an Apache convention.

You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

I do not believe we should add Apache to the licenses key. From the Maven Model:

If multiple licenses are listed, it is assumed that the user can select any of them, not that they must accept all.

We are licensing the "Derivative Work as a whole" as MIT, in compliance with the licenses of all original sources. Including the second license in the POM would confuse tooling, and subject the bulk of Cats to Apache licensing, which is an entirely different can of worms.

[armanbilge]

We are licensing the "Derivative Work as a whole" as MIT, in compliance with the licenses of all original sources.

So also, IANAL :) this bit is the only part I'm confused about. My understanding to date has been that there is a partial order of licenses, and if you combine works with compatible licenses then the stronger license applies to the derivative work.

It says as much here: https://dwheeler.com/essays/floss-license-slide.html

An arrow from box A to box B means that you can combine software with these licenses; the combined result effectively has the license of B, possibly with additions from A.

(emphasis added)

That is to say, Cats may have originally consisted of MIT-licensed works and APLv2-licensed works, but as soon as those two were combined the Derivative Work as a Whole became APLv2-licensed actually.

[rossabaker]

I concur with Mr. Wheeler's partial order, but not the scope. Permissive licenses are not "viral" like those on the right. From the Apache License:

"Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work

"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship.

Then note that the redistribution constraint applies not to the Derivative Work (e.g., David's Cats port, the Cats jar itself), but to the Work (e.g., the Scala HashSet):

use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License

That clause protects the Work from license laundering. If we used Scala's HashSet and Cats is MIT and Tigers repackages Cats, the Apache License still applies to the unmodified portions of HashSet distributed by Cats.

Incidentally, tracking these subtleties is a good reason to use sbt-header. It's boilerplate for original works, but it helps remixes maintain compliance.

[satorg]

Excuse me for a side (and perhaps dull) question. I noticed that different projects in Typelevel use sometimes different licenses. E.g. Cats-Effect uses APL2 in contrast to Cats. There's even at least a project that uses BSD3 (scalacheck actually).

So I wonder – what are the considerations taken for projects to choose one license against another (even though these projects are all within the same Typelevel org)?

[rossabaker]

Cats and Scalacheck are two of our older projects, so they had less of a norm to choose from, and relicensing is a headache. We don't have any Typelevel rules other than that it's listed as popular by OSI or receives a special approval.

If you're starting a project, Apache 2 is the TypelevelPlugin default, matches the standard library, and in Scala is probably the one least likely to make you spend time answering license questions on GitHub or with your employer's legal team.