7 ms·

Do any Open Source Licences require source history?

33 points by edent 6y ago

Latty 6y ago
I mean, each time you distribute the software you are bound to the license terms for that version, so if you use the same license through time, you have to give that much history. Beyond that, it clearly becomes very murky, especially when it comes to git. Is squashing some commits suddenly against the license? Do I have to commit every time I type a character? There is no obvious smallest unit except "the commit the developer decides on", which could then be everything since the last release, resulting in the status quo. I guess there could be a license where if you changed to that license, it required the history, but it would seem a bit pointless, as inherently at that point the person choosing the license could just choose a different one.
- akkartik 6y ago
  Do similar questions come up even for the current snapshot? Are you required to provide comments? Meaningful type and variable names?
  - eredengrin 6y ago
    Not a lawyer, but I did work for a short period for a company that was distributing a modified linux kernel and therefore had to release the source. In my time there, there were a lot of discussions (some involving lawyers) about whether (and how) we could reasonably obfuscate the source before releasing it. Not sure how those conversations ended since I left before they were done, but it seems it's not clear cut at this point.
    - akkartik 6y ago
      dataflow's comment (https://news.ycombinator.com/item?id=24019778#24025779 https://news.ycombinator.com/item?id=24019778#24025779) seems to answer this, and https://opensource.stackexchange.com/questions/5759/code-obfuscation-and-gpl3/5760#5760 https://opensource.stackexchange.com/questions/5759/code-obf... elaborates: FOSS licenses require distributing the form you use to make modifications to your program. To do anything else opens one up to legal liability.
    - jlokier 6y ago
      I struggle to imagine how this definition in the Linux kernel's license: > The source code for a work means the preferred form of the work for making modifications to it. can be seen as "not clear cut" with regard to whether obfuscated source code counts. It plainly rules out obfuscation. (Unless you genuinely prefer editing the obfuscated version. Which you provably don't if obfuscation is done just for release.)
      - eredengrin 6y ago
        What is preventing a company from hiring a developer or two for very cheap to "work" on the obfuscated code, but not do any real work (or better yet, just bundle it into an existing job description of a qa member or a dev on some other team or something)? How would you prove in court that the devs "working" on the obfuscated version weren't the ones doing the work? It brings into question which version is actually preferred over the other, and how do you answer that? Based off number of commits or changes on the branches? Obfuscated version could easily be gamed to have more commits, and given that it's obfuscated, it might have even more individual changes just by default. I imagine there are some companies that think these questions are worth pondering.
  - numpad0 6y ago
    I believe the gist of GPL is you supply the source code that produced the binary object through your compilation processes to whoever received the binary as you were licensed it as part of the sale or distribution. You are not obliged to supply any intermediate files, media assets, manuals, or technical supports as part of the licensing, though you are not restricted from doing so(you absolutely can charge full prices for GPL’d software) Building from source but cleansing it before release or supplying irrelevant intermediate files, even de-complied files as sources... to “protect valuable assets”, those had been tried and are generally considered license/copyright violations.
smcphile 6y ago
> My question to you, gentle reader – are there any licences which compel the distribution or publication of the development history? No, other than that any given project has to give proper credit to code used from other projects / copyright holders. My understanding of why this is so is the following: A free software or open source software licence is based on copyright law. As such, it restricts what users can do with the source code, but it never restricts what the copyright holders can do with the software (assuming all the copyright holders collectively agree). A user can never (theoretically at least, there may be a few edge cases) sue the copyright holders for anything, because there’s no warranty. No warranty on the code source history (or anything else). So code source history is always optional.
- coolness 6y ago
  This is exactly what most people in this thread are missing. The copyright holder, i.e the creator of the code is never obligated to do anything by the licence he chooses to release with. The licence applied to users of the copyright owners work.
  - throwaway936482 6y ago
    That's not true though. Open source licenses (as defined by the OSI) impose specific obligations upon me as creator - to distribute the source code for "no more than a reasonable reproduction cost" to users, allow users to modify it, and to redistribute it for free if it is bundled with other software, and not to discriminate against persons, groups or fields of endeavour in who can use it.
    - smcphile 6y ago
      No, open source licenses impose no obligations on the copyright holder for their own code. For example, if the copyright holder releases their own code under a GPL licence, no law prevents them from also releasing a modified or unmodified version under a proprietary licence. This is allowed by law, but the proprietary version doesn’t of course negate the rights already given to those who received the GPL version. If a project has many contributors (copyright holders), they would all have to agree to a license change, so in practice something like the Linux kernel is very unlikely to ever change to a proprietary licence, but it’s theoretically possible. The copyright holders are never bound by the terms of a user licence.
