5 ms·

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

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

tom_ 6y ago
What modifications would you make that might be useful? The (proprietary) hardware isn't going to change.
- dmurray 6y ago
  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.
  - akvadrako 6y ago
    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.
- ptx 6y ago
  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".
  - tom_ 6y ago
    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.
    - admax88q 6y ago
      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.
      - andromeduck 6y ago
        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.
        admax88q 6y ago
        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.
      - tom_ 6y ago
        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.
rleigh 6y ago
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.
bdowling 6y ago
> ...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”.
- anticensor 6y ago
  "Preferred form for modification" is a form that is suitable for a skilled stranger to modify it with little exposure.
  - bdowling 6y ago
    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.
    - anticensor 6y ago
      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.
      - bdowling 6y ago
        > 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.
de_watcher 6y ago
We can say that it's generated from the "hardware schematics". AMD hardware isn't an opensource hardware.

tom_ 6y ago

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

dmurray 6y ago
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.
- akvadrako 6y ago
  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.
ptx 6y ago
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".
- tom_ 6y ago
  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.
  - admax88q 6y ago
    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.
    - andromeduck 6y ago
      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.
      - admax88q 6y ago
        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.
    - tom_ 6y ago
      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.

rleigh 6y ago

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.

bdowling 6y ago

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

anticensor 6y ago
"Preferred form for modification" is a form that is suitable for a skilled stranger to modify it with little exposure.
- bdowling 6y ago
  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.
  - anticensor 6y ago
    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.
    - bdowling 6y ago
      > 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.

de_watcher 6y ago

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