This should probable be FREEBSD-2-Clause since our preferred license text is not the OSI BSD license.

Except that's no longer a thing. It's an obsolete thing that doesn't match our BSD license.
This would effectively shift out copyright to the standard one since the two are legally identical, at least in the opinion of the SPDX folks.

Yea, I'm going to change this to a new top-level directory called LICENSE to match a complementary standard.

I should be more specific, but this is for like the 4 clause one where the original had names, and they were replaced by a generic phrase. I think "the copyright holders" but I should be more specific.

bwn isn't in GENERIC, it's commented out because it is GPL'd. Are there other examples?
What CDDL code is in generic? zfs and dtrace are both modules and the glue code to get them into the kernel isn't CDDL.
But I'll tighten up the wording to be more explicit to capture the intended meaning.

Side note: GPL code will automatically be loaded due to devmatch.

The SPDX deprecated the FreeBSD-2-clause license. The copy they had was the normal BSD-2-clause license with some weird thing from docs tacked on. We've marked a boatload of code wrong in the tree to date.

I've added some text I hope will clarify this, here and elsewhere.

The FreeBSD project's license (however we spell it) potentially implicates different entities than BSD-2-Clause in the disclaimer (author vs copyright holder). It's not unreasonable to make that change, but it should be discussed on its own and not made implicitly as part of this change.

Do we want this even stronger?

"New contributions to FreeBSD should use the BSD-2-Clause license."

Maybe you could add "whenever possible" to the end to loosen it, but I'd be tempted to just be that direct.

I view the modules as part of GENERIC, i.e. they get installed to /boot/kernel when you build GENERIC, so that includes ZFS and dtrace. It also includes bwn(4) that way. My question was really about that: that we do ship non-BSDL code in the modules included in the base distribution and that those are part of GENERIC insofar as they get built and installed by 'make buildkernel' and 'make installkernel'. I think the new sentence below though about static kernel covers what I wanted to say though.

I'm a little worried about the "explicitly load". As you note, devmatch will auto-load bwn(4) out of the box without a user having to enable anything. Similarly, if you just choose ZFS (which is the default) during an install, it adds zfs_load=YES to loader.conf automatically so the user isn't really consciously saying "I want CDDL" code.

I'm not sure we want to pop up annoying dialogs in the installer to ask "do you want CDDL" and probably prefer our current way of doing things, but I think this text doesn't match what we do.

Ah, I had missed the "detached" bit here previously and had read it as don't use AND at all.

good suggestion.

They are not part of the GENERIC kernel. They are modules compiled with the GENERIC kernel. They are not in the static kernel. That's the important bit here.
I'll think about making that distinction clearer.

devmatch will grow a don't load gpl feature, maybe.
But loading gpl'd code in modules isn't an issue. It's linking it statically in the kernel.
Likewise with CDDL code.
Thinking about this, we made these modules in generic because that's OK. The project is in compliance with the license if we do this, but not, at least some said, if we statically link it into the base kernel.

I agree. That determination has been made and affirmed by SDPX lawyers, but we've not undertaken the change ourselves yet. I wanted to get some official legal advice that this was cool before taking it to the community.

yes. I said it both places not to be clear.

I suspect this will need a more detailed description, if we keep it in.

Should we upgrade from "strongly discourages" to "does not allow"?

"standardize on more standard licensese" reads a bit awkwardly

But loading gpl'd code in modules isn't an issue. It's linking it statically in the kernel.

I do not think this is a claim we can / should make.

We can remove this in the near future

As an aside, I see 965 files that have both a FreeBSD Foundation copyright and All Rights Reserved.
The Foundation has approved removing All Rights Reserved from its copyright statements, so in cases where it is the only copyright holder, or all other holders agree, the text can be removed. I tried to do a pass over the tree in the past but have missed some.

I just think we should be careful to not overstate our claims here. Maybe something like:

Code with these licenses can be used in pre-compiled modules shipped with the GENERIC kernel.

I'd like to keep it vague. ID marking is a separate policy.

where a tag in the file specifies the license, as described in this document

I think that's clearer English.

Assuming {core-email} expands to an email address, then the should be removed.

... the approval of the core@freebsd.org ...

vs

... the approval of core@freebsd.org ...

Which "the BSD license"? How is a license "identical to" it, without actually being it?

Thinking about this, we made these modules in generic because that's OK. The project is in compliance with the license if we do this, but not, at least some said, if we statically link it into the base kernel.

If that's the case, we need an explicit comment to that effect in the various in-tree KERNCONFs. (And possibly also in config.5?)

s/right/correct/g

"relicensing or reimplementation" => "relicensing, dual-licensing, or reimplementation"?

"filesystem, including"

"had it, in order to comply with"

"Nicaragua, the Buenos Aires Convention -- and the phrase -- became obsolete."

"contains, in detached form, the text of all the licenses that are allowed in the FreeBSD software collection."
And similarly throughout this section.

"Because copyrights may be legally transferred, the current copyright holder may vary from what is listed in the file."

Because it's the copyright, not the copyright notice, which has been transferred. And when you say something may vary, you need to specify what it may vary from.

"Foundation, and"
"tool vendors, and"

"contribute"
"under the terms that apply to the modified file(s)."

"and an SPDX tag."

"copyright"

"statement, an SPDX-License-Identifier tag, and an explicit license."

"attempt"

"sample"

"contains"

"marked, should"

"its full form"

👍

I think we should claim the advertising clause is not allowed not just discouraged.

Perhaps even add "and are unlikely to be accepted by the core team."?

ok

done.

yup. done.

I'll note it in the commit message.

s/coremail/core-email/