Thread (111 messages) 111 messages, 9 authors, 2021-02-10

Re: [PATCH 18/18] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree

From: Rob Herring <robh@kernel.org>
Date: 2021-02-09 02:06:57

On Mon, Feb 8, 2021 at 6:49 PM Hector Martin [off-list ref] wrote:
On 09/02/2021 04.14, Rob Herring wrote:
quoted
Does there need to be a legal entity behind 'The Asahi Linux
Contributors' to be valid?
I don't think so, this seems to be common practice in other open source
projects, and recommended these days.

Some recent discussion on the subject from the Linux Foundation:

https://www.linuxfoundation.org/en/blog/copyright-notices-in-open-source-software-projects/
Okay, that's good to know. I'd primarily seen this for Chromium which
obviously has a company (and lawyers) behind it.
quoted
 From a more practical standpoint, if we want to relicense something in
say 5 years from now, who do we ask for an okay?
I thought that's what Git history was for; certainly we aren't keeping
file headers up to date every time someone touches a file (which for
anything other than trivial changes gives them a copyright interest in a
portion of the file).
Yes, for sure. Especially since copyrights tend to be stale as the
blog talks about.
Asahi Linux's policy for bespoke projects is to use "The Asahi Linux
Contributors" for this reason, acknowledging that the copyright headers
aren't up to date anyway (also the years...), and implicitly directing
people to the orignal project (which is where Git history is kept and
contains the true record of copyright owneship).

I'm not trying to shake up how we handle copyright lines in the kernel
here, of course; if you prefer some nominal copyright line from "whoever
first wrote the file or most of it" I can do that. But it certainly
won't be the only person you have to ask if you want to relicense, if
anyone else touched the file in a nontrivial way :)
No, it's fine as is.
There are a few examples of this style in the tree, mostly pulled from
other projects:

arch/arm/oprofile/common.c
drivers/gpu/drm/vgem/vgem_drv.[ch]
drivers/md/dm-verity-target.c
drivers/md/dm-verity.h
quoted
quoted
quoted
I guess Rob will comment on the dt-bindings more... but for me a generic
"arm-platform" is too generic. What's the point of it? I didn't see any
of such generic compatibles in other platforms.
This is a hack for patches #11/#12 to use, and I expect it will go away once
we figure out how to properly handle that problem (which needs further
discussion). Sorry for the noise, this should not be there in the final
version.
I was going to ask on this. If you have a user of it, I'm okay with it.
Generally though, 3 or 4 levels of compatible don't really have users.
The pattern here was board, soc, "arm-platform"; the first two seem to
be a common (and useful) pattern, and I hope I can get rid of the third
once we solve #11/#12 in a saner way.
quoted
It's a WIP to be more consistent around node names. For actual
clock controllers we have 'clock-controller(@.*)?'. There's not really
something established for 'fixed-clock'. We probably should define
something, but that goes in the schema first.
What do you suggest for this series?
Fine as-is unless someone wants to define the pattern and add it to
the fixed-clock schema before this is merged.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help