This patch, and #4800, on which it builds, claim to "clarify" the situation with copyright/licensing, but the contents of the changes visibly shows the otherwise - it represents the situation in tangled, complicated, confusing way.

The purpose of the top-level licensing file is:

1. Specify license of the project as a whole (i.e. what license the resulting binary built from project has).
2. List significant copyright holders (based on the contribution history).

Based on this simple and clear idea, followed by many projects, I submitted #4363, as means to recognize my significant contribution (and also to clarify the threshold for "significant").

That's my agenda and it's simple and clear. #4363 was used by other parties for their agendas, which ain't exactly clear (turning LICENSE into licensing 101 lesson? promote SPDX tags?). IMHO the end result is overdesigned and confusing.

#4363 as viable alternatives proposed:

1. Set a threshold for significant contributors to get into the top-level LICENSE file.
2. As a diminishing compromise, go for depersonalization approach and replace names with faceless "MicroPython developers".

Both of these approaches are used by many real-world projects. The fact that there's coming forward with patches like this (instead of say, p.2 above), shows that there're indeed some unclear agendas.

end result is overdesigned

Agreed on this feeling rather overdesigned especially wrt the SPDX section: not a lawyer, but I'd drop that completely. Is it necessary somehow? I there any particular use for it, will there aver be? It's already mentioned each component is accompagnied with it's own license: isn't that sufficient?

Also what happens when this gets out of sync? Suppose LICENSE says 'component x has copyright y' but then x grows some extra files which have a different copyright than y, or x changes it's license completely, or... I would assume (but can be wrong) that in such case the license which comes with the component, either explicitly or in the source file, is what matters and whatever is mentioned in the toplevel file is just irrelevant. Which is another indication for me it might not have to be there in the first place.

Same goes for the list of all copyrights for MicroPython itself, though to a lesser extent.

and confusing

Don't find it particularly confusing though after having it read top to bottom, what exactly do you think is unclear?

Don't find it particularly confusing though after having it read top to bottom, what exactly do you think is unclear?

I always was an opponent of "license zoo" (while pragmatically understanding that will be source code with multiple licenses).

1. So, it's confusing that this overloads a user with multiple license stuff.
2. In particular, it sprinkles GPL references around, that being a red sign for some contexts.

So, it now goes for a long way in explaining how/why it's so, but of course doesn't explain enough, because it should mention that any GPL parts are for build and support scripts, which are not part of the result binary and don't affect its licensing, etc., etc.

All that stuff doesn't have to be in the contents of the LICENSE file. If there's a motion that licenses of all 3rd-party projects should be collected in one visible place, then it should be a separate motion, went to something like LICENSES.ext, and should be concatenation of the license texts, not some novelties like SPDX tags.

IMHO, that should be enough. If someone entity wants a more detailed report, it may order it (up to date version of it!) from George Robotics, independent IP firm, or on-staff lawyers. I'm not sure why open-source project would be burdened with maintaining such reports. (Again, the original topic, as brought by #4363, was the issue that existing, and pretty lean, copyright tracking infra got out of date/wasn't maintained well).

The purpose of the top-level licensing file is:
... Specify license of the project as a whole (i.e. what license the resulting binary built from project has)

Exactly, it's there to let users know what licenses are contained in a full build, which is not just MIT but also the licenses for all the components.

IMHO the end result is overdesigned and confusing.

Well, that's just reflecting the complexity of licensing and copyright in general, the fact that there are many contributors to this project, and that there are lots of 3rd party components with their own licenses. There's not really any way to get around this fact. And the proposal here is intended to be a user-friendly summary of the (complex) situation.

The fact that there's coming forward with patches like this (instead of say, p.2 above), shows that there're indeed some unclear agendas.

I don't mean it to be unclear. This change is simply intended to spell out in more detail (but not excessive detail) what the license of the MicroPython core code is, and what other licenses are used.

the SPDX section: not a lawyer, but I'd drop that completely. Is it necessary somehow?
Also what happens when this gets out of sync? Suppose LICENSE says 'component x has copyright y' but then x grows some extra files which have a different copyright than y, or x changes it's license completely

