Hi, I agree to Dann, can't see a legal issue here. The vanilla kernel is available from thousands of sources and mirrors. And GPL doesn't require one to provide the source, just to provide it upon request. Keeping it ready for download is good enough. And if kernel.org is down at the very moment somebody wants to find the source, it will be certainly back up within a day or so. I also don't fear that the kernel source will disappear: the oldest kernel I could find at kernel.org was from 1994, so more than 11 years old.
I only see practical issues for packaging (or not packaging) kernel sources with the srpm. As said, I prefer not to pacage it. People who build frequently have the workaround of keeping the source in /usr/src where the build process will pick them up. And OSCAR svn repositories won't be bloated with huge binary SRPMs... (OTOH: some of the small package were really poorly accessible, I wouldn't mind the small opnes to come with the SRPM). Regards, Erich On Wednesday 14 December 2005 21:28, dann frazier wrote: > On Wed, 2005-12-14 at 13:47 -0600, Brian Elliott Finley wrote: > > Bernard recently raised the issue that the SI source tarball only has > > the source for the kernel on which it was created. This raised the > > question of: "Do we include the kernel source for all architectures?" > > > > The problem: that would make for a really honkin' SI source tarball. > > > > Erich Focht's comment (paraphrased): "Don't include the kernel source at > > all, let the getsource tool handle that. The kernel.org mirrors are > > very reliable." > > > > I'd like to come to a conclusion on this quickly, and the crux of it is, > > from an open source perspective, is there anything wrong with us > > providing the kernel source by referencing the URL at which it can be > > found? > > Legally (and IANAL): > Standard GPL - we must either provide the source or provide a written > offer for providing the source on request for the next 3 years. This > doesn't mean you have to bundle it - but not doing so is a risk (as is > sourceforge & all mirrors disappearing, etc). This risk maybe something > we're willing to accept, but also be aware that we're passing this > liability onto folks that redistribute SIS. > > Functionally: > This means that anyone who wants to build SystemImager has to have their > build system on the Internet, and has to have the bandwidth to pull a > large file. And kernel.org has gone down for multiple days before... > > SuSE didn't like a build hitting the net, but they decided not to pick > up SIS anyway. This wouldn't work for Debian either, but I have to do a > different kernel for Debian anyway (non-free issues). > > Historically, I'd tried to keep all archs on the same kernel so only one > tarball is necessary. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Sisuite-devel mailing list Sisuite-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-devel