angel_j 6y ago
The MIT license is so simple, just add/delete to make your own. My bespoke license is free and open source for the user, but restricts them using it for or on behalf of another person.
- josephcsible 6y ago
  That sounds like it's not open source. Also, license proliferation is a bad thing and you really shouldn't encourage it.
  - angel_j 6y ago
    Open source means you can read the source. The idea that all my work must be FOSS is somebody else's ideal, and one that has kept a lot of people I know from getting paid. Meanwhile, plenty of code, probably most running your world, is purely in the dark and definitely not open source. Whatever you think about "license proliferation", that's like, your opinion. What world are you from that I can't have my own license for my own work? What kind of lemmings notion is it that I should only use a well known, open source license, especially a license that explicitly gives my work away uncompensated to random people on the internet? You are so brainwashed with slogan terminology that you think Open Source has exactly one meaning, and that meaning is not even that the source code is open? Jesus, this forum is retarding sometimes. FOH with yr downvotes. Edit, furthermore, I have dozens of totally FOSS code projects out there, downloaded millions of time per month. Is your business 100% open source, down to how to track your users? Stop telling people what they should do out here.
    - angel_j 6y ago
      This needs more downvotes.
    - josephcsible 6y ago
      > Open source means you can read the source. No, that's "visible source" or "source available". Read the Open Source Definition: https://opensource.org/osd https://opensource.org/osd It even addresses your misconception right up front: "Open source doesn't just mean access to the source code." > The idea that all my work must be FOSS is somebody else's ideal, and one that has kept a lot of people I know from getting paid. You can get paid even if everything you build is FOSS. Look at Red Hat. > Whatever you think about "license proliferation", that's like, your opinion. What world are you from that I can't have my own license for my own work? What kind of lemmings notion is it that I should only use a well known, open source license, especially a license that explicitly gives my work away uncompensated to random people on the internet? Even if your bespoke license were open source, there's a very good chance that it would be incompatible with other licenses like the GPL, thus creating more ZFS-on-Linux sort of problems.
deleted 6y ago
[deleted]
powersnail 6y ago
My basic understanding is that license (usually?) applies to just the code. There is no concept of "history" or "snapshot" pertaining to the code itself. Such constructs only exist with regard to the process of development, about which the code license does not care. Otherwise, every keystroke must be recorded and published to ensure compliance, at which point, the license is ridiculous and unenforceable.
mehrdadn 6y ago
Layman here, but this seems pretty easy to answer for GPL at least because it defines [1] what "source code" means (with a rather brilliant definition, I might add): > The "source code" for a work means the preferred form of the work for making modifications to it. I expect it would be tough to argue that the preferred form of a work to modify is its history rather than its present form. [1] https://www.gnu.org/licenses/gpl-3.0.txt https://www.gnu.org/licenses/gpl-3.0.txt
- markrages 6y ago
  When I modify a program, I often refer to its history. So my preferred form would be something like a git repository, rather than just a tarball.
  - mehrdadn 6y ago
    It's the form you would prefer to modify, not the information you would prefer to have available. I'd prefer to have all the information in the world available, but that doesn't make everything the source code.
