Brian Thomas Sniffen wrote: > 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. My apologies for the sloppy phrasing. s/same medium/same act of distribution/g. The point I was making was that by definition, the same wording for methods of distribution was used in both the hypothetical license and the GPL, because the hypothetical license referenced GPL clause 3 for its methods of distribution. >>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. As I said above, "same medium" was sloppy phrasing; "same act of distribution" is more accurate. >>>>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. >>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. That may be true. Thanks for the suggestion of a better example. :) With that example, it becomes even clearer: suppose you provided complete books a page at a time over SMS, and that those books were GPLed. You would clearly need to provide source for the entire book somehow. You obviously don't want to provide it via SMS; it would be both too large and not useful in that medium. There doesn't seem to be any other way to "accompany it" with some other medium. Therefore, in order to handle this distribution sanely, you would need to use the three-year offer. Yet without the three-year offer option, the GPL would still be Free, just more inconvenient in some cases. >>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? Something editable, and probably something that you can put on a more capable system to edit with. >>>>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? This is a problem with "Accompany it with the complete corresponding machine-readable source code, [...] on a medium customarily used for software interchange" as well; the example assumed the applets or pictures in question were GPLed. The only kind of "accompanying" I can think of for a network transmission would be another network transmission; such a network transmission may be infeasible as explained above. Therefore, this issue applies to GPL 3a; fortunately, one can simply take advantage of GPL 3b/3c and provide an offer. Nevertheless, the GPL would be Free without GPL 3b/3c. So to answer your question, I don't propose to solve these problems right now; providing source to comply with a copyleft license with clauses such as GPL 3a can sometimes be inconvenient, but it is nevertheless essential to do so, and the inconvenience can often be mitigated by clauses such as GPL 3b/3c (despite those clauses not being considered the "free path" through the license). I believe the best way to write a "web application license" would be to start with the GPL, and simply add conditions under which source must be provided, leaving in place exactly the same source distribution mechanisms. This is independent of attempting to "solve" the occasional pathological case with GPL clause 3, since any such solution would apply to both cases. >>>>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. First, it is extremely rude to say "you haven't proposed any", as though I hadn't said anything; more accurately, you just didn't find my examples convincing yet. Second, see the example immediately preceding this quote regarding applets or downsampled pictures, as well as the one before that about transmission of book pages. > 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. I'm not sure what exactly you are driving at here. As long as there is a free path through the license, the license is free. The other paths exist only for convenience. Obviously, if the only possibility was "email to work out a method", that would be non-free. >>>>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. Simple misunderstanding: When I said we didn't need to handle these cases, what I meant was that it was acceptable to not require source in these cases until we could figure out a saner way of handling them; I didn't in any way mean to imply that we should just ignore those cases entirely. >>>>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. Exactly, and as far as I can think of, you can't "accompany" the binary in some other way (since it would need to be "equivalent access" to fall in that category). Nevertheless, the GPL would be considered Free > But if the ringtone is a work by itself, why isn't a wikipedia article? I'm not sure I see your point here; I think my statements are consistent: a Wikipedia article is part of Wikipedia, and a ringtone is (derived from) part of a musical work. In both cases, there is a larger work to which you would need to provide source. (I understand that you disagree with the former case; I assume you don't disagree with the latter case.) >>* 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 (This seems to be incomplete; I assume that the last part was intended to be something like 'is source, with clear indications that it isn't what you want.'.) And if the store runs out of source CDs? Either you provided an offer as a backup (which is not part of GPL 3a), or the store could end up distributing GPLed binaries that are not accompanied with either source or an offer to provide source, in which case they would violate the GPL. (Or they would have to pull the products from the shelf if they ran out of source CDs.) >>* 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. Right; excellent solution. Nevertheless, you agree that distributing binaries under GPL 3a would be infeasible in such a case? >>* As discussed below, distributing a book, handout, or other printed >>material based on a GPLed work. > > Stick a CD in the back. In the back of a five-page handout? In the back of a paperback book with smaller width than a CD? Not everything is that simple. >>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. That is absolutely not what I am saying. In every case above, I am simply pointing out that providing Freedom to the recipients may well be inconvenient or even infeasible under GPL 3a alone. This is not in any way intended to imply that it should be permissible to not provide Freedom. >>>>>>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. Just doublechecking. :) >>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. OK. >>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". I'm not sure I understand what it is you are asking. If you mean "why is the CGI being used and not Apache and the kernel", then the answer is "they are, so if they are licensed under such a license, you would need to provide their source as well; for convenience, you don't have to if they are unmodified". If you mean "why is the CGI being used and not the offline page generator", then that is the fundamental "use" versus "allow others to use" distinction. (Note that for simplifying purposes, I ignored the possibility that the offline page generator was using some GPLed source to generate the page, such as GPLed input to the WML page generator. That case is covered under the standard GPL.) >>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? Yes. This of course assumes the kernel is under such a license, which is a big assumption, and not one that is ever likely to be true, given the large volume of "GPL version 2 only" code in the kernel, as well as the general policy of not letting licenses affect the user-kernel boundary. >>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. Yes to the display system, if it were under such a license. If they did in fact trigger the screen saver (rather than an automated process doing so), then that would be covered as well, if it were under such a license. This same concern, about having to provide source to many layers of programs, applies to the GPL as well: consider what would happen if glibc were GPLed instead of LGPLed, and the kernel _did_ consider the GPL to cross the user/kernel boundary. Then any given program developed on GNU/Linux (ignoring the possibility of arguing that it could work on alternative C libraries and/or kernels) would be a derivative of glibc and the kernel, and would therefore need to distribute them. The "OS exception" would apply in one direction, such that the application's GPL license wouldn't force that distribution; however, the OS exception doesn't apply the other way in the case of GPLed OS components, so those OS components would require the GPLed distribution of anything linked to them. So in this scenario, every time you distributed a GNU/Linux program, you would need to distribute glibc and the kernel as well. However, glibc and the kernel are not GPLed, for various reasons. These similar concerns about "interacting" with a huge stack of software all the way down to the kernel would not apply unless large chunks of infrastructure software changed to the new license (and people didn't just keep using and maintaining the old versions). >>>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. I'm not sure how useful such a requirement is. Clearly you shouldn't be required to provide source if someone sees an error page, but that's more of a special case of "access denied" responses; the same applies to a TCP REJECT. :) > A router doesn't have any private state, so it's easy to simulate it. Many routers do have configuration data. > A CGI program doesn't necessarily fall on either side of this line. The implication being that the program would need to depend either on user input or local configuration, and couldn't just be a stock program to generate the primes less than 1000? What if you hadn't done local configuration, but you had tweaked the source to calculate primes to 2000? :) > 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 think I see what you mean; if I access someone's site and see the Debian Apache start page, I could get the same just by doing "apt-get install apache", so they don't have to give me the source to Apache? But if I access their site and get their homepage, they must provide the source to Apache? I'm not entirely sure I see the benefit. Note, however, that I think for convenience there should be an exception for if you haven't modified the software at all; this might be similar. I see no reason to be required to provide the source to Apache if you haven't modified it, since the entire point of getting access to the source would be to get access to your modifications. Derivative works would be included in this as well, since if you place a library under this license, works that link to that library and interact with a user should require source to be provided. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature