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
