Scripsit David Turner <[EMAIL PROTECTED]> > > Since it's viral, it means you can't take some nifty url parsing function > > from your favourite webapp, and use it in, say, xchat or an IRC bot > > (depending on how you want to interpret "interact with users"), without > > having to give xchat some method of exporting its source code via HTTP > > (or maybe DCC, or similar).
> You could simply copy the (2)(d) code from the webapp at the same time > you copy the URL parsing code. No, you'd have to make sure that the (2)(d) code is *functional* (otherwise the implication would be that (2)(d) allows keeping the code in the application and just removing the call to it), which means that you'd have to extend your IRC bot with a way to listen on some port for HTTP connections, etcetera. I may not even trust the safety of the quine code - in some environments it would be quite reasonable for me to have an internal policy saying that all code that listens for incoming TCP connections must be reviewed for buffer overflows and other problems by N independent programmers that I trust personally. This may mean that I have to audit an awful lot more code than the one I actually wanted to borrow. Another problem: web applications are commonly written in a heterogenous mix of languages. What if the quine functionality was written in a language that I don't have the means to execute - as opposed to the code snippet that I'd like to reuse? > It would be no more of a DOS than allowing someone to simply repeatedly > reload the web page... So. What if I want to modify the program such that there is no webpage to reload, save for the invariant-section quine code? > > under it, you'd be required to make the source code to the entire > > system available as soon as you give anyone else an ssh account. > ... but only to the person you gave the account to Where does the 2(d) language say that? If the existing 2(d) code did not do a password-protection check before serving the source to anyone sending the right HTTP request, it would be hard to interpret 2(d) so as to allow *inserting* a password check in the code. (If I were allowed to insert password checks at will, the purpose of 2(d) itself would evaporate). > As I understand Debian's position, Free Software isn't about > commodotizing technology, but about allowing users the freedom to alter > and share the software they use. Well, that's more the FSF's position. Debian's is traditionally more pragmatic. However, even if we go with your interpretation, the 2(d) clause is invading my right to alter the software I use. > But nobody argued when Brandon proposed that the FSF's Four Freedoms > be the "constitution" of license interpretation, ... becasue the Four Freedoms - apart from what philosophical value people may see in them per se - *also* works well as a practical program for commodotizing technology. Lose any of the four freedoms, and the technology gets less commoditized. -- Henning Makholm "Det nytter ikke at flygte der er henna overalt"