Page MenuHomeFreeBSD

Better copyright advice
ClosedPublic

Authored by imp on Dec 13 2019, 8:33 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Dec 14, 3:24 PM
Unknown Object (File)
Nov 18 2024, 12:39 PM
Unknown Object (File)
Nov 7 2024, 1:46 AM
Unknown Object (File)
Oct 17 2024, 6:13 AM
Unknown Object (File)
Sep 27 2024, 3:47 AM
Unknown Object (File)
Sep 22 2024, 6:24 AM
Unknown Object (File)
Sep 22 2024, 2:00 AM
Unknown Object (File)
Sep 20 2024, 1:14 PM
Subscribers

Details

Reviewers
rgrimes
jhb
brooks
Group Reviewers
Core Team
Summary

Document the common practices around copyrights with "all rights reserved" in
them as new copyright notices get added.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 28136
Build 26272: arc lint + arc unit

Event Timeline

This revision is now accepted and ready to land.Dec 13 2019, 8:40 PM
seanc added inline comments.
share/man/man9/style.9
87

If we're updating our copyright advice, do we want to strike the All Rights Reserved verbiage, or, better still, educate our readers that it is obsolete?

https://en.wikipedia.org/wiki/All_rights_reserved#Obsolescence

share/man/man9/style.9
87

We can't strike all 'All Rights Reserved' lines from the tree. So I have to document how to handle them.
I'm hesitant to point people at this, since it's legal advice, but I'll think about adding a one liner at the end of this section.

I would of like to seen a more formal Copyright update plan in place before large tree sweeps got started by people doing the All Rights Reserved cleaning, but too late now.

share/man/man9/style.9
2

the (c) is a archaic and unneeded attempt at making the copyright symbol. Use of the full word "Copyright" totally obliterates any need for either (c) or an actual copyright symbol. IMHO we should remove the (c) from the sample code, encorage people to not use it in new copyrights. I am mixed on any tree cleaning of this though, potentially done in cleaning of "All Rights Reserved".

I would of like to seen a more formal Copyright update plan in place before large tree sweeps got started by people doing the All Rights Reserved cleaning, but too late now.

We have momentum behind the all rights reserved thing. I'm not going to stop that to come up with some perfect copyright policy. It's not good ROI. That ship sailed last year when we were talking about all rights reserved, got a consensus that the time was right to leave it behind, got core to endorse that position and to start to more widely socialize the plans.

The (c) thing is interesting, but doesn't present the same level of problem that "all rights reserved" does. It's presence or absence doesn't matter at all. It is pure noise, that can be ignored. "all rights reserved" has some negative PR value and the current practices are confusing and we need to document best practices. Having a followup commit to remove (c) and/or (C) would be fine. I can certainly do that, but it's out of scope for this current fix.