GPL v2 §2a and git

[TJ]

2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section
a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

I was recently trying to track down the 'blame' history of some code that eventually entered the Linux mainline and was stymied by a lack of traceability.

That got me to thinking about §2a requirements and git history, and in particular that almost all changes to kernel code nowadays carry no change history of their own. The history is contained in
the git repository but anyone receiving a tar-ball does not receive that history.

Also, non-mainline tar-ball distributions typically from device manufacturers typically do not carry any history either.

Comments?

[Arnt Karlsen]

On Sat, 10 Aug 2013 14:33:57 +0100, TJ wrote in message

Post by TJ

2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.

I was recently trying to track down the 'blame' history of some code
that eventually entered the Linux mainline and was stymied by a lack
of traceability.
That got me to thinking about §2a requirements and git history, and
in particular that almost all changes to kernel code nowadays carry
no change history of their own. The history is contained in the git
repository but anyone receiving a tar-ball does not receive that
history.
Also, non-mainline tar-ball distributions typically from device
manufacturers typically do not carry any history either.
Comments?

..file a bug report so Linus and the guys can fix the traceability
bug you may have found.

..traceability became much important 10 years ago when Microsoft
funded shills like Caldera/The SCO Group launched lawsuits on IBM,
Autozone, Chrysler, Novell alleging "stolen Unix code in Linux"
but refused to identify it, as Linus and the guys wanted to yank
out any stolen code bits and rewrite whatever needed rewriting,
which is the honorable one of 2 legally correct ways to fix
copyright infringement. http://groklaw.net/ for details.

[Bradley M. Kuhn]

Post by TJ
Also, non-mainline tar-ball distributions typically from device
manufacturers typically do not carry any history either.

I agree with you that there are a lot of GPLv2§2(a) GPL violations on
Linux out there. But, they are so much less problematic than the
rampant GPLv2§3 violations, it seems sill to pursue these as a priority.

Post by TJ
The history is contained in the git repository but anyone receiving a
tar-ball does not receive that history.

Note that unlike source code, where GPL requires "preferred form of the
work for making modifications to it", there is no "preferred form"
language regarding GPLv2§2(a). Thus, it'd be difficult to argue
non-compliance if the entity doing redistribution just list of changes
and dates in a text file.

I wrote a blog post on the issue a while back, when Red Hat changed the
way it handled its GPLv2§2(a) compliance on Linux:
http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

[Richard Fontana]

Post by Bradley M. Kuhn
I wrote a blog post on the issue a while back, when Red Hat changed the
http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

This was not a change in the way Red Hat was handling GPLv2§2(a)
compliance on Linux, because Red Hat never had the view that
distributing separated-out patches was a form of GPL compliance in the
first place. To put it another way, compliance with GPLv2§2(a) was
unchanged by this change in packaging practice.

- RF

[Bradley M. Kuhn]

Post by Richard Fontana

Post by Bradley M. Kuhn
I wrote a blog post on the issue a while back, when Red Hat changed the
http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

This was not a change in the way Red Hat was handling GPLv2§2(a)
compliance on Linux, because Red Hat never had the view that
distributing separated-out patches was a form of GPL compliance in the
first place. To put it another way, compliance with GPLv2§2(a) was
unchanged by this change in packaging practice.

Good point, Fontana, and you're (sort of) saying what I said in my blog
post (linked above). Namely, that GPLv2§2(a) never required Red Hat to
publish a full Git repository of its Linux changes, but that publishing
such a git repository is a good contribution to the community. Indeed,
IMO, GPLv2§2(a) exists to help downstream use a diachronic approach to
understand the software and how it works: that's the spirit of
GPLv2§2(a).

Ultimately, in early 2011, Red Hat instituted a policy to follow only
the letter of the GPLv2§2(a) rather than its spirit. Granted, Red Hat
was one of the few for-profit Linux redistributors that *ever* followed
the spirit of GPLv2§2(a), so I'm not being particular critical of Red
Hat here. I'm sad Red Hat back-slid on this issue, but OTOH, even with
this change in policy, Red Hat is still "better" on GPLv2§2(a) than most
redistributors.