mysterymath
commented
4 months ago I'd really like to avoid the license soup that newlib and picolibc have ended up in. We should avoid building tooling intended to handle a vast array of licenses, because we shouldn't have a vast array of licenses in the SDK.
I had only placed licenses in the LICENSE file that had requirements to do so, but I think you're right that it's a good idea to let users know which licenses they'll be bound by when they use which features, even if the terms are extremely light. I'll go through and add the remainder and a callout to where they're used.
The llvm-mos-sdk project has gone with an LLVM-compatible license, which is the Apache License v2.0 with LLVM Exceptions. However, the llvm-mos-sdk project has come to incorporate code from a few other projects, such as PDCLib and cc65. Each of these subprojects has its own license agreement, either public domain or BSD, with its own restrictions and covenants.
When incorporating code from various sources to make a new product, it is common to present those licenses from subprojects, in a way where the consumer can easily read and understand it, in order to decide whether they're willing to abide by those licenses. There are several ways for doing this that I am aware of.
One way is to do manual collection and generation of a master COPYING file, which displays all the licenses for each of the subprojects. Since this method is done manually, it is generally free form, and responsibility for keeping it correct falls on us. This method seems fine for small projects.
One way is to follow the Debian standard, demonstrated here for example. This file is generated with a shell script that greps through each of the subprojects, looking for copyright information and appending discovered info to this generated list.
One way is to follow the Yocto standard, as I do at ${DAYJOB}, which includes licenses from thousands of subprojects. The license file is generated in the SPDX format as an SBOM. There are multiple tools for generating an SBOM. This may be overkill for such a small project, but such a solution scales to an arbitrary number of dependencies.