Move all the software license stuff to a central location.

[imp]

Summary

This leaves an appropriatesummary on the website pages, committer's
guide and contributing pages, and augments license-guide with
information that was on those pages (though the license exceptions
moves to software-license).

It's mostly word motion with light edits.

[imp]

nits

[ziaee]

Thank you so much, this is sorely needed. I would be more comfortable if we reduce the documentation proliferation by having only two places for policy (web and src) and using redirects. This is a lot better but still requires years of heroism to maintain, and for readers they still have to read a good amount of text in order to deduce that they need to actually be reading something else.

[imp]

In D57340#1314896, @ziaee wrote:

Thank you so much, this is sorely needed. I would be more comfortable if we reduce the documentation proliferation by having only two places for policy (web and src) and using redirects. This is a lot better but still requires years of heroism to maintain.

So suggest something more specific.

[ziaee]

I think the best way would be to put everything in internal/software-license.adoc or articles/license-guide/_index.adoc, and then clusteradm would use html redirect if someone tries to navigate to the other one. Then we would only have two possible documents (style.9 and the policy) to answer questions on, interpret, or maintain.

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

2807

We would keep just this line.

documentation/content/en/articles/contributing/_index.adoc

272–274

This way there's two less sentences of state for the reader to interpret before they realize they need to read the policy.

website/content/en/internal/policies.adoc

27

And limit this to just one or the other.

[imp]

In D57340#1314898, @ziaee wrote:

I think the best way would be to put everything in internal/software-license.adoc or articles/license-guide/_index.adoc, and then clusteradm would use html redirect if someone tries to navigate to the other one. Then we would only have two possible documents (style.9 and the policy) to answer questions on, interpret, or maintain.

I think license-guide is the best place for everything except the marketing summary. I've tagged what I think should move in my comments, please tell me what you think about that with this direction in mind.

Also, would you be interested in helping me create, more generally, a collection of policies for many other aspects of the project? One that may need to be distributed between different teams that care maybe not enough to make them the quality I'm hoping for. So what is the official maintainer policy in ports? Can one take some time off from maintaining and get it back when you're able to devote the time a port needs? what's the actual cross repo policy? What is our election policy? When were these policies last reviewed and/or approved?

Basically, there's too much tribal knowledge and it's really getting in the way because the new people that are interested in FreeBSD tend not to mix with the people that know things. And that is causing growing pains and other needless drama.

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

2807

and move the rest of this section to license-guide somehow? Is that what you're implying?

2862

Is the above section good here, or would it be better in license-guide?

2872

does this belong here or in license-guide?

website/content/en/internal/software-license.adoc

28

What do you think about moving this to the top of the file along with the summary. It's useful, I think, to have the summary for marketing, but have the nitty gritty details just in license-guide.

36

This whole section belongs in license-guide, in addition to the redirect.

[ziaee]

In D57340#1314917, @imp wrote:

In D57340#1314898, @ziaee wrote:

I think the best way would be to put everything in internal/software-license.adoc or articles/license-guide/_index.adoc, and then clusteradm would use html redirect if someone tries to navigate to the other one. Then we would only have two possible documents (style.9 and the policy) to answer questions on, interpret, or maintain.

I think license-guide is the best place for everything except the marketing summary. I've tagged what I think should move in my comments, please tell me what you think about that with this direction in mind.

Also, would you be interested in helping me create, more generally, a collection of policies for many other aspects of the project?

Oh lawd yes. I really think that could fix a lot of our problems. Personally I think the most logical place for those charters is internal/ like internal/doceng, but the paint is not important, what matters is that it's in only one place so that people aren't arguing over different sets of rules. Since we're moving in the direction of preferring articles, we should gradually off internal/ and just use articles/. For example, https://www.freebsd.org/internal/developer/ should not exist, I'd like to move everything over to the committers guide. Most of it is in there already.

Although I would really like to finish what we started getting device.hints and other driver options standardized in D54586 before trying too much to standardize new information organization systems.

One that may need to be distributed between different teams that care maybe not enough to make them the quality I'm hoping for. So what is the official maintainer policy in ports? Can one take some time off from maintaining and get it back when you're able to devote the time a port needs? what's the actual cross repo policy? What is our election policy? When were these policies last reviewed and/or approved?

Basically, there's too much tribal knowledge and it's really getting in the way because the new people that are interested in FreeBSD tend not to mix with the people that know things. And that is causing growing pains and other needless drama.

I agree and have a few arrows in my back for it already. However, I suspect @adamw will help :)

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

2807

Yes, although most of it is already in there, iiuc just tracking.license.grants would be moved.

2862

Better in license-guide. Then the licensing guide is a one stop shop for the whole licensing concept.

2872

SPDX-License-tags are for licensing, so it would be super clean to move it. No cognitive load for remembering because licensing is all in the licensing guide :)

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

332

I would put tracking.license.grants here

website/content/en/internal/software-license.adoc

28

This would be a gorgeous introduction to license-guide, and still keep it all together. If this page redirects, then marketing will still see that as the intro, but we'll have everything in one place.

[imp]

update, per review
Take a stab at what is a BSD license

[imp]

website/content/en/internal/software-license.adoc

28

I'm not yet sold on the redirect. But maybe having a common file included both places wouldn't be bad? It's still an open issue for me what the best way to incorporate this feedback is.

[ziaee]

website/content/en/internal/software-license.adoc

28

Having one file and including it both places solves my duplication problem. It seems slightly more complex than what I am proposing, and I don't know what benefit there would be from doing it that way, but I'm open to that!

[imp]

website/content/en/internal/software-license.adoc

28

Yea, maybe two copies are better for now instead of the complexity of another include for fewer than a dozen lines.

[imp]

So I think that all the editorial changes have been made. I'll wait to commit this until at least after the core 13 -> 14 handoff next week.