- gizmo686 6y ago
  My preferred form of a work would be the a VCS repository with the complete history (assuming it is a familiar VCS like git. If you are using some obscure VCS that I can't get to work, I'd settle for a simple source dump). Almost every project I have worked on has went out of its way to maintain a good history. Wheather it is by cleaning up commits before merging into a main branch; making sure history gets copied when a reorganization moves a significant amount of files to a different repository, or making sure history gets copied when an entire repository moves over to a new VCS.
  - mehrdadn 6y ago
    The quote was that the source code is the form of the program you would prefer to modify, not the information you would prefer to have available. These are different things.
  - 6y ago
not2b 6y ago
What would the definition of "source history" be? The git database? If I do a rebase would I be violating the license? After all, I am collapsing the history, getting rid of failed ideas no one else needs to see.
gramakri 6y ago
AFAIK, postfix has no history. Only releases.
- cookiengineer 6y ago
  > AFAIK, postfix has no history. Only releases. This is correct. It is also hosted on an original BSD (the b as in berkeley) 0.1 with the RCE affected ftpd 0.1 that had issues with too long usernames and passwords. Oh, it's also hosted via http and ftp only, in case anyone is wondering about security aspects of it. I'm talking about the porcupine server, as it is how the source gets distributed... I mean, gpg signing is fine and all, but if transport can be MITM'ed there's no way to verify the gpg signatures. Contacted the author like hundreds of times, offered to help, but not a single eff was given apparently.
  - yjftsjthsd-h 6y ago
    Is https://github.com/vdukhovni/postfix/commits/master https://github.com/vdukhovni/postfix/commits/master not official?
    - cookiengineer 6y ago
      Nope, ftp.porcupine.org is the only distribution source, from there it gets pushed to mirrors, from there people maintain the history manually. Postfix is really a nightmare project from both the missing collaboration aspects and missing security aspects.
- yjftsjthsd-h 6y ago
  Maybe? https://github.com/vdukhovni/postfix/commits/master https://github.com/vdukhovni/postfix/commits/master I wouldn't call them releases, but they aren't normal commits...
  - deleted 6y ago
    [deleted]
  - 6y ago
sverhagen 6y ago
Isn't the requirement to disclose source with a system so that you can make changes (bug fixes and such) without being locked into a vendor? Current source offers that. Other than that licenses typically stipulate that there are no warranties and no support. I see source history more as a support tool (to understand design decisions) than as the "absolute" ability to fix a bug. (This is not and answer to the question, I realize.)
ximm 6y ago
This reminds me of a post by Steve Klabnik: https://steveklabnik.com/writing/what-comes-after-open-source https://steveklabnik.com/writing/what-comes-after-open-sourc... In that he argues that open source is less about publishing the code and more about a culture of developing in the open, with a public source repository and public issue tracker.
walterbell 6y ago
With the advent of reproducible builds, it can also be useful to have a specification of the build environment needed to reproduce a binary from a given source code snapshot.
deleted 6y ago
[deleted]
kemitchell 6y ago
I am not aware of any common "open source" license that requires distribution of comprehensive source code revision history or version-control information. A number of licenses, including the GPLs, require those who make changes to licensed software to note that changes have been made when distributing their changes to others. A few also require distribution of changed versions in the form of the original or "official" distribution plus patch files. Have a look at the Artistic Licenses from the Perl community. And note that "permissive" (non-copyleft) licenses don't require sharing source at all. Nonetheless, some licenses assume that development-related information will be available, required or not, for the purpose of other license provisions. For example, Apache 2.0 determines which patents get licensed based on who is contributing code that implicates a patent, alone or in combination with the state of the project prior to their offer of a new contribution Even with comprehensive revision-control and licensing information, it's not always practical to determine whether a patent is covered. The Apache Foundation systematically compiles and archives contribution-related information, by institutional policy. Other users of Apache's license, like startups, don't necessarily follow suit. Ditto with other licenses following Apache's approach to patent scope, which is now quite common in "enterprise"-oriented license terms. Even my own, very strong copyleft Parity license (https://paritylicense.com https://paritylicense.com), which comes the closest to requiring "development in the open" of any terms I've seen, does not require unbroken development history or distribution of history data in any particular form, like a Git repository or an unbroken chain of patch files. My first thought is that requiring open work process would be difficult, especially without tying the requirement to specific tools or platforms---GitHub, Git---that will surely face obsolescence in time. But my second thought is that licenses have already adequately solved an analogous problem with success. A license could require that source code changes be made available not only in the preferred form for making further changes, but also in the preferred form for analysis of prior changes already made, for code copyright provenance verification, regression testing, incorporation into the "official version", development metrics calculation, or the like. I'm not sure I see a concrete use case requiring those kinds of terms. Nice to have, sure. But in what circumstance essential?
tleb_ 6y ago
Assuming a GPLv3-licensed project, would one be in his rights to ask for a previous "Corresponding Source" because he uses a previously released "object code"?
- tsimionescu 6y ago
  At least in the company I work for, the understanding is that we have to make available the source code that corresponds to0 the binaries that we are distributing. So, if I am distributing Linux 2.0.12, I have to also make the source code of Linux 2.0.12 available to my customers. The sources for Linux 5 (or Linux 2.0.13) are not useful.
