OSI Approval of License

[zklaus]

For the conda-forge build of udunits2, I'd like to include an appropriate SPDX Identifier as strongly recommended by conda-forge. I expected this to be straight forward since the current recipe claims that the license is OSI approved. However, I was unable to find the license on the official OSI list.
Digging a bit more, I found some doubts as to the FOSSness of the license (eg here).

Is the udunits2 license OSI approved?

[semmerson]

The BSD 3-clause portion of the license is OSI approved and the anti-software-patent clause exists in many OSI-approved licenses.

I'm open to including an SPDX Identifier for the license, but I don't know of one.

[zklaus]

Thanks for the clarification. To document the status quo, I will remove the note on OSI approval and use LicenseRef-BSD-UCAR, following the SPDX specification for custom identifiers as (somewhat) documented here and here.

It might be worthwhile to put this string (or any other of the form LicenseRef-what-ever if you prefer) into the documentation so that everyone who uses SPDX can use the same string.

It would be desirable to resolve the situation in a better way. The options for doing that that I can see, in order of decreasing desirability, are:

1. Change to a well-established license. The Apache 2.0 License might be suitable. In particular, Section 3 contains a termination clause like Section 4 in the present license. The advantage of this approach is not only that everyone knows that license well, but also the interactions with other licenses have been considered and recorded, for an example with the GPL see e.g. Point 5, here, here, and here.
2. Get OSI approval for the present license. The process is described here. The advantage would be a greater sense of security by users of the software and a very simple process for understanding whether the license is suitable for a given purpose.
3. It might be possible to construct a SPDX composite license expression like BSD WITH UCAR-exception, but this would require either finding an appropriate exception in the current list of exceptions or getting a new exception approved by SPDX. I am not sure if this is feasible.
4. Add the present license to the SPDX list. The process is described here. This page also applies if a new exception should be added for solution 3. Note that UCAR already has at least one custom license on the list for netCDF.

[semmerson]

#1 seems reasonable (if a bit verbose). I'll see about it in my copious spare time.

[zklaus]

That would be great! I really appreciate it!

[semmerson]

That would be great! I really appreciate it!

Why?

[zklaus]

Mainly to fight license proliferation, see the OSI proliferation report or this Wikipedia page. In short, having many different licenses makes it difficult for projects to use the software. For example, I am involved in ESMValTool and we are now dealing with all the licenses of the many upstream projects. With a more formal form of governance being instituted, that means that every upstream license needs to be assessed by the legal departments of several institutes for acceptability and compatibility with our own license. Having fewer different licenses, preferably already well-understood ones, perhaps even tested in court, helps this process immensely.

[semmerson]

That's not a problem I've encountered. I'll take your word for it.

[semmerson]

@zklaus What do you think of the "Academic Free License ("AFL") v. 3.0"? I like their "Termination for Patent Action" clause more than the related clause in the "Apache 2.0 License" because it appears stronger.

[zklaus]

@semmerson, sorry for the delayed response, I was on holiday break.

First, just to be clear: I am not a lawyer. This is not legal advice.

I am afraid I can also not comment on which license best serves your licensing goals.

Nevertheless, I tried to make an assessment of the AFL, using the following resources:

• choosealicense
• OSL 3.0: A Better License for Open Source Software
• Chapter 2 of Laurent, Andrew M. St. 2004. Understanding Open Source and Free Software Licensing. O’Reilly Media, Inc. (you can read the book by following the links in the table of contents on that page)

From this, it seems to me that you are right and the AFL is stronger in its patent litigation protection. Particularly, where the Apache License only seems to terminate any patent rights granted, the AFL terminates all rights, including those granted under copyright, in the case of patent litigation.

You may want to consult with the abovementioned resources and/or your legal department to determine if any other differences in the licenses make a material difference to you.

In any case, both AFL and Apache license are good choices to address my concern about license proliferation and easy reference.

[semmerson]

@zklaus

@semmerson, sorry for the delayed response, I was on holiday break.

During a pandemic? Impressive! :-)

First, just to be clear: I am not a lawyer. This is not legal advice.

Neither am I. Probably doesn't matter all that much considering my organization is non-profit and these things don't appear to be litigated much.

choosealicense OSL 3.0: A Better License for Open Source Software

I didn't know about the OSL license. I must admit, I like this clause:

c) to distribute or communicate copies of the Original Work and Derivative Works to the public, with the proviso that copies of Original Work or Derivative Works that You distribute or communicate shall be licensed under this Open Software License;

Not quite copyleft, but it preserves the licensing intent. It also seems similar to the AFL 3.0 license (but more explicit).

In any case, both AFL and Apache license are good choices to address my concern about license proliferation and easy reference.

Workin' on it.

[zklaus]

@zklaus
@semmerson, sorry for the delayed response, I was on holiday break.
During a pandemic? Impressive! :-)

I figured my sanity would benefit from a complete absence of work, even while just sitting inside...

choosealicense OSL 3.0: A Better License for Open Source Software

I didn't know about the OSL license. I must admit, I like this clause:

c) to distribute or communicate copies of the Original Work and Derivative Works to the public, with the proviso that copies of Original Work or Derivative Works that You distribute or communicate shall be licensed under this Open Software License;

Not quite copyleft, but it preserves the licensing intent. It also seems similar to the AFL 3.0 license (but more explicit).

Indeed, the AFL is one of the three variants of the OSL and the second link I posted above (repeated here for convenience) is an article by the author of the license on his own server explaining all three variants.

In any case, both AFL and Apache license are good choices to address my concern about license proliferation and easy reference.

Workin' on it.

Thanks!

[semmerson]

@zklaus Upon further research, I think I'll go with Apache License 2.0.

[zklaus]

Sounds good 👍

[ryandesign]

I think I'll go with Apache License 2.0.

When? As of today, the repository's COPYRIGHT file hasn't been changed for 7 years.