Rename HT Operation Protection micros to represent the state of the art.

[cc]

Test Plan

Passed kernel build.

[cc]

Add missing update in if_iwn.c and keep IEEE80211_HTINFO_OPMODE_S from the kernel build lesson.

[cc]

add Copyright in if_iwn.c

[manu]

sys/dev/iwn/if_iwn.c

11

I don't think that changing one define is enough to add you as an author of this file.

[cc]

Remove Copyright headnote and myself from if_iwn.c, as noted in review.

[cc]

sys/dev/iwn/if_iwn.c

11

Removed. Thanks for this comment.

[jrm]

In D43770#999098, @cc wrote:

Remove Copyright headnote and myself from if_iwn.c, as noted in review.

Thanks. This follows the contract text.

Consultant shall ensure that the copyright notice and license text attached as Exhibit B shall appear at the top of any new files that Consultant creates; and that the copyright notice and license text attached as Exhibit C shall appear at the top of any pre-existing files that Consultant significantly modifies during the course of providing the Services.

[imp]

In D43770#999112, @jrm wrote:

In D43770#999098, @cc wrote:

Remove Copyright headnote and myself from if_iwn.c, as noted in review.

Thanks. This follows the contract text.

Consultant shall ensure that the copyright notice and license text attached as Exhibit B shall appear at the top of any new files that Consultant creates; and that the copyright notice and license text attached as Exhibit C shall appear at the top of any pre-existing files that Consultant significantly modifies during the course of providing the Services.

Yea, the Foundation needs to fix their contracts to be more in line with project norms. This isn't the first time it's come up. It just creates friction and provides no benefit because the project generally won't allow it for trivial changes.

[jrm]

In D43770#999126, @imp wrote:

In D43770#999112, @jrm wrote:

In D43770#999098, @cc wrote:

Remove Copyright headnote and myself from if_iwn.c, as noted in review.

Thanks. This follows the contract text.

Consultant shall ensure that the copyright notice and license text attached as Exhibit B shall appear at the top of any new files that Consultant creates; and that the copyright notice and license text attached as Exhibit C shall appear at the top of any pre-existing files that Consultant significantly modifies during the course of providing the Services.

Yea, the Foundation needs to fix their contracts to be more in line with project norms. This isn't the first time it's come up. It just creates friction and provides no benefit because the project generally won't allow it for trivial changes.

How is the text above not in line with project norms? This keeps coming up, but it's related to contract text from years ago that was also updated years ago. I think this is more a case of people either making incorrect claims or reacting to people who cargo-cult old things they find in the tree and then incorrectly blaming the contract text.

Here is an example of what I'm talking about.

[2023-06-09 13:24] <XXX> emaste_: funnily enough the foundation contract I have now says I have to put [all rights reverved] in
[2023-06-09 13:25] <emaste_> damn it
[2023-06-09 13:26] <emaste_> it's like a weed
                   <emaste_> don't have to put it in
                   <XXX> y'all should reveiw your contract template
[2023-06-09 13:27] <emaste_> (like a weed in that we keep taking it out of FF contract templates and somehow it comes back)

