Re: Web application licenses

[Brian Thomas Sniffen <bts@alum.mit.edu>]

Josh Triplett <josh.trip@verizon.net> writes:

> Brian Thomas Sniffen wrote:
>> 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.
>
> You're taking one part of my message out of context, and analyzing it
> without considering the rest.  I'm saying that the GPL has the same
> clause as the hypothetical license would, which is true by definition,
> since in the hypothetical license, I incorporated the GPL clause in
> question (3) by reference; I did not intend to suggest that "on the same
> medium" was the *only* option.  There would be a full set of clauses
> that would parallel GPL clauses 3 a-c, so one could either accompany the
> binary with source, or distribute an offer.

But the GPL doesn't *have* a "same medium" clause at all.  There's
nothing like that in the GPL.  Some poster back there -- I can't tell
through the quotes -- wrote that "on the same medium" is non-free.
You countered that it isn't, because it's the same as the GPL.  But
the GPL doesn't have that at all.

> I was simply drawing a similarity between the "free path" of the GPL and
> the hypothetical license, for the purposes of showing below that both
> can cause severe inconvenience.

Please highlight the section of the GPL which you believe is similar
to this, including the text which talks about source being distributed
on the same medium.

>>>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.
>
> I'm referring to the content being served.
>
>>>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.
>
> (You seem to have switched from SMS to WAP.  I'm going to stick with the
> SMS example for now.)
>
> First, it is quite a stretch to say that one page of a
> heavily-hyperlinked and interwoven encyclopedia is an independent work.
> To do so, I believe you would be implying that Wikipedia is merely an
> aggregation of a number of separate and independent works, which I do
> not believe is accurate.

No, I'm not implying that at all.  You're providing one part of a
larger work, but when you separate it out by itself, sure, that's a
work too.  Articles in a normal encyclopedia are often credited to
individual authors.  It's not a mere aggregation of separate and
independent works.  It's a combination of integrated and dependent
works.  Sets of articles are interesting on their own; often, a
singleton set is interesting.

>  You're simply providing one part of a larger
> work, and it is that larger work that you should be distributing the
> source for.  Also consider what happens if you make a full-text search;
> the results page would be a derivative of quite a number of pages, and
> their sources would be far larger than that results page.

The results page is not a derivative work, and has no creativity in
the results presented.  It's probably fair use of the pages
referenced, anyway.

> If you had truly taken Wikipedia and abridged it, creating a new work,
> which you then distributed, then it would be acceptable to distribute
> only the source for your new work.  However, that is not what you are
> doing here.  Instead, you are taking a larger work and serving pieces of
> it at a time.

Perhaps you'd be more convincing with a different example, like a
normal book.  But an enclopedia is so clearly composed of many works
precisely because it is useful to look at individual articles.

> Furthermore, even if it *were* acceptable to distribute only the source
> to the single page being served, you still would not be providing it in
> a particularly usable or useful form, and you would, at a minimum,
> double the number of messages required.

Well, what would be a useful format for source for those pages, then?

>>>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.
>
> The full source code for an applet, or for that matter, a downsampled
> video or picture, would likely be significantly larger than the applet,
> video, or picture served to the phone.

Indeed.  You have identified a major problem of the "same medium"
clauses mentioned above.  How do you propose to require source in a
way that doesn't have those problems?

>>>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 think that for almost any copyleft license (or license of similar
> complexity to a copyleft license), it is possible to find or invent
> pathological cases where a requirement such as providing source would be
> a huge burden, perhaps enough to prevent distribution in that case.  I
> believe this is true of the GPL and LGPL, as well as the hypothetical
> license under consideration.

Then it should be easy for you to provide such an example for the GPL
or LGPL.  I believe you that such cases might exist, but since I can't
think of any and you haven't proposed any, I think it's unlikely.

Therefore, I'm inclined to say that there are no such cases, and that
this is a useful criterion for distinguishing free licenses.  It's
easy to prove me wrong with a counterexample, if I am wrong.

>>>>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"?
>
> Exactly; that would work as well.

Hm.  So how about a license which requires that, if anybody contacts
me and shows <proof of having used a copy of the software which I
possessed at the time>, I must provide source.  Well, it's got the
hanging-weight problem, so that can't be the free path.  Hm.

> (An interesting side issue that this point raises: it is well-accepted
> that "contact me before you distribute" is non-free, but if a piece of
> GPLed software is accompanied by the three-year offer, then in order to
> make use of their freedom, a user would need to contact the distributor.
> Perhaps this is free because only the first person needs to do this,
> and then could supply the source without this requirement; or perhaps
> this is just another symptom of the three-year offer not being the Free
> path through the GPL.)
>
>>>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.
>
> While I do believe such cases would be useful to deal with, and the user
> of such works should still be able to have the freedom to
> use/copy/modify/distribute them, I think it is reasonable to rule them
> out due to the inconvenience of handling them.  (At least until a much
> more innovative license idea comes along that can handle these cases
> more sanely.)

I do think it's important to handle these cases now.  The licenses in
Debian all handle those cases just fine right now; you're suggesting
that something can be a free software license without handling those.

What about GNU Bayonne?  That's software already in Debian; I think
any license you claim is Free should be applicable to any software in
Debian and still be clearly free.

