Clean GPL examples?

[Someone]

So its time again to visit the minefield of open source licensing. I've used plenty of LGPL sources in the past and contributed back any fixes/changes etc and fully support open source, but completing obligations under GPL seems wildly impractical. Take for example the simple case of distributing some software that runs on linux, easy to do and comply with GPL. But if you want to package that already installed on linux (for instance in an embedded product) you need to have complete source for everything that is being distributed:
https://www.gnu.org/licenses/gpl-faq.html#UnchangedJustBinary
After much hunting around for an example of a Raspberry Pi image that meets this I'm still stumped. Even the "official" build processes use binary blobs:
https://github.com/RPi-Distro/pi-gen
How do high profile examples like this get away with not providing a way to pull all the sources? A end user accessible copy of all the GPL sources is required to be able to distribute the aggregate, and then provides the convenient base for customising where the user can then redistribute the modified form and the corresponding source.

Does anyone have some good examples of linux repos that include the build flow so they are buildable to a booting image from source? Do any exist for Raspberry Pi?

[agehall]

As I understand it, the distribution can consist of software that is GPL or whatever. The individual pieces of software do of course retain their own licenses but the distribution as a whole can have it's own license on top of this as long as it does not contradict the other licenses.

The whole discussion about GPL and how far it spreads with everything it touches is a lengthy one but I think distro makers are in the camp that says that it stops with the linking step in the binary and thus a single GPL software does not pollute the whole distro and therefore it is perfectly fine to include non-GPL software in the same distro. Another approach is to leave the combining of non-GPL and GPL to the end-user.

If you are looking for something that always builds from source, I think you should look at Gentoo.

[nick_d]

It doesn't happen automatically, it's more of a demand thing. Like for example when a new mobile phone is released, eventually enough people will buy it that it starts to be targeted for open source Android distributions such as LineageOS. Then the LIneageOS developers will pester the manufacturer of the phone until they eventually come up with the GPL sources. I have done this for a router that I bought, it was a Billion BIPAC model and eventually I got hold of the Linux sources. It wasn't all that pretty and as you said, it included many binary blobs which was a bit disappointing. However, I think technically speaking those binary blobs were kernel modules. It is very much a grey area whether this constitutes combination with the GPL'd code. I would naively say it does, the manufacturer obviously thinks it doesn't. There was a high profile case where a LInux developer sued VMware over this issue. That's because VMware was distributing a closed source product which I think was VMware ESX Server or similar. Which is basically a cut-down LInux distributiuon that runs only the VMware hypervisor, and hence you load OSes underneath it. For the concept to work, the hypervisor needs to be able to control all devices attached to the computer, and they were using Linux device drivers to do so. They claimed that the ESX Server binary blob wasn't Linux, it only adhered to Linux interfaces and loaded Linux kernel modules (the device drivers which are GPL'd). I think this claim is bullshit and so did the Linux developer who sued them. It went on for years and I do not know the outcome in the end. I do know that when commercial stakes are high, companies are very incentivized to bend the rules.
cheers, Nick

[magic]

How do high profile examples like this get away with not providing a way to pull all the sources?

Not a lawyer and didn't even read your link That being said, it's my understanding that some blobs are acceptable, such us:
- binary applications running on top of a GPL kernel or even using GPL libraries with special exemptions (such as libc)
- kernel drivers for hardware and filesystems, Linux copyright holders make it clear it is their intent to allow them
- firmware for peripheral devices

Does anyone have some good examples of linux repos that include the build flow so they are buildable to a booting image from source?

OpenWRT might be one, a third party firmware for various routers. You download a repo, choose your model, run make and get an image you can upload through the admin panel.
I think ChromiumOS comes close too, save for binary driver blobs, but I never actually tried building it.
Many hardware vendors don't bother, though. Reasons include:
- it's an effort to publish and maintain such build system
- their internal build system may employ proprietary tools they don't want or aren't allowed to publish
- the code contains their patches which they want to (legally or not) withhold from competitors

Take for example the simple case of distributing some software that runs on linux, easy to do and comply with GPL. But if you want to package that already installed on linux (for instance in an embedded product) you need to have complete source for everything that is being distributed:
https://www.gnu.org/licenses/gpl-faq.html#UnchangedJustBinary

