Re: The Show So Far
[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
Reply to: