The ASP nightmare: a description (was Re: OSD && DFSG - different purposes - constructive suggestion!)
tb@becket.net (Thomas Bushnell, BSG) writes:
> Jeremy Hankins hasn't explained well enough for me why in that
> future we would be unable to make the kinds of free software we have
> now.
Ah, I wasn't aware of that. I'll see if I can flesh it out a bit for
you.
Imagine a world with omnipresent connectivity, and a lot of copylefted
software. Someone decides that they could make the browser into a
platform (remember Netscape & the MS antitrust trial). So they take
commonly available Free software packages and stick them behind a web
interface. Gcc, tetex, emacs, etc. They lock them down so that no
one can access the filesystem of the server directly via these
packages (and thus gain access to the binaries, say), and charge a
monthly fee for access. Maybe they provide a sort of stripped down
client computer with a browser (possibly all proprietary) that is set
up to use their server for all your computing needs.
Take this to the logical extreme where everybody starts doing this and
every Free program has several ASP versions, and you have the ASP
nightmare.
Personally, I think there are a lot of flaws in this prediction. For
one thing it assumes that single organizations would be able to
effectively compete with the commons in the development of the
software, which I doubt. But it could be argued that whenever Free
Software developers add features to their software they'll just be
"taken proprietary" by adding them to the software behind the web
interfaces. And they can add features with impunity since, without
access to binaries, no one has access to source, so features added to
software behind a web interface will never get added to the versions
with source available. All it would take is someone like MS deciding
they could trust their code to be included in the mix behind the ASP
wall and the scenario becomes somewhat (if not completely) believable.
In the end, reasonable people can disagree as to how likely this
scenario (or one a bit less extreme) is.
--
Jeremy Hankins <nowan@nowan.org>
PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Reply to: