History and licensing isn't really a red-herring
History and licensing isn't really a red-herring
Posted Jun 21, 2015 12:36 UTC (Sun) by paulj (subscriber, #341)In reply to: History and licensing isn't really a red-herring by angdraug
Parent article: The costs of forks
The code concerned does seem to be under the Apache licence. The Apache Licence does have "preferred form of modification" type language in its definition of "Source" and does seem to consider that if works are distributed that this can only be in either "Source" or "Object" form. Whether that means it is /required/ that distributions of modifiable code meet the "Source" definition, I don't know.
However, what is important here is that Borodaenko's claim that:
"Besides, there's a historic precedent that stripping commit history is
acceptable even with GPL: https://lwn.net/Articles/432012/"
is refuted.
It is *not* the case that because of RedHat and their deliberate collapsing of patches in their Linux kernel SRPM that therefore deliberate stripping of commit history is generally acceptable under the GPL. The RedHat case was quite specific to the preparation of Linux kernel RPMs from a set of patches (kept in a git repo, but that's almost incidental) to a base kernel version and publishing SRPMs that didn't (don't?) reflect that. That no one of consequence objected doesn't really generalise out to the GPL for all projects, in all situations.
(Note: Objecting to what RedHat did does not mean you think Linux, or any GPL project, can only be distributed as a git repo with full history either).
Posted Jun 22, 2015 3:57 UTC (Mon)
by angdraug (subscriber, #7487)
[Link] (7 responses)
It seems to me that the way this discussion is going fits the proverbial textbook definition of red herring: a seemingly plausible, though ultimately irrelevant, diversionary tactic. What's the point of reintroducing the question of licensing into the discussion of collaboration between two free software projects? Which part of the outcome described in the article do you find unsatisfactory? "seems to suggest that he'd prefer" is nowhere near "explicitly declare a git repository as the preferred form". Which we do, in a way that not only establishes code provenance, but also allows to create a branch in upstream git from Fuel specific changes. Try to declare that level of history preservation not legally satisfactory and you end up with a license that forbids all kinds of useful behaviours such as converting to a different SCM. If you want to refute it, you have to do better than simply declare it refuted, give a proof that isn't full of fallacies: Strawman. The claim is that there is a precedent, not that it's generally acceptable. Precedent proves that you can't summarily declare all cases of stripping commit history unacceptable, which is not the same as declaring that all cases of stripping commit history are acceptable. I think you're mislead by use of "is acceptable" in the claim in question, a more logically precise form would have been "can be acceptable". (Which does not invalidate its relevance for the case of Fuel.) Special pleading. You failed to demonstrate how the specifics of the Red Hat kernel SRPMs case are relevant to the compatibility of stripping commit history with GPL. Appeal to authority combined with cum hoc ergo propter hoc, followed by the same precedent vs generalization strawman. "That no one of consequence objected" makes a false implication that if they did, it wouldn't have been found legally acceptable anyway. Can we just agree that the claim about the Red Hat precedent is instrumental to removing the license compliance question out of the scope of Fuel and Puppet OpenStack discussion, but that it shouldn't be taken as generalization of this precedent to all GPL projects?
Posted Jun 22, 2015 10:45 UTC (Mon)
by paulj (subscriber, #341)
[Link] (5 responses)
"Besides, there's a historic precedent that stripping commit history *is acceptable*" (emphasis mine).
You're attacking my comment with all kinds of claims about logical fallacies, except your attribution of logical fallacies is predicated on your claim that I should have read Borodaenko's comment in a different way:
“ I think you're mislead by use of "is acceptable" in the claim in question, a more logically precise form would have been "can be acceptable"”
Basically, you're making the bizarre argument that my claim about the generality of Borodaenko's comment is incorrect because I should have interpreted in some way *other* than what the words he wrote indicated. If you're going to start attacking people with nit-picking deconstructions of the logical consistency of their arguments, then you should perhaps not base your claims of inconsistencies on your own modifications to the facts being argued.
As for refuting the claim: Noting that the RedHat case related to downstream preparation of SRPMs from an upstream tarball + patches, stored somewhere (in a git repo - but that actually was *NOT* of any relevance - it was *not* the git or CVS history that they stopped providing), and that that case is very different from the normal case of software development repositories of upstreams, should be enough to make any reasonable person realise you can't automatically generalise the RedHat case to the other. When two situations are quite different from each other, simply highlighting that fact is sufficient to refute any trivial attempt to generalise from one to the other that doesn't account for the differences.
As for your last paragraph, yes, I have no opinion about the licensing history question wrt Fuel and OpenStack Puppet. However, the RedHat SRPM thing has little to do with it, I'd agree, and nor does the RedHat SRPM thing generalise to other GPL projects, I'd agree.
Posted Jun 22, 2015 16:01 UTC (Mon)
by angdraug (subscriber, #7487)
[Link] (4 responses)
I hope you agree that it looks less bizarre after you realize that I am Dmitry Borodaenko (as I have indicated in my first comment here), and I know that I didn't mean to generalize this precedent, and I have already conceded that the choice of words I used was imprecise. No, git history is something they weren't publishing in the first place, but having that modification history reflected in patches in SRPM was good enough for practical purposes. Removing patches from SRPM removed the last public instance of that modification history, which is why it was functionally the same as taking away SCM history.
Posted Jun 23, 2015 14:01 UTC (Tue)
by paulj (subscriber, #341)
[Link] (3 responses)
You posted before me, but said only "Disclaimer: I'm one of the Fuel developers mentioned in the article.", neither that nor your nick are likely to make it immediately obvious to others that you are Dmitry Borodaenko. And I wasn't replying to that comment of yours, so I probably didn't even read it fully. In another comment on another thread you did say "The answer is in one of my emails" which was linked to an email with your name - but that was the day *after* I posted to this thread. Further, I read only the comments made in reply to me, in this thread, of which I was notified - not the others.
So yes, my comment was bizarre, as I should have been able to make the non-obvious connection between your nick and your real name, or read your comments from the future. :) I responded to text linked to directly in the article, bizarrely ignoring clarifications to that text from its author in comments made to me in the future. :)
The RedHat SRPM issue is that the "source" of that SRPM is a base upstream kernel + a set of patches to it. That is what the RedHat kernel RPM maintainers work on. However, the SRPM they release to satisfy the GPL source requirements on the SRPM go through a process that deliberately collapses the patches and folds them together (or folds them into the tarball - I don't remember). The SRPM released does not reflect the source input files that the RedHat people work on and, clearly, prefer to maintain (useful enough that RedHat considers it a commercial advantage).
Where those patches are stored, whether it's an SCM or just a folder in dumb directory, is a by the by and not really relevant. This isn't about SCM history. You could copy those files away from the SCM and run the same process (after the SCM checkout anyway), and get the same result: The SRPM does not contain the inputs in their preferred format (certainly not RedHats' preferred format).
The SCM has nothing to do with it, other than RedHats' SRPM build process happens to have "do a checkout from an SCM" at an early, irrelevant stage (AIUI).
Posted Jun 23, 2015 18:03 UTC (Tue)
by angdraug (subscriber, #7487)
[Link] (2 responses)
You've completely misread my previous comment. You said "you're making the bizarre argument", to which I responded "it looks less bizarre", by "it" referring to the same argument you were referring to. So I did not call your comment bizarre, you did that to mine. By saying that now that I confirmed my identity it should look less bizarre I implicitly confirmed that I agree that it can look bizarre if you don't know who I am. I hope this helps close this bizarre meta-conversation ;-) What's important here, and what makes this story relevant to the topic, is the history of modifications. It doesn't matter how this history is represented, what matters is whether that history is publicly available or not.
Posted Jun 23, 2015 22:15 UTC (Tue)
by paulj (subscriber, #341)
[Link] (1 responses)
On history thing. It's an interesting question. Normally, it is pretty obvious what the norms and preferred modifications are: what a project distributes or puts together in "releases" is the practice others should follow. So if a project's releases are tarballs, then a tarball of the source of others making releases of that project's code in a similar vein should be enough.
Things possibly get fuzzier though as you move away from the original project.
So if someone adds a whole layer more of meta-data and associated tooling around the original's release file, allowing the original upstream's release file to be combined with yet other's people patch-files and built and packaged: Is it sufficient to release just the tarball with those patches collapsed in? (The RedHat case).
Lots of interesting questions here. I suspect norms are in flux somewhat now. With older SCMs you did not distribute the SCM with the code. With git, however, you do. Things could develop somewhat. Certainly, since git has added an "Author" field to commit messages, distinct from the commiter, some take that field very very seriously.
Posted Jun 23, 2015 22:50 UTC (Tue)
by angdraug (subscriber, #7487)
[Link]
Interestingly enough, I tried to raise similar questions as far back as 12 years ago, when git didn't yet exist and distributed SCMs were a subject of research, not a standard part of software engineering process:
Now that git is something every software engineer is expected to be fluent with, and distributing source in the form of a cloneable git repository is trivial, some of the challenges that came up in the conclusion of that discussion might have disappeared :)
Posted Jun 22, 2015 10:56 UTC (Mon)
by paulj (subscriber, #341)
[Link]
"Try to declare that level of history preservation not legally satisfactory and you end up with a license that forbids all kinds of useful behaviours such as converting to a different SCM."
Agreed. Making the SCM history be part of the "source" would probably make life difficult in many common cases. The place for any legally significant attribution, history, etc., should be in the non-SCM source itself.
That said, it is *possible* that the community could one day consider the full SCM data to be the source wrt "preferred form of modification" for the purposes of the GPL. Whether the community around a specific project could set that expectation, or whether it'd need to be set by wider community and/or industry practices, I don't know.
Advisable as things stand? Probably not, as you say. Possible, yes.
(Again, to be 100% clear, the RedHat case was *NOT* about SCM history!)
History and licensing isn't really a red-herring
Fuel people did their work in a way that preserved the history in the SCM
what is important here is that Borodaenko's claim (...) is refuted.
deliberate stripping of commit history is generally acceptable under the GPL
The RedHat case was quite specific to the preparation of Linux kernel RPMs
That no one of consequence objected doesn't really generalise out to the GPL for all projects, in all situations.
History and licensing isn't really a red-herring
History and licensing isn't really a red-herring
Basically, you're making the bizarre argument that my claim about the generality of Borodaenko's comment is incorrect because I should have interpreted in some way *other* than what the words he wrote indicated.
Noting that the RedHat case related to downstream preparation of SRPMs from an upstream tarball + patches, stored somewhere (in a git repo - but that actually was *NOT* of any relevance - it was *not* the git or CVS history that they stopped providing)
History and licensing isn't really a red-herring
History and licensing isn't really a red-herring
So yes, my comment was bizarre
The SCM has nothing to do with it
History and licensing isn't really a red-herring
History and licensing isn't really a red-herring
Define information source as a full history of published modifications
to the licensed piece of information in preferred form for making
modifications.
Distribution of modified versions of the piece should require that such
source is preserved by respective authors of individual modifications,
and its availability is guaranteed by (a) providing a valid reference to
how the source can be obtained for a charge no more than the cost of
physically performing source distribution, (b) updating the reference on
request in case it becomes invalid, and (c) providing the source on
request in case no other valid reference can be provided.
History and licensing isn't really a red-herring