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. 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. >>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. 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. 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. 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. >>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. >>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. >>>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. (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.) (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. * 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. * 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. * As discussed below, distributing a book, handout, or other printed material based on a GPLed work. 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. >>>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. >>>>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). 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. 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). 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. 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. > 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. 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
Attachment:
signature.asc
Description: OpenPGP digital signature