Re: How to start using only SDPX-License-Identifier tags
See some comments below.
This is FYI as you may be able to provide some insights and
recommendations based on the Linux kernel journey towards
SPDX that could help Warner and FreeBSD?
On Wed, Mar 17, 2021 at 11:11 PM Warner Losh <imp@...> wrote:
I'm looking at doing whatever it would take to create a framework so
Today, the project has SPDX tags in about 25k of 90k files in our
I happened to have helped quite a bit for a similar effort for the Linux
kernel and as a FOSS license buff I can provide a few comments. I assume
that you are considering only the core FreeBSD source tree and not the
ports for now.
1. There were similar concerns brought up during this kernel effort.
Eventually folks came down to agree after heated discussions and
adjustments. The fact there were a few ultimate decision makers or tie
breakers surely helped quite a bit together with supports from lawyers
here. Thomas Gleixner (in CC) led the effort and may be able to provide
some comments too.
2. The FSFE Reuse  is a closely related spec that co-evolved with the
kernel efforts. It provides a good set of documentation and practices
that are not project-specific and could be adapted to the unique FreeBSD
3. Beyond Linux and the pioneers of U-Boot, many projects now use and
accept SPDX license expressions and SPDX- License-Identifier. I made a
fairly extensive survey of related package metadata documentation
practices in my pending proposal to adopt SPDX expressions for Python
 which shows how prevalent things started to be.
4. Because of the above I would say that there are now established
community norms and practices that using SPDX-License-Identifier and
SPDX license expressions are acceptable ways to document licensing.
I do not know of any vocal objections from lawyers here and elsewhere.
Therefore, these norms are now the de-facto way things are done in
community at large.
5. The FreeBSD situation is different because there is a greater
number of licenses and origins at play because of all the different
packages. Nevertheless, the way things have been documented in the
kernel  may be a good start. You have similar documents for
FreeBSD , but not as detailed as Linux's and with one 404 
Is your plan to start by proposing a new/updated "process" document
for FreeBSD? That would be my first step.
6. The FreeBSD license audit from ~ 2014 by Pedro Giffuni could be
refreshed to help. We could use scancode-toolkit  (that I maintain)
to help there. This could allow to classify the codebase based on the
different licenses and license documentation approaches and drive the
actual planning and efforts. And help with the file replacement tooling
7. On the mechanics of replacing license notices by SPDX identifiers
in source code, I have some (old) code that may help with this 
and would only need some minor love and care to be functional again.
This could mean automating large volumes of code changes.
8. BSD historical attribution notices are usually more than just a
copyright + a license notice, but often contain extra notices such as:
- This code is derived from software contributed to Berkeley by John
- This code was contributed to The NetBSD Foundation by Jane Doe.
- or : "Created by: Warner Losh <imp@...>"
You should document what you would want to do with these.
9. BSD historical licenses comes with many small variants of BSD and MIT
licenses (even in some case your own making  ;))
You should document what to do with these cases and in particular:
- should ALL the original name be kept when the text meets SPDX
matching-style guidelines? MO no
- define a process to resolve cases that are borderline and fall outside
the strict guidelines
- when should original authors be contacted, and what to do if they are
- when to submit a new license to SPDX? I suspect you will find a large
number of licenses that are unknown to SPDX. I would suggest to use
first a LicenseRef namespace like I do in  either scancode's or to
create your own first then funnel these as needed to SPDX. In my Linux
Kernel scans, I "discovered" several new and weird license variants
(several being franken-BSD and franken-MIT hybrids and mods). Many
were eventually added to the SPDX license list. It would be great to
have the same outcome for your FreeBSD effort!
10. When doing large commits to fix many files, Thomas Gleixner and Kate
Stewart enrolled several volunteers from this list -- several of them
legally trained -- to help review and sign-off on the changes. This was
helpful on so many levels. IMHO you should do the same for FreeBSD.
11. What would be your strategy? A trickle a few files at a time over
time, possibly grouped by package or authors/licenses? Or a few larger
tree-wide changes? The latter approach was used for Linux and we started
with grouping things based on the licensing documentation clarity. It
was large to swallow but once we were over the hump I think it made
things easier afterwards.
12. What's your plan for files with no explicit license and copyright?
I hope this long list of comments may help ... I did not have the time
to make them shorter!
+1 650 799 0949 | pombredanne@...
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com