Why not generate it during the build? Is there a good reason not to do that?
So, it includes many times more register definitions than are ever used (consider there are 8x more register definition lines than actual code lines that could use them) and it includes many sets of 16 or 64 definitions that a software developer would have made one parameterized definition (all the same except for _00, _01, _02, _03, etc). But this is exactly what the hardware guys generated for public release, and it is to be used as-is.
IMHO it's kinda annoying and sad. The rest of the kernel is held to a higher standard, that's why all the other non-trivial multi-arch multi-family multi-generation code in the linux kernel is much more concise / less sloppy. It takes a lot of effort to make it that way, and commercial companies pretty much never bother, except when required by the Linux maintainers.
But, modern graphics drivers are way too complex and way too much work, and most people do want some proper modern GPU support in the kernel, so compromises have to be made. It's not too bad, just a bunch of inert header lines, git and the compiler handle them just fine I guess.
...which is arguably not compatible with the GPL:
"The source code for a work means the preferred form of the work for making modifications to it."
This is the published hardware interface for the driver, the formal public contract. You can't change it without changing the hardware itself.
If you really want to run the generator... well, the preferred form for modification is open to interpretation and if it's some proprietary tool then just getting the output is preferable to a dependency. Sometimes the rabbit hole is too deep, and we have to draw a line.
From what I can tell, most if not all of the driver is licensed with an MIT-style license. But even if it was GPL, AMD would be the licensor, so it gets to decide the “preferred form of the work”.
> a licensee who receives ... GPL license cannot compel the copyright owner to do anything.
Unless licensee in question has also contributed to a published revision of original licensor's code. And for that to work (remember the wording "preferred form for modification"), you need a form suitable for modification by a skilled stranger with little prior exposure to said work. You would otherwise get different preferred forms of modification of each contributor, which is unworkable.
That’s a nice idea, but it’s not a condition of the GPL. GPL v2 and v3 both only state, “The ‘source code’ for a work means the preferred form of the work for making modifications to it.” That definition exists because without it a licensee might try to argue that distribution of modified and then obfuscated code satisfies the source code offer condition.
Regarding a project licensed to others under the GPL, if the project owner accepts contributions under the GPL, then he becomes a licensee of the contributions. So, as you pointed out, he would need to meet the “preferred form” clause and other terms, at least as regards to the contributed portions. As you might expect, for a substantial project with many contributors, this could become very complicated. Therefore, many projects require contributions be made under a more liberal license (or even a copyright assignment) that allows the contribution to be sub-licensed to others without conditions.
Most, but not all of European jurisdictions, have a legal stipulation that all copyright assignments are either void or revocable even if the assigner says otherwise, except for work-for-hire. You therefore cannot release yourself from preferred form even if you required a copyright assignment, otherwise you will get stuck in the case any further published modifications to your work, not only for the contributions, but any part those modifications that interact so much so that they are inseparable, even by the original licensor, may become illegal overnight. As GPL does not state "the form deemed preferred for modifications by the licensor(s)", but " preferred form ... for modifications", you need to apply that objective definition I stated above. It would be nice if they explicitly stated that way though, relieving a lot of load from judges in resolving a possible dispute on which forms are preferrable for modification and which are not.
So, in the case of the project owner who (1) starts out owning all of the rights to the project, (2) incorporates code licensed from a contributor and, (3) distributes the combination, the only person who could possibly sue the project owner for copyright infringement is the contributor. The claim would only pertain to the contributor's code, because that is the only part he owns the copyright to. The project owner/defendant would raise the license as a defense and the key question would shift to whether the owner/defendant violated any of the conditions of the license.
Where the license is the GPL, one of the conditions is partially affected by the "preferred form" definition of source code. The court would look at what the owner/defendant did and whether he met that condition. Importantly, the condition and "preferred form" definition would only be considered in relation to the plaintiff's code; the owner/defendant's code wouldn't be relevant.
Regarding the contributor's code being "inseparable", that will not be the case for one very simple reason: If the contributor sues the project owner, then he must identify which portion of the code he is suing about. If he can't do that or can't show ownership of it, then he will lose.
It works like that in fully assignable IP jurisdictions (like USA), but it works like a contract of adhesion in the author's compulsory rights jurisdictions (like Germany and Czechia).
What I meant by inseparable contribution was a significant contribution, when eliminated, that would make entire work not resemble the current state of the work; i.e. the line that tells derivative work versus near-equal co-authorship apart (which are treated similarly in fully assignable IP jurisdictions, yet have entirely different regimes in the compulsory rights jurisdictions). Not the entirety of the work indeed.
> the condition and "preferred form" definition would only be considered in relation to the plaintiff's code; the owner/defendant's code wouldn't be relevant.
It would, in a compulsory rights jurisdiction, because all copyright assignments are either void or revocable at will in such jurisdictions.
I didn't believe this, so I looked at a study of EU copyright law[0]. Rights of authors are split into moral rights and economic rights. Economic rights are transferable as property. Moral rights, however, inure to the author and are inalienable. In some countries, the moral rights include the right to withdraw the work from circulation. This right to withdraw is probably what you are referring to when you say that copyright assignments are void or revocable.
The right to withdraw a work from circulation, however, does not come for free. In Spain it is only, "after indemnification of the holders of exploitation rights for damages and prejudice."[1] In Estonia, "The rights ... shall be exercised at the expense of the author and the author is required to compensate for damage caused to the person who used the work."[2] In France, "... he may only exercise that right on the condition that he indemnify the assignee beforehand for any prejudice the reconsideration or withdrawal may cause him."[3] In Romania, the right is "subject to indemnification of any holder of exploitation rights who might be prejudiced by the exercise of the said withdrawal right."[4]
In all of the examples I could find, the withdrawal right essentially extinguishes an assignment of the economic rights. So, in a sense you are correct that an assignment is revocable. Practically, however, the author who exercises that right would be liable for damages to the assignee, which could be significant, and the author would not be able to exercise the right if he could not pay for the economic harm.
Anyway, this has been interesting and I learned something about European copyright regimes. Thanks.
[0] https://www.europarl.europa.eu/RegData/etudes/STUD/2018/6251...
[1] Id. at 134.
[2] Id. at 93.
[3] Id. at 173.
[4] Id. at 301.
1) represent it more compactly;
2) represent it in a form that can more easily be read and transformed to handle future use-cases for the data;
3) after some future restructuring of the driver, represent the data in a form that better fits with that structure.
If you have to regenerate the code using the proprietary tool in order to restructure the driver, the generated code is not "the preferred form of the work for making modifications".
And, besides, there is an excellent chance that you will never end up changing the names.
And yeah sure pragmatically it might not make much of a difference in this specific case, but if the AMD devs were to port their driver to a new language they wouldn't edit the C headers they would certainly just update their generator, so the preferred form for modification is clearly not the generated C headers.
Not to mention if all you wanted to do was change the names, maybe prefix them with something, editing the generator is _still_ clearly the preferred format for making that change.
Strikes me that AMD have supplied everything required: all the driver code in the preferred form for modification of the driver, i.e., a bunch of C files.
Some of these C files are a big long list of slightly opaque magic number defines that relate to the hardware, perhaps generated by some unreleased tool, who can say - it's all speculation at this point - but that's OK! The hardware is not the bit you're going to modify. As far as the people modifying the drivers are concerned, those numbers are never going to change. This portion of the driver is fixed.
Honestly lifting it from a header file manually is going to be easier for everyone.
They sure as shit didn't type out these header files by hand, so clearly these are not the "preferred form" for modification.
I'm not an open-source absolutist: I think the pragmatic solution Linux went with is good here. But it's silly to suggest that the driver couldn't be improved if it were more open.
It’s lists of registers and stuff like that; not things that can really be fixed by external devs.
In other words, there's more functionality that they're keeping secret? Sounds like a challenge...
Edit: so the hacker spirit is not welcome here...?
And ... you know this. Checking your comment history https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... I easily found https://news.ycombinator.com/item?id=8834863
> Intel CPUs have had undocumented features since their introduction; it's not hard to imagine their chipsets do too.
Before I did the search I thought you were one of the 10,000 (https://xkcd.com/1053/ ), surprised that others didn't share your enthusiasm. Now I don't understand your surprise.
You must surely know your comment about "the hacker spirit is not welcome here" comes across like snobbish gatekeeping, yes? At the very least, the implied lack of knowledge about undocumented features makes it seem that you aren't one to judge what the hacker spirit might be. ... which cannot be correct given your posting history.
Now I happen to know that the vast majority of it is shared between GPU generations to some extent, so someone could abstract things out manually to remove duplication, but it's a huge task.
If those headers aren't expected to change then, with regards to accountability, it's far better to have the code checked into the version control and processed as is.
More importantly, if the code is already generated then there's no need to make the build system more brittle by adding a non-standard build target that depends on custom/third-party tools.
In many hardware shops the C definitions for the visible registers are generated automatically from the hardware's source code