Talk:Ksplice

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Unnamed section[edit]

I added more info on how Ksplice works and clarified the relationship between the open-source Ksplice technology and the subscription service that the Ksplice company offers. I work for Ksplice (the company) -- want to make sure that's clear to all. I believe these changes are NPOV and improve the article, but want to make sure these edits conform to community standards and wanted to disclose my relationship. KeithWinstein (talk) 07:32, 9 February 2010 (UTC)[reply]

GPL[edit]

If it is GPL, please provide a link to source code in the article. Seems like it's not GPL, it's proprietary 93.170.3.2 (talk) 15:30, 10 February 2010 (UTC)[reply]

Added source code link. KeithWinstein (talk) 22:47, 18 February 2010 (UTC)[reply]
The ref (link) you added has since been removed and the .tar.gz file is no longer available from that location. Currently, the article links to the Ksplice Uptrack Subscription Agreement as a reference for "open-source" in the lead, and for "GNU General Public License version 2" in the infobox. This won't do. The agreement includes a sentence that "some Oracle software related to the Service" is available under the GPL. It does not explicitly mention Ksplice. Furthermore, the ksplice.com website does not provide a link to a source package. A link to a random repository on GitHub would not be a reliable source. I've tagged the reference with {{Better source}}. --82.136.210.153 (talk) 07:21, 28 December 2014 (UTC)[reply]
Hello! Nice catch; I've tried to search for better information on licensing, but nothing usable seems to be (publicly?) available. However, there are two interesting blog posts (of course, they aren't good enough to serve as references): http://cormander.com/2011/07/ksplice-currently-violates-the-gpl/ and http://cormander.com/2011/06/ksplice-raw-utilities-not-working-on-recent-kernels/ . — Dsimic (talk | contribs) 07:44, 28 December 2014 (UTC)[reply]

Ksplice utilities on oss.oracle.com. I note that the README includes the following: This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License, version 2.. LFaraone 01:37, 31 December 2014 (UTC)[reply]

Hello, and thank you! This is a good reference, got the article updated. — Dsimic (talk | contribs) 09:06, 31 December 2014 (UTC)[reply]
That language no longer exists there. The original code is GPL, but from all indications it hasn't been maintained since 2011. Ksplice as Oracle runs it has either never been updated, or it has been locked up and not been made available. The only places I can find explicit GPL term applied are an old github repo from 2011. All legal terms on Oracle websites say it's proprietary. Wubby (talk) 22:07, 8 January 2020 (UTC)[reply]

Not a GPL Violation in this case[edit]

I spent some time (OK, only around 45 mins) googling and reading the paper, and if the architecture of the software has not changed much, Ksplice uses user space tools to build and diff binary kernels, and uses kernel modules to load the binary diffs into a running kernel. I don't think this is any GPL Violation in this case:

1) Kernel modules are not required to be licensed under the GPL, unless they reference GPL symbols.

2) User space tools are not required to be licensed under the GPL (or else we wouldn't have DB2, Oracle, etc on Linux).

3) The GPL section that is used by the cited source says:

 For an executable work, complete source code means all the source code... plus the scripts used to control compilation and installation of the executable.

However, Ksplice builds the original kernel & the new kernel using gcc (with special flags), and then performs the binary diffs using the BFD library. The GPL does not explicily include compilers or linkers, and as far as I know, GPL code is used on many platforms than Linux/gcc. For example, a port of glibc was available on SunOS (pre-Solaris), but the build compiler was Sun's non opensource compiler...

If tools that generate a GPL executable (be it the kernel or another GPL application) were required to be licensed under the GPL, then clang (BSD) can't be used to compile any GPL source. A bigger problem is that the Intel compiler can't be used to compile the kernel as well.

Finally, so far it is one guy blogging about this - unless we have a more credible source, or unless we have real evidence that the Ksplice kernel modules reference GPL symbols, then I don't think it is any more special than NVidia shipping a binary video card driver, or someone uses Clang or Intel C compiler to compile GPL applications. Raysonho (talk) 06:56, 23 April 2012 (UTC)[reply]

Source code of redistributed Kernel patches[edit]