> (Although, sticking a "fine print" sticker on a light pole or an
> elevator panel would not be difficult.  Nevertheless, I agree that we
> should not attempt to cover these cases for now.)
>
>>>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.
>
> Actually, there are various standards for sending "binaries" through
> SMS, for the purposes of ringtones, images, and similar.  Furthermore,
> it is quite possible that a ringtone could have been created from a much
> larger composition, or that an image could have been scaled down and
> reduced in color starting from a high-resolution image.  Consider the
> issue of supplying source in those cases.
>
>>>>[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?
>
> I believe I have sufficiently clarified the examples above so that they
> do still apply.
>
> If you want further examples, consider the following:
>
> * Distributing ringtones or images created from a much larger GPLed
> work, as described above.

SMS is not a medium customarily used for software exchange, so if you
want to distribute a GPL'd ringtone, you have to give the source to
the recipient some other way.

But if the ringtone is a work by itself, why isn't a wikipedia article?

> * Distributing any embedded binary (such as a firmware image on a piece
> of hardware) based on a GPLed work.  Supplying the source in the
> embedded system would likely be difficult or impossible; the alternative
> under GPL 3a would be to supply an additional medium such as a CD.  This
> might be feasible in the case of a router, but consider much cheaper
> consumer electronics, with much smaller margins.

A CD is pretty darn cheap.  If you're selling hardware, including a CD
is reasonable.  Alternately, give ten CDs to the store with each
thousand whatzits, and a dispenser offering the CD free with a
whatzit, noting that all it contains is 

> * Even normal electronic software distribution can become more difficult
> or even impossible: on one site for information on the Linksys WRT54G
> GNU/Linux-based router, there are cases of people who would like to make
> a firmware image available, but do not have the resources to host a full
> copy of the source (which is far larger than the image), and so they
> cannot supply the binary firmware image, only a patch for people to
> build the modified image themselves, which is far less convenient for
> end-users.

But any other person can build the modified image and distribute it
with source, so that's OK.  The person in your example might even
negotiate with one such entity to do distribution for him,
distributing a binary and source to that one person, then have him
distribute further.

> * As discussed below, distributing a book, handout, or other printed
> material based on a GPLed work.

Stick a CD in the back.

> In all these cases, GPL 3a alone ranges from highly inconvenient to
> impossible.  This is most likely the primary reason the offer option is
> included in the GPL.  Nevertheless, even without the offer option, the
> GPL is a Free Software license.

Yes.  What you're really asking for in the examples above is a way to
distribute without giving freedom to the recipients; that's not an
interesting case for free software analysis.

>>>>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.
>
> However, a handout, unlike a projection, is distributed, just as a book
> is distributed.  It might be inconvenient to provide source in that
> case, but that doesn't make it reasonable to not do so.

Well, right.

>>>>>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?
>
> That's actually basically what I had in mind when I initially suggested
> that "interaction" is an important distinction.  However, if the SMS
> service is triggered by sending it a message, I would definitely define
> that as interaction.
>
> I'd prefer not to define interaction that way, though.  Consider for
> example that many interactive programs are not particularly
> "predictable" even if you do know the input (unless you count PRNGs or
> hardware RNGs as input).

Yes, I phrased it the way I did and not the converse on purpose.

> I think that trying to supply an exact definition for interactivity will
> start becoming too technology-specific, as well as either too broad or
> too narrow.

My definition was based on information theory in an attempt to avoid
technology-specific definitions.

> I do think the "use" versus "allow others to use" distinction is a key
> point, and almost a sufficient definition for interaction by itself.
> For example, if I use a program to generate an HTML page (assuming the
> output is not a derivative of the program), which I manually save (not
> triggered by any user action), and later distribute, that is no
> different from using Emacs to write an HTML page: in neither case should
> I be required to distribute the software used to create the page
> (although I might still be required to provide the software that serves
> it).

How are these different, the page generator and the http protocol
generator and the kernel packet generator?  I do not understand why
only the middle one is being "used".

>  However, if, in response to user action, a CGI program generates a
> page and a web server distributes it, the user is interacting with
> those pieces of software, and should be entitled to the source of
> those pieces of software and freedom to use/copy/modify/distribute
> them.
>
> It is not the fact that the user receives the output of the program that
> entitles them to source/freedom for that program; the license of a
> program does not cover it's output.  It is the fact that the user
> requested that output, and in some sense *used the program* to generate
> it, even if only minimally by simply triggering the process.

So the kernel does have to be distributed?  The user triggers the
process of opening a TCP connection, right?

> For another example: if I give a presentation using software under this
> license, that does not entitle people to source/freedom for that
> software.  If I use such software to create a kiosk with a set of
> presentations, where the user can select one and play it, then they
> _are_ entitled to source/freedom for that program.

But not to the display system or the screen saver, even though they
triggered those?  I just don't see the boundary.

>> 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?
>
> Can you clarify this further?  As I'm reading it, that would rule out
> almost any useful case, since in most cases, the whole *point* of
> getting access to the source would be so that you could set up a similar
> installation yourself.  You seem to be saying that the results must not
> be reproducable.

They must not be reproducible without access to your instance of the
software.  For example, if MediaWiki were under such a license, I'd be
entitled to a copy from the Wikipedia folks when I got an article, but
not an error page.  That's because the error page is part of the
software, but the content is part of the state of their installation.

A router doesn't have any private state, so it's easy to simulate it.
A CGI program doesn't necessarily fall on either side of this line.

The point, as far as I can tell, is to set up a *similar* installation
without it being the *same* installation.  If you can already set up
the same installation, by predicting the output of the original, then
you aren't really using or interacting with it, it's just a mirror for
you.

> I do agree that it would introduce many complexities to cover routers.
> However, it is difficult to construct a requirement that would require
> supplying the source to a web server and a CGI program, but not a router.
>
> (One big reason why I'm quite amenable to compromises that exclude
> certain of these cases is that we currently cover _no_ cases, so if a
> new license covers _some_ cases, that's better than the current situation.)
>
> - Josh Triplett
>

-- 
Brian Sniffen                                       bts@alum.mit.edu