[I correct XXX to say he's wrong.  The contract he signed did not say anything about All rights reserved.]
 
[2023-06-09 18:22] <XXX> jrm: right it's not there.  Did I remember this wrongly?

Here is another example.

[2023-09-29 13:18] <YYY> I've noticed that the foundation seems to have difficulty keeping the contract license template up to date
[2023-09-29 13:19] <WWW> it'd be nice if they'd update it to explicitly state whether they're ok (or not) with omitting the license text in favor of the spdx short form (retaining the copyright and sponsorship lines)
[2023-09-29 13:20] <WWW> emaste: jrm: CC ^
                   <WWW> that one's pretty recentm though
[2023-09-29 13:21] <YYY> All right reserved keep getting added to sponsored projects way after we started removing it
[2023-09-29 13:22] <UUU> perhaps the foundation copyright requirement should be "Use src's share/examples/etc/bsd-style-copyright with the foundation as the copyright holder"...

[2023-09-29 13:36] <jrm> We've had this conversation a few times now.  Let me recap.
                   <jrm> XXX had recently said that his contract required him to add 'All Rights Reserved', but that was incorrect.  Neither the template nor his contract say that.
                   <jrm> We also had a conversation about the SPDX tags.
[2023-09-29 13:38] <jrm> [I share parts of the contract template.] 
[2023-09-29 14:04] <jrm> YYY: Can you share an example?  I just looked back at contracts for the last few years and I don't see any mention of 'All rights reserved'.  I also did rg -i 'freeBSD foundation.*all rights reserved' /usr/src and found 13 hits, but the latest was from five years ago.
[2023-09-29 14:06] <YYY> I don't recall one right off hand, but recall emails on the subject where someone commits with all rights reserved that gets called out at obsolete. I can believe the contracts are right and people are just confused or looking at a previous contract

I can share the contract template with you. If there are any specific points about it not following project norms, I'll be happy to fix them, but again, I think these accusations are wrong.

[imp]

I can share the contract template with you. If there are any specific points about it not following project norms, I'll be happy to fix them, but again, I think these accusations are wrong.

I'd love to see the template. However, I make the comments in reviews they shouldn't do that, the reason proffered is because the contractors thought they had to do this for their contract. I've had this conversation many times, hence my grumpiness each time it comes up. I'd love to fix that issue, perhaps with better guidance in general that we could have in the project as well (and the template could refer to by reference).

[emaste]

In D43770#999165, @imp wrote:

I'd love to fix that issue, perhaps with better guidance in general that we could have in the project as well (and the template could refer to by reference).

That is what's really needed, and the contract can then reference that document for general guidance.

[imp]

In D43770#999170, @emaste wrote:

In D43770#999165, @imp wrote:

I'd love to fix that issue, perhaps with better guidance in general that we could have in the project as well (and the template could refer to by reference).

That is what's really needed, and the contract can then reference that document for general guidance.

I'm writing a how to submit to github article. I'd like to include a few sentences about this topic there... but I'd also like to have a more detailed discussion somewhere.

[jrm]

In D43770#999165, @imp wrote:

I can share the contract template with you. If there are any specific points about it not following project norms, I'll be happy to fix them, but again, I think these accusations are wrong.

I'd love to see the template. However, I make the comments in reviews they shouldn't do that, the reason proffered is because the contractors thought they had to do this for their contract. I've had this conversation many times, hence my grumpiness each time it comes up. I'd love to fix that issue, perhaps with better guidance in general that we could have in the project as well (and the template could refer to by reference).

I welcome anything that means we don't have to repeat this conversation. I don't know what to do with respect to the contracts, though. Maybe we need to put the part about only adding copyright notices when significant changes are made in 1990s-style flashing text.

Here are the relevant parts of the template. There are minor style issues because I just converted it to plain text.

8.10. License Obligations. Consultant shall ensure that the copyright notice and license text attached as Exhibit B
shall appear at the top of any new files that Consultant creates; and that the copyright notice and license text
attached as Exhibit C shall appear at the top of any pre-existing files that Consultant significantly modifies
during the course of providing the Services.

                                                             EXHIBIT B


                                          Sample Copyright and License (for new files)

/*
 * SPDX-License-Identifier: BSD-2-Clause
 *
 * Copyright (c) 2024 The FreeBSD Foundation
 *
 * This software was developed [1] by <>
 * under sponsorship from the FreeBSD Foundation.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS "AS IS" AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE
 */

  [1] //documentation was written// should be substituted for //software was developed// as appropriate.

                                                             EXHIBIT C


                                 Sample Copyright and License (for pre-existing modified files)

/*
 * SPDX-License-Identifier: <<existing license identifier>>
 *
 * Copyright <<existing copyright notices>>
 *
 * Copyright (c) 2024 The FreeBSD Foundation
 *
 * Portions of this software were developed [2] by
 * <> under sponsorship from the FreeBSD Foundation.
 *

  << existing copyright and license text... >>

*/




 [2] //documentation were written// should be substituted for //software were developed// as appropriate.

[bz]

Can we please NOT do this. I explained it in my other review (D43658) twice by now.

This is (a) only changing some defines to change and not all the others for the same structure, (b) it's been in at least 3 major releases this way why still change it? It fits with the entire HT code. For VHT which is not used yet we still can do and do.

Also, if doing I said replace them with the names from LinuxKPI so we do not have two versions. You are just trading one name for another name and still leaving us with more compat names.

[cc]

In D43770#999610, @bz wrote:

Can we please NOT do this. I explained it in my other review (D43658) twice by now.

This is (a) only changing some defines to change and not all the others for the same structure, (b) it's been in at least 3 major releases this way why still change it? It fits with the entire HT code. For VHT which is not used yet we still can do and do.

Also, if doing I said replace them with the names from LinuxKPI so we do not have two versions. You are just trading one name for another name and still leaving us with more compat names.

The goal of this change is to clarify the names, reduce confusing and save the trouble to remember two sets of different names/meaning, other than the reasons you provided to keep them.
I am fine with two versions that have the same name/meaning. That is when you have both the LinuxKPI version and this version, their names represent the same meaning. As I mentioned in D43658.
I am also fine with only one set of names from LinuxKPI so we don't have two versions. But you said it does not make sense to be inconsistent with other "*HTINFO*" defines. Or there may be technical challenge for the compat of native freebsd code and linuxKPI code, so I made this patch.