You seem to believe this implies that any software contained in an embedded Linux system must be open source.
However, the paragraph you link only talks about redistributing a binary of GPL software you obtained from someone else.
I think more relevant is this one:

What is the difference between “mere aggregation” and “combining two modules into one program”?
    Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program.

    Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL—if you can't, or won't, do that, you may not combine them.

    What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

    If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

    By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

So you can argue that an embedded system is a self-contained program and none of it would be of any value to the end user without some particular critical GPL component, but the vendor will argue back that their embedded system is merely an aggregation of multiple "programs" communicating over usual inter process communication channels and go fight them now.

[Someone]

The whole discussion about GPL and how far it spreads with everything it touches is a lengthy one but I think distro makers are in the camp that says that it stops with the linking step in the binary and thus a single GPL software does not pollute the whole distro and therefore it is perfectly fine to include non-GPL software in the same distro. Another approach is to leave the combining of non-GPL and GPL to the end-user.

You've summed up the situation in those few sentences better than any other reference I have found, well done.

The challenge still remains that if you want to distribute a system incorporating GPL code you need to be able to provide the source for those GPL parts (and the sources they extend to). After much more searching I did find one example for the Raspberry Pi that collects the sources of all the GPL components:
http://www.arbetsmyra.dyndns.org/nard/index.html
Somewhat comedically that flow which makes it easy to comply with the GPL is licensed in a way that it can't be freely distributed by others. It is utterly bizarre there isn't one (or possibly even any at all) widely used GPL build flow for maintaining compliance with GPL.

[gamblingfetus]

For GPL compliance, sources of all modifications you made need to be available, but not necessarily a complete dependency walk of all original sources.

Also, a best practice is to concatenate all of the licenses from each included component into a Markdown file.

In general, libraries that use AGPL, GPL3 or lack a license are radioactive to begin with. GPL2 is risky. MIT, Apache, BSD2/3 and similar are ideal.

(IANAL)

[janoc]

This site has a good run-down of which methods of distributing source code are acceptable and what you need to do:
https://www.softwarefreedom.org/resources/2008/compliance-guide.html

They specifically cover also embedded devices. However, in practice if you distribute only source for things you have modified (kernel, etc.) and any required build scripts (which may e.g. pull in the official Raspbian sources) you will be likely fine.

The RPi example you gave doesn't really apply - not everything in an RPi image is GPL licensed. So they need to distribute sources only for things that are (and they do, IMO). pi-gen is a distro generation tool, that it pulls in pre-compiled packages doesn't mean it uses "blobs" for which no source is available.

In general, libraries that use AGPL, GPL3 or lack a license are radioactive to begin with. GPL2 is risky. MIT, Apache, BSD2/3 and similar are ideal.

If it lacks a license, then it is all rights reserved by default and it cannot be used. AGPL you are very unlikely to encounter in embedded space (or even in general - it is so nasty that very few projects use it).

The blanket statement on the rest is really unhelpful because then nobody could ever use any embedded Linux, for example (most of Linux kernel and userspace is GPL2/3 licensed). All of those licenses can be complied with, even in embedded code - and companies do it every day. Just make sure you understand the obligations being imposed and what they mean in the context of your product.

I also don't understand why GPL3 would be "radioactive" and GPL2 merely "risky" - they impose the same obligations, only GPL3 makes some things more explicit, such as the patent grants and the anti-DRM/Tivoization clause (aka conveying the source code but making it unusable by cryptographically locking the product down).  BTW, if the patents are your concern about GPL3, then the Apache license has a fairly similar clause ...

[andersm]

The GPLv3 requirement that the user must be able to install their own software onto the device is usually the sticking point. At best it's a hassle, at worst impossible to fulfil due to eg. certification requirements. It also kind of dovetails into the whole "right to repair" question. Where does the manufacturer's responsibility end when the user starts tinkering with the firmware?

[magic]

The GPLv3 requirement that the user must be able to install their own software onto the device is usually the sticking point. At best it's a hassle, at worst impossible to fulfil due to eg. certification requirements.

To be honest, the inverse is impossible to fulfill, i.e. preventing modifications to equipment by its owner. That kind of regulations are nonsense and should be pushed against.
At the same time, a locked down device running Linux is still preferable to me to some proprietary invention so I'm glad Linux isn't GPL3 and that sentiment seems to be shared by many people, including most Linux (and BSD) developers.

