Hacker News Reader

Isn't that the beauty of open source, when if someone has severe OCD they could just spend their time tidying up the kernel driver instead of watching mind numbing telly?

I'm not sure what the score is - if these things were tidied up would AMD still be able to upstream their own changes or do they take back fixes from Kernel devs? Seems likely a complex political process...

> It was generated by the hardware division. These are the registers that are authorized for disclosure in the open-source driver by the AMD employed open-source driver developers.

...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."

What modifications would you make that might be useful? The (proprietary) hardware isn't going to change.

Remove some bugs, or improve its performance. Hardware drivers get updated all the time even when the hardware remains the same.

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.

The topic is not the driver - it’s the definition of the lowest level hardware interface.

It’s lists of registers and stuff like that; not things that can really be fixed by external devs.

If the generated code is a representation of certain unchangeable data about the hardware, you might still want to

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".

All you're going to end up doing is changing the names. And for that, in my view, a big long list of defines (or whatever), autogenerated or not, is as good a form of the work as any other.

And, besides, there is an excellent chance that you will never end up changing the names.

You might want to port it to a new language, in which case having the hardware description and a generator tool is easier and better than converting the C headers.

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.

You fundamentally can't because the defining code is usually hard core proprietary or a proprietary toolchain artifact from cadence/synopsis. We're talking like a memory map of the entire system or 1MB+ XML blobs.

Honestly lifting it from a header file manually is going to be easier for everyone.

What do you think AMD would do if they decided to port their driver to a new language? Would they update their generator or would they copy and edit the existing header?

They sure as shit didn't type out these header files by hand, so clearly these are not the "preferred form" for modification.

But the GPL applies to the driver they released, not some hypothetical driver that you or somebody else might create in the future. You're already going to have to rewrite it all in this proposed alternative language... this header is the least of your worries.

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.

It's not applicable, in practice.

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.

> ...which is arguably not compatible with the GPL:

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”.

"Preferred form for modification" is a form that is suitable for a skilled stranger to modify it with little exposure.

What I meant is that the copyright owner is not bound by the terms of a GPL license he grants to others. Similarly, a licensee who receives software from the copyright owner under a GPL license cannot compel the copyright owner to do anything.

An author that licenses the software under GPL, but does not release the source code in that format cannot legally incorporate outsider contributions into his GPL'd work as he would be in a position of infringing the derivative work author's right.

> 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.

> you need a form suitable for modification by a skilled stranger with little prior exposure to said work

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.

> 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.

It may help to think about who can sue whom. Generally only a copyright owner can sue an infringer. A license operates as a defense against a claim of infringement. If a licensee fails to meet a condition, then the license is invalid.

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.

> license operates as a defense against a claim of infringement

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.

> 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.

We can say that it's generated from the "hardware schematics". AMD hardware isn't an opensource hardware.

These are the registers that are authorized for disclosure in the open-source driver by the AMD employed open-source driver developers.

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...?

Modern high-end processors have a lot of undocumented features. This is rather widely known, though of course not universally known. These have existed for a long time - https://en.wikipedia.org/wiki/Illegal_opcode .

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.

What you're describing sounds like a binary blob masquerading as C header files.

It's just a list of registers names, offsets, field names, and bit assignments. It is nothing like a binary blob. It is GPU documentation in the form of C header files.

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.