PE>> I write a lot of Public Domain software, practically everything I do
 PE>> at home is.  However, I don't use the GNU compilers, because they are
 PE>> next to useless to me, because I don't have the flexibility of
 PE>> writing commerical software with them, like I have with IBM or
 PE>> Borland compilers.

 RS> OTOH you can argue that that wouldnt worry a completely dedicated PD
 RS> person, who presumably wouldnt be writing anything except PD stuff.

Not true.  I can't distribute the executable as Public Domain for the same
reason that I can't sell the executable - because it is a "derived
work".

 PE>> So I bought the commercial compilers instead, as does practically
 PE>> everyone else I know.  If they were Public Domain, it would be a
 PE>> different issue entirely.  I would become an avid user, and may even
 PE>> make enhancements to it.

 RS> Dunno, IMO a more usual reason for going the commercial route on the
 RS> compilers is just to get more, particularly the fancy stuff like IDE and
 RS> stuff which isnt in the free one.

I personally use the command line compiler, never bothered learning the
fancy stuff, although I did learn the debugger after a long time.

 RS> But many of the PD zealots actually have nothing to do with commercial
 RS> enterprises at all, and are often employed on the public purse in some
 RS> way.

What PD zealots?

 PE>> largely because anyone who writes a program, inevitably starts from
 PE>> scratch. Every single time, everyone who writes commercial software,
 PE>> starts from ground zero.

 RS> True, it is a very fundamental limitation. OTOH its not quite that bad,
 RS> you do now see the compilers provide user interface tools for the stuff
 RS> being developed. Thats pushing a complete layer of stuff down into what
 RS> you start from with a new product. And is almost completely missing from
 RS> the PD products at this time. So in some ways the commercial products
 RS> allow you to start further ahead, quite the reverse of your point.

PD can be added to commercial stuff, you don't have to scrap the commercial
stuff that helps.

 PE>> If you want to see the commercial software you use on a daily basis
 PE>> to be advance a lot quicker, then what we basically need to do is
 PE>> give the developers a non-zero starting base.

 RS> I'm not convinced it will have much effect on commercial products at all
 RS> myself. What it can do tho is advance the capability of the PD stuff
 RS> available.

Ah, but this is where you're wrong.  Both GoldEd and MsgEd/SQ are
copyrighted. Both were based on code from MsgEd, which was Public Domain.

 PE>> If we have a public domain spreadsheet program, then they can pick
 PE>> that up and start coding on top of it.

 RS> I cant see any commercial operation ever doing that tho. Many wont even
 RS> actually use a true PD compiler for various reasons.

Another mistake.  One of the guns from Software Development (makers of
Netmaster) was saying that they had to write in assembler because of
performance reasons.  He said it would be a different matter if they had a
C compiler in source code that they could play around with themselves.

 PE>> That way when you go and purchase their product, all the money you pay
 PE>> goes into the development of something NEW, instead of what's already
 PE>> available in the PD.

 RS> Cant argue with the advantage, just argue about if it will ever happen
 RS> like that. IMO it wont.

Well the first thing to decide, is whether it is POSSIBLE.  If it is
possible, then whichever companies don't take the "lowest cost"
route, will go bust. Naturally the PD stuff needs to be easy to use, and I
can assure you that at the moment, Tobruk is NOT easy to use as a set of
APIs, whilst the MSGAPI routines that Scott Dudley wrote are.  Basically,
for something to be usable, it needs to have a set of interface specs for
the C routines, just like you see in the ISO C standard.  My error handling
routines have this in the comment block of the error.h.

 PE>> Basically, anything you don't want to pay for, make sure it's in the
 PE>> PD!

 RS> Bit of zealotry and fanaticism creeping in here |-)

 RS> Its got some very real practical problems. Just take a C compiler now.
 RS> Currently the only choice you have is a copyleft or commercial. So even
 RS> if the ideal is beaut, reality is something else entirely.

So?  How does this weaken my case one iota?

 PE>> E.g. I am writing a mailprocessor at the moment.  It is public
 PE>> domain. There are other non-pd mailprocessors around (all of them I
 PE>> suspect). Well the mailprocessor I have (TOBRUK), doesn't have a
 PE>> fancy configuration program.  I don't like writing such software, but
 PE>> most people like using it.  Hopefully someone will see a commercial
 PE>> oppurtunity, and take Tobruk lock stock and barrel and put a fancy
 PE>> iterface on it, and sell it as their own.

 RS> Want to make a small wager on that ever actually happening ?

You mean like they did with GoldEd and MsgEd/Sq?  Also included in that
package is getopts() and error-handling.  Actually, I've included trav() in
there too. I suspect others will use parts of this.  Actually, I think Paul
Markham is already using dtsplit(), which is another sub-part of it.  I'm
not sure how he knew he could use that though, as I don't recall there
being a decent interface spec to it.  Although there could be, there's more
comments than code in it.

Paul

--- GoldED/2 2.42.G1114