It also kind of dovetails into the whole "right to repair" question. Where does the manufacturer's responsibility end when the user starts tinkering with the firmware?

When user's firmware causes a failure that wouldn't otherwise exist. I doubt courts would have doubts about it and few people are going to sue vendors who refuse repair on that grounds in the first place.
People have been hacking embedded devices for decades (hey, bandwindth unlocks, anyone?) and that kind of controversies just don't seem to be a thing in practice.
Most of the locked-down systems are either due to certification requirements as you say or for DRM and crap like that.

[Tomorokoshi]

Tried to figure it out specifically in the case of fonts for an embedded system. It felt like an unterminating while() loop - effort without answer. The guides we did find never really answered the questions, and there were just too many ambiguities about how much the source was "polluted" by the font being imported, along with when obligations were triggered by the license.

Finally threw it all out and bought a commercial font. Money very well spent.

[janoc]

The GPLv3 requirement that the user must be able to install their own software onto the device is usually the sticking point. At best it's a hassle, at worst impossible to fulfil due to eg. certification requirements. It also kind of dovetails into the whole "right to repair" question. Where does the manufacturer's responsibility end when the user starts tinkering with the firmware?

Well, that's the anti-tivoization clause. The problem with this idea is that once you lock the device down, the entire point of GPL (being able to fix/improve/replace the code running on the device) is moot, because there is no way to upload and actually use that code.

The certification part (radios, etc.) can be solved by simply locking only those parts down (e.g. a protected binary firmware blob to be loaded at runtime - a pretty common solution). If the entire device needs to be certified (e.g. safety-critical medical hw or avionics), then are you sure you want to use a bunch of open source software written by Joe Random you have no control over?

And re manufacturer's responsibility - that's a very poor excuse for locking the hw down. It is trivial to log somewhere in an eeprom or something (e.g. blowing some sort of config. fuse) that the bootloader/whatever has been unlocked and then refuse warranty/responsibility if the user has tinkered with it. But this may not absolve you from fixing any actual hw faults - e.g. computer vendors tried to pull this off by refusing to honor warranties if someone has installed Linux on their laptop instead of the preloaded Windows. They got this thrown back in their faces by the various consumer protection agencies as unreasonable when the client was demanding repair for hardware problems, such as broken fans, GPUs and similar issues. Ultimately, you can't really prevent the user from tinkering with their own hardware and any such lock will get broken sooner or later.

Instead of that certification/responsibility fig leaf, a way more common reason why companies want to lock the hardware down are purely commercial reasons - preventing the user from changing configurations to obtain something they didn't pay for or to lock out competition.

[andersm]

The certification part (radios, etc.) can be solved by simply locking only those parts down (e.g. a protected binary firmware blob to be loaded at runtime - a pretty common solution). If the entire device needs to be certified (e.g. safety-critical medical hw or avionics), then are you sure you want to use a bunch of open source software written by Joe Random you have no control over?

There's a ton of devices outside of medical or avionics that require certification too. And there's also a lot of common software that has switched to GPLv3 or LGPLv3, eg. Bash, which is quite reasonable to have installed in a Linux-based device. Though medical and avionics would not fall under the anti-Tivoization clause anyway, as neither is a user product as defined in the license. But that definition has its own issues that aren't clear at least to a layperson.

Say you have a burglar alarm system, and it is sold and installed into a warehouse. That is clearly not a "dwelling", so the installation information clause does not apply. But if that same product is installed in a dormitory, does it apply then? And what about hotels, hospitals, office buildings?

And re manufacturer's responsibility - that's a very poor excuse for locking the hw down. It is trivial to log somewhere in an eeprom or something (e.g. blowing some sort of config. fuse) that the bootloader/whatever has been unlocked and then refuse warranty/responsibility if the user has tinkered with it.

It may be trivial if you have those features in your hardware. But the argument is that you wouldn't be allowed to refuse.

Instead of that certification/responsibility fig leaf, a way more common reason why companies want to lock the hardware down are purely commercial reasons - preventing the user from changing configurations to obtain something they didn't pay for or to lock out competition.

That's certainly part of it for some, but hasn't really been a concern in any discussions I've been involved in.

[Doctorandus_P]

Decian is a linux distro that is pretty strict in what it finds acceptable to include.

