Introducing RedPatch (Ksplice Blog)
The Ksplice team is happy to announce the public availability of one of our git repositories, RedPatch. RedPatch contains the source for all of the changes Red Hat makes to their kernel, one commit per fix and we've published it on oss.oracle.com/git. With RedPatch, you can access the broken-out patches using git, browse them online via gitweb, and freely redistribute the source under the terms of the GPL." (Thanks to Dmitrijs Ledkovs.)
Posted Nov 10, 2012 3:39 UTC (Sat)
by geofft (subscriber, #59789)
[Link] (4 responses)
I have approximately zero sympathy for Oracle, but ... you have to wonder if Red Hat thought this trick would actually work against Oracle.
Posted Nov 10, 2012 5:05 UTC (Sat)
by devferret (guest, #77830)
[Link] (3 responses)
I mean, there's spin, and then there's propaganda, and then you sort of fall off the end of the scale and the tummy trouble starts...
Posted Nov 16, 2012 8:28 UTC (Fri)
by jrn (subscriber, #64214)
[Link] (2 responses)
What is misleading about it? I might be naïve, but to me it *does* seem useful to be able to conveniently look up what changes went into the kernel a large number of users are testing. It also means there is a git repository I can point to and ask people to bisect in. And if I end up needing to develop against RHEL for some reason, "git blame" will finally work.
Posted Nov 16, 2012 14:53 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (1 responses)
At the very least, it's misleading propaganda because Oracle is doing to MySQL this very same thing which RedHat does to the kernel. So Oracle being self-righteous about it won't wash.
RH does it to annoy Oracle, and Oracle does it to annoy MariaDB.
Posted Nov 19, 2012 3:40 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
Posted Nov 10, 2012 3:46 UTC (Sat)
by jcorgan (subscriber, #47213)
[Link] (8 responses)
Posted Nov 10, 2012 4:34 UTC (Sat)
by brouhaha (subscriber, #1698)
[Link] (7 responses)
Posted Nov 11, 2012 0:29 UTC (Sun)
by misc (subscriber, #73730)
[Link] (6 responses)
Posted Nov 12, 2012 9:07 UTC (Mon)
by lkundrak (subscriber, #43452)
[Link]
Posted Nov 19, 2012 15:22 UTC (Mon)
by leromarinvit (subscriber, #56850)
[Link] (4 responses)
Posted Nov 19, 2012 15:42 UTC (Mon)
by nix (subscriber, #2304)
[Link] (3 responses)
Posted Nov 19, 2012 15:46 UTC (Mon)
by leromarinvit (subscriber, #56850)
[Link] (2 responses)
Posted Nov 19, 2012 16:11 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Nov 19, 2012 16:12 UTC (Mon)
by mpr22 (subscriber, #60784)
[Link]
Posted Nov 10, 2012 7:15 UTC (Sat)
by rodgerd (guest, #58896)
[Link] (2 responses)
Posted Nov 10, 2012 13:50 UTC (Sat)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
Posted Nov 11, 2012 20:49 UTC (Sun)
by mcgrof (subscriber, #25917)
[Link]
https://github.com/jirislaby/ksplice
Will others *cough R* use this as well or will they fork out... again?
Posted Nov 10, 2012 8:45 UTC (Sat)
by danpb (subscriber, #4831)
[Link] (3 responses)
https://oss.oracle.com/git/?p=redpatch.git;a=commit;h=64f...
Once that's complete, they just create a giant commit lumping together all the remaining pieces they can't match up against upstream.eg "The rest of RHEL 2.6.32-279.5.2.el6 to 2.6.32-279.9.1.el6"
https://oss.oracle.com/git/?p=redpatch.git;a=commit;h=278...
wouldn't be at all surprised if this is just done using a simple automated script.
Posted Nov 11, 2012 0:41 UTC (Sun)
by misc (subscriber, #73730)
[Link] (2 responses)
Posted Nov 10, 2012 8:46 UTC (Sat)
by lkundrak (subscriber, #43452)
[Link] (19 responses)
What Oracle does now is not the above. Their repository obviously contains hand-crafted commits of stuff they could not match with anything in public git repositories and could not break out by hand (e.g. https://oss.oracle.com/git/?p=redpatch.git;a=commitdiff;h...).
Also, did someone else notice that Red Hat started to obfuscate RHS glusterfs packages in this way? I could not even find it in the patch browser, but it might be that it does not list it because I don't have a RHS subscription (could someone confirm this?).
Posted Nov 10, 2012 9:44 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (18 responses)
Otherwise, RedHat could sue Oracle for breach of copyright. Which (as we all know) carries very stiff penalties.
Posted Nov 10, 2012 9:52 UTC (Sat)
by lkundrak (subscriber, #43452)
[Link] (17 responses)
So, is it that a development history in between two GPL-licensed trees is not licensed by GPL? Or is the patch file not considered a derived work of the tree itself? Or am I completely missing the point?
I could not find conditions for use or redistribution of the patch files on Red Hat web site.
Posted Nov 10, 2012 10:02 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (16 responses)
Oracle can redistribute the information about individual patches in RHEL, however they obtain it (by subscribing to RHEL, for example). But they can do it exactly once.
Because publishing the patches terminates the contract between RHEL and Oracle. And without a contract it's illegal to access the RHEL systems that carry patch information.
Posted Nov 10, 2012 10:34 UTC (Sat)
by boklm (guest, #34568)
[Link] (2 responses)
Posted Nov 10, 2012 13:51 UTC (Sat)
by khim (subscriber, #9252)
[Link]
Posted Nov 10, 2012 14:14 UTC (Sat)
by bahomet (guest, #87773)
[Link]
However, what Oracle aims at and RH tries to prevent is:
... for which Oracle would need an authentic public distribution of that
RedPatch is a clever trick though -- while Oracle cannot publicly use the original knowledge base, it's certainly possible for them to reverse engineer it from public sources and arrive at a freely usable by-and-large equivalent of the original.
Posted Nov 10, 2012 13:26 UTC (Sat)
by cyanit (guest, #86671)
[Link] (1 responses)
Surely Oracle can afford to either incorporate a new company or pay a new individual every time RedHat updates their kernel, subscribe to RHEL with it, release the patches, and then terminate the contract.
Also, couldn't that contract term be construed as an additional restriction on the patches, and thus a violation of the GPL by RedHat?
Posted Nov 10, 2012 13:49 UTC (Sat)
by khim (subscriber, #9252)
[Link]
This only works in countries where it's easy to bribe court to look the other way. In any sane country after few repeats all the lawsuits will be connected together and there will be looong investigation which will try to see if Oracle instigated these repeated violations in some way. Think recent Apple in UK fiasco. Apple was pretty sure that since they found clever way to issues non-apology without violating a letter of law they were in the clear. Court was not amused.
Posted Nov 14, 2012 2:02 UTC (Wed)
by Lennie (subscriber, #49641)
[Link] (10 responses)
So how do they do that ?
Posted Nov 14, 2012 2:51 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
Oracle would be totally free to redistribute patches they receive from RHEL subscription. However, nothing in the GPL forces RH to continue providing Oracle with further patches - that's not a question of copyright.
FSF had decided that it's legal quite a time ago.
Posted Nov 14, 2012 20:58 UTC (Wed)
by paulj (subscriber, #341)
[Link] (8 responses)
Regarding the patches: Either the GPL applies to these patches, in which case RedHat must supply them to any 3rd party, and the RHEL contract makes no odds. Alternatively, the patches are not supplied because of GPL obligations, in which case this discussion above about the GPL and contract re the patches has been moot.
You can't get around the GPL "binary-distribution: supply preferred source to any 3rd party condition" via support contracts, just to be clear.
Posted Nov 15, 2012 5:22 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
GPL does NOT force you to distribute it in the first place. For example, I might have some personal code under the GPL. I can give it to you and say: "If you distribute this code to someone else, I won't give you any more of my code". That's totally legal under the GPL and it's what RedHat is doing.
Posted Nov 15, 2012 6:31 UTC (Thu)
by raven667 (subscriber, #5198)
[Link]
IIts kind of silly as well because in most cases the individual change sets are also submitted and integrated into the mainline kernel. I don't know how many changes are only made in customer facing redhat kernels that aren't upstream, if any. Its probably hard to tell automatically because the same bug fix or feature might be coded slightly differently between different kernel versions
Posted Nov 15, 2012 8:52 UTC (Thu)
by paulj (subscriber, #341)
[Link] (4 responses)
Distributing under the GPL *does* force you to distribute the source, if you distribute the work at all. Further, if at any point you distribute in binary-only form, then you are obliged to provide source to *any* 3rd party, for a specified period. This obligation, once incurred, can not be terminated.
Anyway, the point I wanted to make was more about the patches, and whether RedHat making split-out kernel patches available had anything to do with honouring their GPL commitments. If it does, then RedHat should be providing those split-out patches to *any 3rd party*, and if they do not do this then they are in breach of the GPL.
Posted Nov 15, 2012 8:58 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Can you please read this article again?
RedHat distributes source code of all patches. Under the GPL. You can get a RHEL subscription and you'll get access to them. Under the GPL.
You can then take these patches and re-distribute them. That's not a problem at all, you're totally free to do it. Under the GPL.
However, RedHat will revoke your access to the RHEL repository should you do this. I.e. they won't give you any further updates - neither in binary form nor in source-code form.
> If it does, then RedHat should be providing those split-out patches to *any 3rd party*
Posted Nov 24, 2012 5:12 UTC (Sat)
by steffen780 (guest, #68142)
[Link] (2 responses)
Are you sure about this? Unless I'm severely mistaken the GPL requires you to make the sources available to the party/parties to whom you shipped GPLd stuff. It does not require you to make anything available to anyone else.
Posted Nov 24, 2012 5:29 UTC (Sat)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
Posted Nov 25, 2012 1:18 UTC (Sun)
by steffen780 (guest, #68142)
[Link]
Posted Nov 15, 2012 15:35 UTC (Thu)
by jschrod (subscriber, #1646)
[Link]
AFAIU, the source must be published, but not the internal commits that lead to that source. And the kernel source is published, as srpm.
FTR: I'm neither connected to RH, nor do I use RHEL or Oracle's dist privately or at my company. I think RH's policy concerning kernel source distribution is ethically wrong, but not illegal.
Posted Nov 10, 2012 8:50 UTC (Sat)
by stressinduktion (subscriber, #46452)
[Link]
Posted Nov 10, 2012 12:04 UTC (Sat)
by epa (subscriber, #39769)
[Link] (26 responses)
Certainly, when Red Hat receive the code from Linus and pals it is in the form of a git tree, and if they distribute their changed version in a different form the onus is on them to show that this is now the "preferred" form for making modifications.
Posted Nov 10, 2012 12:41 UTC (Sat)
by branden (guest, #7029)
[Link] (3 responses)
It will be interesting see if the definition of "preferred form for modifying the work" now changes for the sake of whacking Oracle with a stick.
Which, to be fair, is not without its appeal...
Posted Nov 10, 2012 14:03 UTC (Sat)
by khim (subscriber, #9252)
[Link] (2 responses)
Not at all. “Closed internal repo with only occasional tarballs drop for outside consumption” is how FSF developed it's flagship products (Emacs, GCC, GLiBC) for years starting from the very beginning. And they created the GPL, remember? P.S. You may say that FSF eventually opened their repos but remember that this was political decision, not copyright-dictated one.
Posted Nov 10, 2012 19:51 UTC (Sat)
by donbarry (guest, #10485)
[Link] (1 responses)
We owe them our gratitude. Remember that their resources are often orders of magnitude less than that of even the free software companies.
Posted Nov 15, 2012 13:36 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link]
I can get Linus' kernel source as a tarball, unpack it and make a git repo for my own use, and thus have a set up that makes my development more productive. I might even throw in some other, closed source tools for my own pleasure. That doesn't mean anybody is entitled to said tools results. What GPL demands is the source code to study and modify, not random gossip on who wrote what line and changed what else. The same way it doesn't require anybody to ship the editor, compiler and whatnot the developers require for their work.
Posted Nov 10, 2012 13:01 UTC (Sat)
by paulj (subscriber, #341)
[Link] (1 responses)
Posted Nov 10, 2012 13:18 UTC (Sat)
by dowdle (subscriber, #659)
[Link]
What is weird to me... is that btrfs is the "zfs for Linux" but it so happens that Oracle also owns zfs. They could change (or dual license) zfs for Linux if they wanted to, but no... they'd prefer to have one product that is ok with the GPL (btrfs) and one that is not (zfs).
Posted Nov 10, 2012 13:59 UTC (Sat)
by khim (subscriber, #9252)
[Link] (13 responses)
Many developers don't use git (Linus himself used just a series of tarballs for years). And since in court you'll be confronted by FSF (it developed gcc, glibc and many other things in exactly this fashion for years—the only difference was that they used CVS and not git back then) who wrote GPL in the first place… I wish you luck—you'll need it.
Posted Nov 10, 2012 16:48 UTC (Sat)
by epa (subscriber, #39769)
[Link] (12 responses)
Counsel: And so during your time at Red Hat you normally worked on changes to the software using the git tree?
Witness 1: That's right.
Counsel: But why didn't you just use a tarball instead?
Witness 1: That would make my job more difficult, because...
Counsel: So you would say that you preferred to operate on the git source tree rather than a tarball?
Witness 1: Yes.
Posted Nov 11, 2012 2:31 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
The line has to be drawn somewhere. IANAL, but I'd think it'd be close to the form which implies the fewest number of "tools" given a "clean system" and is such that a "reasonable modification" could be made. For example, a standard tarball requires tar, one of the decompression binaries, and an editor (which could likely be assumed since modifications need to be made). These "tools" should probably be generally accessible (though not necessarily free), but that's another definition that would need pinned down.
Posted Nov 11, 2012 18:27 UTC (Sun)
by khim (subscriber, #9252)
[Link] (10 responses)
FSF set the standard. Others (for example Cygnus) worked in this fashion also. And now for the cross-examination: As I've said: I wish you luck—you'll need it. I'm not saying it's impossible to prove that git is "the preferred form for making modifications to the program", but it'll be quite hard. You'll need to collect statistic and prove that most developers use replica of the official git tree (I'm not sure if that's even true at all and to use this argument in court you need to prove that it's true without any shadow of doubt), then you'll need to somehow explain why kernel developers themselves don't think git repo is essential, etc. Fell free to do that if you have too many millions of dollars to burn.
Posted Nov 11, 2012 19:03 UTC (Sun)
by Jonno (subscriber, #49613)
[Link]
Actually, that would be a civil case, so you only have to prove it *on the balance of probabilities* (eg. that is more likely than not) but that is still quite a hurdle.
And BTW, even criminal cases only require *beyond reasonable doubt*, not beyond any doubt, as that would generally be impossible...
Posted Nov 11, 2012 21:22 UTC (Sun)
by epa (subscriber, #39769)
[Link] (1 responses)
Posted Nov 12, 2012 15:59 UTC (Mon)
by khim (subscriber, #9252)
[Link]
It may be surprising, but yes, not all developers use Git. That's well-known fact. And the ones who use it not always use replica of the official repo. It's hard to find out solid numbers, of course.
Posted Nov 11, 2012 23:06 UTC (Sun)
by viro (subscriber, #7872)
[Link] (6 responses)
> Witness 1: No.
Perjury is generally frowned upon... I do *not* think that "preferred form" argument would fly, since the general practice is what it is, but your "defence" is a load of horse manure. Anybody who starts a tree by importing a tarball instead of doing git clone is an idiot; "too large and unwieldy" being what, ~500Mb for full history? _And_ that's ~500Mb that only has to be present in a local clone of mainline tree; setting alternates to point to it eliminates that from yours, so unless you seriously propose a workflow that consists of git show or git format-patch on another box + mail or scp to the box where you work on your tree for each backport... *shudder*
In any case, I don't think that "RH kernel team does not consist of hopeless idiots" can be considered confidential information, so... No, rhel6 kernel git tree is *not* set up in such a cretinous way.
Posted Nov 12, 2012 12:03 UTC (Mon)
by nix (subscriber, #2304)
[Link] (5 responses)
(Alternates aren't ideal -- one fetch in the wrong place and oops you suddenly have heaps of redundant objects since you need to pull in the other place too and you probably don't have them set as alternates of each other. You need to be quite rigid in your fetching habits if this is really to save you a lot of space. But, heck, I do that sometimes and it just vanishes in the oceans of space on my multiple-year-old obsolete small disks. Even the *Chromium* source tree vanishes in the oceans of space on those disks. Disks you can actually buy nowadays will be even larger. This argument will never fly.)
Posted Nov 12, 2012 16:05 UTC (Mon)
by khim (subscriber, #9252)
[Link] (4 responses)
It makes sense when kernel is only part of the package. "~500Mb for full history" may not seem like much, but take 500Mb for kernel, 600Mb for gcc, 100Mb for binutils, etc and you soon arrive at gigabytes. And if you throw aways history of other projects to save space, then why will you want to offer special treatment to kernel?
Posted Nov 12, 2012 17:13 UTC (Mon)
by peter.todd (guest, #63121)
[Link] (1 responses)
I find it hard to believe that arguing tarballs are the preferred form of source code for a project otherwise developed with git would pass the balance of probabilities test in a civil case. After all, as mentioned elsewhere the other side just needs to ask your developers what they use to work with the source code. Even if they reply with a different revision control system, that indicates that you should be publishing your changes from it instead.
Having said that, if internally you *actually* don't use *any* revision control system, then yeah, maybe for you the preferred form really is tarballs.
Posted Nov 12, 2012 19:34 UTC (Mon)
by tzafrir (subscriber, #11501)
[Link]
Posted Nov 12, 2012 21:43 UTC (Mon)
by viro (subscriber, #7872)
[Link] (1 responses)
_Legally_ git doesn't qualify as "preferred source", but for all practical purposes it is strongly preferred as far as kernel work is concerned. gcc is a different story - they prefer suckversion and _that_ is a space hog, indeed. binutils... IIRC, they also use svn these days.
I don't know how to express that in license without running into insane corners, like "you must never rebase / cherry-pick / fold incremental fixes". On the other hand there's patently obnoxious behaviour several groups used to demonstrate - once a year or so they ran diff between the mainline and whatever had been in their CVS tree and post megabytes of non-differentiated garbage to e.g. l-k, usually reverting a bunch of fixes in process. Hell knows... TBH, I doubt that license is the right tool here...
Posted Nov 13, 2012 12:12 UTC (Tue)
by jwakely (subscriber, #60262)
[Link]
It's true the repo lives in subversion, but some (many?) of us use git-svn to work with it. I certainly don't prefer subversion and can't remember the last time I used subversion to commit anything.
Posted Nov 10, 2012 14:00 UTC (Sat)
by Otus (subscriber, #67685)
[Link]
The problem I (IANAL) see with that argument is that the GPL allows you to
Posted Nov 10, 2012 14:14 UTC (Sat)
by pbonzini (subscriber, #60935)
[Link] (4 responses)
You need patches to analyze a process (the creation of the Red Hat kernel) and replicate the same changes to *another* program (the Oracle kernel).
I see it the other way round: the actual preferred form of modification is flattened source code. To modify something you work on a checkout, not on a source tarball + some patches. "Source code + patches" is only acceptable because it is easily flattened.
Think of it. Suppose you have a bug in a Fedora package and you found that there is a fix upstream for it, for example via a Bugzilla search. Roughly speaking, Fedora packages are distribute as a tarball and a possibly empty set of patches.
The first things you do in order to test the fix are "fedpkg prep" to flatten the Fedora package and "git clone" to fetch the upstream change. You do not need the patches that build up the Fedora package (which is what you're modifying), but you need the patches that build up upstream (which is what you're analyzing.
Posted Nov 10, 2012 16:50 UTC (Sat)
by epa (subscriber, #39769)
[Link] (2 responses)
Posted Nov 10, 2012 21:48 UTC (Sat)
by apoelstra (subscriber, #75205)
[Link] (1 responses)
Most code I changes to code, it's usually because
(a) I am a project developer, and I need git to keep track of all the work I'm doing, or
Posted Nov 15, 2012 12:08 UTC (Thu)
by pbonzini (subscriber, #60935)
[Link]
Just use quilt, you do not need the history.
(Devil's advocate, of course---nowadays I'm spoiled by the ease of doing "git init", but I was doing the above a lot in CVS/svn days).
> (b) I am not a project developer, so I'm just doing a small bugfix. Then I'd like 'git log' or 'git blame' to find out where the bug came from.
Nice to have, but definitely not a requirement for modification.
(Not devil's advocate here, I rarely do "git clone" if I'm just fixing something for myself. I just work on top of the Fedora package).
Posted Nov 11, 2012 11:34 UTC (Sun)
by cyanit (guest, #86671)
[Link]
It seems to me they might very well be in violation of the GPL.
Posted Nov 10, 2012 14:36 UTC (Sat)
by paulj (subscriber, #341)
[Link] (2 responses)
http://lwn.net/Articles/432012/
At a minimum, anyone starting a discussion here needs to read all of that previous discussion first.
Posted Nov 10, 2012 15:53 UTC (Sat)
by branden (guest, #7029)
[Link]
Posted Nov 10, 2012 16:51 UTC (Sat)
by epa (subscriber, #39769)
[Link]
Posted Nov 11, 2012 12:20 UTC (Sun)
by johannbg (guest, #65743)
[Link] (12 responses)
Posted Nov 11, 2012 13:41 UTC (Sun)
by seyman (subscriber, #1172)
[Link] (11 responses)
The only issues were would be if you're selling support (like Unbreakable) and if you're using Red Hat's efforts to maintain another kernel over the same stretch of time.
Posted Nov 11, 2012 16:06 UTC (Sun)
by johannbg (guest, #65743)
[Link] (10 responses)
Posted Nov 11, 2012 17:48 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link] (9 responses)
Posted Nov 11, 2012 18:25 UTC (Sun)
by johannbg (guest, #65743)
[Link] (8 responses)
Care to share with audience which Red Hat changes caused it to be if not the obfuscation manoeuvre?
Posted Nov 11, 2012 18:45 UTC (Sun)
by mjg59 (subscriber, #23239)
[Link] (5 responses)
Posted Nov 11, 2012 18:59 UTC (Sun)
by johannbg (guest, #65743)
[Link] (4 responses)
Posted Nov 11, 2012 19:08 UTC (Sun)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Posted Nov 11, 2012 19:18 UTC (Sun)
by johannbg (guest, #65743)
[Link] (1 responses)
Posted Nov 11, 2012 19:20 UTC (Sun)
by mjg59 (subscriber, #23239)
[Link]
Posted Nov 11, 2012 19:08 UTC (Sun)
by johannbg (guest, #65743)
[Link]
Posted Nov 12, 2012 0:48 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Posted Nov 12, 2012 1:01 UTC (Mon)
by dlang (guest, #313)
[Link]
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Not at all likely. Red Hat already has individual patches in their internal repository. They only mash them together when they build the packages for release.
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Conceivably. To find out, you need to find someone who has the standing and funding to bring a lawsuit over the matter and an interest in doing so.
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Yes and no. You can distribute it, no problem (patches are GPLed, after all), but contract is terminated in this case (and can not be renewed).
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
- neither access to the knowledge base meant by the patches
(that's fairly accomplished by an RHN subscription)
- nor a crusade for making this knowledge base public
- rather, making a business that builds on this knowledge base
knowledge base, and that's exactly what RH stopped to give out.
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Can you provide a reference to that in the GPL? I'm under impression that GPL kicks in during the moment of distribution only.
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
The git tree is the source code
The git tree is the source code
The git tree is the source code
It will be interesting see if the definition of "preferred form for modifying the work" now changes for the sake of whacking Oracle with a stick.
The git tree is the source code
The git tree is the source code
The git tree is the source code
The git tree is the source code
The git tree is the source code
If the workflow of programmers is heavily based on git, then the preferred form of the work is the git tree and that is what the GPL requires Red Hat (and others) to distribute.
The git tree is the source code
The git tree is the source code
The git tree is the source code
The FSF is not relevant here - as the copyright holders of the code they wrote, they could not get in trouble for violating the GPL no matter what they did.
Counsel: And so during your time at Red Hat you normally worked on changes to the software using the git tree?
Witness 1: That's right.
Counsel: But why didn't you just use a tarball instead?
Witness 1: That would make my job more difficult, because...
Counsel: So you would say that you preferred to operate on the git source tree rather than a tarball?
Witness 1: Yes.
Counsel: Was your repo a replica of the official tree?
Witness 1: No.
Counsel: You imported the official tarball and applied local patches on top of that to make repository smaller.
Witness 1: That's right.
Counsel: And you have not used the full replica of the official repo, because...
Witness 1: It'll be too large and unwieldy and it was easier to start with tarball.The git tree is the source code
The git tree is the source code
The git tree is the source code
The git tree is the source code
The git tree is the source code
The git tree is the source code
The git tree is the source code
The git tree is the source code
The git tree is the source code
$ du -s .
652664 .
$ du -s .git
118828 .git
and that - on a tree with alternates pointing to straight mirror of kernel.org linux-2.6.git (which obviously doesn't need to be distributed). Note that unpacked kernel source eats about 4.5 times more than everything in .git. IOW, it's really noise. Granted, that's unpacked (i.e. working tree, not package being distributed), but packed (tar.bz2) will give only ~2 times increase compared to that of source without history - more than 1.2, but not very much more.
The git tree is the source code
The git tree is the source code
> form of the work is the git tree and that is what the GPL requires Red Hat
> (and others) to distribute.
keep undistributed versions private. Those intermediate versions in the git
tree were not distributed, and could in theory even include upcoming
features that were later taken out and still count as trade secrets.
The git tree is the source code
The git tree is the source code
I see it the other way round: the actual preferred form of modification is flattened source code.
There's some merit in that argument. Even when people do fetch a git tree to modify the code, they don't usually look at the history of past patches but just work on their change based on the state of the code as it is now.
The git tree is the source code
(b) I am not a project developer, so I'm just doing a small bugfix. Then I'd like 'git log' or 'git blame' to find out where the bug came from.
The git tree is the source code
The git tree is the source code
The preferred form discussion has already been done (to death)
The preferred form discussion has already been done (to death)
The preferred form discussion has already been done (to death)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)
Introducing RedPatch (Ksplice Blog)