It's not really necessary, but it's there as an overview for users to know what kind of licenses exist in the whole project and where to look to find out more. IMO it's a bit disingenuous to list MIT as the only license, which might give a user the wrong impression that the entire code (and binaries) are fully MIT licensed. Of course a user must do their own audit of the code to verify the full licensing conditions of everything they use, but this here is giving them a starting point for that.

The idea that it would not get out of sync and be updated when components licenses are added/removed/changed. And that's "a feature not a bug" because it forces us developers to make sure there isn't some new and unwanted license added inadvertently (if this list was there from the beginning, maybe some components would not have been included).

If there's a motion that licenses of all 3rd-party projects should be collected in one visible place, then it should be a separate motion, went to something like LICENSES.ext, and should be concatenation of the license texts,

That was pretty much what #4432 proposed. But it's 4000+ lines which is not very useful, and what's presented here is a summary of that.

Exactly, it's there to let users know what licenses are contained in a full build, which is not just MIT but also the licenses for all the components.

Full build is licensed under the MIT license. Any components included into it are compatible, and should allow re-licensing the full project under MIT license. The original license is preserved where it was (e.g. in 3rd-party components original source files) because:

• Out of respect to efforts of these 3rd-party projects.
• Because it was there and it would take extra effort to go and re-license those files explicitly.
• Because some parties may want to extract those components (in source form) out of MicroPython codebase, in which case it naturally would go under its original license.
• To let 3rd parties (e.g. binary distributors) to perform their due diligence on any additional requirements or suggestions other licenses may have (e.g., requirements or suggestions regarding attribution).

Note the last point - in the end, it's the responsibility of each party involved with product use to comply with the license regarding that particular use. It may be a nice courtesy for a project to make it easier for its users to do that, but it may turn to be a false courtesy to provide false, incorrect, incomplete, out-of-date information, instead of a default situation when each party must perform their own due diligence on that, treating the licenses themselves as the ground truth, not particular compilation or commentary of them.

FWIW, a while ago, I started on a 3RD_PARTY_NOTICES file to list 3rd party software that has been incorporated into MicroPython. It is something kind of in between #4432 and #4800.

You can find it here: https://github.com/dlech/micropython/blob/notices/3RD_PARTY_NOTICES.md

If it seems useful, I can continue working on that. Or, if not, I still like the idea of listing 3rd party stuff in a separate file from the MicroPython license - mainly just because that is what I have seen in other projects and if you see something enough times, it starts to feel right.

That was pretty much what #4432 proposed. But it's 4000+ lines which is not very useful, and what's presented here is a summary of that.

Not very useful for what? What's the purpose of it at all? Formal compliance with various licenses' requirements that the license text and copyright was clearly presented? Then presenting the license texts is very useful and obvious way to achieve that, whereas all those summaries seems like leisure "why don't we ...".

Android phone, Setting -> Legal Information -> Open source -> Open source licenses, presents a list of many-many (binary) files, and allows to look up exact license text for each. "Useful" or not, that's an obvious way to comply with license terms' that license text should accompany a software product.

I was also sure that I saw a similar "wall of licenses" in Chromium or Chromium OS source, but not so easy:

https://github.com/chromium/chromium/tree/master/third_party :

<Include table of license information here, once it is available>

If you don't see a pattern here, then I do: as some licenses require their texts/copyrights to be made available along side the binaries, Google for their partners provide facility to collect and present all licenses (all, just to be on safe side). For "their partners", because my phone is made by Motorola, it's their product, and it's their responsibility to comply with licenses in their product. Of course, they're customers of Google, and they included means to get that done in their competitively priced Android licensing package.

But on source code side, even Google is a bit relaxed. Because heck, all 3rd-party licenses are already in the source tree. Yeah, would be nice to deliver them on silver plate, but seems all folks with responsibility like that are stuck in the partner licensing department, and can't get to development departments which manage open-source repos.

IMO it's a bit disingenuous to list MIT as the only license, which might give a user the wrong impression that the entire code (and binaries) are fully MIT licensed

That's a good point. But is also covered (though not very clearly perhaps) by stating each component/source file might comes with it's own license.

And that's "a feature not a bug" because it forces us developers to make sure there isn't some new and unwanted license added inadvertently

Also a good point.

Closed in favour of commit 2fa975c