purpleidea 6y ago
Assuming it's still the case, Red Hat used to release all their RHEL-kernel specific changes as individual patches, but apparently it made this too easy for Oracle to copy and cherry-pick in the ones they wanted, so the Red Hat released source code became a big giant squished patch. They felt it still complied with GPLv2, and TBH, I don't think that it doesn't. Not necessarily in the spirit of the license, but a necessary solution against Oracle in their minds. GPLv3 defines it differently, but I doubt you could convince anyone of this in court. I think getting the source in any form would be a good enough start for most of the companies flaunting the GPL.

33 points by edent 6y ago

I mean, each time you distribute the software you are bound to the license terms for that version, so if you use the same license through time, you have to give that much history. Beyond that, it clearly becomes very murky, especially when it comes to git. Is squashing some commits suddenly against the license? Do I have to commit every time I type a character? There is no obvious smallest unit except "the commit the developer decides on", which could then be everything since the last release, resulting in the status quo. I guess there could be a license where if you changed to that license, it required the history, but it would seem a bit pointless, as inherently at that point the person choosing the license could just choose a different one.

akkartik 6y ago
Do similar questions come up even for the current snapshot? Are you required to provide comments? Meaningful type and variable names?
- eredengrin 6y ago
  Not a lawyer, but I did work for a short period for a company that was distributing a modified linux kernel and therefore had to release the source. In my time there, there were a lot of discussions (some involving lawyers) about whether (and how) we could reasonably obfuscate the source before releasing it. Not sure how those conversations ended since I left before they were done, but it seems it's not clear cut at this point.
  - akkartik 6y ago
    dataflow's comment (https://news.ycombinator.com/item?id=24019778#24025779 https://news.ycombinator.com/item?id=24019778#24025779) seems to answer this, and https://opensource.stackexchange.com/questions/5759/code-obfuscation-and-gpl3/5760#5760 https://opensource.stackexchange.com/questions/5759/code-obf... elaborates: FOSS licenses require distributing the form you use to make modifications to your program. To do anything else opens one up to legal liability.
  - jlokier 6y ago
    I struggle to imagine how this definition in the Linux kernel's license: > The source code for a work means the preferred form of the work for making modifications to it. can be seen as "not clear cut" with regard to whether obfuscated source code counts. It plainly rules out obfuscation. (Unless you genuinely prefer editing the obfuscated version. Which you provably don't if obfuscation is done just for release.)
    - eredengrin 6y ago
      What is preventing a company from hiring a developer or two for very cheap to "work" on the obfuscated code, but not do any real work (or better yet, just bundle it into an existing job description of a qa member or a dev on some other team or something)? How would you prove in court that the devs "working" on the obfuscated version weren't the ones doing the work? It brings into question which version is actually preferred over the other, and how do you answer that? Based off number of commits or changes on the branches? Obfuscated version could easily be gamed to have more commits, and given that it's obfuscated, it might have even more individual changes just by default. I imagine there are some companies that think these questions are worth pondering.
