[U-Boot] [PATCH 13/60] ARM: tegra: sort some board file include directives

Tom Rini
2016-04-26T18:15:36Z

On Tue, Apr 26, 2016 at 10:18:06AM -0600, Stephen Warren wrote:
> On 04/25/2016 05:22 PM, Tom Rini wrote:
> ...
> >I know company lawyers come up with various policies and some are more
> >restrictive than others. Anything about the exact guidelines you can
> >share would be appreciated.
>
> They're simple and I would assume quite standard:
>
> 1) When creating a new file, add an NVIDIA copyright header.
>
> 2) When performing a non-trival edit to an existing file, if it has
> an existing NVIDIA copyright header, update the data, and if not,
> add one.
>
> Guidance on "non-trivial" isn't given. I would take it to mean
> anything other than typos and whitespace fixes.
>
> Re-ordering your email slightly:
> >I want to echo my agreement on this point. Re-ordering includes does
> >not rise to the level of adding copyright/author/etc lines.
>
> I can see your argument re: copyright headers in the individual
> files, although again I'd echo my previous comments re: a simple and
> unambiguous process being preferable.

Here's where I hope I don't get everyone at NVIDIA that's doing Linux
Kernel or other F/OSS work in trouble. Point #1 above is quite
understandable. Point #2 is something I can see but has totally not
been done by the folks doing Linux Kernel work.

What I do not want to see is a changing of the norms and when possible
and makes sense, a deviation from the norms of the Linux Kernel. And
that would be that you have to make a pretty huge change (at which point
for maintainability and refactoring and so forth, it's probably a new
file or set of new files) to add a Copyright line to an existing file.
But we're not the kernel, true. But looking over the current changes
for the year, same thing.

Now, if you want to instead make the point that in various cases fileB.c
is based heavily on fileA.c and the copyright was missing on fileA.c
when fileB.c was made, that makes sense. Or if they dropped the
copyright line (and we assume no malice), add it back in.

But I do not want to see the threshold for "add your copyright to a
file" be set at "made a non-whitespace/non-typo change".

> However, I don't agree with that argument for the patch/series
> overall; it's certainly a creative process with work behind it to
> decide upon and implement the overall operation. But, if the changes
> to every individual file are trivial and the real work is in the
> idea (of the appropriate directory organization/separation) itself,
> there's nowhere left to represent that. Perhaps copyright should be
> applied to the patch as a whole, and represented in the patch
> description, rather than individual files in this case. I don't
> imagine that would satisfy lawyers though, since e.g. .tar
> distributions would not contain that meta-data. I wonder if an
> overall README listing all copyright holders and saying "for
> details, see git log" would be satisfactory to them, at least for
> "cleanup style" commits.

The review on this patch series itself has indeed been derailed, which I
do not like either. With respect to copyright on individual changes and
so forth, is this a concern you have, or a concern the lawyers at NVIDIA
have?

--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160426/7aaba61e/attachment.sig>