Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)
On Sat, 2002-07-27 at 19:10, Lars Hellström wrote:
> At 27 Jul 2002 09:50:54 -0700, firstname.lastname@example.org (Thomas Bushnell, BSG) wrote:
> >However, more to the point, free software is about particular
> >freedoms. In the instant case, the freedom I'm asking about is a
> >freedom to modify and distribute the program, something that both the
> >DFSG and the GPL highlight as a crucial freedom.
> >You might think we shouldn't care about this freedom, but we do, and
> >if we don't have it, then it can't be part of Debian.
> The relevant question is however whether the restrictions imposed by the
> LPPL are severe enough to make it DFSG-unfree (while keeping in mind that
> the (current) GPL is by definition DFSG-free). It occurs to me that a
> better way of demonstrating that a certain amount of restrictions are
> allowed might be to look at condition 2c in the GPL:
> c) If the modified program normally reads commands interactively
> when run, you must cause it, when started running for such
> interactive use in the most ordinary way, to print or display an
> announcement including an appropriate copyright notice and a
> notice that there is no warranty (or else, saying that you provide
> a warranty) and that users may redistribute the program under
> these conditions, and telling the user how to view a copy of this
> License. (Exception: if the Program itself is interactive but
> does not normally print such an announcement, your work based on
> the Program is not required to print an announcement.)
> Suppose I had written a shell-like program for, say, trading with stocks or
> something like that and that I've put it under the GPL, and that it "reads
> commands interactively when run" as described above. Following the
> instructions in the GPL on "How to Apply These Terms to Your New Programs"
> I make it print a bunch of information such as described above when
> started, so that the exception will not apply. Suppose then that Thomas
> would like to modify my program so that he and his friends can use it as a
> login shell on some server and that they normally communicate with this
> server by SMS sent from or to their mobile phones. Suppose further that he
> would like to remove from the announcement some of the above information
> since all of it cannot be fitted into a single SMS (or perhaps he feels
> that such a large SMS would be too expensive). Since he claims "a freedom
> to modify _and_ distribute the program", he also gives a copy of the
> modified version to a friend.
> There is however a catch: the GPL won't let him. This functional change is
> expressively forbidden by the above clause in the license. I'm not sure
> whether he is forbidden to make the modification in the first case or just
> forbidden to distribute this modification, but he wouldn't be meeting
> condition 2c. It makes absolutely no difference that he and his friend both
> want it this way---unless I approve of it separately, they're violating the
> license and consequently lose their right even to use the program.
This is not true.
If you've modified the program in such a way as to respond to SMS
queries directly, then you've modified the program such that it no
longer "normally reads commands interactively when run". Specifically,
the SMS messages are stateless, and there is no correlation between
If you've written a terminal emulator that works over SMS messages
(yuck!), then sure, you're right. But, in that case, you're asking for
huge charges, bandwidth, etc. anyway. It would be wrong to modify the
program to not display the legal messages just for the sake of SMS
savings. Besides, as mentioned above, you can get around the problem by
making the program drive SMS directly.
> So how is that a significantly smaller restriction than that of not being
> able to distribute Non-LaTeX claiming to be LaTeX?
Because messages required by the GPL have zero functional content. They
do not affect how you start the program, how other programs start the
program, what icons or menu items may say or not say in a GUI, etc. All
of these functional elements are affected by a filename change.
This argument has nothing to do with the DFSG, by the way, as the DFSG
specifically allows the requirement to rename.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org