Linux is GPL'ed and GPL states anything reproduced, taken, redistributed or recompiled must have source code with it in the redistribution: See http://en.wikipedia.org/wiki/GPL

"The fourth section for version 2 of the license and the seventh section of version 3 require that programs distributed as pre-compiled binaries are accompanied by a copy of the source code, a written offer to distribute the source code via the same mechanism as the pre-compiled binary, or the written offer to obtain the source code that you got when you received the pre-compiled binary under the GPL. The second section of version 2 and the fifth section of version 3 also require giving "all recipients a copy of this License along with the Program". Version 3 of the license allows making the source code available in additional ways in fulfillment of the seventh section. These include downloading source code from an adjacent network server or by peer-to-peer transmission, provided that is how the compiled code was available and there are "clear directions" on where to find the source code."

Since Ksplice is taking the security patches from Linux stable tree so where is that recompiled source code? GPL requires redistribution of GPL'ed software to be made public. Like RHEL has to go through. Unless that code is made public from Ksplice, the violation seems to be there. — Preceding unsigned comment added by 110.39.70.23 (talk) 09:11, 23 April 2012 (UTC)[reply]

Again, compilers are excluded from the GPL. As you said, Ksplice takes source code that are available from the Linux stable trees. The input to Ksplice (the kernel source code from the Linux stable trees) is available for download from Oracle. Anyone who uses Oracle Linux can use Oracle's public yum, and as far as I know Oracle has a public git that hosts the GPL source code.
Please read the Ksplice paper and understand how Ksplice works first before saying that Oracle is violating the GPL. Raysonho (talk) 15:15, 23 April 2012 (UTC)[reply]
The paper doesn't clearly say where to find those redistributed patches source code which is what the GPL requires. — Preceding unsigned comment added by 110.39.70.23 (talk) 23:10, 23 April 2012 (UTC)[reply]
How many times do I need to repeat myself - Ksplice takes kernel source code as input, and the kernel source code can be cloned from Oracle's public git. You need to understand the architecture of Ksplice before you jump to the conclusion. Raysonho (talk) 23:15, 23 April 2012 (UTC)[reply]

Additional source code location[edit]

http://slackbuilds.org/repository/13.37/system/ksplice/ — Preceding unsigned comment added by Davidwr (talkcontribs) 21:48, 27 July 2012‎ (UTC)[reply]

Official source code location here. --82.136.210.153 (talk) 18:02, 4 January 2015 (UTC)[reply]

Misreporting[edit]

The current text says that it was "widely misreported" that Oracle dropped SUSE support. The citations do not support the misreporting, they are just the original erroneous reports. I am tagging that section as synthesis. --68.14.246.234 (talk) 17:09, 11 January 2013 (UTC)[reply]

I removed the section. LFaraone 02:11, 1 May 2013 (UTC)[reply]

Jeff Arnolds[edit]

The reference points to the wrong person. — Preceding unsigned comment added by 93.205.24.101 (talkcontribs) 20:01, 26 June 2013‎ (UTC)[reply]

kGraft and Kpatch[edit]

It might be worth noting that there are plans to develop alternatives to ksplice, namely kGraft (SUSE) and Kpatch (Red Hat) — Preceding unsigned comment added by 141.58.5.85 (talk) 11:23, 14 February 2014 (UTC)[reply]

Let's hope that SUSE delivers kGraft in March 2014 as promised; having this merged into the Linux kernel mainline would be just awesome. Though, there's next to no info available on kpatch? — Dsimic (talk | contribs) 02:34, 15 February 2014 (UTC)[reply]
Some kpatch info can be found from http://rhelblog.redhat.com/2014/02/26/kpatch/ . I see there's a redirect from kpatch to ksplice nowadays, but I'm not sure if that was a particularly good move. Avij (talk) 19:42, 12 March 2014 (UTC)[reply]
Yeah, not a great thing, but soon kpatch and kGraft should be expanded into separate articles, so any confusion will be eliminated. — Dsimic (talk | contribs) 03:11, 14 March 2014 (UTC)[reply]
 Done. — Dsimic (talk | contribs) 11:47, 1 December 2014 (UTC)[reply]