There is also a linux distribution that claims it build (almost?) everything from source. I think it's Gentoo, but I migh be wrong here.

[blacksheeplogic]

Well, that's the anti-tivoization clause. The problem with this idea is that once you lock the device down, the entire point of GPL (being able to fix/improve/replace the code running on the device) is moot, because there is no way to upload and actually use that code.

Support cost can be very high, if Joe Blogs  screws his device you can be sure Joe's still going to try and get support. When you've invested support cost and found the root cause, you think Joe's going to front up with payment? Nope.

[Someone]

And re manufacturer's responsibility - that's a very poor excuse for locking the hw down. It is trivial to log somewhere in an eeprom or something (e.g. blowing some sort of config. fuse) that the bootloader/whatever has been unlocked and then refuse warranty/responsibility if the user has tinkered with it. But this may not absolve you from fixing any actual hw faults - e.g. computer vendors tried to pull this off by refusing to honor warranties if someone has installed Linux on their laptop instead of the preloaded Windows. They got this thrown back in their faces by the various consumer protection agencies as unreasonable when the client was demanding repair for hardware problems, such as broken fans, GPUs and similar issues. Ultimately, you can't really prevent the user from tinkering with their own hardware and any such lock will get broken sooner or later.

A very interesting point when more and more function is being off loaded into the higher level OS. But getting wildly off topic 

[janoc]

Say you have a burglar alarm system, and it is sold and installed into a warehouse. That is clearly not a "dwelling", so the installation information clause does not apply. But if that same product is installed in a dormitory, does it apply then? And what about hotels, hospitals, office buildings?

That's actually explained directly in the license (https://www.gnu.org/licenses/gpl-3.0.en.html):

For a particular product received by a particular user, “normally used” refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product.

A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product.

So unless you make an alarm system that is specifically designed, sold and used only for warehouses, it applies even if you have installed it in a place that isn't a "dwelling".

And also:

In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage.

However, in the case of this clause it is in your own interest to consider the product as "consumer product", with the attached consequences (distribution of the source code, etc), because otherwise the license doesn't apply. Which means that in the absence of some other license (e.g. obtained separately from the sw's author) it defaults to all rights reserved - and you do not have any right to distribute it.

That said, I do agree that this clause is weird - it would make much more sense to not restrict this to "consumer products", regardless of how are they defined.

It may be trivial if you have those features in your hardware. But the argument is that you wouldn't be allowed to refuse.

And how are you going to deal with the case that someone jailbreaks the device? Historically pretty much all of these protections have been bypassed as long as the hw was an interesting target. If you aren't allowed to refuse a warranty/repair for a modified device (which may well be the case in some situations), then the anti-tivoization clause is really the least of your concerns, because leaving the device unlocked would have the same consequences - most people don't hack and the few that do would do it regardless of your lock.

[Marco]

How do high profile examples like this get away with not providing a way to pull all the sources?

No Linux contributor has ever decided to sue.

Linus&co have not commented on the situation for over a decade now, so they seem to be pretty much at peace with distribution of binary modules with the kernel. I assume they keep their mouth shut because license wise they can't actually do anything to make it legal at this point and they don't want to put ideas in any other contributor's heads.

[janoc]

Support cost can be very high, if Joe Blogs  screws his device you can be sure Joe's still going to try and get support. When you've invested support cost and found the root cause, you think Joe's going to front up with payment? Nope.

Yes, but people will screw with their stuff regardless whether or not you lock them. In that case it is actually less costly to keep it unlocked/make it unlockable and only keep track of it in some tamper-proof way. Because at the end of the day that is what you need to reduce the support costs - to be able to justify refusing the support/repair, not preventing the Joe from messing with it (they will find a way regardless). It is the same as the liquid detection strips - you can either make the phone waterproof (=expensive and difficult - and people will still go diving with it thinking waterproof means 40m under the surface waterproof!) or add a $0.01 detection strip inside.

Of course if the company's goal is something else (such as locking out competition or forcing the customers to pay more), that's another matter. But then let's not pretend it is about support costs ...

[janoc]

How do high profile examples like this get away with not providing a way to pull all the sources?

No Linux contributor has ever decided to sue.

That's completely wrong.
https://wiki.fsfe.org/Migrated/GPL%20Enforcement%20Cases
https://www.theregister.co.uk/2005/04/29/fortinet_settles_gpl_lawsuit/

