Page MenuHomeFreeBSD

license: Create a license guideline document
Needs ReviewPublic

Authored by imp on Apr 2 2021, 5:37 AM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
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 that is done to achieve an unambiguous
result necessary for formation of a legal contract. Some additional work will be
necessary in the base system on top of this to start to archive licenses so
that this system can work.

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

imp requested review of this revision.Apr 2 2021, 5:37 AM
imp created this revision.

I got -only/-or-later and + mixed up. Fix that.

use 'legal document' instead of 'legal contract' to dodge the apparent question
of whether or not, and how exactly, these create contracts or not. The former
phrasing is sufficiently specific for our needs while the latter may introduce
ambiguity and uncertainty in the minds of some readers.

gnn added inline comments.
documentation/content/en/articles/license-guide/_index.adoc
33

s/give/receive//

35

s/suggests and//

48

s/so-called//

51

I don't think you mean "the above license" I think this got munged in the rearrangement? The above license is the one we want, without the advertising clause.

55

Having a number of different licenses in the tree causes problems for those....

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

The following sections outline the project's Software License Policies in detail. For the most part we expect developers to read, understand and utilize the sections above this one in order to apply appropriate licenses to their contributions. The rest of this document details the philosophical background to the policies as well as the policies in great detail. As always if the text below is confusing or if you are questioning how to apply these policies, please reach out to {coremail}.

jhb added inline comments.
documentation/content/en/articles/license-guide/_index.adoc
35
51

Hmm, I had read "above license" as the one in the program listing above, but I do think it might be best to be explicit and say something like "If you have code in the tree with the advertising clause, please consider removing it. In fact, please consider using the project's preferred license above."

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.