Page MenuHomeFreeBSD

license: Create a license guideline document
Needs ReviewPublic

Authored by imp on Apr 2 2021, 5:37 AM.

Details

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.

Diff Detail

Repository
R9 FreeBSD doc repository
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 38274
Build 35163: arc lint + arc unit

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
documentation/content/en/articles/license-guide/_index.adoc
35
58–59

So this is a bit wishy-washy as GENERIC includes modules, and we definitely have CDDL (and even GPL for bwn(4)) in modules. Not sure if you want to be a bit more explicit about what this requirement really is.

66

Is the goal of this doc to supplant that page btw? I kind of feel like we probably don't want two copies of this, but want this doc to become the new license policy or some such. As it is, this doc is so small it could just be the policy doc rather than a separate article IMO.

67

Could you summarize those differences? Is it just replacing the sample license with SPDX versions, or are there other substantive changes?

177
203

I don't know of a better way to say it, but the end of this sentence is a bit rough with "license" occurring 3 times in about thrice as many words.

207
214

I guess the "a" vs "an" part depends on if you say "an ess-pee-dee-ex" or "a spy-dex" (I read it as the former).

234
249
255
292

I think it is somewhat confusing that we describe AND here after saying it shouldn't be used. I can think of two ways to resolve this. One might be to better highlight that this last section is a verbatim copy of the SPDX expression format with a link to the original reference. Another might be to add an explicit note here as a reminder that this example is included for completeness but should not be used the tree. I probably prefer the first approach, but it might also need a brief mention of why we are duplicating the content vs relying on the external source, and which version is authoritative (I think your intention is that say that this version is authoritative over SPDX's version just as the licenses in /usr/share/license are authoritative, but I think we could be explicit about that).

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

I copied this text verbatim from the website internal page.
I think we should just say "Please consider using the BSD-2-Clause license as shown above"

58–59

This is copied from elsewhere, but you are correct.

66

The goal of this article to have all things license in one place, rather than having some in the handbook , some in the developer's guide and some in the web site only. It's confusing when people are looking for it. All places we talk about license will be referenced to this article, or the appropriate section.

67

Just that.
The plan is to remove this from the website and replace it with a pointer here.

203

Yup.

292

It's only the detached license that you can't use this. For tagging of files with multiple licenses, you can use it (and need to).

brooks added inline comments.
documentation/content/en/articles/license-guide/_index.adoc
130

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

185
220
228

It feels weird to refer to the installed location rather than something in the source tree.

237

I don't understand this.

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

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.

228

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

237

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 marked 24 inline comments as done.Apr 6 2021, 4:09 AM

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

documentation/content/en/articles/license-guide/_index.adoc
58–59

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.

130

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.

292

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

imp edited the summary of this revision. (Show Details)

try to roll in all the review text.

More nits from proof reading and looking at markup.

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

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

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.

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
58–59

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.

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

good suggestion.

58–59

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.

130

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 added inline comments.
documentation/content/en/articles/license-guide/_index.adoc
44

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

48

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.

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

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

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

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

imp added reviewers: emaste, brooks, jhb, gnn.
imp removed subscribers: emaste, brooks, jhb, gnn.
rpokala added inline comments.
documentation/content/en/articles/license-guide/_index.adoc
33
where a tag in the file specifies the license, as described in this document

I think that's clearer English.

54

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

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

63

s/right/correct/g

87

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

115

"filesystem, including"

118

"had it, in order to comply with"

119

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

186

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

206

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

214

"Foundation, and"
"tool vendors, and"

217

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

222

"and an SPDX tag."

223

"copyright"

233

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

235

"attempt"

259

"sample"

261

"contains"

278

"marked, should"

287

"its full form"