Re: Web application licenses
Josh Triplett <josh.trip@verizon.net> writes:
> Glenn Maynard wrote:
>> Here's a case that I'd remembered vaguely but havn't been able to find again
>> until now:
>>
>> http://lists.debian.org/debian-legal/2003/03/msg00369.html
>>
>> In this case, the only realistic way to fulfill this type of "source to
>> network users" requirement is by some other channel than the actual network.
>> Costs aside, spamming the source at the SMS receiver is useless; it needs
>> to be sent to a computer.
>
> Agreed.
>
>> This isn't a matter of resources; the very medium itself is not designed
>> for the transmission of source code, and a "make the source available on
>> the same medium" could make use in this context not onerous, but impossible,
>> and I think that's a clear non-free boundary.
>
> I don't think that's a non-free boundary at all.
>
> The GPL has the same "make available on the same medium" clause, so
> the
No, it doesn't -- for two reasons. First, the referrerents are
diffent. "same medium as the binary" and "same medium as the
interface" are different. What if this is a kiosk? Must I provide
source by scrolling it up the screen?
Second, the GPL talks about a medium customarily used for software
exchange. It specifically *doesn't* require the same medium, party to
avoid this bug.
> only reason you are suggesting it shouldn't apply here is because you
> are providing a service rather than distributing a GPLed work. See below
> for a case where providing source for a distributed work could be just
> as onerous.
>
> Consider what would happen if you started a service to provide GPLed
> Wikipedia-like content via SMS. (Ignore the fact that Wikipedia itself
> is GFDLed; consider a hypothetical GPLed version.) In this case, you
> would have the same requirement to provide source to the recipients.
Are we talking about the content, or the server? The source to the
provided works seems perfectly reasonable.
> Providing the full source to this Wikipedia-like encyclopedia via SMS
> would be nearly impossible and prohibitively expensive, and as you said
> above, quite useless to the recipient. (And I don't think providing
> only the source for each page would be acceptable, nor would it really
> be feasible or useful either.) You would again need to provide the
> source via a separate medium.
Why wouldn't providing the source for the page be acceptable? It's
the work which is being copied to you. And Wikipedia is a great
example of this: the source for a page is roughly the same order of
magnitude as the page, and there's a link *right there* on every page
to get the source. So you could GPL the content of Wikipedia and it
would work fine as is, even over WAP for cellphones.
> Also, consider the more modern version of SMS, called MMS. It can be
> used to transmit large quantities of data to a phone, including
> pictures, video, *applets*, etc. This is clearly distribution. Suppose
> an applet were GPLed. It still would be difficult to transmit the
> source to people's phones (or perhaps impossible, if the complete source
> were too large).
Sure, but that doesn't help with the SMS case. And if you can get
applets on your phone, you can get an editor on your phone. Maybe
even a network interface to a fast machine with a compiler, to bring
in another example.
> Yet we do not say the GPL is non-free because of these cases, nor should we.
>
> Just because a requirement to provide source code might be inconvenient
> or even impossible in a particular case does not mean the license is
> non-free.
Actually, I think it does. A requirement which makes some *uses* (not
business models) impossible is non-free. You're placing requirements
on use cases, so I don't expect you to like that model. But if you
want to convince people that you can do required source distribution
on use, you've got to find a way to do it that's universally applicable.
>> I don't think an alternative, "make it available by some medium"--for
>> example, setting up a webserver and pointing to it--is reasonable, since
>> it boils down to "if you run an SMS server, you must also run a webserver".
>> That becomes an unrecoupable expense if nobody actually downloads it. If
>> I'm not already running a webserver, merely setting one up will cost me
>> monthly.
>
> That is one of many alternatives; others include mail-order CDs (if you
> think you won't get many requests), "email me for the source", etc.
How about "email me to work out a method"?
> A copyright notice is only a handful of bytes, and other than a medium
> like SMS, there are few cases where it would be difficult to
> include.
Traffic lights, elevator controls, all those situations where the user
thinks he's interacting with a machine, not some piece of software.
And the copyright notices for *every library in use* would be insane.
> Furthermore, in the cases given above for distributing a GPLed work via
> SMS, you would have the same problem. I think distribution via SMS is a
> pathological case, and you can probably find many ways in which existing
> licenses would cause large inconveniences or impracticalities in such a
> case.
Distribution via SMS is a very useful edge case, though: we usually
*don't* send binaries through SMS for exactly the same reason we
usually don't send source.
>> [1] refresher: as we've discussed elsewhere, requiring that I archive the
>> source for every binary I distribute for several years is unreasonable;
>> fortunately, GPL#3a makes this irrelevant
>
> And as shown above, there are cases where distribution of source under
> GPL#3a could be completely infeasible as well.
I don't think any survived. Got any others?
>> On Thu, Aug 12, 2004 at 10:34:27PM -0700, Josh Triplett wrote:
>>>What if you are distributing a book, or a handout, or a flyer, or a
>>>reference card, and you suddenly have to either include a CD of source
>>>with every copy, or include an offer to provide source? That could
>>>certainly be considered onerous, and yet it is considered to be Free.
>>
>> I personally don't tend to think that requiring that I include a CD along
>> with a handout is reasonable; it's just a battle that I've never had the
>> inclination to fight.
>
> That's a big statement; are you suggesting that recipients of such
> distributed versions of a GPLed work do not deserve Freedom over that work?
I think he's looking at the handout as a variant form of projecting it
on a wall, not as a distribution. Yes, it really is a distribution,
but since it gets used as a variant projector it would be nice if it
didn't have to be.
>>>Personally, I don't think this is a use restriction, because I think
>>>using software to provide services to others goes beyond your own use,
>>>since it involves others; those others deserve freedom as well.
>>
>> The purpose of the restriction isn't what makes it a use restriction or
>> not. If it restricts use, it's a use restriction. This says "if you
>> use this program to generate stuff for others, do this and that"; that's
>> a use restriction by my understanding, just as is "you may not use this
>> software to spam".
>
> What I am suggesting is that it is going beyond "if *you* use the
> program to generate stuff for others", into "if you allow *others* to
> make use of the program". I think that is a meaningful distinction.
Now that's interesting. Maybe you can define things in terms of this,
in such a way that a stoplight isn't an interaction, and an SMS
message isn't... that the output is critically dependent on the input,
and not predictable without knowing the input?
And in order to avoid the routers, include a non-simulatability
property? So it has to have been *this* instance of the software,
running under my control, and with access to *that* input -- but if I
provide the resulting output, then I am required to provide source in
some way, which I can work out with the person who wants it, at a
reasonable cost for the media, time spent for the transfer, and cost
of establishing communication?
-Brian
--
Brian Sniffen bts@alum.mit.edu
Reply to: