New license request: any-OSI

[xsuchy]

1. License Name: Any OSI License
2. Short identifier: any-osi
3. License Author or steward: Unknown
4. Comments: This license is used in perl module Exporter::Tidy and is used in Fedora
5. License Request Url: http://tools.spdx.org/app/license_requests/320
6. URL(s): https://metacpan.org/pod/Exporter::Tidy#LICENSE
7. OSI Status: Unknown
8. Example Projects: https://metacpan.org/pod/Exporter::Tidy

[xsuchy]

Text of the license:

Pick your favourite OSI approved license :)

http://www.opensource.org/licenses/alphabetical

[jlovejoy]

ugh, that is really annoying that Tidy has done that. From SPDX perspective, we can't have an ID that represents multiple licenses (and in this case, which are very different!).

I think Fedora can just pick one of the OSI licenses - at least that seems to be the intent.

@richardfontana did you see this?

[richardfontana]

I saw this issue but not sure if @xsuchy has submitted an issue on the Fedora side. While Fedora could pick one of the OSI licenses, that is not what it has traditionally done; the current Callaway license tag for this package is:

AAL or AFL or AGPLv3 or APSL 2.0 or ASL 2.0 or Artistic 2.0 or BSD or
             : Boost or CATOSL or CDDL-1.0 or CNRI or CPAL or CeCILL or ECL 2.0 or EFL
             : 2.0 or EPL-1.0 or EU Datagrid or EUPL 1.1 or Entessa or Fair or GPLv2
             : or GPLv3 or IBM or IPA or ISC or LGPLv2 or LGPLv3 or LPL or LPPL or MIT
             : or MPLv1.1 or MPLv2.0 or MS-PL or MS-RL or MirOS or Motosoto or NCSA or
             : NGPL or Naumen or Nokia or OFL or OSL 3.0 or PHP or PostgreSQL or
             : Python or QPL or RPSL or SPL or Sleepycat or VSL or W3C or ZPLv2.0 or
             : zlib

By longstanding policy, Fedora does not pick among allowed licenses in a disjunctive license set. I don't think however that the traditional solution of enumerating all the (Fedora allowed) licenses makes that much sense, so I think this should be treated as a single license (that happens to reference the set of OSI approved licenses, which is not fixed). The only complication with that is some OSI-approved licenses are not-allowed (or are not generally allowed).

If SPDX does not want to add this to the license list, Fedora can use a LicenseRef.

[xsuchy]

I submitted it directly here, because I interpreted https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YTWKNAX7YU5PHXGQ77CENRD6BIKBKZOC/ that it is a good candidate for separate license id.

[swinslow]

Is there a reason not to just add this as a new identifier, with the verbatim text that Tidy uses?

I get that it's annoying that they did this... but if I were trying to describe the license for this package, I'd prefer to use an identifier that referenced the exact text, rather than (1) picking a different OSI-approved license; or (2) using the monstrosity expression that @richardfontana pasted above. New licenses are (occasionally) added to the OSI list, in any case, so trying to capture them all via "OR" statements wouldn't really express this correctly either.

And, for what it's worth, from some quick searches I see this formulation getting used by other projects, e.g.:

• https://github.com/Juerd/eq3-max/blob/master/LICENSE
• https://github.com/Juerd/p6-mqtt/blob/master/LICENSE
• https://blueprints.launchpad.net/ubuntu/bionic/+source/libdbix-simple-perl/+copyright -- item at the bottom; note that they also use "any-OSI" to describe this
• https://metacpan.org/pod/Net::MQTT::Simple::Auth

Seems to be a Perl thing 🤷

I'd probably go with just adding this as-is, with the identifier any-OSI (personally, I'd capitalize OSI) and the name "Any OSI License".

[jlovejoy]

+1 to adding as per @swinslow analysis and given this exact text is used in multiple projects that are included in Fedora and Ubuntu (even though it's still a bit annoying)

[swinslow]

License Inclusion Decision

Decision:

• approved
• not approved

Name

Any OSI License

License ID

any-OSI

XML markup

N/A

Notes

N/A

Next steps

@swinslow to add PR unless someone else gets there first :)

[xsuchy]

I will create a PR.

[github-actions]

This new license/exception request has been accepted and the information for the license/exception has been merged to the repository. Thank you to everyone who has participated!
The license/exception will be published at https://spdx.org/licenses/ as part of the next SPDX License List release, which is expected to be in three months' time or sooner. In the interim, the new license will appear on the license list preview site at https://spdx.github.io/license-list-data/.
This is an automated message.