At 05:53 AM 8/26/2006, Robert G. Brown wrote:
On Fri, 25 Aug 2006, Geoff Jacobs wrote:
I should have been more specific and said that I do not believe any
integrated benchmarks packaged and shipped by SPEC are in any WSOF Open
Source or Free Software. Apparently some software included in SPECCpu
2006 is in fact licensed under the GPL, including sjeng. Possibly some
other Free Software and OSS licenses are represented as well.
To use the benchmark itself requires a license from SPEC.
Hmmm, GPL viral?
This raises a really "interesting" question about the depth at which
open source GPL code is embedded in a tool when the viral clause kicks
in. As in, if I embed a GPL program (source) straight inside a calling
subroutine in a single program, there is no question that viral kicks in
and the resulting program must also be GPL.
So what about if I embed a GPL program inside a (say, perl or bash)
script that does PRECISELY the same thing that such a calling shell
might have done -- execute the GPL fragment, process the results,
present them, but now as a part of the NEW program's functionality. Is
this not viral? If it is a C program and I use perl through e.g. the
system commands instead of a C program inside a C wrapper with the
system commands, what's the real difference?
I think the essential distinction is separate compilation&linking, or
perhaps separate process. If I could take your compiled GPL program out
and replace it with another program with the same function, without
changing the wrapper, then the wrapper isn't GPL. (leaving aside evil
things like the wrapper peering into the executable code after it is loaded)
Another analogous situation is a loadable driver. Does loading a non-GPLed
driver into a GPL framework make the driver subject to GPL? Generally, I
think the answer is no, because the driver is separately compiled and
supplied as a discrete isolated chunk.
I realize there's a (bit) of discussion on these topics, and I don't want
to start a long discussion about F/OSS, GPL, FSF, BSD, etc.etc.etc.
It would be very interesting to sic the FSF lawyers on the SPEC folks
and argue that by including GPL code in the suite, the suite wrapper
itself and all GPL code wrapped by the suite (in place) has become GPL,
period. Perhaps it couldn't be extended to "infect" other commercial
components of the test suite, but they are basically replaceable by
cloned GPL code in many cases -- you won't get a perfect match but then
you wouldn't need one. Just one that produced consistent results that
could be compared across architectures in a meaningful way.
rgb
--
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
_______________________________________________
Beowulf mailing list, [email protected]
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
James Lux, P.E.
Spacecraft Radio Frequency Subsystems Group
Flight Communications Systems Section
Jet Propulsion Laboratory, Mail Stop 161-213
4800 Oak Grove Drive
Pasadena CA 91109
tel: (818)354-2075
fax: (818)393-6875
_______________________________________________
Beowulf mailing list, [email protected]
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
