Re: The Affero license
Scripsit David Turner <novalis@novalis.org>
> > 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"
Reply to: