Re: lynx-dev Licensing Lynx: Summary (Repost with a few typos corrected)

[RobertM]

It is alleged that Brett Glass once typed:
> At 06:52 PM 10/6/99 +0100, RobertM wrote:
> >I'm sorry to rake over old coals, but this has been REALLY bugging me.
> >Why can't a blind user, or anyone for that matter turn to the
> >internet for help, if thier web browser isn't working?
> Right now, alas, there are many environments (especially UNIX ones)
> where you can't easily do text-to-speech on an arbitrary program.

OK, I've not done much support work under unix that involved 
speech-to-text

> For example, there's no good way that I'm aware of to get PINE to
> speak!

So don't use pine?

> >I would assume they'd still be able to send e-mail ro read news, 
> I wish we could assume that, but we can't. However, with the Web
> browser, it's possible to read news, do e-mail, and more. Getting
> the Web browser working solves a LOT of other problems.

So adding mail reading capability to lynx would be one of your feature
adds? Using an integrated suite of tools is far more sensible than
using single monolithic application. If only because it means that
when one thing goes not everything else goes.

> >which
> >tend to be far more helpful than the web, which is all they could use
> >lynx for, and if they couldn't do any of these things
> >surely they'd be better off talking to thier ISP? 
> Depends upon what the problem is, and if the ISP understands (for
> example) how to fix a DecTalk. Most do not.

Now a really serious question, other than by means of either:
a) a remote access device /* not allowed in many places */
or
b) a third party
how on earth would you do phone support, when the contents of the
screen are unknowable?

If the screen reader is dead then surely call support for the screen
reader, in the same way as if the monitor is dead you call the monitor
manufacturer not your ISP. 


> >What you seem to be selling is support, 
> No -- that's only one of the things we want to offer. We also want
> to license and reuse the code for many applications. Putting your

I would put money on whatever you produce causing serious conflicts
with other already existing screen reading software, unless you are
going to do a total package and go for some serious lock in. Either
way you're going to be in a really bad position.

> work under the GPL means that you are effectively foregoing ANY
> income from it and giving up all control of its evolution -- for
> good. Maybe you could get a little money printing books, pressing 
> CDs, or doing one-off consulting work, but the investment you'd 
> made in the work itself is gone forever.

I disagree with a lot of this, but it's not the debate I'm interested
in having.

> Also, a "selling support" model has another severe problem: the 
> better your work is, the more income you lose because people do 
> not need much support! We want to be rewarded if our code is good, 
> not because it is bad.

This simply isn't true, if the code is good enough people will try to
do more and need different help. Good code just saves you from some
major problems. Users are such invenitve people that support is for
most products/companys a bottomless money pit.

> We also don't want to "nickel-and-dime" users to death. A 900
> support line (besides giving most of the revenues to the telephone
> company) would be too expensive for many of our users, especially 
> those who were unemployed, underemployed, or elderly. And asking 
> for a credit card is equally awkward and inefficient. Better to 
> finance support from the sale price of the product.

So sell support subscriptions, and training. There are loads of
ways to do support that wouldn't fall foul of the traps above. 
Seriously if you think that selling support by any model isn't viable
you've not done your research.
 
[snip more GPL stuff]
-- 
Robm
873
  "Ask not what I can do for the stupid, 
         but what the stupid can do for me" - Graeme Garden