3 ms·

IANAL, but I work on the Red Hat kernel. I don't need the patches of the Red Hat kernel in order to make modifications to it. I need the patches from the upstre

IANAL, but I work on the Red Hat kernel. I don't need the patches of the Red Hat kernel in order to make modifications to it. I need the patches from the upstream kernel in order to copy them to the Red Hat kernel, but I often use "--depth=1" clones of git trees, in other words clones without the "patches", and make modifications to them. Patches are useful, of course. They are useful to understand the evolution of the software, to support it, etc. But they are not necessary in order to make modifications to the software. Ten-fifteen years ago it was actually the norm that open source software had private source control repositories and only made periodic releases as tarballs.

lmm 8y ago
Sure, it's possible to work without the patches. Equally it's possible to make modifications to code that was generated by a Perl script - or even to modify binary code directly without having the source at all (I've seen it done). The salient question is: what is the preferred form for making modifications to the work? And certainly I'd always want to have the patch history available when working on a codebase.
- bonzini 8y ago
  Working on a codebase however is not what the license says. It says specifically "making modifications". If you have the Perl script that generates C code, you get a benefit from being able to modify the Perl script rather than the C code. So the Perl script is the preferred form for making modifications. If you have the history, you don't get any benefit from modifying the history. In this sense, having the history is not relevant to making modifications, only to studying the code (for example to make the same modifications on another branch/fork of the code, like I do with upstream patches, or like Oracle could do if they had the Red Hat patches). Your could say that this phrasing is shortsighted, but note that neither Red Hat not Debian or anyone else has ever given the complete history to Linux or any other piece of software they distribute, but they had to give the complete base source tarball as distributed by the upstream project.
  - lmm 8y ago
    > In this sense, having the history is not relevant to making modifications, only to studying the code Studying the code is the first step in making modifications. I would always want to have a working "git blame" before trying to modify a codebase, so that I could understand lines in the context of the changes they were part of before I modified those lines. I consider it considerably harder to modify a codebase when I don't have proper version control history available.
    - bonzini 8y ago
      The rest of the comment explains what the license means by "preferred form for making modifications" and why the full commit history isn't it.

lmm 8y ago

Sure, it's possible to work without the patches. Equally it's possible to make modifications to code that was generated by a Perl script - or even to modify binary code directly without having the source at all (I've seen it done). The salient question is: what is the preferred form for making modifications to the work? And certainly I'd always want to have the patch history available when working on a codebase.

bonzini 8y ago
Working on a codebase however is not what the license says. It says specifically "making modifications". If you have the Perl script that generates C code, you get a benefit from being able to modify the Perl script rather than the C code. So the Perl script is the preferred form for making modifications. If you have the history, you don't get any benefit from modifying the history. In this sense, having the history is not relevant to making modifications, only to studying the code (for example to make the same modifications on another branch/fork of the code, like I do with upstream patches, or like Oracle could do if they had the Red Hat patches). Your could say that this phrasing is shortsighted, but note that neither Red Hat not Debian or anyone else has ever given the complete history to Linux or any other piece of software they distribute, but they had to give the complete base source tarball as distributed by the upstream project.
- lmm 8y ago
  > In this sense, having the history is not relevant to making modifications, only to studying the code Studying the code is the first step in making modifications. I would always want to have a working "git blame" before trying to modify a codebase, so that I could understand lines in the context of the changes they were part of before I modified those lines. I consider it considerably harder to modify a codebase when I don't have proper version control history available.
  - bonzini 8y ago
    The rest of the comment explains what the license means by "preferred form for making modifications" and why the full commit history isn't it.