and many others. A lot of these cases have been led by Harald Welte (iptables author):
https://en.wikipedia.org/wiki/Harald_Welte

Most of these cases are actually settled out of court, before it comes to the actual process, so you may not be aware of them. The goal is to bring companies into compliance (= release the sources), not to wring money out of them.

[Marco]

No Linux contributor has ever decided to sue (within the context of closed source binary modules being distributed with the kernel).

They got a bit upset about it when NVIDIA half-half did it, with shim and without packaged distribution ... and then when Android went full steam ahead and it started to be done a million times worse than anything NVIDIA did, not a peep. Funny that.

[janoc]

No Linux contributor has ever decided to sue (within the context of closed source binary modules being distributed with the kernel).

They got a bit upset about it when NVIDIA half-half did it, with shim and without packaged distribution ... and then when Android went full steam ahead and it started to be done a million times worse than anything NVIDIA did, not a peep. Funny that.

That's also wrong.

https://sfconservancy.org/copyleft-compliance/vmware-lawsuit-faq.html
http://ipkitten.blogspot.com/2019/01/vmware-gpl-case-is-back-in-courtwill-we.html

It specifically concerns binary modules combined with the kernel. The first suit was dismissed, now it is in court again.

And there were many other cases where the violation has been resolved after the vendor has been called out publicly on the kernel mailing list or elsewhere (e.g. Oracle was famous for trying to play games like that). Lawsuit is really the last resort - absence of court cases does not mean that the license isn't being enforced! Only that the violators realize that fighting this is futile and they would (expensively) lose unless they fix their mess.

E.g.: https://plus.google.com/+gregkroahhartman/posts/6Zu4x37jv9G


There is no problem with binary modules per-se. They are frowned upon, because they are often unmaintained, cannot be audited and tested properly so are potential sources of stability problems and security issues (kernel drivers run with "root" access to anything on the machine).

The Nvidia's shim was not designed to bypass GPL but to provide a "buffer" against changing kernel APIs (otherwise you would have to recompile everything every time you change kernel). Only the shim gets rebuilt. ATI/AMD has the same design. And plenty of others. It is tolerated because it is understood that these drivers were never derivative works of the Linux kernel, in some cases weren't even originally developed for Linux to begin with.

