Bart Schaefer wrote: BS> On Fri, 19 Apr 2002, Craig R Hughes wrote: BS> BS> > Bart Schaefer wrote: BS> > BS> > BS> Right; the GPL doesn't require you to expose to any third party any BS> > BS> changes that you make; it just requires you to provide the source code if BS> > BS> and when you do expose changes to a third party. BS> > BS> > I'm not sure what the GPL requires of you if you modify config files BS> > which interact programmatically with GPLed code BS> BS> All config files interact programmatically with the software they're BS> configuring. Whether the config file happens to be written in the same BS> language as the software is irrelevant.
But some config files are more programmatic than others. Is EvalTests.pm code, or config file? How about the rules files which contain the more complex regular expressions? What's the difference between EvalTest and the rule files? How about between EvalTest and PerMsgStatus? PerMsgStatus and SpamAssassin? Getting a clearer sense of the potential issues? BS> > In the case of SA, the config files are really more or less part of the BS> > program code. Does that mean ISPs would have to make their changes to BS> > the code available to their customers, if those customers are allowed to BS> > edit their user_prefs? BS> BS> Section 0 says: BS> BS> "Activities other than copying, distribution and modification are not BS> covered by this License; they are outside its scope. The act of BS> running the Program is not restricted, and the output from the Program BS> is covered only if its contents constitute a work based on the BS> Program (independent of having been made by running the Program)." BS> BS> The usual IANAL applies, but I don't think installing SA on a machine you BS> own and allowing users of the machine to run it can be said to constitute BS> "copying" or "distribution" to those users. modification though is covered, and if the config files can be considered part of the code (they are being executed, not just setting parameters [and what's the difference anyway in a turing machine?]), and users can edit the config... BS> > ... The problem I'm more concerned with is the config-file-is-code one BS> > which is a feature of many Perl programs, combined with section 2(b) of BS> > the GPL which says that you must apply the GPL to any work "that in BS> > whole or in part _contains_ or is derived from" GPLed code (my BS> > underlining). My reading of that is that containing a GPLed piece in BS> > the distribution of a greater package requires the greater package to BS> > carry the GPL. BS> BS> I don't think you're reading 2(b) that wrong, but just because the program BS> reads and executes a config file doesn't mean that the config file is BS> "contained" in the "work." (If the GPL included a definition of a "work" BS> a lot of this confusion could be avoided.) "Running the Program is not BS> restricted" -- if the config file doesn't become part of the program until BS> the program runs, it's not covered. Can I build any extension I want to on a GPL base and just all those extra bits config files? Or just call the parts I don't want the GPL to apply to config files? If that's true then the GPL strikes me as providing no value. BS> > ... The last bit of section 2 seems to say that you can distribute the BS> > GPLed module separately from the non-GPLed part, and then avoid being BS> > compelled to GPL the whole thing, but if you package them together, the BS> > whole enchilada need to carry the GPL. BS> BS> It doesn't really even say that. "... mere aggregation of another work BS> not based on the Program with the Program (or with a work based on the BS> Program) on a volume of a storage or distribution medium does not bring BS> the other work under the scope of this License." A GPL'd plugin does not BS> (in fact, specifically cannot -- "This General Public License does not BS> permit incorporating your program into proprietary programs") cause the BS> program into which it plugs to become GPL'd. The clause you quote sound to me like it does not cause the plugged-into program to become GPLed, because you are not granted a license to use GPLed code in that way in the first place. BS> On Fri, 19 Apr 2002, Daniel Quinlan wrote: BS> BS> > Bart Schaefer writes: BS> > BS> > > This, on the other hand, is not clear. The GPL attempts to apply to the BS> > > algorithms used in the code as well as to the literal code itself; some BS> > > people interpret this to mean that if you so much as look at a piece of BS> > > GPL'd code, you might accidentally learn something, which, if it later BS> > > affected the way you wrote some other piece of code, would mean that the BS> > > code you wrote was now also GPL'd. BS> > > BS> > > This is obviously a very paranoid interpretation, but not unheard-of. BS> > BS> > It is not a correct understanding of the GPL. Actually, it's BS> > completely wrong. The GPL makes absolutely no claims on algorithms. BS> BS> I don't know the exact reasoning behind the above claim, but it has been BS> repeated a number of times recently -- there was a slashdot discussion, BS> I think, and I've also seen remarks from a person who works at a large BS> software-company-that-shall-remain-nameless to the effect that their BS> corporate lawyers interpret the GPL that way. On a guess, I'd say that BS> it all comes back to the GPL's use of "work" as a noun without defining BS> it. "The work" of a program could be construed to include its algorithms. I don't read the GPL that way, and am not concerned about that aspect of it. I would hazard to guess that any such restrictions which are not based on patent law, and which tried to prohibit the exercise of by an individual of the tools of his or her trade would be invalid in most jurisdictions. BS> > The GPL is not viral. It cannot "infect" your code. You must actively BS> > *copy* GPL code and *put* it into your code for the GPL to apply to the BS> > derivative work. At a later date, you could remove all of the GPL code BS> > (and any code derived from it) and then the work would no longer be BS> > required to be GPL. BS> BS> The "viral" meaning goes this way: I actively copy some GPL'd code X into BS> my program Y. The GPL now applies to the *entire* derivative work Z. I BS> later remove X from Z; this creates a new work W. However, all the deltas BS> from Y to W are GPL'd, because the entirety of Z was GPL'd. In order to BS> remove the GPL from W, I have to revert all the way back to X. As this is BS> usually impractical if not impossible, the GPL has effectively "infected" BS> my code. Well, that's one version of the viral aspect. The version I'm more concerned about is that I'm not gonna want to remove GPL modules once they're in the code. Why would I? I made a choice to put them in in the first place. If I didn't want the code in there, I'd just rewrite it in the first place before inserting it. When I talk about GPL cancer (which I'm not saying is a bad thing, I'm just borrowing a phrase coined by others), what I'm referring to is the fact the while there is indisputably GPLed code forming a part of my own stuff, I am forced to license all my work (which might be a much more substantial effort than the small module I included) under the GPL. If I copy/paste one line of GPL code into SpamAssassin, then I *must* release the entire thing under the GPL for at least as long as that line remains in the code. To me, that is a highly infectious licensing restriction. Again, that's not necessarily a bad thing in all cases; in the case of the SpamAssassin project, where I think there are probably a number of modified versions out there, that could well be a serious issue. The perl artistic license seems to achieve the needs of the project far more effectively (it even allows you to have a GPL license on the package if you want one). C _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
