OSI-approved license requirement?

[ericphanson]

I think the General registry should have a policy that requires packages to have an OSI-approved license. And the existence of this policy is separate from whether or not it is automatically checked by CI; e.g. with such a policy, noncompliant packages can be asked to comply or be yanked. (Automerge license requirements are tracked in in https://github.com/JuliaRegistries/RegistryCI.jl/issues/261).

As @aviks mentioned in https://github.com/JuliaRegistries/RegistryCI.jl/issues/261#issuecomment-720437403, this used to exist:

Also, there used to be a clear requirement for an OSI approved license in METADATA. Did we lose that in the migration to General? I've always expected that this requirement is present.

[DilumAluthge]

Yeah can you make a PR to add this to the README?

In my opinion, we have always had this requirement, as evidenced by the METADATA README. So we're not actually adding a new requirement; we're just restoring it to the documentation.

[Nosferican]

I would say if we want to enforce an open source license requirement, to pick from a subset of the machine-readable OSI approved licenses. Say for instance,

|     SPDX     |                       Name                      |
|:------------:|:-----------------------------------------------:|
|     0BSD     |             BSD Zero Clause License             |
|    AFL-3.0   |            Academic Free License v3.0           |
|   AGPL-3.0   |      GNU Affero General Public License v3.0     |
|  Apache-2.0  |                Apache License 2.0               |
| Artistic-2.0 |               Artistic License 2.0              |
| BSD-2-Clause |        BSD 2-Clause "Simplified" License        |
| BSD-3-Clause |     BSD 3-Clause "New" or "Revised" License     |
|    BSL-1.0   |            Boost Software License 1.0           |
|  CECILL-2.1  |   CeCILL Free Software License Agreement v2.1   |
|    ECL-2.0   |        Educational Community License v2.0       |
|    EPL-2.0   |            Eclipse Public License 2.0           |
|   EUPL-1.2   |        European Union Public License 1.2        |
|    GPL-3.0   |       GNU General Public License v3.0 only      |
|      ISC     |                   ISC License                   |
|   LGPL-3.0   |   GNU Lesser General Public License v3.0 only   |
|      MIT     |                   MIT License                   |
|    MPL-2.0   |            Mozilla Public License 2.0           |
|     NCSA     | University of Illinois/NCSA Open Source License |
|    OSL-3.0   |            Open Software License 3.0            |
|    UPL-1.0   |        Universal Permissive License v1.0        |
|   Unlicense  |                  The Unlicense                  |
|     Zlib     |                   zlib License                  |

[DilumAluthge]

So, there are two things here.

1. The requirement, which is a matter of policy. We can just say in the README it has to be an OSI approved open source license.

2. The AutoMerge automatic check, which is a technical matter. For AutoMerge, sure we can only check for a subset of easy to verify licenses.

Consider the following different cases:

1. Package has machine-readable easy to verify OSI approved license. AutoMerge is green. Package is automatically merged.
2. Package has an OSI approved license, but for whatever reason, AutoMerge is not able to parse it. AutoMerge is red. Registry maintainer manually reviews the license and confirms that it is an OSI approved open source license. Registry maintainer manually merges the package (assuming the other checks pass).
3. Package has a license that is not an OSI approved license. AutoMerge is red. Registry maintainer manually reviews, realizes it is not an accepted license, refuses to merge package.

[Nosferican]

For reference: here are the licenses that CRAN allows: https://cran.r-project.org/web/licenses/.

• AGPL-3
• Artistic-2.0
• BSD-2-Clause
• BSD-3-Clause
• GPL-2.0
• GPL-3.0
• LGPL-2.0
• LGPL-2.1
• LGPL-3.0
• MIT