The GPL issues get triggered only if there is a binary-only module/blob that uses kernel interfaces that are explicitly tagged as GPL-only (don't remember the symbol used for that from top of my head). Then the module becomes a derivative work of the kernel and must be GPL-ed too. That's the crux of the VMWare lawsuit above. If the module/driver doesn't need these interfaces, then there is no problem - it is not considered as a derivative work and GPL doesn't apply (using a public API doesn't make something a derivative work, that's why the kernel uses this kludge with the symbols being tagged as GPL-only to make it explicit).

This way of delimiting the kernel boundaries was chosen many years ago following an incident with a webcam driver (I believe it was for Phillips webcams) that had some sort of closed source, proprietary compression scheme. The developer then included a "hook" in their driver to load this blob into the kernel. That was considered a GPL violation because that driver was developed specifically for Linux, as a derivative work of the kernel, using its files - and had closed source part. Which isn't allowed. I believe the hook in question was removed, along with the proprietary compression scheme and later a fully GPLed driver was made after someone reverse engineered that compression scheme.

And re Android - I am not quite sure what are you talking about, given that the Android kernels are open source, the vendors ship the source (how would e.g. Cyanogen and the other modders get their kernels?). What may be in binary blobs are some device drivers but see above - as long as the driver doesn't need the GPL-only interfaces or it is a firmware for e.g. some radio (i.e. not a derivative work of the kernel by definition), it is fine. Also many drivers have an open part which is a part of the kernel that e.g. exposes the device to user space (e.g. as a special file or memory block) and then there is closed user space library to deal with it (cameras on Android are often like this).

For example Samsung's page:
http://opensource.samsung.com/

Or Huawei's (!):
https://consumer.huawei.com/en/opensource/

What is often proprietary on Android is the user space stuff - but that has nothing to do with the kernel, it is not even Linux and most of those tools were either developed from scratch by Google or have permissive licenses allowing such distribution/use. Even in Linux you can (and do - e.g. Matlab) have closed-source proprietary applications.

[Marco]

Mea Culpa, so someone is suing. It's just Linus and other major contributors who have almost certainly intentionally not spoken out about it for over a decade.

The GPL only tags don't mean much, every contributor has as much right to make a copyright claim as another. The people who add the tag don't have the right to overrule the GPL for other contributors. Either distribution with a binary only module is okay, or it isn't ... the tags can't be relevant, except for the standing of the specific person who added them to sue. I think Linus&Co would like them to be relevant, but they can't go back in time to change the license to really make them so ... so instead they just stay intentionally quiet and try to maintain a status quo where nearly everyone pretends they overrule the license.

Graphics drivers aren't user mode ... how many mobile GPU drivers are open source?

[Gabri74]

Does anyone have some good examples of linux repos that include the build flow so they are buildable to a booting image from source? Do any exist for Raspberry Pi?

I'm surprised no one mentioned Yocto https://www.yoctoproject.org/

With Yocto you can build complete distributions from source, with really high grade of customization and granularity of what is built and shipped.

It's based on recipes and will build everything from source: it will build a cross-compiler for your target (i.e. arm) to be run on your host machine (i,e, x86) using your compiler and then with this will cross-build all the packages.

License management and compliance is a big part of Yocto: you can limit built packages based on licence type (GPL/LGPL 2/3, commercial, open source, etc) and once the build is done you'll have complete manifests and reports on all the used packages and licenses.

It's de de-facto standard in the embedded industry, with official support by any serious vendor (NXP/Freescale, Intel, Texas, etc).

The learning curve to use it extensively is really steep, but there are plenty of examples and the documentation is really good, so you can set up an example image that can run emulated in quemu in minutes (... for the setup.. the build process take hours depending on your hardware)

Also worth mentining is BuildRoot: https://buildroot.org/

Regarding GPL3 compliance, note that the mainstream interpretation is that you must only allow the end user to install/upload to your target the L/GPL libraries that you already ship and he wants to modify, You don't need to give complete access to your machine/product. I.e you can allow your end user to use an USB drive from which the libraries can be installed on your product using a script.
See for example: https://www.embeddeduse.com/2016/04/10/using-qt-5-6-and-later-under-lgpl/

[magic]

It's just Linus and other major contributors who have almost certainly intentionally not spoken out about it for over a decade.

No doubt intentionally because those things have been decided over a decade ago and the legal landscape hasn't changed much since then.
Everything I'm going to write below you could find yourself simply by reading mailing list archives from early 2000s.

The GPL only tags don't mean much

They mean precisely that the authors and maintainers of given code consider it Linux-specific and you are likely to get sued for creation of a derived work if you link yourself with it. And finding your code a derived work is the only way you could possibly be in violation of the GPL if you wrote it all yourself.
It is also believed that your module is unlikely to be found a derived work of the kernel if it is OS-agnostic and only calls basic interfaces which - in minor variations - exist on every general purpose OS out there and haven't even been invented in Linux. Hence EXPORT_SYMBOL for such interfaces and EXPORT_SYMBOL_GPL for everything else.
The primary purpose of those tags is to document which parts are which and to aid in proving willful infringement if somebody chooses to circumvent them.

every contributor has as much right to make a copyright claim as another.

Not really, contributors don't share copyright to the entire kernel. You only own what you wrote yourself. If you think that having contributed a network interface driver gives you any legal standing to sue NVIDIA for their use of MM or PCI subsystems, you are probably wrong.

[Marco]

Not really, contributors don't share copyright to the entire kernel. You only own what you wrote yourself. If you think that having contributed a network interface driver gives you any legal standing to sue NVIDIA for their use of MM or PCI subsystems, you are probably wrong.

If NVIDIA distributes YOUR code in the process, of course it does. If they are distributing YOUR code under the GPL in a way which extends the GPL to their code, they have to obey it ... and there is absolutely nothing in the GPL about GPL only tags.

Now the question of whether distributing a binary module with a Linux kernel with YOUR code extends the GPL to that module is undecided as of yet, but the GPL only tags can not matter. They are not part of the license, they are just some random text added by a bunch of geezers who can not change the license on YOUR code.

That's the essence of the GPL, it tries to infect the whole project and make it impossible for any one contributor to limit the license without owning the copyright for the whole thing. Which Linus does not.