[kepler-users] saving workflow in eps format

[Christopher Brooks]

It is an interesting question about at what point is
a system aggregating GPL code and thus GPL'd.

If I create a system that download the GPL'd code and installs
it for the user, then that seems awfully close to just shipping
the release with GPL'd code.

Plug-ins and the GPL are covered:

http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLAndPlugins
says:
--start--
If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?

     It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no 
requirements for them.

     If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of 
both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those 
plug-ins are distributed.

     If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a 
borderline case.

--end--

Thus, if we call GPL'd code via reflection, then the entire mess is GPL'd.

Of course, IANAL, (but I play one on TV). :-)

I'm still sticking with the idea of a non-GPL'd core and maybe a GPL'd extended
version.  At first, I'd probably ship a non-GPL core binary installer and leave
the GPL version for developers to build.  Eventually, we could ship a GPL'd
binary version.

_Christopher

On 3/1/10 5:41 PM, Peter Reutemann wrote:
>> The bottom line in this case is that we can provide instructions
>> for how to modify our source code so that you can export to PDF,
>> but we can't actually provide the code that does that...
>
> I'm not familiar with the Kepler code basis... But how easy would it
> be to provide a plug-in mechanism for "print" modules. Users would be
> able then to download these modules separately and enable print
> support, without having to modify the code basis (merely placing a jar
> in a "lib" directory and maybe making a small change to a props file).
> It should be possible to provide a Java-based installer for this kind
> of plug-in installation, I'd say.
>
>> Unless of course we write our own PDF utility and put it under BSD.
>
> A lot of effort, unfortunately.
>
> Cheers, Peter

-- 
Christopher Brooks, PMP                       University of California
CHESS Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841 fax:510.642.2718	      (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 cell: 707.332.0670