- numpad0 6y ago
  I believe the gist of GPL is you supply the source code that produced the binary object through your compilation processes to whoever received the binary as you were licensed it as part of the sale or distribution. You are not obliged to supply any intermediate files, media assets, manuals, or technical supports as part of the licensing, though you are not restricted from doing so(you absolutely can charge full prices for GPL’d software) Building from source but cleansing it before release or supplying irrelevant intermediate files, even de-complied files as sources... to “protect valuable assets”, those had been tried and are generally considered license/copyright violations.

smcphile 6y ago

> My question to you, gentle reader – are there any licences which compel the distribution or publication of the development history? No, other than that any given project has to give proper credit to code used from other projects / copyright holders. My understanding of why this is so is the following: A free software or open source software licence is based on copyright law. As such, it restricts what users can do with the source code, but it never restricts what the copyright holders can do with the software (assuming all the copyright holders collectively agree). A user can never (theoretically at least, there may be a few edge cases) sue the copyright holders for anything, because there’s no warranty. No warranty on the code source history (or anything else). So code source history is always optional.

coolness 6y ago
This is exactly what most people in this thread are missing. The copyright holder, i.e the creator of the code is never obligated to do anything by the licence he chooses to release with. The licence applied to users of the copyright owners work.
- throwaway936482 6y ago
  That's not true though. Open source licenses (as defined by the OSI) impose specific obligations upon me as creator - to distribute the source code for "no more than a reasonable reproduction cost" to users, allow users to modify it, and to redistribute it for free if it is bundled with other software, and not to discriminate against persons, groups or fields of endeavour in who can use it.
  - smcphile 6y ago
    No, open source licenses impose no obligations on the copyright holder for their own code. For example, if the copyright holder releases their own code under a GPL licence, no law prevents them from also releasing a modified or unmodified version under a proprietary licence. This is allowed by law, but the proprietary version doesn’t of course negate the rights already given to those who received the GPL version. If a project has many contributors (copyright holders), they would all have to agree to a license change, so in practice something like the Linux kernel is very unlikely to ever change to a proprietary licence, but it’s theoretically possible. The copyright holders are never bound by the terms of a user licence.

angel_j 6y ago

The MIT license is so simple, just add/delete to make your own. My bespoke license is free and open source for the user, but restricts them using it for or on behalf of another person.

josephcsible 6y ago
That sounds like it's not open source. Also, license proliferation is a bad thing and you really shouldn't encourage it.
- angel_j 6y ago
  Open source means you can read the source. The idea that all my work must be FOSS is somebody else's ideal, and one that has kept a lot of people I know from getting paid. Meanwhile, plenty of code, probably most running your world, is purely in the dark and definitely not open source. Whatever you think about "license proliferation", that's like, your opinion. What world are you from that I can't have my own license for my own work? What kind of lemmings notion is it that I should only use a well known, open source license, especially a license that explicitly gives my work away uncompensated to random people on the internet? You are so brainwashed with slogan terminology that you think Open Source has exactly one meaning, and that meaning is not even that the source code is open? Jesus, this forum is retarding sometimes. FOH with yr downvotes. Edit, furthermore, I have dozens of totally FOSS code projects out there, downloaded millions of time per month. Is your business 100% open source, down to how to track your users? Stop telling people what they should do out here.
  - angel_j 6y ago
    This needs more downvotes.
  - josephcsible 6y ago
    > Open source means you can read the source. No, that's "visible source" or "source available". Read the Open Source Definition: https://opensource.org/osd https://opensource.org/osd It even addresses your misconception right up front: "Open source doesn't just mean access to the source code." > The idea that all my work must be FOSS is somebody else's ideal, and one that has kept a lot of people I know from getting paid. You can get paid even if everything you build is FOSS. Look at Red Hat. > Whatever you think about "license proliferation", that's like, your opinion. What world are you from that I can't have my own license for my own work? What kind of lemmings notion is it that I should only use a well known, open source license, especially a license that explicitly gives my work away uncompensated to random people on the internet? Even if your bespoke license were open source, there's a very good chance that it would be incompatible with other licenses like the GPL, thus creating more ZFS-on-Linux sort of problems.

