license: Create a license guideline document

[imp]

Summary

Create a license guideline document for the project. This pulls together all the
disparate docs into one location.

Also, introduce a new policy to allow SPDX identifiers to completely specify a
license and specify the mechanics of how to construe the license for such files.

Changes of note:

o Our model license and the SPDX model license have slightly different text. This switches us to the SPDX text.
o This also switches our default preference to using the detached license with the SPDX keyword.

[brooks]

documentation/content/en/articles/license-guide/_index.adoc

131

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

[imp]

documentation/content/en/articles/license-guide/_index.adoc

131

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.

229

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

238

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.

[imp]

Update after I've re-read this and checked markup.

documentation/content/en/articles/license-guide/_index.adoc

59–60

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.

131

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.

293

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

[imp]

try to roll in all the review text.

[imp]

More nits from proof reading and looking at markup.

[imp]

Upon further review, add a bit more context to the SDPX License identifier
expresison to hopefully ease John's concerns some more.

[brooks]

documentation/content/en/articles/license-guide/_index.adoc

131

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.

[jhb]

documentation/content/en/articles/license-guide/_index.adoc

51

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.

56

59–60

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.

61

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.

201

214

247

257

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

[imp]

documentation/content/en/articles/license-guide/_index.adoc

51

good suggestion.

59–60

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.

61

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.

131

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.

257

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

[emaste]

documentation/content/en/articles/license-guide/_index.adoc

44

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

49

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

55

"standardize on more standard licensese" reads a bit awkwardly

61

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.

104

We can remove this in the near future

122

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.

[jhb]

documentation/content/en/articles/license-guide/_index.adoc

55

61

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.

63

[imp]

rebase, fold in reviews to date to the best of my knowledge

[imp]

documentation/content/en/articles/license-guide/_index.adoc

44

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

[rpokala]

documentation/content/en/articles/license-guide/_index.adoc

34

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

I think that's clearer English.

55

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

... the approval of the [e-mail] ...

vs

... the approval of [e-mail] ...

60

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

61

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?)

64

s/right/correct/g

88

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

116

"filesystem, including"

119

"had it, in order to comply with"

120

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

187

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

207

"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.

215

"Foundation, and"
"tool vendors, and"

218

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

223

"and an SPDX tag."

224

"copyright"

234

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

236

"attempt"

260

"sample"

262

"contains"

279

"marked, should"

288

"its full form"

[emaste]

documentation/content/en/articles/license-guide/_index.adoc

34

👍

49

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

56

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

[imp]

last call

[imp]

Remove warning

[imp]

updated

documentation/content/en/articles/license-guide/_index.adoc

49

ok

55

done.

56

yup. done.

131

I'll note it in the commit message.

[rpokala]

documentation/content/en/articles/license-guide/_index.adoc

207

[bcr]

Very minor issue with the core-email in one place.
Thanks for working on this!

documentation/content/en/articles/license-guide/_index.adoc

70

s/coremail/core-email/