[I screwed up and sent this to Glenn first, apologies] I'd also like to ask a clarification of scope question: Are we discussing whether:
1) The GPLv2 should be interpreted to treat RPC calls as creating a combined work? 2) The GPLv3+ should be altered to make RPC calls create a combined work explicitly? 3) Whether a license that interprets RPC calls to require release of server source is DFSG free? So far, I'm just saying that I think requiring release of server if an RPC call is made from a Free work is a "Bad Thing" on general principles. It's better to release the server source, but legal force has too many side effects, IMHO. Still sitting on the fence a bit, though, which is part of why I'm still talking so much. ;-) On Wednesday 12 March 2003 08:55 pm, Glenn Maynard wrote: > People who develop GPL code do so with the understanding that nobody can > take that code and make it proprietary. Well, yes. But it does so by restricting redistribution, not use. And use restrictions are generally viewed (and I agree) as non-free and possibly legally-impossible anyway, as a violation of copyright fair-use principles. > > Surely the carrot -- allowing free developers to improve the software instead > > of having to bear all development costs on yourself -- is adequate to > > encourage release, without the stick. > > If we believed this, then we would all be using BSD licenses, not GPL. > The GPL is written with the express belief that this is not true. > (Experience shows--lots of proprietary vendors, such as Microsoft, have > taken BSD code, integrated it into their products, improved it and > never contributed back code at all[1].) Okay, touche. But I'm *not* trying to argue against copyleft in principle. I'm saying it isn't the only reason people share code. And no, I'm using the GPL on my project. I *would* actually like to avoid the case of someone developing on my codebase without releasing it. With the GPL, no one can release (or sell) their modifications without releasing source. That means the only person who would make modifications without releasing them would be someone who wants to provide the service. And IMHO there's reason to believe that having that motivation makes it more desireable to release (they have less to lose and more to gain by it than a developer who intends to sell the application directly -- or so it seems to me). Being their own customer, they would be more sensitive to the customer need -- which is for the service to work well, and the cost -- which is development. They would typically be on a thinner margin than someone selling the software to high-end customers. Those are both strong reasons to prefer an open-source development process. The tricks that people have learned to make money from open-source software (e.g. selling services instead of software goods), it seems to me, work both ways: when you're selling the service, the open-source approach makes more business sense. I don't know, maybe that's wishful thinking, but it *seems* reasonable. > I agree that the RPC loophole may either be unfixable, or it may not be > possible to fix it without sacrificing too much freedom elsewhere. I'm > not yet convinced, of course. I do think there's a potential problem; > I'm not *quite* convinced it'll become a real one. I'm moderately convinced it won't be, which is my point. And I do think that "closing the loophole" would require onerous "non-free-ness" of the licensing. I think as long as the problem is theoretical, we shouldn't be trying to solve it this way. I'd want to see a "clear and present danger" before doing something like that. At present it seems to me that there's too much unknown -- both about what possible threats exist and about what would be lost in flexibility by restricting use like this. In my particular application there is one possible solution (just thought of it), using social pressure: The application is meant to be multi-homed, residing on multiple servers with varying degrees of cooperation between them. It would not be onerously non-free (IMHO) to make releasing source changes a requirement for joining such a trust group (i.e. you get to join my club if you do the "right thing" and release source changes for your site, even if you aren't redistributing it). There are practical advantages to this as well as philosophical ones -- keeping all the networked sites more or less in synch is liable to improve interoperability. I know that won't work as a general solution, though. Hmm. Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com