deleted 6y ago

[deleted]

powersnail 6y ago

My basic understanding is that license (usually?) applies to just the code. There is no concept of "history" or "snapshot" pertaining to the code itself. Such constructs only exist with regard to the process of development, about which the code license does not care. Otherwise, every keystroke must be recorded and published to ensure compliance, at which point, the license is ridiculous and unenforceable.

mehrdadn 6y ago

Layman here, but this seems pretty easy to answer for GPL at least because it defines [1] what "source code" means (with a rather brilliant definition, I might add): > The "source code" for a work means the preferred form of the work for making modifications to it. I expect it would be tough to argue that the preferred form of a work to modify is its history rather than its present form. [1] https://www.gnu.org/licenses/gpl-3.0.txt https://www.gnu.org/licenses/gpl-3.0.txt

markrages 6y ago
When I modify a program, I often refer to its history. So my preferred form would be something like a git repository, rather than just a tarball.
- mehrdadn 6y ago
  It's the form you would prefer to modify, not the information you would prefer to have available. I'd prefer to have all the information in the world available, but that doesn't make everything the source code.
gizmo686 6y ago
My preferred form of a work would be the a VCS repository with the complete history (assuming it is a familiar VCS like git. If you are using some obscure VCS that I can't get to work, I'd settle for a simple source dump). Almost every project I have worked on has went out of its way to maintain a good history. Wheather it is by cleaning up commits before merging into a main branch; making sure history gets copied when a reorganization moves a significant amount of files to a different repository, or making sure history gets copied when an entire repository moves over to a new VCS.
- mehrdadn 6y ago
  The quote was that the source code is the form of the program you would prefer to modify, not the information you would prefer to have available. These are different things.
- 6y ago

not2b 6y ago

What would the definition of "source history" be? The git database? If I do a rebase would I be violating the license? After all, I am collapsing the history, getting rid of failed ideas no one else needs to see.

gramakri 6y ago

AFAIK, postfix has no history. Only releases.

cookiengineer 6y ago
> AFAIK, postfix has no history. Only releases. This is correct. It is also hosted on an original BSD (the b as in berkeley) 0.1 with the RCE affected ftpd 0.1 that had issues with too long usernames and passwords. Oh, it's also hosted via http and ftp only, in case anyone is wondering about security aspects of it. I'm talking about the porcupine server, as it is how the source gets distributed... I mean, gpg signing is fine and all, but if transport can be MITM'ed there's no way to verify the gpg signatures. Contacted the author like hundreds of times, offered to help, but not a single eff was given apparently.
- yjftsjthsd-h 6y ago
  Is https://github.com/vdukhovni/postfix/commits/master https://github.com/vdukhovni/postfix/commits/master not official?
  - cookiengineer 6y ago
    Nope, ftp.porcupine.org is the only distribution source, from there it gets pushed to mirrors, from there people maintain the history manually. Postfix is really a nightmare project from both the missing collaboration aspects and missing security aspects.
