Re: LCC and blobs

[Henning Makholm <henning@makholm.net>]

Scripsit Anthony DeRobertis <anthony@derobert.net>
> Henning Makholm wrote:
>> Scripsit Anthony DeRobertis <anthony@derobert.net>

>>>That would, however, cover firmware and wind up sending X to
>>>contrib. So maybe: ... iff it is stored on the local machine's file
>>>system.

>> That would be my *intuitive* understanding of how the mail/contrib
>> difference works.

> So would a web-based firmware loader, that never saved the firmware to
> disk allow the drivers to be in main?

Hmm. Maybe. If it was properly documented in the package description
for the driver that its proper function relies on an external website
that the user presumably has no control over, then perhaps. But I
don't think I would be really comfortable with it.

The line is difficult to draw in the area of relying on external
services.

At one end of the spectrum is cases where what a typical user really
wants to use is the external service; he knows that the service is
external and views the client as a mere conduit to access something
that he knows he does not control. I _think_ everybody agrees
intuitively that such clients can be in main. The canonical example
would be a client for proprietary IM systems, but the situation is
somewhat similar with, say. IRC clients. Even though main does contain
IRC server software, the vast majority of users want to connect to
existing external IRC networks, so having the source does not really
help them control the service that they use. Yet nobody would suggest
that the client does not belong in main for this reason (except
perhaps as part as a reductio-ad-absurdum argument about the true
meaning of the SC).

Things begin to get murky when the client provides a local service
that is useful in its own right, and only incidentally needs to
contact external network sites to provide it. One could imagine an
anti-spam tool that submitted checksums of message fragments to a
central server for correllation with other user's data. (Never mind
that such an anti-spam measure would probably not be effective, at
least not if it became popular). Or one could imagine a heuristic
keyword extractor for plain text files which, behind the scenes,
queried Google to find out how common cetain phrases. In these cases
the user is not primarily interested in interacting with an external
service but is probably still aware that the quality of the results he
gets owe something to the use of external resources.

At the extreeme other end is situations where the net service the user
actually wants ("I want to scan this photograph with my WinScanner")
has no *extrinsic* reason to require a non-local resource. Web-based
firmware loaders belong here.

I have definite qualms about including something of the latter
category in main, but I am not sure that I can support this judgement
with deductions from a short clear-cut definition of what each word in
the SC and Policy means. However, I don't think that such a deductive
development is a necessary requirement for which policy the project
should adopt. Bright-line tests are overrated anyway.

-- 
Henning Makholm        "Jeg køber intet af Sulla, og selv om uordenen griber
                    planmæssigt om sig, så er vi endnu ikke nået dertil hvor
                   ordentlige mennesker kan tillade sig at stjæle slaver fra
 hinanden. Så er det ligegyldigt, hvor stærke, politiske modstandere vi er."