Licence audit

[purcell]

Some packages are not explicitly licensed, and we should either actively stop hosting these, or work with maintainers to remedy the situation. An example would be anaphora, not to single out @rolandwalker particularly. A good starting point would be to at least determine which single-file packages have no license (or spdx) header. Multi-file packages would need their -pkg.el file inspecting. Bulk cross-referencing with the github API to determine repo licenses would also be a useful approach. I think we should work towards having the license displayed on the package pages, and maybe even in the package list.

[rolandwalker]

Since I cannot claim copyright over the code in anaphora, how should the license be given for MELPA's purposes?

[purcell]

Since I cannot claim copyright over the code in anaphora, how should the license be given for MELPA's purposes?

As a header in the code, e.g. via the spdx package. Or am I misunderstanding the question?

[rolandwalker]

Looks like SPDX does include a disclaimer covering this case https://spdx.org/licenses/CC-PDDC.html .

(I've always been certain that I don't have the right to define the license for code I didn't write.)

[purcell]

@rolandwalker Public domain seems a reasonable choice in that situation imo.

[tarsius]

anaphora.el already begins with

;;; anaphora.el --- anaphoric macros providing implicit temp variables  -*- lexical-binding: t -*-
;;
;; This code is in the public domain.

That is compatible with the GPLv3 and therefore good enough, right?

Among all the packages on the Emacsmirror (which is a superset of the packages distributed by Melpa) there are currently only three whose license I couldn't extract. [And two of those are mirrored directly from the fsf. I reported the issue and nothing happened. It's a bit annoying to say the least.]

So I don't think there really is anything we have to do. If you want I can give you lists of packages whose licensing terms are hard to detect programmatically. We already did the real work a few years ago. All that is left to do is to improve how the terms are specified in a few cases that depart to far from the conventions. Personally I consider This code is in the public domain appearing in the library header to be a perfectly reasonable way of making that known and wouldn't contact the authors of packages that do only that.

[tarsius]

See https://github.com/emacscollective/elx/blob/01ad699c562887dfe135f21dbf65d72cfe7d9cd9/elx.el#L362 for a list suboptimal permission statements found in the wild. That list does contains a few phrases that really should be replaced with a header keyword with a supported value, a proper permission statement and/or a license file.

If someone wants to work the the maintainers to get that done, then I can provide the list of packages that should be improved, but I don't want to do that work myself.