yjftsjthsd-h 6y ago
Maybe? https://github.com/vdukhovni/postfix/commits/master https://github.com/vdukhovni/postfix/commits/master I wouldn't call them releases, but they aren't normal commits...
- deleted 6y ago
  [deleted]
- 6y ago

sverhagen 6y ago

Isn't the requirement to disclose source with a system so that you can make changes (bug fixes and such) without being locked into a vendor? Current source offers that. Other than that licenses typically stipulate that there are no warranties and no support. I see source history more as a support tool (to understand design decisions) than as the "absolute" ability to fix a bug. (This is not and answer to the question, I realize.)

ximm 6y ago

This reminds me of a post by Steve Klabnik: https://steveklabnik.com/writing/what-comes-after-open-source https://steveklabnik.com/writing/what-comes-after-open-sourc... In that he argues that open source is less about publishing the code and more about a culture of developing in the open, with a public source repository and public issue tracker.

walterbell 6y ago

With the advent of reproducible builds, it can also be useful to have a specification of the build environment needed to reproduce a binary from a given source code snapshot.

deleted 6y ago

[deleted]

kemitchell 6y ago

I am not aware of any common "open source" license that requires distribution of comprehensive source code revision history or version-control information. A number of licenses, including the GPLs, require those who make changes to licensed software to note that changes have been made when distributing their changes to others. A few also require distribution of changed versions in the form of the original or "official" distribution plus patch files. Have a look at the Artistic Licenses from the Perl community. And note that "permissive" (non-copyleft) licenses don't require sharing source at all. Nonetheless, some licenses assume that development-related information will be available, required or not, for the purpose of other license provisions. For example, Apache 2.0 determines which patents get licensed based on who is contributing code that implicates a patent, alone or in combination with the state of the project prior to their offer of a new contribution Even with comprehensive revision-control and licensing information, it's not always practical to determine whether a patent is covered. The Apache Foundation systematically compiles and archives contribution-related information, by institutional policy. Other users of Apache's license, like startups, don't necessarily follow suit. Ditto with other licenses following Apache's approach to patent scope, which is now quite common in "enterprise"-oriented license terms. Even my own, very strong copyleft Parity license (https://paritylicense.com https://paritylicense.com), which comes the closest to requiring "development in the open" of any terms I've seen, does not require unbroken development history or distribution of history data in any particular form, like a Git repository or an unbroken chain of patch files. My first thought is that requiring open work process would be difficult, especially without tying the requirement to specific tools or platforms---GitHub, Git---that will surely face obsolescence in time. But my second thought is that licenses have already adequately solved an analogous problem with success. A license could require that source code changes be made available not only in the preferred form for making further changes, but also in the preferred form for analysis of prior changes already made, for code copyright provenance verification, regression testing, incorporation into the "official version", development metrics calculation, or the like. I'm not sure I see a concrete use case requiring those kinds of terms. Nice to have, sure. But in what circumstance essential?

tleb_ 6y ago

Assuming a GPLv3-licensed project, would one be in his rights to ask for a previous "Corresponding Source" because he uses a previously released "object code"?

tsimionescu 6y ago
At least in the company I work for, the understanding is that we have to make available the source code that corresponds to0 the binaries that we are distributing. So, if I am distributing Linux 2.0.12, I have to also make the source code of Linux 2.0.12 available to my customers. The sources for Linux 5 (or Linux 2.0.13) are not useful.

purpleidea 6y ago

Assuming it's still the case, Red Hat used to release all their RHEL-kernel specific changes as individual patches, but apparently it made this too easy for Oracle to copy and cherry-pick in the ones they wanted, so the Red Hat released source code became a big giant squished patch. They felt it still complied with GPLv2, and TBH, I don't think that it doesn't. Not necessarily in the spirit of the license, but a necessary solution against Oracle in their minds. GPLv3 defines it differently, but I doubt you could convince anyone of this in court. I think getting the source in any form would be a good enough start for most of the companies flaunting the GPL.