[Beowulf] SPEC CPU 2006 released

[Jim Lux]

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:rgb at phy.duke.edu
>
>
>_______________________________________________
>Beowulf mailing list, Beowulf at beowulf.org
>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