source access vs dynamism

356 views
Skip to first unread message

Erik Naggum

unread,
Aug 23, 1999, 3:00:00 AM8/23/99
to
once upon a time, I was very much opposed to Free Software on a variety
of political grounds. then I thought that it could do a lot of good,
partially motivated by seeing a lot of problems that came with lack of
access to source code. these days, I largely think both Free Software
and Open Source are very serious mistakes, because they don't solve the
core problems, they make them much, much worse.

suppose one operating system (or language) lets you open an already open
file by calling OPEN or whatever on the open stream. since this is
clearly beneficial to anyone who can do it, let's assume people start to
do it and demand the same functionality elsewhere. one easy way to do
this is to use a function other than OPEN to do this, but this does not
scale well: every request for a feature would need a new OPEN, and you
would have to decide _which_ OPEN to call both in your code and in the
implementation of the new functionality. clearly, this is a very messy
situation and migration from one system that did support a feature to one
that did not would be a function of the number of features people might
have added. this problem would be solved if people had the source and
could fix things themselves and then channel the fixes back to a central
place that could "take over the world" with better versions. consider
the Unix way, which used to have the function call DUP, but recently has
/dev/fd/<N> -- you can fake /dev/fd/<N> with DUP, but to do that requires
getting under the skin in OPEN and parsing a file name and all sorts of
cruft that the file system code would normally do. ugly, but it would be
necessary, right?

the reason that source access is needed is the same as the cause of the
problem: the inability to modify system behavior non-intrusively. if one
could modify OPEN on any given system to acquire new behavior _without_
compiling a new OPEN or, even if you did, without re-linking the entire
system (thus the need for dynamic linking and similar solutions, too),
source code access would be entirely immaterial.

so suppose you wanted to wanted to add DUP functionality when OPEN was
called on /dev/fd/<N>. you could grab the old OPEN definition and call
it anonymously, while redefining OPEN to be your particular function,
which acted only on a match to such pathnames, or you could redefine OPEN
once and for all and add your stuff via a well-defined hook system, or
advice or whatever. whether you would try the new thing first or only
after trying the argument the old way had failed would be an orthogonal
design decision, subject to how easy error handling is and the expected
frequency of failures. this way of doing things would in any case cause
a few simple improvements over static source: (1) the core system could
upgrade its OPEN without the need to migrate the changes. (2) if you did
it right, you could also inspect, add, remove, and reorder your changes,
and you wouldn't need the source for either of these operations, either.
(3) bugs introduced by changes could be fixed the same way the changes
were put in place, as opposed to rebuilding the system with the previous
version of the dynamic library or whatever didn't fail. (4) you could
communicate your desire for a system-wide improvement to someone who
could put it in the official sources and you could add your changes
conditionally.

compare this to a world where no dynamism is available and people don't
think in dynamic terms, anyway. you need to make OPEN change behavior so
of course you need access to the source! you want this functionality
everywhere, not just in particular programs, so of course you need the
ability to modify it and rebuild from scratch! since this creates a
maintenance nightmare, of course you want your changes to be part of the
core system, too. to get that to happen, of course you need to be part
of a huge movement where people compete with eachother for features they
think they need and the best way to implement them. this is incredibly
exhilarating, so of course this is the solution to all the world's many
problems with missing features in software.

suppose you drive down the highway and you suddenly want to go some nice
place you saw just before you pass a forest. you veer off the road,
plunge into the wilderness and promptly decide that you need four-wheel
drive, a huge cutting device in front of your car, much better shock
absorbers, a bigger engine that could actually run on swamp water instead
of getting all drowned, and then need an amphibious vehicle to get across
the river on the far side of the forest. you can't get all that right
away after you made up your mind to veer off the road, and This Is Surely
Somebody's Fault, so now you start this big protest movement to have auto
manufacturers use Open Car Design by making your own cars and giving them
away so people can modify them. the obvious morale of this story is that
it would have been a little smarter to see if there were another way to
get there over existing roads or ferries or whatever, even if that would
cost a lot less and be faster if not Your Way Right Now, and which didn't
need all this add-on stuff to your car, and perhaps you would just get
there instead of getting all worked up about all the neat stuff that
other people had done to their cars while claiming that if it weren't for
Open Car Design, they would actually never have gotten where they are,
and they sure wouldn't have built this very versatile car, which they
talk about a lot more than where they have used it and for what. suppose
someone adorns a commercial vehicle with a proprietary navigation system
that let you discover any and all ways to get from point A to point B by
talking to it, including scheduling and cost estimates so you could
decide whether it was worth it, but refused to give it away to Open Car
Designers. why would anyone who weren't more interested in building cars
than Getting There insist on home-made Swiss Army Cars with Open Car
Design when the _real_ goal had become attainable? why would Open Car
Designers _not_ call the producer of the navigation system and find a way
to deploy it almost everywhere? and would they insist that a home-made
navigation system would be better than buying it from whoever invented
it? although a ridiculous example, I don't see why anyone would insist
on a way to do things that does not solves the real problem, but rather
solve an ancilliary problem that is a problem only because someone is
very stubborn.

I keep wondering when and under which conditions the models employed by
Free Software and Open Source make sense. I don't think it makes sense
when the design is _already_ flexible and open and so malleable that it's
used as an argument against it by the very same people who want to change
everything, but only Their Way. in other words, if all you have is Unix,
certain problems are so staggeringly tall that it takes an extra special
genius to see what the _real_ problem is because all the people who are
trying to climb it make it look as if doing something else is stupid. if
you have, say, Common Lisp and good access to the exposable parts of the
internals, with advice support, hooks, etc, why do you _need_ the source
code? not that it wouldn't be useful, but would the demand be as great
if the Smart Route to Yonder Place was at least available to intelligent
people instead of requiring everybody to scale every mountain just to
prove a point about inaccessibility?

the problem is that scaling such mountains is much more fun than actually
doing anything useful with computers. mostly, computers are used to do
Really Boring Stuff, especially if you don't have any dynamism, either,
and if you're young and getting into computers because it is supposedly
exciting, you discover that writing quality software for real people is
tremendously hard and the real rewards are pretty far apart in real life,
so it's a lot more fun to spend one's time cutting another cycle off an
interrupt handler or bolt another semi-dynamic feature onto a system as
flexible as a block of granite.

the solution is dynamic _software_, but Open Source (etc) is the best way
to ensure that this never happens on a large scale, because a pale shadow
of the dynamism people actually need is immediately achievable using the
static model that people accept without question through fixing a source
file and recompiling. ever better ways to overcome this inherent problem
are created, such as Java and interpreted languages, dynamic linking and
lots of nifty features. to help people _find_ the solution, however, we
need to show them that the problem is aggravated by the way they think
they are solving the problem today: by making the static software model
even more entrenched and unmaintainable.

I think Free Software and Open Source addicts will get down from their
current high and become tremendously frustrated when the obvious problem
of having millions of pieces of source code available and they actually
can't move in any direction because the ability to make modifications
that they have so lauded in the past turn into a very serious problem
when much bigger problems require modifications to much larger systems
than the ones people today think are usefully modified locally.

I predict that "migrability" will be the one factor that causes people to
choose dynamic software over static software, however modifiable, because
while the software has been the most valuable for a long while (because
of its cost of development), the data we stuff into the programs and ask
them to safekeep for us will be so much more valuable than the software.
static software is totally unable to deal with graceful migration and the
need for the cost of changes to be linear in the size of the changes.

however, writing "migrable" software is not a task for novices or people
who are not fully aware of the impact of their decisions, and I think
that too much access to source code will cause a lot of people to be
exceedingly good at stuff that is antithetical to long-term solutions.
it seems that programmers need to be made as aware of the problem of not
killing the patient while fixing some problem as the medical profession,
because as long as the static software world considers "crash and reboot"
to be an option, we won't get anywhere worth going.

Free Software and Open Source may well be the last gasp of the static
software world and its "success" may well cause companies who believe in
static software to fail while users betray their own long-term needs in
exchange for the smidgeon of dynamism that source code affords. in the
long run, software that adapts and can migrate from one half-expressed
need to another as real users discover what they actually want, _should_
win. resisting the sometimes attractive non-solution of unrestricted
source access and full modifiability may be the only way to get what we
really need.

#:Erik
--
save the children: just say NO to sex with pro-lifers

Howard R. Stearns

unread,
Aug 23, 1999, 3:00:00 AM8/23/99
to
Let me summarize Erik's argument essay as this:

1. Free software and open source are a poor way to adapt and grow
software.
2. Dynamic mechanisms that don't even require access to source are
better.
3. Eventually the world will see this.

My measure of agreement diminishes in the same order.

Erik lists a couple of dynamic mechanisms that provide better
adaptability. My personal favorite, which was not explicitly
mentioned, is the the "Open Implementation" work done at Xerox PARC by
the CLOS-MOP people. (http://www.parc.xerox.com/spl/projects/oi/) It
is worth noting that OI is still an area of RESEARCH. There are
problems with it. We don't know much about how to design OI
protocols. We don't even know much about how to DOCUMENT the
protocols we've got.

Consider, for example, that even amongst Lispers, many of whom
subscribe to OI philosophies, that CLOS STREAMS is still not
standardized and not wholly adequate for all the uses people hope for
it, and that CLOS PATHNAMES hasn't yet been designed. Similarly for
OI environments, compilers and debuggers. (Indeed, most mention I've
made of such things on c.l.l has been answered by more silence than
enthusiasm.)

This stuff is hard, and the existing technology doesn't solve all the
worlds problems, though it does help some.

So does free software and open source.

We're familiar with Dick Gabriel's "Worse is Better" argument (from
http://www.ai.mit.edu/docs/articles/good-news/good-news.html). Gabriel
points out that under the right circumstances, something that gives us
some of what we want can be more successful, and by some measure,
even "better", than something else which addresses some specific issue
in
a fundamentally more direct, complete, or consistent way.

Open Source is a "worse is better" approach to Open Implementation
(and to dynamic systems in general).

Open Source works (though not well). It is successful (but it's not
clear how general or sustainable). Its hard to argue with success.
The fact is, that Open Source is CURRENTLY meeting the immediate needs
of more computer users than dynamic systems such as Lisp are.

I completely agree that more needs can ultimately be met by dynamic
systems such as Lisp. The issue is getting there. Open source and
free software does meet this need more directly than dynamic systems.
If you need something, you can start with an EXISTING, AVAILABLE,
WORKING thing and modify it to do something else. One problem with
Lisp is that there is so much that is not quite existing, not easily
(cheaply) available, or not quite working.

Barry Margolin

unread,
Aug 23, 1999, 3:00:00 AM8/23/99
to
I used to do system programming on Symbolics Lisp Machines; a big part of
my job was customizing the system for our users' needs. As commercial
operating systems go, it was probably one of the most modular (just about
everything was implemented using Flavors, a predecessor to CLOS) and
dynamic. I managed to achieve quite a bit using all the hooks that the
system provided (I used ADVISE pretty heavily, and implemented Ethernet
trailer support by defining appropriate flavors).

However, even with all this modularity, I still relied on source code.
First of all, when using ADVISE you have to know what to advise -- often it
was internal, undocumented functions. The networking API that I hooked my
trailer code into was also not documented.

There were also many thing that I needed to do that I could only do by
modifying functions. If there's a place in a function where it does (+ x
y) and you need it to do (- x y), there's no practical way to do that
without replacing the function definition.

Object orientation and dynamism generally only work well if the designer of
the system can anticipate where people will need to customize. He then
documents an API appropriate for customizing those places. But if someone
comes up with a need that he didn't think of, often the only way for them
to implement their changes is by hacking the source code.

One other thing: this whole argument only applies to customization. Much
of the benefit of open source is the ability of anyone to implement bug
fixes and general evolution of the code. Emacs is a reasonable example os
a system that has balanced the two ways that programs change. If someone
wants to change the way the garbage collector or redisplay works, or add
support for floating point numbers, this is done by modifying the code in
place; however, Emacs's dynamism was used when they wanted to add web
browsing capability. Sometimes both need to be done: often while
developing an external package you discover that it would work better if
there were a hook in a new place, so you make that one little change to the
guts.

--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

Christopher R. Barry

unread,
Aug 23, 1999, 3:00:00 AM8/23/99
to
Barry Margolin <bar...@bbnplanet.com> writes:

> There were also many thing that I needed to do that I could only do by
> modifying functions. If there's a place in a function where it does (+ x
> y) and you need it to do (- x y), there's no practical way to do that
> without replacing the function definition.

(let ((y (- y)))
...
(+ x y))

Or something.

Christopher

Barry Margolin

unread,
Aug 24, 1999, 3:00:00 AM8/24/99
to
In article <87wvumf...@2xtreme.net>,

That's what I mean. There's a function that currently looks like:

(defun do-something (...)
...
(setq z (+ x y))
...)

How do you insert your "let" form without rewriting that function? And how
would you do that without the source code to that function?

Symbolics's ADVISE actually provided a way around this in some cases; you
could do something like:

(advise (func1 :within func2) ...)

and the advice would modify FUNC1 only when it was called by FUNC2.
However, this doesn't work for open-coded functions like + (in fact, you
can't generally ADVISE them at all).

Erik Naggum

unread,
Aug 25, 1999, 3:00:00 AM8/25/99
to
* Barry Margolin <bar...@bbnplanet.com>

| However, even with all this modularity, I still relied on source code.

I thought I had already covered the value of source access to people with
real needs. in your case, doing systems programming as your job is
certainly within the realm of licensing the source, and I can't see why
this is an argument for full source access with unrestricted rights to
modify and redistribute modified code to essentially random people, which
is what I'm arguing against. again, I'm all for source access, but only
to those who actually need it and commit to using it constructively.

| First of all, when using ADVISE you have to know what to advise -- often
| it was internal, undocumented functions.

well, I modified Allegro CL's pathname behavior long before Franz Inc
shipped the sources to these particular files to all supported customers,
and all I had was a good grasp of the SPARC assembler and the standard
functions that let me peek at the actual running code. Franz Inc has
since started shipping most of the "surface code" to supported customers,
and it's easier to change a function, except that when upgrading, retro-
fitting fixing becomes more risky than making the initial fix.

| There were also many thing that I needed to do that I could only do by
| modifying functions. If there's a place in a function where it does (+ x
| y) and you need it to do (- x y), there's no practical way to do that
| without replacing the function definition.

communicating with the people who own the source would solve this
problem, and there is still no need to require unrestricted rights to
modify the source. having that right, however, means you won't find the
need to communicate with the owners of the source until you're really
pissed at something you can't do yourself. if you think this is an
exaggeration, read GNU Emacs bug reports for a while -- a pattern emerges
where those who think they have rights tend to demand instead of ask.

| Object orientation and dynamism generally only work well if the designer
| of the system can anticipate where people will need to customize.

yes, and that's the point: if we never get any practice in anticipating
it or feel the consequences of our mistakes, neither will be ever become
good at it, and the less well-designed software is, the bigger the "need"
for unrestricted source access. the more people have access to source,
the less they will be interested in more modular designs or ways to fix
things. by giving random people unlimited source access, you may tell
them, if not in words, then in the consequence of what you accept and
implicitly encourage, that end-user customization is a subordinate need
in the software as delivered.

| But if someone comes up with a need that he didn't think of, often the
| only way for them to implement their changes is by hacking the source
| code.

of course, but why should the implementor of such changes _have_ to have
(1) the automatic _right_ to access the sources, (2) the automatic right
to distribute it further to others without the owner's approval, and (3)
the right to distribute his modifications? if you want to make something
new, I really don't see why building on the works of the past has to mean
that the works you create must be modifiable by anyone even before you
know where you're going with it.

| One other thing: this whole argument only applies to customization. Much
| of the benefit of open source is the ability of anyone to implement bug
| fixes and general evolution of the code.

when this happens in cooperation with the owner of the code, it is good.
when it causes a myriad of independent fixes to the same problem and
branches into a variety of incompatible "products", we have instead of
causing people's creativity to be employed usefully, failed to contain
the biggest problem inherent in the free market, that it costs too little
to fragment the market. look at Unix. it was essentially open source
before anyone invented the term, and that caused a large number of ways
to solve the same problem and left the market to sort them out, which
they didn't (the market never will sort out bad quality in anything but
the single most important property of the products), and Unix got itself
into a position where some horribly demented crapware from Microsoft
could compete with it and fool a whole bunch of people for a while.

Linux is a success because it is well _managed_, not because it is Open
Source. whether people would have to sign an agreement to get access to
the source and be allowed to fix things or not is immaterial: people who
want to commit serious work to GNU Emacs must already sign an agreement,
and that hasn't stopped GNU Emacs from succeeding, either.

it appears to me that the crux of my argument has been lost, however: by
giving people something they don't need, but which covers a need by sheer
accident, they don't discover the solution to their _real_ needs. people
don't need source code to modify if the system doesn't work, they need
working systems. people don't need source code to add functionality to
some static function design, they need flexibility in the design. the
more we give random people unrestricted access to source code, the more
we will design software that is expected to be modified just that way,
and the less we will design software that is not intended to be modified
by random users at the source level, and the less we will design systems
that are actually able to adapt to people without changing the code.

| Emacs is a reasonable example os a system that has balanced the two ways
| that programs change. If someone wants to change the way the garbage
| collector or redisplay works, or add support for floating point numbers,
| this is done by modifying the code in place; however, Emacs's dynamism
| was used when they wanted to add web browsing capability. Sometimes both
| need to be done: often while developing an external package you discover
| that it would work better if there were a hook in a new place, so you
| make that one little change to the guts.

none of this even hints at why it was a good idea to give source code to
random people and give them the right to modify the existing source code.
those who develop their own packages for Emacs already communicate with
the source holders and other developers. nothing in this requires that
the source code be given to _anybody_.

as I have said several times, I think source access is a good idea, but I
think it should be regarded as an investment by both parties, probably
more so by whoever gets the source access, and modifications to the
source should be channeled back to the owner before they are spread
further down the line or to other developers. my goal is to educate
those who want to be educated, not to let random people have "rights"
that only hurt them in the long run.

Marco Antoniotti

unread,
Aug 25, 1999, 3:00:00 AM8/25/99
to

Just my .2 Euros (or Euro? or Euri? or Eures?) worth.

Erik Naggum <er...@naggum.no> writes:

> Linux is a success because it is well _managed_, not because it is Open
> Source. whether people would have to sign an agreement to get access to
> the source and be allowed to fix things or not is immaterial: people who
> want to commit serious work to GNU Emacs must already sign an agreement,
> and that hasn't stopped GNU Emacs from succeeding, either.

I believe the "well managed" or "well coordinated" concept is key
here, but I also believe that it is somewhat orthogonal to the
"freedom" or "openness" of the software (for the appropriate
definitions of SW). So, the use of this argument to sway opinion
toward or away from "libero" software, is not very appropriate.

Cheers

--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa

Philip Lijnzaad

unread,
Aug 25, 1999, 3:00:00 AM8/25/99
to

> communicating with the people who own the source would solve this problem,
> and there is still no need to require unrestricted rights to modify the
> source. having that right, however, means you won't find the need to
> communicate with the owners of the source until you're really pissed at
> something you can't do yourself.

My impression is that in practice this doesn't matter that much, as it seems
to be considered bad nettiquette to fork a project, and it doesn't appear to
happen often. Also, most people realize it would be foolish, because most
projects/packages are too complex to comprehend and subsequently support as a
separate fork. There's also the problem of mind-share: most developers want
to see their stuff used, and there are only so many niches. E.g., I wonder
it there is now any likelihood of having a succesful YEmacs: emacs and xemacs
are already there, and there is probably simply no 'audience' for yemacs.

So, if people don't want to contribute: fine, let them fork and keep it to
themselves, no damage done (but to themselves). If they contribute: so much
the better, this kind of system appears to work.

> if you think this is an
> exaggeration, read GNU Emacs bug reports for a while -- a pattern emerges
> where those who think they have rights tend to demand instead of ask.

I haven't but I can imagine this, it's bad behaviour, but to me it doesn't
prove that open source is to blame for this behaviour.

> yes, and that's the point: if we never get any practice in anticipating
> it or feel the consequences of our mistakes, neither will be ever become
> good at it, and the less well-designed software is, the bigger the "need"
> for unrestricted source access. the more people have access to source,
> the less they will be interested in more modular designs or ways to fix
> things.

Now that is an interesting thing: one could argue that the ultimate modules
are the language elements (functions, libraries, whatever) themselves. Fully
customizable, as it were. The question, clearly, is where to draw the line.

> of course, but why should the implementor of such changes _have_ to have
> (1) the automatic _right_ to access the sources,

that's up to the authors; if they give it (by using GPL or BSD or whatever),
then that's fine. People whining about other people's licences (as some open
source advocates do) is a bit tiresome. Although I'm inclined to say that
software developed with public money (.edu, .gov) should preferably use an
open licence.

> (2) the automatic right
> to distribute it further to others without the owner's approval,
> and (3)
> the right to distribute his modifications?

same thing. And again, nettiquette and common sense dictates that it is
general much better for all parties involved to get to hat with the
authors(owners?)

> Unix got itself into a position where some horribly demented crapware from
> Microsoft could compete with it and fool a whole bunch of people for a
> while.

I don't think this is an accurate description of what happened: Unix simply
had, for a variety of non-technical reasons, no presence on the platform that
mattered; I don't think they ever really competed (but they do so now,
luckily).

> Linux is a success because it is well _managed_, not because it is Open
> Source.

yes, but at the same time I cannot conceive of a well managed Linux that does
not give source access.

> whether people would have to sign an agreement to get access to
> the source and be allowed to fix things or not is immaterial: people who
> want to commit serious work to GNU Emacs must already sign an agreement,
> and that hasn't stopped GNU Emacs from succeeding, either.

I'd be interested in this thing; it makes sense to oblige people to commit,
but then I imagine it is equally difficult to 'enforce' such commitments
(especially with e.g. students). Possibly the main thing is to exclude
nitwits that just make demands and not much else.

> don't need source code to modify if the system doesn't work, they need
> working systems.

Open source developers crave code: they are less interested in coding
applications, it is less sexy for some reason. If and when Linux breaks
through to the masses, the masses will just be relieved to have a cheap,
stable system on their laptop. They won't want the source, and don't need it.

> more we give random people unrestricted access to source code, the more
> we will design software that is expected to be modified just that way,

that might seem so superficially, but big part of the motivation for open
source developers is to do something well, and be known for it (somehwere I
read the strange term 'egoboo' for this). The packages/projects that really
last fall in this category.

> and the less we will design software that is not intended to be modified
> by random users at the source level, and the less we will design systems
> that are actually able to adapt to people without changing the code.

No: first of all, most packages need recompiling of modified source code
before the package can be said to have adapted. This is simply not
convenient, for neither power user nor layman, and there is clearly an
incentive to make software adaptable in an easier way. Secondly, adaptability
necessarily involves generality and therefore complexity. Using this to its
full extent will likely remain the domain of the power user, and this
category of users overlaps with those who'd be inclined to change source code
anyway.

> none of this even hints at why it was a good idea to give source code to
> random people and give them the right to modify the existing source code.
> those who develop their own packages for Emacs already communicate with
> the source holders and other developers. nothing in this requires that
> the source code be given to _anybody_.

I have several times submitted, to the authors, little patches to parts of
emacs; this was acknowledged as being useful, and I fail to see how I could
have made these contributions without access to the source. Many many others
have done exactly the same, and have thusly contributed to this package. It
helps yourself, others, and it is fun. This system appears to *just work*,
all theorizing aside. Good leadership and netiquette are essential, but big
packages simply need lots of 'eyeballs', as pointed out by Raymond.

> as I have said several times, I think source access is a good idea, but I
> think it should be regarded as an investment by both parties, probably
> more so by whoever gets the source access, and modifications to the
> source should be channeled back to the owner before they are spread
> further down the line or to other developers.

absolutely!


Philip
--
The cause of the millenium bug is Homo Sapiens having 10 fingers
-----------------------------------------------------------------------------
Philip Lijnzaad, lijn...@ebi.ac.uk | European Bioinformatics Institute,rm A2-24
+44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53

Erik Naggum

unread,
Aug 25, 1999, 3:00:00 AM8/25/99
to
* Erik Naggum

| Linux is a success because it is well _managed_, not because it is Open
| Source.

* Philip Lijnzaad


| yes, but at the same time I cannot conceive of a well managed Linux that
| does not give source access.

sigh. neither can I. _please_ note that my argument is not against
source access, but against giving it to anyone, without restrictions or
need or any concept of investment in it. I have argued for source access
so much that I really did believe it would be very hard to for anyone to
confuse the issues, but let me phrase it differently in the hopes that I
can transcend the apparently strong desire to see this as an access vs no
access issue: I want source access to be granted by the author/owner to
those deemed worthy as part of building a community of people who agree
to co-invest and share knowledge. I don't want source access to be a
"right" to be demanded of authors/owners regardless of personal values or
intentions. on a higher level, I want to solve better the problem that
source access is solving badly: helping people get software that works
the way they, individually, want it to work.

| that might seem so superficially, but big part of the motivation for open
| source developers is to do something well, and be known for it (somehwere
| I read the strange term 'egoboo' for this). The packages/projects that
| really last fall in this category.

my argument is that you get more egoboost (I'm sure that's the word you
saw) out of being part of a community with privileges than you get out of
having access to source code. with source access to any stray comer, it
is actually _harder_ to build the community, and the time it takes to
deal with the eager incompetents is alarming.

| No: first of all, most packages need recompiling of modified source code
| before the package can be said to have adapted. This is simply not
| convenient, for neither power user nor layman, and there is clearly an
| incentive to make software adaptable in an easier way. Secondly,
| adaptability necessarily involves generality and therefore complexity.
| Using this to its full extent will likely remain the domain of the power
| user, and this category of users overlaps with those who'd be inclined to
| change source code anyway.

I think you miss my point, again: at issue is using _dynamic_ languages.
I'm arguing that source access is a necessity in the static language camp
and that by giving people access to source in static languages, you deny
them the opportunity to do what they really want, which is to add or use
dynamic properties of the system as delivered.


if you reply, _please_ keep in mind that I'm not opposed to source
access, nor do I think that source access is not necessary for a number
of useful things. I'm opposed to giving people access to the source as a
means of "solving" their real problem: insufficiently dynamic software to
deal with the complexity of real-world applications and people. most
people who code leisurely fail to appreciate the inherent complexity of
every problem that actually deals with real people, and I'm NOT talking
about the user interface, and I want to remove the source access from
people who are likely to be hurting themselves and the whole profession
by doing stuff that they should rather communicate in a human language to
a human developer.

William Deakin

unread,
Aug 25, 1999, 3:00:00 AM8/25/99
to
Erik Naggum wrote:

> ...these days, I largely think both Free Software and Open Source are very


> serious mistakes, because they don't solve the core problems, they make them
> much, much worse.

and

> I think Free Software and Open Source addicts will get down from their
> current high and become tremendously frustrated when the obvious problem of

> having millions of pieces of source code...turn into a very serious problem


> when much bigger problems require modifications to much larger systems than
> the ones people today think are usefully modified locally.

I think that these is a fair point about what the outcome of the Free Software
and Open Source model. But where do you say anything about the educational
function of Free Software and Open Source? The things that I most cherish about
this model is that through exposure to Free Software and Open Source I have
learnt much. e.g. I would never have tried to learn cl. How many people have
been moved to learn cl having started with elisp?

> the reason that source access is needed is...the inability to modify system


> behavior non-intrusively. if one could modify OPEN on any given system to

> acquire new behavior _without_ compiling a new OPEN or ...re-linking the
> entire system...source code access would be entirely immaterial.

This is very true. Surely this is one of the things that Free Software now
gives us with gcc/glibc?

[..elided a car/software analogy...]

> I keep wondering when and under which conditions the models employed by Free
> Software and Open Source make sense. I don't think it makes sense when the

> design is _already_ flexible and open and so malleable...

I agree. But when the design is not flexible and open and so malleable. I
wouldn't describe MS OS development as flexible and open and malleable! (But
please don't read this as that I think that you do :))

> ...that it's used as an argument against it by the very same people who want


> to change everything, but only Their Way. in other words, if all you have is
> Unix, certain problems are so staggeringly tall that it takes an extra
> special genius to see what the _real_ problem is because all the people who
> are trying to climb it make it look as if doing something else is stupid.

You will always have the ill-informed and the zelots. But this is human nature.
"I'm in this gang, and me and my friends all thing because you don't act
exactly the same as us and think exactly the same as you you are wrong."

For my sins this make me think of the Monty Python Film 'The Life of Brian', a
deep and vitriolic attack on the stupidity of the far left in the UK. For
example "The one thing that we hate in this world more that the Romans,
is...splitters." Much of the white-noise that seems to be generated by the Free
Software community seems to be of this splitter ilk. There should be more
acceptance of diversity and tolerance of other peoples points of view.

> the data we stuff into the programs and ask them to safekeep for us will be
> so much more valuable than the software.

This is so true.

> however, writing "migrable" software is not a task for novices or people who
> are not fully aware of the impact of their decisions,

But how do you become a migration master?

> I think that too much access to source code will cause a lot of people to be
> exceedingly good at stuff that is antithetical to long-term solutions.

Why?

> ...if you have, say, Common Lisp and good access to the exposable parts of


> the internals, with advice support, hooks, etc, why do you _need_ the source
> code?

You don't need the source code!

> ...but would the demand be as great if the Smart Route ... was at least
> available to intelligen people instead of requiring everybody to scale every


> mountain just to prove a point about inaccessibility?

For me, if bits were written in assembly language or heavily optimised it would
be really neat to see, but would it help me in my day to day coding tasks? Of
course not.

A strange coincidence happened I was going for an eyetest yesterday. Bhe
traffic on the road between where I work and the place in town that I was going
to very slow moving. The ten minute that I had allowed 20 minutes for turned
into a 45 minute chug. Such are the problems with living in a seaside town on a
sunny afternoon. I missed the appointment and to quell my raging anger I went
to the local library. Quiet. Calm.

The Library in town has about 3'6" of books on computing. But next to the book
on 'BASIC for the Commodore Pet' and 'Work out your High School Timetable with
the BBC B Computer' was Richard Gabriel's "Patterns of Software".

(now back to the point). In this book Gabriel makes many good point that (IMHO)
have bearing on this:

Firstly, showing me (or infact anybody apart from the bloke who want to write
another cl compiler) the optimised code is pointless or infact worst than that,
it is confusing. To get the kind of optimisations based on I would want,
because I was writing a fast mail editor, or a large MIS or what ever, will not
be helped by looking at this optimised code. More generic patterns or examples
of code would what I needed.

Secondly, software engineering (or whatever you want to call it) is only 40 or
maybe 50 years old. If it were civil engineering and you want to build a
bridge, you have at least 2000 years of people building bridges, patterns,
experiences, writing books, trying out all the angles. Software engineering
doesn't have this. These are exciting times. But we need to give things time to
develop and settle down. And not be too critical of what other people are
doing. They may not have the answer. Or at least the whole answer. But neither
do I. Or you :-)

But I think we need to look at ways the ways in which code is developed. Be it
Free or Open, Closed or Garden ;) coding. People are making lots and lots of
mistakes behind closed doors and then not telling anybody else about them. At
least Free/Open coding has more visibility.

It took me some time to read Erik's essay but I found it was well worth the
effort :-) Thank you.

Best Regards,

:-) will

Tim Bradshaw

unread,
Aug 25, 1999, 3:00:00 AM8/25/99
to
* Erik Naggum wrote:

> I thought I had already covered the value of source access to people with
> real needs. in your case, doing systems programming as your job is
> certainly within the realm of licensing the source, and I can't see why
> this is an argument for full source access with unrestricted rights to
> modify and redistribute modified code to essentially random people, which
> is what I'm arguing against. again, I'm all for source access, but only
> to those who actually need it and commit to using it constructively.

I don't see that there is a need to restrict source access like this.
So long as you (as the vendor) are careful to restrict
*redistributability* of modified sources, then I think there's no real
problem licensing source to essentially random people. If they shoot
themselves in the foot they don't hurt anyone but themselves. You
also need to be careful that when they ask for support they're asking
for support on your code not something they've broken (which might
actually be a harder problem to solve).

I've found source access (for pretty dynamic systems, including
Genera), extremely useful, even though I could not redistribute
changes. Dynamic systems only let you alter behaviour down to a
certain level -- the `chunking level' or something -- below that and
you really need source.

I suspect that I'm agreeing with you here -- to me anyway the
important thing is *access*.

--tim

Erik Naggum

unread,
Aug 25, 1999, 3:00:00 AM8/25/99
to
* William Deakin

| But where do you say anything about the educational function of Free
| Software and Open Source?

actually, in numerous other articles prior to the one you comment on.

| The things that I most cherish about this model is that through exposure
| to Free Software and Open Source I have learnt much. e.g. I would never
| have tried to learn cl.

why do you give Free Software and Open Source credit for source access?

access to source code is not predicated on having the right to do
anything with it other than read it and play with it for personal use.

I really wonder why people have so much difficulty understanding that
source can be licensed in ways that give anyone who ask for it the
ability to see whole or parts of the source, but without thereby forcing
the author to lose control over the source. e.g., Franz Inc supports
their customers with source to much of the surface functions in Common
Lisp, but you have to agree not to give this away to others. why is this
not sufficient to learn from? why do you have to be able to give the
source to other people in order to learn anything from it?

| But how do you become a migration master?

by becoming an expert at what you do and acutely aware of the impact of
your decisions. this is hard work and requires dedication and investment
far above and beyond reading source code. you have to write a lot of new
code and also maintain systems _without_ source access to be able to see
what it takes to support software migration.

| > I think that too much access to source code will cause a lot of people
| > to be exceedingly good at stuff that is antithetical to long-term
| > solutions.
|
| Why?

because people take the road of least immediate resistance, not the road
of least resistance. it's far easier to hack a function to do something
new than to figure out how the old and the new functionality should
co-exist. if you can't hack the function to do something new, but have
to treat its current functionality as a black box and do the extra stuff
outside of it, you tend to think more carefully about not changing things
incompatibly.

| But I think we need to look at ways the ways in which code is developed.
| Be it Free or Open, Closed or Garden ;) coding. People are making lots
| and lots of mistakes behind closed doors and then not telling anybody
| else about them. At least Free/Open coding has more visibility.

it's been said that architects raise monuments to their mistakes, while
doctors bury theirs. programmers tend to erase the evidence of their
mistakes if they catch them before they need to document them and have to
support them backward-compatibly in the future. I would like to see ways
to _really_ fix mistakes and produce backward-compatible code as an extra
feature, effectively local changes to the code, instead of an integral
part of the evolution of the system.

William Deakin

unread,
Aug 25, 1999, 3:00:00 AM8/25/99
to
Erik Naggum wrote:

> * William Deakin


> | But where do you say anything about the educational function of Free
> Software and Open Source?
>

> actually, in numerous other articles prior to the one you comment on.

Yes you have. Fair point. Ho Hum.

> | The things that I most cherish about this model is that through exposure
> | to Free Software and Open Source I have learnt much. e.g. I would never
> | have tried to learn cl.
>

> why do you give Free Software and Open Source credit for source access?

Because I am an idiot :-)

> access to source code is not predicated on having the right to do anything
> with it other than read it and play with it for personal use.

true.

> I really wonder why people have so much difficulty understanding that source
> can be licensed in ways that give anyone who ask for it the ability to see
> whole or parts of the source, but without thereby forcing the author to lose
> control over the source.

See the answer above.

I think this is then about trust. Or access to big men with sticks. Or lawyers
with big sticks. This is also about me understanding what you are talking
about. I agree with you. There is no reason why licenses cannot be drawn up so
that anyone who asks for it has the ability to see whole or parts of the
source.

> e.g., Franz Inc supports
> their customers with source to much of the surface functions in Common
> Lisp, but you have to agree not to give this away to others. why is this
> not sufficient to learn from?

It is sufficient. I agree. Franz seem like very nice people.

> ...people take the road of least immediate resistance, not the road of least


> resistance. it's far easier to hack a function to do something new than to
> figure out how the old and the new functionality should co-exist. if you
> can't hack the function to do something new, but have to treat its current
> functionality as a black box and do the extra stuff outside of it, you tend
> to think more carefully about not changing things incompatibly.

Yup. Also as I understanding this is the one of the differences between doing
The-Right-Thing and Worse-Is-Better.

I think that anything worthwhile doing is never easy. Its what gives the
satisfaction. Even if it is digging a large hole in the ground with a spade.
I'm good at digging myself into holes ;-)

Have you any thoughts about how this fits in with planned as opposed to organic
development?

> ...programmers tend to erase the evidence of their mistakes if they catch


> them before they need to document them and have to support them

> backward-compatibly in the future....it's been said that architects raise


> monuments to their mistakes, while doctors bury theirs.

One of the things though is that when a doctor makes a mistake there is then an
inquiry into what went wrong and how not to do it again. These results are then
published. To stay in the doctoring (I believe) every doctor, at least in this
country, has to then read the outcome of these (along with lots of other
stuff). But this goes back to the idea that programming, or software
development is a Profession and should be carried out in a professional manner.

> I would like to see ways to _really_ fix mistakes and produce
> backward-compatible code as an extra feature, effectively local changes to
> the code, instead of an integral part of the evolution of the system.

This is an excellent idea.

I would also like to also talk about things like design mistakes. I think there
are things to be learnt about setting about coding. But one thing that seems
like a big gaping hole in the scheme (sic) of things is the bits before and the
bits after the coding start.

Best Regards,

:-) will


Bruno Haible

unread,
Aug 25, 1999, 3:00:00 AM8/25/99
to
Erik Naggum <er...@naggum.no> wrote:
>
> the cause of the
> problem: the inability to modify system behavior non-intrusively. if one
> could modify OPEN on any given system to acquire new behavior _without_
> compiling a new OPEN or, even if you did, without re-linking the entire
> system (thus the need for dynamic linking and similar solutions, too),

Have you ever used LD_PRELOAD ? You create your added functionality in form
of a shared library which then overrides functions in any system library.
Below is a small sample.

> source code access would be entirely immaterial.

Source code is still important 1. for understanding how something works,
2. if your patch needs to insert 1 line in the middle of the OPEN function.

Bruno http://clisp.cons.org/~haible/


Bruno Haible

unread,
Aug 25, 1999, 3:00:00 AM8/25/99
to
Here is the sample I promised. Compile and use it like this.

$ gcc -O -fPIC hack.c -o hack.so
$ export LD_PRELOAD=`pwd`/hack.so

Bruno

================================== hack.c ====================================
/* Hack function time(). */
/* It might not be legal to use this code to circumvent evaluation licenses. */

#include <sys/types.h>
#include <sys/time.h>
#include <dlfcn.h>

#define DAYS_BACK 2*30 /* two months */
#define TIME_BACK DAYS_BACK*24*60*60

time_t time (time_t * ptr)
{
static void* libc_handle = NULL;
static time_t (*original_time) (time_t*) = NULL;
time_t t;
if (libc_handle == NULL)
libc_handle = dlopen("/lib/libc.so.6",RTLD_LAZY);
if (libc_handle != NULL)
original_time = dlsym(libc_handle,"time");
t = original_time(NULL);
t -= TIME_BACK;
if (ptr)
*ptr = t;
return t;
}

Paul Wallich

unread,
Aug 25, 1999, 3:00:00 AM8/25/99
to
In article <31445696...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:

>* Erik Naggum


>| Linux is a success because it is well _managed_, not because it is Open
>| Source.
>

>* Philip Lijnzaad


>| yes, but at the same time I cannot conceive of a well managed Linux that
>| does not give source access.
>

> sigh. neither can I. _please_ note that my argument is not against
> source access, but against giving it to anyone, without restrictions or
> need or any concept of investment in it. I have argued for source access
> so much that I really did believe it would be very hard to for anyone to
> confuse the issues, but let me phrase it differently in the hopes that I
> can transcend the apparently strong desire to see this as an access vs no
> access issue: I want source access to be granted by the author/owner to
> those deemed worthy as part of building a community of people who agree
> to co-invest and share knowledge. I don't want source access to be a
> "right" to be demanded of authors/owners regardless of personal values or
> intentions. on a higher level, I want to solve better the problem that
> source access is solving badly: helping people get software that works
> the way they, individually, want it to work.

This sounds good, but it has a serious implementation problem: if you
actually gave serious thought to who should have access to the source,
you would spend far more time on the distribution/decision problem than
on building working software. You would have to give all requestors the
equivalent of a job interview, and even then it's often difficult to tell
whether someone will ocntribute to a project/community until they've
been working for a while. Some people you think will be good will be
disastrour, and some people you think will be bad will turn out brilliant.

So most people or organizations make a default decision: either don't
release the code unless someone can onvince the hell out of you, or
else release the code to all comers. The first has been shown to suck
in many cases, not least because people who may want the code won't
want to bother with making a huge investment in convincing someone
if the outcome is uncertain. The second seems to be doing rather better,
but has scaling problems.

paul

Barry Margolin

unread,
Aug 25, 1999, 3:00:00 AM8/25/99
to
In article <31445696...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
>* Erik Naggum
> confuse the issues, but let me phrase it differently in the hopes that I
> can transcend the apparently strong desire to see this as an access vs no
> access issue: I want source access to be granted by the author/owner to
> those deemed worthy as part of building a community of people who agree
> to co-invest and share knowledge.

How do you know beforehand whether someone should be granted this right?
In the open source environment, everyone gets the right. However, when
they contribute changes back to the overseers of the project, the code can
be rejected if it's no good. They prove they're "worthy" by submitting
worthwhile changes.

In the proprietary software environment, the "right" is transferred through
payment.

> I don't want source access to be a
> "right" to be demanded of authors/owners regardless of personal values or

Who is "demanding"? "Requesting" would probably be a better term.

> intentions. on a higher level, I want to solve better the problem that
> source access is solving badly: helping people get software that works
> the way they, individually, want it to work.

I agree that better modularity and design for customization is better than
simply depending on source availability. However, I also believe that it's
a very hard problem to solve well (many Macintosh applications are doing
pretty well with AppleScript, but its applicability is pretty limited).
Pragmatically, source access is the workaround.

BTW, I think I've also heard "ego boost" pronounced as "egoboo".

Kent M Pitman

unread,
Aug 25, 1999, 3:00:00 AM8/25/99
to
Erik Naggum <er...@naggum.no> writes:

> none of this even hints at why it was a good idea to give source code to
> random people and give them the right to modify the existing source code.

Well, a specific experience from my past:

I worked at MIT a couple decades ago on Macsyma. It was not free
software, but it was also not read protected. Those were simpler
times. It was written in Maclisp, and everyone had source access.
Later, it had to be translated to a modern dialect and I was the only
one willing to tackle it. (It was 100,000 lines of pretty intricate
code and took two or three months to convert, thanks to the Lisp
Machine's good tools for helping me.) The big problem in converting
it was not the mechanical part, but the conceptual part. Every thing
I changed was a potential incompatibility and I had no idea what
things people were using and what they weren't because they were never
previously forced to tell me, and in principle they could be depending
on even the most obscure little detail of implementation-specific
stuff. And I have no doubt someone's code broke as a result. The
code I was responsible for made it through ok, as far as I know. The
original implementors never came after me with knives or stones or
anything. But it was darned scary for the reason of knowing I had
this weird obligation not to break things and yet to know that the
definition of "porting" is "change" and an implication of "change" in
a system where sources are known is probably "breakage". So in a
sense my job was to break things and I felt bad about it. After it, I
advocated a revised policy which was never implemented but that I
liked: source on demand. That is, a system where you cannot have the
sources unless you tell me what you need and why then I'll either tell
you why you should use a different thing or I'll give you the source
you need. (The idea was maybe a bit to be like a database keeping
track of read dependencies in a transaction so that it didn't have to
lock the whole database in order to get a consistent transaction for
one user.) The problem with openness is that it provides no feedback
about what is being used and what is ignored, and it does not optimize
the case of update by the owner; it pessimizes that in favor of potential
(but not always realized) update by others.

ANSI had a similar problem when we said we wanted to put the draft
specifications out online. Their immediate concern was "in the past we
have always known who got the spec, so if there were fixes/changes we
would know who to contact". We had to compromise and say we'd tell people
that they could either continue to get directly from ANSI or else register
their desire for updates/fixes separately or else understand that getting
sources didn't mean a guarantee of any consistency or freedom from change.

People tend to depend heavily on open-source stuff not to change, but it's
absolutely critical in such systems to separate what things will and won't
change. And for people depending on non-change to register that need.
Too often, it's not done. I think because a lot of people think that
the whole point of open source is a selfish kind of "i can do whatever i want
and damn everyone else". But when you build real societies of real people
who really depend on one another, there become rules whether you want them
or not. The first thing you learn when you gain any REAL power in the
world is that REAL power requires responsible exercise, and that you were
a lot freer to do whatever you wanted when you didn't have any power than
when you do. Or such, at least, has been my experience.


> as I have said several times, I think source access is a good idea, but I
> think it should be regarded as an investment by both parties, probably
> more so by whoever gets the source access, and modifications to the
> source should be channeled back to the owner before they are spread
> further down the line or to other developers. my goal is to educate
> those who want to be educated, not to let random people have "rights"
> that only hurt them in the long run.

yes, this seems consistent with my experience.

far...@spam.tunes.org

unread,
Aug 25, 1999, 3:00:00 AM8/25/99
to
Dear Erik, dear readers,
just in case I'm not (yet) in your kill-file, here is

Erik Naggum <er...@naggum.no> writes on comp.lang.lisp:
> * Philip Lijnzaad


> | yes, but at the same time I cannot conceive of a well managed Linux that
> | does not give source access.
>

> sigh. neither can I. _please_ note that my argument is not against
> source access, but against giving it to anyone, without restrictions or
> need or any concept of investment in it.

I believe you mix up the issues of *fact* and *right*.
Free software is about anyone having the *right* to access the source;
it doesn't mean they will or should actually do it,
and it doesn't mean doing it will happen free _of charge_,
and even less free of personal time investment.
(How could they read the sources without time investment?
And if they just compiled it, what difference with giving binaries,
except that it will work on more platforms?)

Just like having the *right* for anyone to repair a car
(as opposed to having to return it to the maker) doesn't mean
that everyone will repair one's own car, but that proficient people can
and will do it in a free market.

> I want source access to be granted by the author/owner to
> those deemed worthy as part of building a community of people who agree
> to co-invest and share knowledge.

and the author is refused work on his own program (frequent case,
particularly in the proprietary LISP community)?
What if the owner is a marketing guy who doesn't care zilch
about sharing knowledge? That's precisely what happens
with proprietary software. The owner has absolute power to decide
who will touch the program, and this absolute power corrupts him
absolutely. Who will want to share knowledge with someone who can
reject him at his whim and prevent the use of further modifications?

> I don't want source access to be a
> "right" to be demanded of authors/owners regardless of personal values or

> intentions.
Do not confuse right and opportunity.
I demand the right to copy, understand, and modify, software.
But I'm ready to pay for the _opportunity_ to do it.

> on a higher level, I want to solve better the problem that
> source access is solving badly: helping people get software that works
> the way they, individually, want it to work.

Free software is not the end of software engineering problems,
only the beginning to their solutions.
Just like free market is not the end of economical problems,
only the beginning to their solutions.

> | that might seem so superficially, but big part of the motivation for open
> | source developers is to do something well, and be known for it (somehwere
> | I read the strange term 'egoboo' for this). The packages/projects that
> | really last fall in this category.
>

> my argument is that you get more egoboost (I'm sure that's the word you
> saw) out of being part of a community with privileges than you get out of
> having access to source code. with source access to any stray comer, it
> is actually _harder_ to build the community, and the time it takes to
> deal with the eager incompetents is alarming.
>

The idea is that when there are no rights that get in the way,
the mindshare structure will naturally emerge out of remaining criteria,
that is, actual proficiency.
Compare technical decisions taken by political motives
with technical decisions take by technical motives.
When political criteria take precedence over technical criteria
in technical questions, you don't obtain technically good technology
(conversely, if political questions were to be taken engineers,
the world wouldn't be good, either).

> at issue is using _dynamic_ languages.
> I'm arguing that source access is a necessity in the static language camp
> and that by giving people access to source in static languages, you deny
> them the opportunity to do what they really want, which is to add or use
> dynamic properties of the system as delivered.

Your statement would be true if computing was merely compositional.
However, it is also decompositional.
You can't add real-time properties to a software component,
modify its GC infrastructure, make it network-transparent,
security-aware, internationalized, "Y2K-compliant", etc,
only by composing it as a black box;
you need be able to see its source so as to weave new aspects into it.

Dynamism does solve the compositional problems.
But to solve the decompositional problems, you need Reflection,
whose ultimate form is the ability to reify source code.

Access to source is also essential to get rid of the "hardware compatibility"
and "binary API compatibility" problems that tie computer science to
obsolete hardware and system software design.

> I'm opposed to giving people access to the source as a
> means of "solving" their real problem: insufficiently dynamic software to
> deal with the complexity of real-world applications and people.

Free software is not the be-all end-all of software design;
it's not about design at all; it's about rights.
Dynamism is not the be-all end-all of software design, either,
although it's an essential and oft undervalued property.

> most
> people who code leisurely fail to appreciate the inherent complexity of
> every problem that actually deals with real people, and I'm NOT talking
> about the user interface, and I want to remove the source access from
> people who are likely to be hurting themselves and the whole profession
> by doing stuff that they should rather communicate in a human language to
> a human developer.

Free software doesn't remove that.
All the serious free software projects I know have active mailing-lists;
just like all serious proprietary software projects, I suppose.
Non-serious posters just get ignored (or possibly flamed or kicked out),
and eventually go away;
just like in all serious proprietary software projects, I suppose;
until the non-serious guys happen to be in some decisional committee
concerning the project.

Free software does not _replace_ project management;
but it _allows_ management to be proficiency-based,
rather than boss-hair-pointiness-based.

Stupid people will hurt themselves and other people stupid enough
to trust them not to be stupid. Let them do so, you just can't prevent that.
Just don't prevent good people from doing good things,
and don't force them to follow the whims of stupid people.
(hey, you had a .sig just like that, once!).

Best regards,

[ "Faré" | VN: Уng-Vû Bân | Join the TUNES project! http://www.tunes.org/ ]
[ FR: François-René Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics | Project for a Free Reflective Computing System ]
Tolerance is not about respecting other people's ideas.
We have every right to fight ideas we think are stupid.
Tolerance is about respecting other people's persons.
We have every duty to respect even persons we think are stupid.

Kent M Pitman

unread,
Aug 25, 1999, 3:00:00 AM8/25/99
to
far...@SPAM.tunes.org (I+far...@tunes.NO.org.SPAM) writes:

> Do not confuse right and opportunity.
> I demand the right to copy, understand, and modify, software.
> But I'm ready to pay for the _opportunity_ to do it.

I don't understand this as expressed.

I have some software I've written for myself that is not free.
Suppose I say it is free and that anyone has the right to use and modify
it as they like, but that they have to pay `` 1 billion dollars ''
to exercise that right. Is that within your definition of free software?

Francois-Rene Rideau <I+fare+WANT@tunes.NO.org.SPAM>

unread,
Aug 26, 1999, 3:00:00 AM8/26/99
to
Kent M Pitman <pit...@world.std.com> writes on comp.lang.lisp:

>> Do not confuse right and opportunity.
>> I demand the right to copy, understand, and modify, software.
>> But I'm ready to pay for the _opportunity_ to do it.
>

> I don't understand this as expressed.

It's all about rejecting intellectual property. See pointers to articles
collected down <http://www.tunes.org/~fare/libre-logiciel.html>;
particularly <http://www.freenation.org/fnf/a/f31l1.html>.

I deny anyone any claim to a "right" to control what I do with ideas
that are in my mind. If I come in possession of a poem, a book, a piece
of software, I may use it as I like. But I deny any "entitlement"
to access other people's private information, either.

If you have a program that no one else has, or are able to write it,
then it is fair that you ask me some money before to disclose or complete
the program; but once you disclosed it to me, I'm free to do whatever
I want with it. You may even convince me not to get the sources;
but if I have binaries, I should be free to copy or hack them.

> I have some software I've written for myself that is not free.
> Suppose I say it is free and that anyone has the right to use and modify
> it as they like, but that they have to pay `` 1 billion dollars ''
> to exercise that right. Is that within your definition of free software?

No. To me, anyone has the _right_ to modify software.
However, you also need the _opportunity_ to do it,
i.e. have access to a copy (preferrably source code) of the software.
So, even without violating anyone's rights,
you can keep your software _secret_, which is quite, quite different.

If your secret software is worth one billion dollar to me,
I'm ready to pay for the _opportunity_ to use it.
Most usually, however, I don't expect people to pay such sums for software
that happens to be here and sits waiting for someone to purchase;
rather, they will pay for incremental and/or tailored development,
customization, bug-fix, support, maintenance, etc;
programmers will likely get continuously paid for small services,
rather than getting paid once (with a big risk)
for an essentially one-shot service.

Now, the recent release of Xanadu shows to me how big software
developed in secret doesn't work:
people reinvent well-known concepts in particular cases,
and cut themselves from widely available culture,
and end up with programs that may have a few interesting ideas,
and a whole lot of stupid cruft.
Actually, this is all an incentive for people to sell their secrets
while they are still worth it, at a fair price,
which is a much better system than intellectual property
so as to promote creation and publication of original works.

Hence, I don't expect _much_ software to stay secret for any great length
in the future world when intellectual property will have been abolished.

Regards,

[ "Faré" | VN: Уng-Vû Bân | Join the TUNES project! http://www.tunes.org/ ]
[ FR: François-René Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics | Project for a Free Reflective Computing System ]

Because people confuse information and information-related services
(which include searching, creating, processing, transforming, selecting,
teaching, making available, guaranteeing, supporting, etc), they are afraid
that Free (libre) Information mean free (gratis) information-related services,
which would indeed kill the industry of said services. On the contrary,
Free Information would create a Free Market in these services, instead of
current monopolies, which means they will be available at a fair price,
so the result would be a flourishment of that industry! -- Faré

William Tanksley

unread,
Aug 26, 1999, 3:00:00 AM8/26/99
to
On Wed, 25 Aug 1999 21:55:47 GMT, Kent M Pitman wrote:
>far...@SPAM.tunes.org (I+far...@tunes.NO.org.SPAM) writes:

>> Do not confuse right and opportunity.
>> I demand the right to copy, understand, and modify, software.
>> But I'm ready to pay for the _opportunity_ to do it.

>I don't understand this as expressed.

>I have some software I've written for myself that is not free.


>Suppose I say it is free and that anyone has the right to use and modify
>it as they like, but that they have to pay `` 1 billion dollars ''
>to exercise that right. Is that within your definition of free software?

Yes, it is. So long as your definition of "use and modify" also included
redistribution, publishing, charging for, and so on.

In other words, if you give your user something, you have to allow them to
use it any way they want to.

Many Free Software advocates don't stop there -- they say some weasel
words intended to make the GPL look like a free license rather than a
pragmatic license. The GPL fails to be Free because it places a
restriction on the redistribution of the software, so that you cannot
redistribute it unless you're willing to meet certain conditions.

I don't want to make the GPL sounds bad, because it's not. It's merely
not completely free, as the X11, BSD, or Python licence is. Claims to the
contrary should be met by a polite correction, and haughty scowls at the
"pragmatism" of the open source advocates should be met with violent
logical slapdown.

So to speak :-).

BTW, oddly enough, this means that I consider "freeware" (typically
MSDOS-only software which costs nothing but includes no source) to be free
software. You're not given everything, but what you're given you're
allowed to do anything you want to.

--
-William "Billy" Tanksley

Philip Lijnzaad

unread,
Aug 26, 1999, 3:00:00 AM8/26/99
to

> | that might seem so superficially, but big part of the motivation for open
> | source developers is to do something well, and be known for it (somehwere
> | I read the strange term 'egoboo' for this). The packages/projects that
> | really last fall in this category.

> my argument is that you get more egoboost (I'm sure that's the word you


> saw) out of being part of a community with privileges than you get out of
> having access to source code.

yes, agreed. At the same time, I imagine not a few people have started
contributing competently to a project after having been 'lured' by the
wholesale availability of the source code in the first place.

> with source access to any stray comer, it
> is actually _harder_ to build the community, and the time it takes to
> deal with the eager incompetents is alarming.

yes, granted; but, as somebody else noted too, in practice, careful selection
of those deemed worthy it may not worth the trouble. Good leadership (to
reject eager incompetents) is paramount.

> I think you miss my point, again: at issue is using _dynamic_ languages.


> I'm arguing that source access is a necessity in the static language camp
> and that by giving people access to source in static languages, you deny
> them the opportunity to do what they really want, which is to add or use
> dynamic properties of the system as delivered.

Yes and no: in static languages, open source is much more of a necessity than
in dynamic ones (if only to bolt on a bit of dynamicity poorly). In dynamic
languages, you can use things like the emacs hooks mechanism (which probably
originated elsewhere and is possibly available in others tools under a
different name. And they are probably other, better? mechanisms, I'd be
interested to hear). All very useful, but at some point, the proliferation of
hooks become unmanageable (and/or too complex for non-experts to use), and
the commonly applied functionality is better implemented in the core of the
software, by componentizing, or using some meta-language. Pretty much of this
complexity may simply be unavoidable in whatever form.

I guess the whole point about limiting source code access to non-nitwits
simply isn't very important. The open source model has only gained visibility
fairly recently, and it may take the audience at large some time to realize
that open source doesn't buy you much unless you are willing to really get
involved and develop and contribute to a community. And in practice, ignoring
'demands' and useless contributions from nitwits may be sufficient.


Philip
--
The cause of the millenium bug is Homo Sapiens having #b1010 fingers

Vassil Nikolov

unread,
Aug 26, 1999, 3:00:00 AM8/26/99
to comp.la...@list.deja.com
Paul Wallich wrote: [1999-08-25 12:40 -0400]

> In article <31445696...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:

|...|


> > my argument is not against
> > source access, but against giving it to anyone, without restrictions or
> > need or any concept of investment in it.

|...|


>
> This sounds good, but it has a serious implementation problem: if you
> actually gave serious thought to who should have access to the source,
> you would spend far more time on the distribution/decision problem than
> on building working software.

|...|


> So most people or organizations make a default decision: either don't
> release the code unless someone can onvince the hell out of you, or
> else release the code to all comers.

|...|

There are two `traditional' (old-fashioned?) mechanisms that might help:
* decide to whom to give the source based upon their reputation (a good
name vs. great riches);
* and/or based upon other people's recommendations (references).

I would like to note that good reputation is hard to fake.


Vassil Nikolov. (See header for additional contact information.)
Abaci lignei --- programmatici ferrei.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Howard R. Stearns

unread,
Aug 26, 1999, 3:00:00 AM8/26/99
to
There's some vagueness here (at least to me) regarding conditional use.

I might agree to let my older daughter have an art supply kit IFF she
shares it with her sister.

The state might agree to let me drive a car on public roadways IFF I
follow the rules. In my case, I'm additionally required to wear glasses
while I drive.

I might agree to let people use some software of mine for non-commercial
purposes.

I get the impression that there are those here who have a problem with
such conditional use restrictions. (One problem is in defining
limitations such as "sharing", "non-commerical use", "dangerous use".)

Can someone summarize their complaint about such restrictions, or
alternatively, the "conditions" under which such conditions can be
fairly/efficiently/logically/legally (take your pick) applied?

Erik Naggum

unread,
Aug 26, 1999, 3:00:00 AM8/26/99
to
* Erik Naggum

| I want source access to be granted by the author/owner to those deemed
| worthy as part of building a community of people who agree to co-invest
| and share knowledge.

* Paul Wallich


| This sounds good, but it has a serious implementation problem: if you
| actually gave serious thought to who should have access to the source,
| you would spend far more time on the distribution/decision problem than
| on building working software.

both economics and engineering are about using the available resources
wisely and without undue waste. both have long standing in our society
as serious problem-solvers and even serious problem-inhibitors, meaning:
by being aware of economics and core principles of engineering, we don't
get into a large category of problems. I don't see why it makes sense to
dispense with economics and core principles of engineering just because I
propose to give source access to people based on merit. it has, however,
always seemed a rather brilliant way to kill any form of proposal to say
that it would _necessarily_ be reduced to a complete and utter waste of
all available resources. (pardon my cynicism, but Norway is holding its
quadrennial local elections 1999-09-13 and the mass media user is now a
hapless victim to an unprecedented level of braindamage that emanates
from politicians and reporters. it is physically painful to me. I guess
I'll vote for whoever can show a non-flat EEG at the end of the day.)

people who have source code to offer today find ways to work with others.
those who want to work with those who have source code, also find ways.
one very simple way to measure interest and dedication is to ask them to
sign various forms of agreements. e.g., GNU Emacs contributors of any
consequence have to sign over the copyright to their works to the FSF. I
didn't have a problem with that at the time and I don't regret signing
it. I have signed so many agreements and contracts over the years which
in the minds of people who don't appreciate what any contract necessarily
has to provide for if you enter into a limitation of your present freedom
would mean in otherwise inaccessible and invaluable opportunities that a
source license or a non-disclosure agreement as a prerequisite to taking
part in something is not the hurdle it is for people who hate lawyers and
legal complications when they just want to have fun. but frankly, I'm
strongly opposed to the view that others have to behave in certain ways
because that's the only ways I think I can have fun, and this is probably
because I believe the most fun comes about after very serious investments.

the serious thought I want to give to who shall take part in a project
should be doable once, in setting up the license and the contract that
individual contributors have to sign. in order to sign a contract, you
have to establish a pretty clear image of what you will invest and what
you expect in return, and that process is usually sufficient to sort out
people who don't take it seriously enough. on this topic, I might add
that I have never quite figured out why employees don't interview their
employers at least as rigorously as they interview them, but I have
always been an independent consultant because I don't want to work for
people who don't realize that they have to give me a very solid reason to
work for them for at least 8 hours a day in a location of their choice,
nor do I understand why people individually accept so horrible working
conditions that they have to form labor unions so they don't have to
accept them, anymore, but I digress.

if giving source code to random people is such a panacea, the people who
want the source code should have very convincing arguments why they
should be given it, arguments that should make good business sense here
and now. the reason I don't believe in the panacea is that people aren't
making solid cases for releasing source code that business people will
listen to, and it is not _only_ because human beings are prone to act in
contradiction with their personal or long-term interests. put bluntly,
if I have some source, what's in it for me if I give it to everybody?
those who want other people's source code have failed to consider the
transverse situation. one person's want is not automatically the
motivation of another; something has to come between that can motivate
those who have something to give, and it is important to understand what
would fill the need and stop the want, otherwise it is meaningless to
give them anything at all. if the value of open source was as great as
its proposers want it to be, the only thing that keeps vendors from
giving it out to everybody is a failure to understand their own (still
the vendors') needs. my advice is: stop talking about the value of
source code to those who will get it for free, and concentrate on the
value of giving away source code for free.

| Some people you think will be good will be disastrour, and some people
| you think will be bad will turn out brilliant.

I keep wondering when this is _not_ the case, so why bring it up? you
appear to want to make it sound as if there is an inherent flaw in some
_particular_ way to deal with people, but it's obviously an inherent
problem in dealing with people qua people any way you decide to do it.

| So most people or organizations make a default decision: either don't
| release the code unless someone can onvince the hell out of you, or else

| release the code to all comers. The first has been shown to suck in many
| cases, not least because people who may want the code won't want to
| bother with making a huge investment in convincing someone if the outcome
| is uncertain.

as I said above: if source code access is such a boon to mankind, how
come those who want the source are so incredibly bad at convincing those
who hold the source today? you appear to admit that there is very little
obvious value and very significant obvious costs in giving people source
access, yet don't appear to let this affect your desire for giving it all
comers. I actually wonder why you see this only from the _recipients'_
point of view, when it is quite obvious that the _originator_ is the one
who needs convincing.

personally, I don't think the value of sharing source code and the
programmers' mindsets with other people is uncertain at all: it is of
_tremendous_ value to be able to discuss these things intelligently. but
that's precisely why it's an incredible waste to give it to everybody.

let me add too much personal history to illustrate my point: I wrote to
manufacturers of soft drinks, chocolates, toys, etc, when I was a kid,
with whacky and useful suggestions alike, and they had the good sense to
reward the most the suggestions they actually used. to this day, I am
concerned with what every supplier of mine does, from buying stock in the
airline I use and making sure they get the most money out of my tickets
while I get the lowest possible prices (squeezing out the middlemen), to
asking for the site manager of a supermarket and suggesting they stock
Water Joe because I want to buy it cheaper from them than from the few
soft-drink stands that sell over-priced bottles. I consider every single
manufacturer and vendor to be a _supplier_ to my well-being, and I cannot
understand why people don't do something on the personal level when they
think their suppliers could do a better job, but instead wait to stage
boycotts or make big stinks or demand that politicians take action when
they could have obtained a lot more by just talking to the guys who do
the work. it doesn't take more than a fraction of a second to express
concern, but it usually wastes a lot of energy not to. the flip side of
this is I have a serious problem with people who waste other people's
time just because they don't see how much of their own time they waste --
people who just plain don't _care_ bug me, big time.

I have come to consider the clamor for source access for people who don't
care (that's what this is about, since the people who care wouldn't have
any significant problems in the first place) to be a gargantuan waste of
everybody's time and effort, and a very strong reinforcer for those who
want others to care _for_ them and who get bitter and demanding when they
don't get what they think they have a right to. my problem with getting
this aspect of Free Software is that Richard Stallman is a guy who really
cares about what he's doing, and he's caring about something valuable,
but it won't work constructively as long as it benefits people who don't
care more than it benefits people who _do_ care.

Paul Wallich

unread,
Aug 26, 1999, 3:00:00 AM8/26/99
to
In article <l03130309b...@195.138.129.122>, Vassil Nikolov
<v...@einet.bg> wrote:

>Paul Wallich wrote: [1999-08-25 12:40 -0400]
>
> > In article <31445696...@naggum.no>, Erik Naggum <er...@naggum.no>
wrote:
> |...|
> > > my argument is not against
> > > source access, but against giving it to anyone, without restrictions or
> > > need or any concept of investment in it.
> |...|
> >

> > This sounds good, but it has a serious implementation problem: if you
> > actually gave serious thought to who should have access to the source,
> > you would spend far more time on the distribution/decision problem than
> > on building working software.

> |...|


> > So most people or organizations make a default decision: either don't
> > release the code unless someone can onvince the hell out of you, or
> > else release the code to all comers.

> |...|
>
>There are two `traditional' (old-fashioned?) mechanisms that might help:
>* decide to whom to give the source based upon their reputation (a good
> name vs. great riches);
>* and/or based upon other people's recommendations (references).
>
>I would like to note that good reputation is hard to fake.

It can also take an awfully long time to develop.

Still, I thinking that both of these ideas have severe scaling trouble
given the current and future size of the potential programmer base.

If a hundred people want source enough to ask you, and it takes you
five minutes to make a decision, that's a day's work. If 25,000 people
want source enough to ask you, that's an entire working year. Obviously
you may be able to reject a lot more of the 25,000 out of hand, but at
some point even reading the email will clobber you. For any project (like
an operating system) that has a potentially enormous base of interested
programmers, personal communication with everyone who wants to look
at the source code and has a superficially good reason to do so is going to
clobber the person who acts as a choke point.

I suppose you could delegate things to a cabal, but that has its own problems.

On the other hand, some kind of weeding-out mechanism may be needed;
I think Erik's example of the FSF license is a good one.

paul

User Knotwell

unread,
Aug 26, 1999, 3:00:00 AM8/26/99
to

I've read this discussion with interest.

I've a couple of question for Erik.

I'm trying to understand your point of view. Based on your posts on this
topic, it appears to me that you're advocating for source access based on
merit and/or investment. What is your reasoning for this position?

Personally, I don't like open source software because of its quality.
Similarly, I don't particularly like source availability (I've only
ever modified three packages and I've only read the source for 3-4 others).
I like open source software because it's:

1)inexpensive. I've always been amazed by the people
who try to make out that this isn't a big motivator. Does
anyone else but me snort when they see a comment like "I'd
pay for it even if it wasn't free?"
2)lacking in administrative bullsh*t. IBM's C compiler for the
RS/600 cost $400. Personally, I don't care about the $400
(a cost of doing business). On the other hand, I do care about
having to chase down a PO. I do care about having to install
a goofy-a** license monitor to make sure I don't do something
evil. Similarly, I do care about having to call IBM sales support
to get a new license key when we decide to move development to a
new box with a faster network card. . .I could go on, but I'm
even starting to bore myself :-).
3)generally tailored towards use on commodity hardware.
4)another tool in the fight against getting jabbed by your
vendor. To be honest, I believe a better tool in this fight would
be open, understandable data formats so my data won't be held
"captive" against it's will.
5)community-oriented. From what I can tell, open source projects
tend to do an extremely good job of putting "customers" and
developers together. On the other hand, most commercial companies
where I've worked went out of there way to keep developers and
customers apart (counter-productive in my view).

Why do I get the feeling I'll regret this?

--Brad (eyes about to shut)


User Knotwell

unread,
Aug 26, 1999, 3:00:00 AM8/26/99
to
Erik Naggum <er...@naggum.no> writes:

> I honestly wonder why so many people don't see the dynamism argument and
> only latch onto the source access argument. is it because people don't
> really know why they want source access? Christopher's argument appears
> to be that it isn't needed. my argument is that people who don't need
> source code still need dynamic behavior. take GNU grep. wouldn't it be
> great if you could make GNU grep always print the filename with an option
> instead of tacking on /dev/null at the end like Emacs does? wouldn't it
> be great if you could instruct GNU grep to default to case-insensitive
> searches? how about enclosing the filename in double quotes so Emacs can
> find matches in files that happen to contain colons in their names?
> these would be simple local patches in a dynamic system, but it may just
> be too much work to fix the source, submit a patch, and argue for the new
> features. as you correctly observe, local fixes die with source access,
> but if the fixes are in the form of manageable advise code, they would
> survive an upgrade. again, dynamic languages win on all points, but
> since people have source access, they won't think they need it, even with
> the many problems caused by source access, such as the ones you bring up.

One thing I found a bit bizarre about your "dynamism" v. open source argument
is that I don't really understand how they can't complement one another.
It seems to me that Emacs and Apache are good examples of this being the
case. Their main difference from other projects (open and closed) is that
their "extensible modularity" appears to have been a big goal in their
current (initial???) designs.

BTW: if you believe extension via "scriptability" (ie Emacs, Apache, or Gimp)
or dynamic linking (ie Apache's mod_so) isn't a viable model for dynamism, I'd
be curious to understand why.

>
> #:Erik

--Brad

Erik Naggum

unread,
Aug 27, 1999, 3:00:00 AM8/27/99
to
* Paul Wallich

| If a hundred people want source enough to ask you, and it takes you five
| minutes to make a decision, that's a day's work. If 25,000 people want
| source enough to ask you, that's an entire working year.

and here I thought we were programmers, but instead you argue that people
should do all kinds of things _manually_? something wrong, here.

| Obviously you may be able to reject a lot more of the 25,000 out of hand,
| but at some point even reading the email will clobber you. For any
| project (like an operating system) that has a potentially enormous base
| of interested programmers, personal communication with everyone who wants
| to look at the source code and has a superficially good reason to do so
| is going to clobber the person who acts as a choke point.

if that person can be trusted to manage something as complex as an
operating system, I sure hope he's smart enough to realize what a silly
problem this is before it hits him. otherwise, who knows what kinds of
silly things the operating system will do.

there's a reason companies hire more people when the work-load increases:
most people who want something done and want to make money doing it have
figured out that it is beneficial if they can actually train other people
to do certain tasks and not have to do everything themselves. given the
wondrous society in which we live, several people come pre-trained or, lo
and behold, from other, similar, jobs with a directly useful skill set.

here's a fairly simple idea: write a program. publish it. earn money
doing this. support your customers. include automatic means to get
upgrades and patches. include _some_ source, the stuff you'd like people
to use for innocuous customization and generally to understand your
program better. also include a description of what it takes to get more
or all source, such as printing a file, adorning it with a signature, and
sending it by ground-to-ground mail. then do the natural thing in our
advanced economic society: charge applicants whatever it costs to process
their application so you have money to employ people doing just that. or
write a web thingamajig that deals with the boring administrative stuff.
it's like the _rage_ among managers and marketing people these days, so
it's a little odd that programmers don't think about it, isn't it? ;)

I think more programmers should have business training or at least some
_exposure_ to what it takes to start and run a business. it seems it
might surprise a great many people, but you don't _have_ to work alone
and do everything yourself. basements and garages do _not_ beat a corner
office and an efficient secretary. you actually do get a lot more done
if you hire people who are smarter than yourself at whatever they are
doing than you would be yourself. rewarding competence is the best way
to ensure that the team's competence increases, but it's sadly out of
vogue in a world of programming where it matters more that people can be
replaced than that they do outstanding work, because they will leave and
need to be replaced, and the next guy won't be able to figure it out.

if, out of 25,000 people who write you with a desire to learn more about
your software, you don't get 250 "hi, I want to work for you" and manage
to take proper care of those people, you're doing something _very_ wrong.

however, I wouldn't hire people who only see problems and refuse to check
whether the rest of the world perhaps would have to change somewhat if
you changed one particular factor. hell, even the free software/open
source change has a whole lot of ramifications, not all of them equally
apparent, but I guess I'm used to thinking in terms of cascading changes
and see that there's no way we can avoid serious scaling problems if a
lot of people get access to an insurmountable heap of inaccessible source
as the answer to their _real_ need: software that should fade away into
oblivion (i.e., not stand out and demand attention) and just do whatever
it is intended to do, seemlessly and according to how people find most
beneficial and productive on their own terms. this kind of software will
not happen if a whole lot of people value access to source code above all
and want their mark on software that stands out and demands attention
like a laser beam right into your eye. we need to work on something much
bigger than one person's individual egoboost. it's _incredibly_ hard to
do that reliably without forming a loyalty that lasts beyond the feeling
you get from seeing your name in a ChangeLog entry. and worse, you don't
_want_ to work with people who aren't loyal to the goals you have set for
your project. if you can't get rid of destructive people, you will have
very little time available to keep going in the right direction. this is
also something you learn PDQ if you try to run a business with employees.

let me put it this way: I dread the situation where software is written
by people who are satisfied with name recognition and status among their
peers -- we'll just get MS-DOS all over again. granted that we live in a
culture that adores youth and reveres immaturity as a deity, but if
everyone who succeeds in any way loses their position to someone younger
than they were when they were recognized, it isn't just a whole lot of
disillusioned people we have to deal with: those who aren't wiz kids in
time won't even have a brilliant flash of youth to look back at.

I'll do a giant leap to something entirely different: I think a whole lot
of the issues that plague the world today is based squarely in a rampant
fear that the world will end _very_ close to 2000-01-01. Y2K is nothing
more than fin-de-sičcle all over again, as far as the societal response
is concerned -- technically nothing important will go wrong. reverence
for youth is a pretty good sign people don't think they'll get old. what
better way to go than when listening to Abba revived by some jail bait?
I think when the world wakes up with a huge hangover near 2000-01-05 and
start to realize that the only thing that really ended was the _hope_
that the world would end and we wouldn't have to take care of things for
the next 50 to 80 years of our lives, a whole lot of people will start to
work and value things very differently from what they do now. when the
world doesn't end and we aren't plunged back to the dark ages because the
entire world electricity system didn't fail, after all, I predict that
all the crap we're doing now with a three-month horizon at most will take
on much longer horizons, again, like 50 years. there are some signs that
some people think like this already: a publisher in Norway has decided to
revamp their renouned 16-volume encyclopędia of world history and publish
a special hand-made leather-bound edition in only 2000 copies to those
who think it's important to maintain excellent craftmanship and some of
the traditions of the millennium past. they used to say that nostalgia
was better in the old days, but I think it'll get better and better in
the coming years... but, anyway, let's get this millennium nonsense over
with so we can get back on track. we have work to do, damnit.

Erik Naggum

unread,
Aug 27, 1999, 3:00:00 AM8/27/99
to
* Christopher Browne
| In short, the situation where source access causes problems appears to
| represent a rather peculiar scenario that is not representative of any
| widespread phenomenon.

someone here accused me of confusing fact and right, but I think what you
have posted is just that. I have no interest in discussing numbers of
people or magnitude of practical problems. my interest is on an entirely
different axis: dynamism in software. it's right up there in the subject
line, too. I'm arguing that those who want dynamism and think they need
source code will get less dynamism when they get source code than a they
would if they (1) chose a dynamic programming language and (2) could do a
lot of interesting things without source code. we are obviously not
talking about people who do not benefit from source code because they
don't own computers, either, and frankly, I don't understand the point of
arguing about "source access vs dynamism" in such terms.

my purpose was to show that people _need_ dynamism in their software,
which you might of course argue against by saying that only N people do
it and the rest are happy without it, but I only care about those N
people in my argument. I argue that those N people will not learn to
write dynamic software that can adapt without source access or even at
runtime because they have source access and think that's great, when it's
only great compared to _not_ having source access -- it is not great
compared to having fully dynamic behavior in the software, and since they
are used to 10% dynamism-via-source-code-in-static-language and don't
even see what 40% dynamism-via-dynamic-languages-without-source would
mean for them or even 90% dynamism-via-dynamic-languages-with-source in
the case where you can experiment with a change to a function in a
running system.

I honestly wonder why so many people don't see the dynamism argument and
only latch onto the source access argument. is it because people don't
really know why they want source access? Christopher's argument appears
to be that it isn't needed. my argument is that people who don't need
source code still need dynamic behavior. take GNU grep. wouldn't it be
great if you could make GNU grep always print the filename with an option
instead of tacking on /dev/null at the end like Emacs does? wouldn't it
be great if you could instruct GNU grep to default to case-insensitive
searches? how about enclosing the filename in double quotes so Emacs can
find matches in files that happen to contain colons in their names?
these would be simple local patches in a dynamic system, but it may just
be too much work to fix the source, submit a patch, and argue for the new
features. as you correctly observe, local fixes die with source access,
but if the fixes are in the form of manageable advise code, they would
survive an upgrade. again, dynamic languages win on all points, but
since people have source access, they won't think they need it, even with
the many problems caused by source access, such as the ones you bring up.

#:Erik

Erik Naggum

unread,
Aug 27, 1999, 3:00:00 AM8/27/99
to
* User Knotwell <knot...@knotwell.ix.netcom.com>

| I'm trying to understand your point of view. Based on your posts on this
| topic, it appears to me that you're advocating for source access based on
| merit and/or investment. What is your reasoning for this position?

I'm advocating source access to people who express an actual desire and
need for it. "investment" here isn't monetary, as in "an investment of
time and effort", but a concern that one has limited resources and want
to maximize the value of using those resources. without a sense of
"investment", people are likely to waste what they get.

| 1) inexpensive. I've always been amazed by the people who try to make


| out that this isn't a big motivator. Does anyone else but me snort
| when they see a comment like "I'd pay for it even if it wasn't free?"

of course it's a big motivator for the users. who argues against that?

| 2) lacking in administrative bullsh*t. IBM's C compiler for the RS/600


cost $400. Personally, I don't care about the $400 (a cost of doing
business). On the other hand, I do care about having to chase down a
PO. I do care about having to install a goofy-a** license monitor to
make sure I don't do something evil. Similarly, I do care about
having to call IBM sales support to get a new license key when we
decide to move development to a new box with a faster network
card. . .I could go on, but I'm even starting to bore myself :-).

of course it helps to deal with non-stupid people. however, there are
lots and lots of license-restricted software products that doesn't need
any of this administrative bullshit. if "PO" is a Purchase Order, it is
unclear to me whether that is a requirement of IBM or of your company. I
have worked for companies where senior programmers are given budgets to
purchase tools and time alotments attend courses without individual
management approval.

| 3) generally tailored towards use on commodity hardware.

this implies that commodity hardware would have been ignored if it
weren't for the current crop of freely available source-based tools. I
don't think this is the case. the quality of implementation may be an
issue, but SCO Unix and even SUN Solaris for Intel are certainly present
in the market.

| 4) another tool in the fight against getting jabbed by your vendor. To


be honest, I believe a better tool in this fight would be open,
understandable data formats so my data won't be held "captive" against
it's will.

well, I worked with SGML for half a decade because I believed it would be
a means to free the data, but that turned out to be false, it makes no
difference whatsoever. if your data should be less captive, I think the
way to go needs to be the ability to call functions to retrieve objects
and manage them. again, dynamic languages win big in my view. there
might be an issue of just how much you get access to even in a running
system, but at least the world isn't closed up.

I personally fail to see why people don't take this "getting jabbed by
your vendor" thing much more seriously. if you're afraid of it, and you
don't tackle the issue head-on, is it because you _fear_ the vendor? do
you actually _need_ products that will likely cripple you in the future?
(I don't think so.) have you ever talked to the vendor and expressed
your concern? if you haven't, do it now. if you have and was dissed,
why do you still deal with them? this is the labor union thing all over
again, except now with entities you'd expect were able to defend their
own interests much better.

| 5) community-oriented. From what I can tell, open source projects tend


to do an extremely good job of putting "customers" and developers
together. On the other hand, most commercial companies where I've
worked went out of there way to keep developers and customers apart
(counter-productive in my view).

yup, counter-productive in the extreme. if you use a software tool for
developers, and you can't talk to the developers of the tool, you have
made a mistake in purchasing it. however, this is not a function of
source access, but of smart people who actually care about what they do.

you have pointed at several issues that point to why people should choose
source-based products instead of shrink-wrapped products, and I agree
with all of them, but at issue is not source vs shrink-wrap, in my view:
at issue is a lot of incompetent people who are mortally afraid that if
anyone saw their source, they'd be exposed as the frauds they are, and I
actually believe that a certain major software company in Redmond, WA,
would be history the day its sources were released in a much more
important sense than any other company would fold if its trade secrets
were dispersed. I have argued elsewhere that I think a big motivator in
the source-based software world is legitimate rejection of said company
and its extremely predatory behavior. however, defense against idiocy
and evil is not an end in itself -- you have to have a pretty clear
picture of what you're fighting _for_. while destroying a company that
has defrauded millions if not a billion of people is a very worthy goal,
we need to consider what comes after it, and we need to consider what we
want to accomplish when the idiotic evil is gone, otherwise, we'll just
give rise to another.

| Why do I get the feeling I'll regret this?

beats me. and you don't come with source, so I can't fix your problem.

Francois-Rene Rideau <I+fare+WANT@tunes.NO.org.SPAM>

unread,
Aug 27, 1999, 3:00:00 AM8/27/99
to
Dear Erik, dear readers,

Erik Naggum <er...@naggum.no> writes on comp.lang.lisp:

> I'm advocating source access to people who express an actual desire and
> need for it.

So am I. The question I raise is: "who'll be judge?".
In one case, it'll be an all-mighty centralized marketing department,
and in the other case, it'll ultimately be the person in need oneself.
Of course, in a perfect world, the person in charge will choose well;
but in a perfect world, the person won't need to be in charge, either.
So the question is about the dynamic effects in an imperfect world:
what attitude has most positive dynamic effects?

It looks like to me the "make people responsible and trust them" attitude
is the winning one. You said it many times about the CL vs C++ attitude:
CL trusts the programmer, whereas C++ distrusts them, and the result is
trustworthy CL programmers, and untrustworthy C++ programmers.
The same argument applies to free software vs proprietary software.

There will always be stupid and evil people; no policy will prevent that.
The question is how to make such people harmless to anyone but themselves.
Reminds me quite of F.A.Hayek's "the Road to Serfdom"...

> of course it helps to deal with non-stupid people. however, there are
> lots and lots of license-restricted software products that doesn't need
> any of this administrative bullshit.

And again comes the question of trust and guarantee:
you may have quite non-stupid partners today that provide
great software with great service.
But what if their marketing department decides that this software
is no more profitable and will no more be supported?
With free software, you just move to another service provider
(who may perhaps hire the employees of the former company).
With proprietary software, you just bite the dust;
no possible long-term warranty.

Former ILOG LISP users and developers unhappily know _perfectly_ well
what I'm talking about...
The motto of the AFUL is "liberté, stabilité, perennité":
liberty, stability, perenniality.
Oh, and if what the company sells that has so much value
is their great service, then it has nothing to fear
from "competitors" who'd just sell unsupported copies of the software...

> I personally fail to see why people don't take this "getting jabbed by
> your vendor" thing much more seriously. if you're afraid of it, and you
> don't tackle the issue head-on, is it because you _fear_ the vendor? do
> you actually _need_ products that will likely cripple you in the future?
> (I don't think so.) have you ever talked to the vendor and expressed
> your concern? if you haven't, do it now. if you have and was dissed,
> why do you still deal with them? this is the labor union thing all over
> again, except now with entities you'd expect were able to defend their
> own interests much better.

Yes, we do fear the vendor. And every vendor behaves the same,
so you don't get much choice with proprietary software.
Think of it as meme stability: the meme of dissing users
is co-stable with the meme of proprietary software,
but not quite so with the meme of free software.
We DO organise in unions to fight vendors who diss us,
and the result is called (surprise!) free software.

> | 5) community-oriented. From what I can tell, open source projects tend
> to do an extremely good job of putting "customers" and developers
> together. On the other hand, most commercial companies where I've
> worked went out of there way to keep developers and customers apart
> (counter-productive in my view).
>
> yup, counter-productive in the extreme. if you use a software tool for
> developers, and you can't talk to the developers of the tool, you have
> made a mistake in purchasing it. however, this is not a function of
> source access, but of smart people who actually care about what they do.
>

Again, see meme co-stability. Working with the developers
is not co-stable with proprietary software,
all the less as the software spreads and is used by more and more people.
I can't imagine one's favorite C compiler vendor providing developer contact
to all its customers, there are too many of them.
CL dooms itself in being a fringe language
if it claims providing this contact.
With widely spread proprietary software,
developer contact is part of the cost structure,
and is fought against by management.
With widely spread free software, developer contact is a service
that you sell; it's part of the profit structure and sought by management.

> you have pointed at several issues that point to why people should choose
> source-based products instead of shrink-wrapped products, and I agree
> with all of them, but at issue is not source vs shrink-wrap, in my view:
> at issue is a lot of incompetent people who are mortally afraid that if
> anyone saw their source, they'd be exposed as the frauds they are, and I
> actually believe that a certain major software company in Redmond, WA,
> would be history the day its sources were released in a much more
> important sense than any other company would fold if its trade secrets
> were dispersed. I have argued elsewhere that I think a big motivator in
> the source-based software world is legitimate rejection of said company
> and its extremely predatory behavior.

> however, defense against idiocy
> and evil is not an end in itself

No, but it's a necessary _beginning_.
Without it, don't even try to go further.

> -- you have to have a pretty clear
> picture of what you're fighting _for_.

Indeed. Free software is not the end-all, only the begin-all.
Dynamic software WILL win; it will win WITH free software, not against it.
Proprietary software has brought upon us the domination of
FORTRAN, COBOL, PL/1, C, C++. Static languages.
Free software has always developed its dynamic tools:
LISP (pre-Common; elisp; Scheme), shells, Perl, Python, etc.
Dynamic languages (of various quality).

Of course, there are exceptions: CommonLISP and Dylan are dynamic languages
that have been mostly developed as proprietary systems
(despite heroic free implementations); but they have limited success
among proprietary systems; they don't fit the proprietary software model
of separation between provider and consumer.
On the other hand, there are static free languages (SML, OCAML, Haskell),
but even they have interactive top-levels,
and they have a hard time capturing free software developer mindshare.

> | Why do I get the feeling I'll regret this?
> beats me. and you don't come with source, so I can't fix your problem.

And the fact that he does not come with source is just a fact of nature,
so there's nothing we can do, and we should think about real problems.
On the other hand the unavailability of source of computer software
is _not_ a fact of nature; it _is_ a problem, and it can be solved.

Best regards,

[ "Faré" | VN: ĐŁng-Vű Bân | Join the TUNES project! http://www.tunes.org/ ]


[ FR: François-René Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics | Project for a Free Reflective Computing System ]

..so that IBM Java envangelist tells me "nothing spread as fast as Java",
to which I answer: "crack!"...

Kent M Pitman

unread,
Aug 27, 1999, 3:00:00 AM8/27/99
to
far...@SPAM.tunes.org (Francois-Rene Rideau <I+far...@tunes.NO.org.SPAM>) writes:

> Dear Erik, dear readers,
>
> Erik Naggum <er...@naggum.no> writes on comp.lang.lisp:
> > I'm advocating source access to people who express an actual desire and
> > need for it.
> So am I. The question I raise is: "who'll be judge?".

Traditionally, money.

Money is simply an interchange medium for "stuff I'm interested in"
and "stuff you're interested in". If you do something in
life--anything--that someone else really wants, they'll give you money
for it. If they won't, you have to question whether they want it.

You can create barter systems in which money is not exchanged, but they
are hard to account for and you get people who don't pull their weight.
That's why the world uses money and not smiles as a way of counting who's
done what for who.

So if you're willing to trade the money you have for someone else, all
that says is that it's of value to you. And if you're not, then maybe
it's not as much of value as you think.

If people are willing to give away what they do, that's fine. That
just means they don't value it or they have enough money that they
don't feel a need to charge for everything they do. One would hope
that all people could be philanthropic sometimes. But they have to
eat and I don't see giving them a hard time about that.

> In one case, it'll be an all-mighty centralized marketing department,
> and in the other case, it'll ultimately be the person in need oneself.

It doesn't really matter because it is not your fundamental right to have
me do anything for you. It is my right to make something if I see the point
and not to otherwise. The thing that drives me nuts about these discussions
is how many people seem to think they have a right to something I make just
because I create it. If the world were that way, I'd probably create
fewer things. I would instead use my brain to seek out some way to do
something that would let me eat. I would not spend the same fraction of my
day thinking up good ideas and giving them away and still being hungry.

> Of course, in a perfect world, the person in charge will choose well;

Who are you to say he hasn't. It isn't your right to it until you've ante'd
up the interchange currency (money) for exprssing interest.

> but in a perfect world, the person won't need to be in charge, either.

This is a completely arbitrary and self-serving claim.

> So the question is about the dynamic effects in an imperfect world:
> what attitude has most positive dynamic effects?

Right. And I claim the one that has the most postiive dynamic effect is the
one that incentivizes content creators. Content consumers, the ones who want
to USE free stuff, don't need an incentive. And if you're a legitimate
content creator who can't get access to something, you'll just create
something else. True content creators are versatile and capable of creating
lots of things.

Now, I agree completely that the idea of restrictions on "independent
creation" (software patents) are a nuissance that should be struck
down because they arbitrarily and capriciously restrict the right of
an alternate content creator to show that an idea wasn't as hard to
come up with as the original creator thought. But that's where I stop
in the "free software" area.

> It looks like to me the "make people responsible and trust them" attitude
> is the winning one.

I think once the bills are paid, responsibility is not the issue in
"acquisition" of software. (It might be in the choice of deployment.
My concern about software ethics has little to do with how people "modify"
software but whether they make good ethical use of modified software.
And this is orthogonal to copyright concerns.)

> You said it many times about the CL vs C++ attitude:
> CL trusts the programmer, whereas C++ distrusts them, and the result is
> trustworthy CL programmers, and untrustworthy C++ programmers.
> The same argument applies to free software vs proprietary software.

I can't find a useful structural basis for believing this analogy holds.
The mere use of the same multi-meaning word in a sentence seems a weak
basis for believing an analogy will hold up. Perhaps you can expand on
what structural basis would give you confidence in this analogy other than
that you like the outcome if the analogy is allowed to let stand.

> [...] Yes, we do fear the vendor.

I find the idea of fearing a content creator offensive. Content creators
have no obligation to make you anything at all. Fearing them is being mad
at them that when they gave you something, they didn't give you twice as
much. That is nothing more than rude in my book. No one makes you buy
from them at all.

> Working with the developers

[who did not have to develop this for you and you're lucky did]

> is not co-stable with proprietary software,
> all the less as the software spreads and is used by more and more people.

Then don't use it.

> CL dooms itself in being a fringe language
> if it claims providing this contact.

This is a possible truth, but is not because of right or obligation.
This is the first statement I've seen in here which was focused on effect
rather than right. Nothing I've said should be taken to mean that I don't
think that a content producer doesn't have to meet a certain expectation
level with their product in order to sell it. You can't make a paperweight
and sell it for a hundred dollars; you have to motivate the public to buy
it at that price (as with the "pet rock" marketing plan) or you have to
drop the price. But that "have to" is not a law; it's just an economic
reality. I personally think that some Lisp implementations right now are
overpriced because the languages that are creaming it in the marketplace
are much lower in price, and I think prices have to normalize if the vendor
is to survive. But it is the right of the vendor to disagree, as long as
they like the consequences (which may be "getting rich" because I was wrong
or may be "going out of business" or "eventually dropping the price"
because I was right--or because some other market problem I didn't see
covered over my reasoning error and still made me look like a good predictor).
I don't think it's any vendor's moral or ethical or legal obligation to do
any price with me; my argument is simply based on common sense and not a
"fear of vendors" but a "fear for them" because I care about them and want
them to have many years of happy vending at a proper price point--one that
is non-zero enough to get them life support money and not so high that it
drives my employer to want to use Java instead. Free CL, btw, is NOT where
my employer will go instead.

> With widely spread proprietary software,
> developer contact is part of the cost structure,
> and is fought against by management.

This seems an arbitrary and statistically unsupported claim.

> With widely spread free software, developer contact is a service
> that you sell; it's part of the profit structure and sought by management.

This seems an arbitrary and statistically unsupported claim.
I don't see any reason this can't be true of commercial companies.
Nothing about commercial software says that a company couldn't charge for
developer access. If there are a small number of developers, it's likely
that the inability to clone them creates the real upper bound on access to
them, regardless.

> [...] Dynamic software WILL win; it will win WITH free software,
> not against it.

This is a possible truth but not a necessary truth. There are strong
reasons already cited elsewhere to believe Dynamic Software is more
compatible with proprietariness than Static software is. It can be
composed in a mix and match environment without opening the hood,
pretty much like components in your stereo (where most people don't
look inside either) and where a healthy cost per component doesn't
keep the industry from thriving.

> Proprietary software has brought upon us the domination of
> FORTRAN, COBOL, PL/1, C, C++. Static languages.

I don't know what this claim is based on. I thought some of these
languages came free with operating systems and that all you paid for
was the iron back in the days these things gained dominance. I might
be wrong. Also, people made new languages every day back then and
most of those new languages were not charged for. If free software
had been such a win, it would have clobbered those languages.

> Free software has always developed its dynamic tools:
> LISP (pre-Common; elisp; Scheme), shells, Perl, Python, etc.
> Dynamic languages (of various quality).

I think this particular way of drawing up the facts looks suspect.
I just don't see that the big line has been proprietary/free.
What I see is that developers who had their food bills paid have
contributed interesting things beyond what industry offers, and that
dynamic is beyond the edge of what industry offers because static is
easier to understand. So basically, just as "art" is easier for the
elite to make because they're not busy toiling in the fields every day
and not so exhausted at day's end that they can't paint, so too
dynamic software is the fruit of the FORTRAN/COBOL industry you're
poo-pooing. It may be cool, but it's interest in accounting programs
(largely business) and physics simulation software (largely DoD)
that paid the bills for a long time, fueling the industry to live
long enough to be able to generate people with computers at all and
knowledge at all that allowed the creation of most of these other
things.

> Of course, there are exceptions: CommonLISP and Dylan are dynamic languages
> that have been mostly developed as proprietary systems
> (despite heroic free implementations); but they have limited success
> among proprietary systems; they don't fit the proprietary software model
> of separation between provider and consumer.
> On the other hand, there are static free languages (SML, OCAML, Haskell),
> but even they have interactive top-levels,
> and they have a hard time capturing free software developer mindshare.

Possibly due to a lack of commercial market? Who wants to give away
time if they can't figure out where the dollars will come from?
Why does your whole analysis seem to neglect the importance of money to
these activities which consume large amounts of time and resources, even
if only at one's house?

> And the fact that he does not come with source is just a fact of nature,

It's possible, by the way, that nature found that if you did have the
sources available, a billion little free software viruses would be busy
attacking and you'd lose. I think it's an interesting aspect of human
construction that if they are broken up for disassembly, the running source
begins immediately to decay and to defy inspection. I have often wondered
if this doesn't make it the ideal medium for the distribution of software
in a world that doesn't respect intellectual property once it's been "let
out of the bag". Everyone is so excited they can just disassemble things,
that it seems likely to me we'll have devices with little acid packs in them
that try to burn themselves up if you open them. But a cellular "feed
me oxygen through a complex system of capillaries or I'll start decaying
immediately" model also has a certain elegance--and isn't so messy as acid.

> so there's nothing we can do, and we should think about real problems.
> On the other hand the unavailability of source of computer software
> is _not_ a fact of nature; it _is_ a problem, and it can be solved.

This is not a "problem", it is a problem solution in search of a problem.
I'm very skeptical of problems defined in terms of:

Problem: There is no x.
Solution: Make an x.

Suppose sources did exist to me. Can you explain, even approximately,
how your access to them would materially affect your chances of changing
my mind on this issue? And can you explain why if I thought myself
even remotely valuable I would share them with you? Wouldn't that just
allow you to make more of me or rogue variants of me that compete with me?
And wouldn't that just diminish my ability to say unique and interesting
things that people enjoyed reading, because a bunch of pitman-wannabes
would be out there generating syntactically similar tripe that made it hard
to find the "good stuff"? I just don't see the motivation.

And motivation is what it all comes down to. Because if you don't motivate
me with whatever scheme you make up, I'll go back to hoeing corn in the
fields. At least that will put food on the table. I have no obligation
to you or anyone to even make any software at all, much less give it away
the instant I make it.


Lieven Marchand

unread,
Aug 27, 1999, 3:00:00 AM8/27/99
to
Erik Naggum <er...@naggum.no> writes:

> * User Knotwell <knot...@knotwell.ix.netcom.com>


> | 5) community-oriented. From what I can tell, open source projects tend
> to do an extremely good job of putting "customers" and developers
> together. On the other hand, most commercial companies where I've
> worked went out of there way to keep developers and customers apart
> (counter-productive in my view).
>
> yup, counter-productive in the extreme. if you use a software tool for
> developers, and you can't talk to the developers of the tool, you have
> made a mistake in purchasing it. however, this is not a function of
> source access, but of smart people who actually care about what they do.
>

I have often found, contrary to Mr. Knotwell's experience, that it is
fairly easy to get in touch with the developers of various software
products. In general, these people are protected by a helpdesk to weed
out idiot questions, but once you have demonstrated on a few support
calls that you know what you are doing and that you're capable of
consulting the documentation before raising bug reports, you get
direct telephone or email access to the development department.

I also found that this is often far more useful than source access. If
you describe the symptoms of a bug to a developer he will often know
immediately where or what is the problem. Even with source, it would
take a large investment of my time to get that familiar with the code.

This also happens in the open source world. Far more bugs get resolved
by people like Alan Cox for Linux or Jeff Law for gcc through bug
reports on the mailing lists than that the user who found the bug
starts digging through the code himself. The only reasons this doesn't
work very well for most of the closed source proprietary software is
that it is written in a language like C without much debugger support
to generate useful bug reports and that a lot of firms ship their
stuff without even that meager support by stripping the executable of
all debugging symbols. Since dynamic languages generally have
excellent support for this without having source, I think Erik has a
point.

--
Lieven Marchand <m...@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker

Vassil Nikolov

unread,
Aug 28, 1999, 3:00:00 AM8/28/99
to comp.la...@list.deja.com
Erik Naggum wrote: [1999-08-27 00:47 +0000]

|...|


> also something you learn PDQ if you try to run a business with employees.

|...|

PDQ: pretty damn quickly?

Erik Naggum

unread,
Aug 28, 1999, 3:00:00 AM8/28/99
to
* Vassil Nikolov <v...@einet.bg>
| PDQ: pretty damn quickly?

yes.

incidentally, can you please fix the bug in your newsreader which causes
it to copy the References header unchanged from the article you respond
to if it has any and only do the right thing when it has none? it is
annoying that it doesn't work to go back to the article you replied to
and the threading in other newsreaders gets all messed up, too. thanks.

Gareth McCaughan

unread,
Aug 28, 1999, 3:00:00 AM8/28/99
to
Erik Naggum wrote:

[to Vassil Nikolov]


> incidentally, can you please fix the bug in your newsreader which causes
> it to copy the References header unchanged from the article you respond
> to if it has any and only do the right thing when it has none? it is
> annoying that it doesn't work to go back to the article you replied to
> and the threading in other newsreaders gets all messed up, too. thanks.

Eh?

References header of Vassil's article to which you were replying:

| References: <31444041...@naggum.no>
| <37C17E00...@elwood.com>
| <_Mfw3.358$m84.6201@burlma1-snr2> <31445586...@naggum.no>
| <u7ogfwc...@ebi.ac.uk> <31445696...@naggum.no>
| <l03130309b...@195.138.129.122>
| <pw-260899...@166.84.250.180>

References header of its parent article (reformatted a little):

| References: <31444041...@naggum.no> <37C17E00...@elwood.com>
| <_Mfw3.358$m84.6201@burlma1-snr2> <31445586...@naggum.no>
| <u7ogfwc...@ebi.ac.uk> <31445696...@naggum.no>
| <l03130309b...@195.138.129.122>

The last item in the References of Vassil's article is the Message-ID
of the article to which he was replying. This all looks perfectly
in order to me.

--
Gareth McCaughan Gareth.M...@pobox.com
sig under construction

Stig Hemmer

unread,
Aug 28, 1999, 3:00:00 AM8/28/99
to
Gareth McCaughan <Gareth.M...@pobox.com> writes:

> Erik Naggum wrote: [to Vassil Nikolov]

> > please fix the bug in your newsreader

> Eh?
[...]


> References header of its parent article (reformatted a little):

[...]


> The last item in the References of Vassil's article is the Message-ID
> of the article to which he was replying. This all looks perfectly
> in order to me.

Look closer. The article you call its parent article is, in fact, not
the article to which Vassil Nikolog is replying.

Stig Hemmer,
Jack of a Few Trades.


Gareth McCaughan

unread,
Aug 28, 1999, 3:00:00 AM8/28/99
to
Stig Hemmer wrote:

[I said:]


>> The last item in the References of Vassil's article is the Message-ID
>> of the article to which he was replying. This all looks perfectly
>> in order to me.
>
> Look closer. The article you call its parent article is, in fact, not
> the article to which Vassil Nikolog is replying.

Oooops. Quite right. I'm a twit. My apologies to #\Erik.

Christopher Browne

unread,
Aug 28, 1999, 3:00:00 AM8/28/99
to
On Fri, 27 Aug 1999 13:50:56 GMT, Kent M Pitman <pit...@world.std.com> wrote:
>far...@SPAM.tunes.org (Francois-Rene Rideau <I+far...@tunes.NO.org.SPAM>) writes:
>
>> Dear Erik, dear readers,
>>
>> Erik Naggum <er...@naggum.no> writes on comp.lang.lisp:
>> > I'm advocating source access to people who express an actual desire and
>> > need for it.
>> So am I. The question I raise is: "who'll be judge?".
>
>Traditionally, money.
>
>Money is simply an interchange medium for "stuff I'm interested in"
>and "stuff you're interested in". If you do something in
>life--anything--that someone else really wants, they'll give you money
>for it. If they won't, you have to question whether they want it.
>
>You can create barter systems in which money is not exchanged, but they
>are hard to account for and you get people who don't pull their weight.
>That's why the world uses money and not smiles as a way of counting who's
>done what for who.

Which is good comment, and I would generally agree with the notion
that using money as an expression of value is a good idea, since "an
expression of value" truly is the nature of money.

That calls into question:
"So why does it seem to be economically viable to give away
computer software, particularly in source code form?"

The answers seem to me to lie in the legal gyrations that surround the
"licensing" of the things that get called "intellectual property."

It may be pretty easy to take a slab of steel, kick it, and say "That
slab is worth $50,000, and if you sign a purchase order, you can have
it."

In contrast, it is vastly more difficult to work out the value of
giving somebody a copy of the source code to Emacs, as the results of
giving that to them can vary dramatically based on what they do with
it.

So we head down the path where no decisions can be made without having
a veritable army of lawyers examine the situation, and put their seal
of approval on the notion that the parties have made a legal agreement
to transfer source code from A to B with some precise set of legal
restrictions on what they can do with the results.

The "barter" of free software may not look economically efficient from
some perspectives, but if the alternative involves paying an army of
lawyers, and then having to set up a cryptographically strong License
Management system, the inefficiency of barter starts to look not
nearly so bad...
--
ITS is a hand-crafted RSUBR.
cbbr...@ntlug.org- <http://www.hex.net/~cbbrowne/lsf.html>

Christopher Browne

unread,
Aug 28, 1999, 3:00:00 AM8/28/99
to
On 27 Aug 1999 08:56:48 +0000, Erik Naggum <er...@naggum.no> wrote:
>I honestly wonder why so many people don't see the dynamism argument
>and only latch onto the source access argument. is it because people
>don't really know why they want source access? Christopher's
>argument appears to be that it isn't needed. my argument is that
>people who don't need source code still need dynamic behavior. take
>GNU grep. wouldn't it be great if you could make GNU grep always
>print the filename with an option instead of tacking on /dev/null at
>the end like Emacs does? wouldn't it be great if you could instruct
>GNU grep to default to case-insensitive searches? how about
>enclosing the filename in double quotes so Emacs can find matches in
>files that happen to contain colons in their names? these would be

>simple local patches in a dynamic system, but it may just be too much
>work to fix the source, submit a patch, and argue for the new
>features.

This strikes me as being a fair bit like the OS argument of
microkernels versus monolithic kernels.

Microkernels are (at least in potential, if not always in practice)
more dynamic; the academics have commonly denigrated the monolithic
approach as "passe," and the Torvalds-versus-Tanembaum "flame war" was
pretty exemplary in that regard.

It strangely enough turns out that it is almost as easy to add some
modularity to the monolith and let it do the things that they thought
only a microkernel could do; Linux kernel modules being the canonical
example of this.

With regard to the "grep" issues, it is not difficult to provide a
parallel to "dynamism" via constructing script-based functions to add
suitable filters.

- If I want a grep that defaults to be case insensitive, that is as
easy as "alias grep='/usr/bin/grep -i'"

- If I want a grep that encloses filenames in quotes, and I'm quite
sure I follow your thinking there, my first thought would be to put
a thin layer of Awk/Python/Perl on top that does suitable parsing of
the results.

That is not precisely the same as what one might do with some
equivalent to Emacs "hooks;" it functions all the same, and provides a
form of equivalence.
--
"Surely if the world can't get any other benefit from the existence of
Microsoft, at least people should stop arguing that popularity has any
connection with merit!" -- Brian Harvey <b...@anarres.CS.Berkeley.EDU>
cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>

Erik Naggum

unread,
Aug 28, 1999, 3:00:00 AM8/28/99
to
* Gareth McCaughan <Gareth.M...@pobox.com>

| Oooops. Quite right. I'm a twit. My apologies to #\Erik.

that's OK, but it's been a while since I signed off with #\Erik. ;)

Erik Naggum

unread,
Aug 28, 1999, 3:00:00 AM8/28/99
to
* Erik Naggum

| nor do I understand why people individually accept so horrible working
| conditions that they have to form labor unions so they don't have to
| accept them, anymore, but I digress.

* Erann Gat
| It's because for some people the alternative is to be destitute.

no, that is not the explanation, although some would have you believe
that people can be forced to accept anything under threat of becoming
destitute if they don't. the problem is not that they would become
destitute, but that they want something so badly they will accept the
worst possible conditions because there's something at the other end to
hope for. some people are good at defrauding people of their present and
future in this particular way, but I wonder why so many fall for them.

at issue is why people "invent" solidarity at the wrong time and accept
absolutely everything as long as they are alone, but speak up only when
they think they can gang up on others, and especially why they have to
wait until things are really, really horrible before they react. this is
the stuff I don't understand.

historically, labor unions arose when people had gotten a taste of a
different lifestyle and were willing to pay a lot more for their basic
livelihood and had gotten into a fix they couldn't get out of -- because
they had accepted the unacceptable to begin with. accepting something
you have to form a labor union to fight after the fact only tells me that
people were acting against their own best (or even good) interests for a
long time. I don't see any rational, coherent explanation for this sort
of behavior in humans, but it's all over the place.

I guess it's the same basic argument as "yes, we do fear the vendor": a
complete failure to grasp that the roles people play in a complex society
do not change their nature or (other) qualities as humans beings. why do
people give their money to people they fear will screw them in the future
_because_ they have given their money to them in the past? don't they
_see_ that their capacity to screw them and hence their fear of them, is
a function of giving the wrong people money to begin with? Microsoft is
the ultimate fraud operation, but it's always extremely easy not to get
defrauded: just don't deal with them at all. if you fear you will be
screwed by someone you deal with, whoever forces you to deal with them?

here's my line: don't _ever_ grin and bear it, speak up when you aren't
happy with what you experience. you'll piss a lot of people off for a
while until they figure out that you are actually very happy when you are
happy with things and that most things actually do improve when you care
to express your concern, and then it dawns on a few people that _because_
you consistently speak up, you don't bear grudges or get bitter at people
for not caring. if you can't accept something, don't. don't prostitute
yourself because you want something you can't have without prostituting
yourself -- just stop wanting it when you realize what you'll have to go
through to get it. reject the "future religion" which attempts to tell
people they should accept to suffer now because some future will be so
good: somebody is ripping you of your present if you believe that crap.
if you _don't_ accept to suffer now, the historic evidence shows that the
future _will_ be better. the good future doesn't _come_ to people who
sacrifice today for any rosy promise of a better tomorrow, because there
will _always_ be a "today" that can be sacrified to a "tomorrow", and if
somebody, such as Bill Gates, benefits from your naïve belief in this,
they _will_ rip you off again and again, and the future never comes, it
will remain "the future" for as long as you believe in it. only when you
stop believing in the unreasonably brighter and better future do you have
a shot at improving the present.

Erik Naggum

unread,
Aug 28, 1999, 3:00:00 AM8/28/99
to
* Francois-Rene Rideau

| It looks like to me the "make people responsible and trust them" attitude
| is the winning one. You said it many times about the CL vs C++ attitude:
| CL trusts the programmer, whereas C++ distrusts them, and the result is
| trustworthy CL programmers, and untrustworthy C++ programmers. The same
| argument applies to free software vs proprietary software.

although I have not made the point specifically here, my preferred way to
get one's hands on an exportable subset of the source code is to sign a
prewritten (i.e., non-negotiable) license agreement and go from there.
at issue here is two things: (1) you need to establish sufficient need
and desire to at least read and sign a license agreement, and (2) the
owners of the source code knows who you are and what you have obtained.

on earlier occasions I have briefly discussed how I want things to work
out, in a few classes of users: class A users receive the product and
direct support, only. class B users obtain some source for their own
education and use, persuant to executing a license agreement. class C
users obtain more source and are encouraged to submit fixes, which they
continue to own separate rights to. class D users join the developer
team as volunteers, and still retain their rights. class E users get
paid to fix problems they find and may even get paid to fix problems in
their fields of expertise on demand from the vendor, but as soon as they
get paid, they agree to relinquish the rights to whoever paid them. all
through this scheme, exchange of actual values is an essential ingredient.

| But what if their marketing department decides that this software is no
| more profitable and will no more be supported?

then you either have a breech of contract situation or you go talk to
them and make it profitable. this happens all the time in the world of
actual businesses. part of the deal with bankruptcy and reorganization
is to let creditors recover their money, and only a few creditors will
consciously and purposefully deny themselves the opportunity to recover
more rather than less money. you'd be surprised how much of a company's
assets you can get your hands on if you make like a vulture and pick the
guts of dead companies. (yes, that's intentionally gross.)

| With free software, you just move to another service provider (who may
| perhaps hire the employees of the former company).

why is the parenthetical comment restricted to free software?

| With proprietary software, you just bite the dust; no possible long-term
| warranty.

just because you don't see any options doesn't mean someone else doesn't
see options that you are ideologically prevented from seeing. people
have been known to buy up parts of companies or their assets in the past.
it will happen again, I promise you.

and let me just ask you a simple question: what exactly do you need from
a company after you bought the software (or licence to same)? you keep
arguing on the one hand that you buy broken crap from fraudulent shops
that you subsequently fear will screw you even more, and on the other
hand you want long-term relationships with them? I don't get it. just
how desperately in need of this broken crapware do you believe you are?
and why don't you go talk to a shrink about this rather than believe that
this is due to something wrong with the entire world?

it appears to me that you want source so you don't get screwed, but it
seems to me that you're better off buying quality products to begin with,
stuff that actually continues to work for years and years because the
bugs you found and they fixed are not going to bite you again, and the
old software that needs the long-term warranty isn't likely to be in
active development and thus isn't likely to hit upon new bugs.

| Former ILOG LISP users and developers unhappily know _perfectly_ well
| what I'm talking about...

for any dire strait people _might_ get into, there's always someone it
actually happened to, and which you can blame on your favorite factor.
to people who know some statistics and propaganda, this is _supremely_
unconvincing. _nothing_ is less convincing in a debate than throwing
examples at eachother. it's what politicians do when they want votes
from people who don't know any statistics and don't grasp propaganda at
all, but why the hell should anyone except politicians care about such
driftwood in society? it's not like they are going to have any _say_ in
anything of importance, is it? if you want to argue effectively, aim for
the people who take increased insight away with them -- they will quietly
spread the word. if you want to argue to win _points_, however, I'd say
go for the examples, and the more emotional they are, the better, but at
least be _aware_ that they are competely ineffectual: whoever beats you
with another better example nullifies your point completely. that's what
_doesn't_ happen with insight: people don't un-see an old issues because
you bring up a new issue, you'll just have to keep adding to the insight.

so, how about the fate of Symbolics' Genera? as far as I hear from
people, somebody actually bought up the rights to the product and
continued to support and sell it, and they are constantly arguing that
it's the _best_ software environment in existence still. maybe ILOG was
a weak product with good marketing and management which could nonetheless
not sustain it, and Symbolics' Genera was an excellent product with weak
marketing and management that wiped out its financial foundation?

the interesting question with ILOG TALK is: would you, personally, have
started, or invested your own money in, a company that would do support
on it, if the software were freed now that it is defunct, anyway? if
not, who's to say the exact same fate would not have happened to a free
software project? just because it's free software doesn't mean it's free
of all the well-known consequences of human behavior.

| Oh, and if what the company sells that has so much value is their great
| service, then it has nothing to fear from "competitors" who'd just sell
| unsupported copies of the software...

I'll believe this when it comes from the owner of a business, not from
someone who very explicitly wants to loot businesses. in other words:
again, feel free to risk your own money, and shut up about others until
you have proven that you put your own money where your mouth is.

| Yes, we do fear the vendor.

thank you for stating this up front. now I know you're actually insane,
more specifically a raving paranoid.

| Think of it as meme stability: the meme of dissing users is co-stable
| with the meme of proprietary software, but not quite so with the meme of
| free software. We DO organise in unions to fight vendors who diss us,
| and the result is called (surprise!) free software.

and this ranting proves you've _really_ lost touch with reality.

| I can't imagine one's favorite C compiler vendor providing developer
| contact to all its customers, there are too many of them.

I'm sure that's how a lot of people think when they buy anything at all,
but you gotta understand that if you don't even try, and are so deranged
as to _fear_ your vendor, then you _will_ be treated harshly by the real
world, not because people want to, but because you set yourself up for it.

I actually think that fear of authorities of any kind should be listed as
a serious mental disorder that causes people to become dysfunctional in a
modern society. people who suffer from it should seek psychiatric care.

| Dynamic software WILL win; it will win WITH free software, not against it.

well, I have the exact opposite opinion, but at least I make an argument
for my case, I don't just repeat a mantra.

| Proprietary software has brought upon us the domination of FORTRAN,
| COBOL, PL/1, C, C++. Static languages. Free software has always
| developed its dynamic tools: LISP (pre-Common; elisp; Scheme), shells,
| Perl, Python, etc. Dynamic languages (of various quality).

this is downright ridiculous in its lack of adherence to fact.

Vassil Nikolov

unread,
Aug 29, 1999, 3:00:00 AM8/29/99
to comp.la...@list.deja.com
Erik Naggum wrote: [1999-08-28 10:21 +0000]
[in response to a posting of mine]

|...|


> incidentally, can you please fix the bug in your newsreader which causes
> it to copy the References header unchanged from the article you respond
> to if it has any and only do the right thing when it has none? it is
> annoying that it doesn't work to go back to the article you replied to
> and the threading in other newsreaders gets all messed up, too. thanks.

You are quite right that such behaviour is annoying, and I apologise for
all inconveniences caused.

I can't fix the program but I can fix the headers (or at least I believe
that will work, I'll test it now).

I would like to note that what actually happens is this: the message id
of the article that's being responded to is placed in the In-Reply-To
field, rather than appended to the References field. I admit I don't have
the time to locate the relevant RFCs to find out if this is a feature or a bug,
i.e. if this doesn't happen to be legal though strange.^1 Of course, that isn't
very important as the really important fact is that people using
non-broken software have not been getting the links between articles
right. (To be honest, I knew this but hoped that good newsreaders
would be smart enough to make use of In-Reply-To, but apparently
I assumed too much.)
__________
^1 I am posting via a mail-to-news gateway (Deja's), i.e. using an e-mail
program to send posts, so this might be fine for e-mail but not for
news

(By the way, this happens to be also an example where the problem could
be solved by having access to the source but where a solution using
dynamism would be better. In my particular case now, I have no source
available, and I fix the problem by modifying the file containing
the outgoing message---whether this qualifies as a dynamic solution,
I can't really say.)

Francois-Rene Rideau

unread,
Aug 29, 1999, 3:00:00 AM8/29/99
to
Dear readers,
I'm sorry about this much too long a message.

You know, it's hard enough to argue with two sets of arguments at once,
by two brilliant people (Erik and Ken), each with one's own personal mindset.
It leads to contorted messages that mix without matching
several points of views at once, and that hence are long and hard to read.
Since the debate has (once again) slipped from dynamic software
to free software, I propose that the latter topic be discussed outside
of comp.lang.lisp, for instance on the cybernethics mailing-list
http://lists.tunes.org/cgi-bin/wilma/cybernethics
(please propose other places where to move the debate, if you will).
Whatever messages remain on comp.lang.lisp should focus more
on the technical aspects (such as "what exactly is dynamic software?";
"what does it become in presence of concurrent and distributed systems?").

#f d
------>8------>8------>8------>8------>8------>8------>8------>8------>8------
T'was once said on comp.lang.lisp:
>: Kent M Pitman <pit...@world.std.com>
>>: Francois-Rene Rideau <I+far...@tunes.NO.org.SPAM>
>>>: Erik Naggum <er...@naggum.no>

>>> I'm advocating source access to people who express an actual desire and
>>> need for it.
>> So am I. The question I raise is: "who'll be judge?".
> Traditionally, money.

Bzzt, wrong! Money (as you put it below) is the _medium_
(a good one at that), but not quite the decision maker.
Don't confuse the messenger and the originator!
Mind you, there has always been money
in the Soviet Union and all communist countries
(communism has been arguably described as not opposed to capitalism,
but an embodiment of capitalism in its worst form, complete monopoly).
Money never decides. People decide, depending on price and expected value.
The adequation of price to value depends on the price of exchanged services
being freely negociated by both parties, as opposed to being biased
by the unilateral force of a monopoly, by the arbitrary decision of
a government, or worse, the totalitarian force of a monopolistic government.
So the question is not and has never been "is there a market?".
Of *course* there is a market, even if it trades sheep instead of coins!
The question is "how free is the market?".

> Money is simply an interchange medium for "stuff I'm interested in"
> and "stuff you're interested in". If you do something in
> life--anything--that someone else really wants, they'll give you money
> for it. If they won't, you have to question whether they want it.

Exactly. It is a _medium_. It changes _nothing_ to the wills and forces
in presence, it only fluidifies the dynamics of exchanges (which is a
great feat in itself, but completely independent from the issues at stake).

> You can create barter systems in which money is not exchanged, but they
> are hard to account for and you get people who don't pull their weight.
> That's why the world uses money and not smiles as a way of counting who's
> done what for who.

Sure. That is, when stupid laws don't force people to either exchange smiles
or do things in secret and risk jail, by making it illegal to exchange money
against some whole classes of services: see free trade vs customs & smuggling
or free entreprise vs governmental work & moonlighting,
or freely redistributable software vs software hoarding & piracy,
freely modifiable software vs illegal modification & binary patching,
freely understandable software vs illegal inspection & reverse engineering.

> So if you're willing to trade the money you have for someone else, all
> that says is that it's of value to you. And if you're not, then maybe
> it's not as much of value as you think.

Sure. Now, what if someone forces me to pay an extra fee for no service,
say the mafia who'll destroy my shop if I don't pay protection money?
Most people will just pay the money, all the more if they can say
"after all, it was not completely wasted, since they did not only
protect me, but they also did render a few useful services".
Of course, I could cease activity and close my shop, if I don't value
it that much. I could also let competition play, and ask the protection
of another gang. Or I could do it the hard way and fight the mafia,
by arming my family with guns, hopefully with the help of the police;
but no responsible head of a family would be the first to take that risk.
Worse even: sometimes, the mafia doesn't send mobsters to "explain"
what happens to your shop when you refuse to cooperate; instead they
send lawyers, and then they send the police if you still won't cooperate;
for they have found a way to get law with them rather than against them.
Of course, the worst situation is when political power itself is in the hands
of the mob, as inevitably happens after invasions and revolutions,
but that's another topic of discussion. Suffice it to say that again,
the root of the close match between price and value is in a free market.
If you read "das Kapital", you'll see that Marx founded his whole
"economical" theory by rejecting this basic principle, whereas this principle
is the crown jewel of Economy 101 (see against texts by Turgot and Bastiat).
Oh, and don't try to see more in these examples than a way to comment
on the _argument_ and its large domain of validity; they are in no way
a comparison with the specific case at hand.

> If people are willing to give away what they do, that's fine. That
> just means they don't value it or they have enough money that they
> don't feel a need to charge for everything they do. One would hope
> that all people could be philanthropic sometimes. But they have to
> eat and I don't see giving them a hard time about that.

Bzzt, wrong again! Free software is not, has never been, and
will never be against business. Quite on the contrary, it's all about
the free trade of _services_, and the end of licensing _racket_.
In the same way, those people who fight slavery, or pollution,
don't have anything against business per se, when they fight
slave-traders or polluting industries who make money out of these activities;
they have nothing against making money, only against the particular way
by which money is made, and only in as much as that way negates
fundamental rights of individuals, or global welfare.
They fight for individual rights and common interest, not against business.

Maybe current free software hackers have been working mostly for nothing,
but it's not been because they like it and want it that way;
it's been because capitals have been completely diverted from free software
development by proprietary software development. Happily, things are now
moving fast, and despite all the disbelief of even fine people like you,
people are nonetheless understanding that free software means more business;
and apparently in the last few weeks,
some people have been betting 4.5 bn$ on it with the RedHat IPO.
Not much, but it's only one company among so many, and only a beginning.

>> In one case, it'll be an all-mighty centralized marketing department,
>> and in the other case, it'll ultimately be the person in need oneself.
> It doesn't really matter because it is not your fundamental right to have
> me do anything for you. It is my right to make something if I see the point
> and not to otherwise.

I fear you completely misunderstand the free software philosophy.
_Of course_, you have the right to not do anything for me.
But you do not have the right to forbid other people (including myself)
to do something for me (like, copying software, decompiling it,
understanding it, modifying it, redistributing it, etc).
When you acquire some privilege upon me, it's an injustice.
And if you use this privilege to raise the price of your services,
that's an injustice. If your marketing guy in charge uses that privilege
against you and me and prevents us from cooperating, it's an injustice.
When you make someone else than one responsible of deciding what one can do,
it's not just an injustice, it's making one less than one is; it's an attempt
to one's person. By taking responsibility away from a lot people, you create
as many irresponsible people, and this constitutes an attempt against mankind.

> The thing that drives me nuts about these discussions
> is how many people seem to think they have a right to something I make just
> because I create it.

I fear that once again, you completely miss the point.
Nobody claims a right to see what you create without paying you.
Free software people are the first to claim that software development
is a _service_, that should be retributed as such.
Moreover, if you think laws guarantee you have a right on what you create,
you're a fool: your employer is the one granted the privileges by law!

> If the world were that way, I'd probably create fewer things.
> I would instead use my brain to seek out some way to do
> something that would let me eat. I would not spend the same fraction of my
> day thinking up good ideas and giving them away and still being hungry.

You would be the rare case. Most creators I know create despite ourselves;
we do not choose to create, we just do create, it's the very expression of
our lives; even in the most rotten of communist concentration camp, we do.
So that we be more productive, we only require having enough to live decently
so as to focus on our work, and having adequate tools to work with.
We don't care about having one chance in a thousand to be multimillionaire,
as is the promise of the proprietary information driven star system;
we just want to approximately sure to live decently.
And I'm sure that free information will make it a better world for us
than a world of information hoarding: we live by the services we can render,
and a free market of those services is a easier place for us to render them
than a market partitionned by license barriers.

>> Of course, in a perfect world, the person in charge will choose well;
> Who are you to say he hasn't. It isn't your right to it until you've ante'd
> up the interchange currency (money) for exprssing interest.

So only the dead victims can sue the murderers?
Who are you to say he has? Do you pretend that no legitimate user
was ever refused source access and modification? That it will never
ever be the case and that companies may blindly rely on it?
Don't you know that it is usual vendors either disappear,
or choose cunilaterally to terminate a product line,
at the dismay of years-long satisfied users? [favorite example: ILOG LISP].

And who are you to ask who I am to say?
It isn't your right until you've ante'd enough money to be warrant
for the perfect choice of all persons in charge of disclosing sources,
for the rest of times. *Of course* I have right to doubt that choice
are perfects. The burden of the proof should not be on the one who doubts.
And by the way, my company _is_ a disappointed former customer of _a lot_
of software (LISP for a tiny bit only), that, despite being once
"successful" and sometimes excellently supported, have since been
cruelly abandonned by their vendor, with no recourse it self maintenance.

>> but in a perfect world, the person won't need to be in charge, either.
> This is a completely arbitrary and self-serving claim.

Much less than yours. In a perfect world, no need for anything,
since the world is perfect; I'm pointing to the vaccuum of arguments
based on a hypothesis of perfection, which are at best inapplicable
because of the completely unstability of such perfection.
If you give someone (whoever) a repressive responsibility, you must take
into account the eventuality of that person's mistake or failure;
in a world without failure, repression is unnecessary.
That's where you need dynamic retroaction effects to limit the repression.
If some irresponsible (i.e. cannot be sued, or anything)
is to decide for others, then there's no retroaction,
and things will eventually go wrong.

>> So the question is about the dynamic effects in an imperfect world:
>> what attitude has most positive dynamic effects?
>
> Right. And I claim the one that has the most postiive dynamic effect is the
> one that incentivizes content creators. Content consumers, the ones who want
> to USE free stuff, don't need an incentive. And if you're a legitimate
> content creator who can't get access to something, you'll just create
> something else. True content creators are versatile and capable of creating
> lots of things.
>

Just where is the incentive for creators in proprietary software?
I see none, but possibly a corrupting one.
Consumers put their money where value is.
That's ultimately the one and only source of monetary incentive involved.
When software _is_ useful, and generates value,
it needn't any intellectual property "protection" to happen:
the market forces that will make it appear are already there,
and the necessary infrastructure will quickly appear if let live.
When the software is _not_ useful, or at least not as much as it should,
then, and only then may be benefit from an IP-induced incentive,
feeding on the customers trapped within its IP barriers.
The differential effect of intellectual property on creation
is _against_ creation that builds on former creation and progresses,
and _for_ creation of inferior quality but attractive look that hooks people.
THAT is the IP-induced incentive.
And the fourth effect is to spread venom in society,
by making collaboration look suspicious and discollaboration look meriting.
I see the broken eggs, but I see no omelette; instead, I see poison.
You say creators are versatile? Sure. They'll easily adapt to free software;
actually, they are the ones who built the free software movement, mind you!

As for innovation,
under free software, keeping developments secret for a long time
is counter-productive, for you make little money,
spend a lot in development, and take the risk of other people
independently inventing similar things;
so you have to focus on developments that work, release early,
and sell services early.
No more of these huge projects that take tens and tens of man-years,
never get released (or much too late, when all potential customers are gone),
and end up in a trash can (Xanadu, K-machine, Apple Dylan, Taligent, Multics,
you name it). Actually, no more projects that end up in a trash can at all
because of eventual management decisions (any ILOG guy reading?);
projects raise interest and live according to their technical qualities,
and faded interest may wax again the day people realize
something good was hiding inside the software.
In these conditions, will software firms make these investments?
Of course they will! for in a world of free software,
only technical advance differentiates you from your customer,
so research and development is the most important criterion
to gain a competitive advantage.
Will there be software firms at all? Of course there will! for
the global incentive, i.e. potential use value, is exactly the same
with free software, so the money-making opportunity are the same.
Actually, since free software fluidifies the market,
and prevents parasites that monopolize the market around bad software,
it will increase the money-making opportunity for _honest software makers_,
and decrease the opportunity for crooks,
making it a better world for everyone.

> Now, I agree completely that the idea of restrictions on "independent
> creation" (software patents) are a nuissance that should be struck
> down because they arbitrarily and capriciously restrict the right of
> an alternate content creator to show that an idea wasn't as hard to
> come up with as the original creator thought. But that's where I stop
> in the "free software" area.

You seem to forget the fact that software builds up.
What if I'm a specialist in a fairly specific topic
(like symbolic integration, or numeric approximation of some equations),
but have no particular proficiency in other topics,
including implementation of a symbolic mathematic package.
With the proprietary software model, I cannot freely exercise my talents.
Either I hack a proprietary software infrastructure,
and I must surrender anything I write to the "owners" of the infrastructure,
who by restriction of the job supply can underpay and exploit me,
or I must rewrite a symbolic mathematic package from scratch,
despite my limited specialty, or I must find another specialty.
With free software, I can join any existing project,
and use my talents to develop my own incremental piece of software
without being subject to anyone's whims,
and without preventing anyone from exercising one's talents.
Free software make people free to exercise their talents,
and sell this exercise of their talents.
No barrier, no desincentive, to complex and unnecessary human dependencies;
just what's needed, and no more. Efficiency, productivity.

>> It looks like to me the "make people responsible and trust them" attitude
>> is the winning one.
> I think once the bills are paid, responsibility is not the issue in
> "acquisition" of software. (It might be in the choice of deployment.
> My concern about software ethics has little to do with how people "modify"
> software but whether they make good ethical use of modified software.
> And this is orthogonal to copyright concerns.)

"Once the bills are paid". But proprietary software makes software
licensing so expensive that the acquisition thereof can only be made
before the bills are paid, so as to pay the bills. And there again,
the price will prevent individuals from choosing their tools;
instead, tools will be chosen by management.

>> You said it many times about the CL vs C++ attitude:
>> CL trusts the programmer, whereas C++ distrusts them, and the result is
>> trustworthy CL programmers, and untrustworthy C++ programmers.
>> The same argument applies to free software vs proprietary software.
> I can't find a useful structural basis for believing this analogy holds.
> The mere use of the same multi-meaning word in a sentence seems a weak
> basis for believing an analogy will hold up. Perhaps you can expand on
> what structural basis would give you confidence in this analogy other than
> that you like the outcome if the analogy is allowed to let stand.

Free and open software says "everyone has the _right_ to see the source,
but under one's sole responsibility". It means that programmers are trusted,
and will suffer from the consequences of their sole acts.
Your and Erik's "someone else will decide for the programmer if he
had a good reason to see the source" is an attitude of distrust towards
the programmer. You take away his responsibility to decide which tools
are good for him. You can but lessen the programmer doing that.
This is the opposite of giving advice to him as to whether
or not he needs to use the sources, which could only make him better.
In one case, you make people responsible, hence trustworthy;
in the other case, you make people less responsible, hence untrustworthy.

>> [...] Yes, we do fear the vendor.
> I find the idea of fearing a content creator offensive. Content creators
> have no obligation to make you anything at all. Fearing them is being mad
> at them that when they gave you something, they didn't give you twice as
> much. That is nothing more than rude in my book. No one makes you buy
> from them at all.

Bzzzt, wrong! Of course, a random creator owes me nothing.
But the one whose services I pay sure owes me the services I paid for!!!!
And not blindly trusting them is how I can ensure that I get what I pay for.
Now, I have every reason to fear proprietary vendors, because they have
complete monopoly on services related to the software they support;
if their service is or becomes less than initially expected,
or worse, if they discontinue their service, I have no way out,
but throwing my copious man-time investment in the software;
and seeing that once installed, nothing forces them to produce good services,
they _will_ produce bad services as soon as they gain enough market share,
and they _will_ discontinue their service if their market share
is not large enough; now, because of network effects, it is guaranteed that
for any important, structurating, software, you will only have a few big
vendors and a lot of tiny ones...
The only safe choice is in buying services from a free software company;
this guarantees your freedom to buy similar services from competition,
the stability and the quality of the software, and the perenniality of
your investments.

Creation is a service, but it's just one service among the many needed
to get software running. On the pretense of promoting creation,
intellectual property ignores all the other services, and sets up
monopolies for them. Free market economists have always fought and
will always fight monopolies: all monopolies, and not just public monopolies.
Also, by trapping creation within protection barriers, intellectual property
also devaluates any incremental, progress-making creation.
The god-inspired creator is a myth. We creators create from the material
available to us, provided by 15 billion years of civilization-making;
intellectual property restricts the material available to us,
and makes us lesser creators; it doesn't provide any single additional
incentive to creation, but instead casts creators into chains held
by publishers and other "intellectual property" barons.
What I fear about proprietary vendors is _not_ their mind-slave creators;
what I fear about them is their behavior of monopolistic mind-barons.

>> Working with the developers
> [who did not have to develop this for you and you're lucky did]

In as much as I DID pay, they DID develop this for me.
In as much as I WOULD pay, they WOULD have developed this for me.
If I see value in a (category of) software, then I'm ready to invest
corresponding money, and I don't care, a priori, who will provide me
the software and how. Intellectual property reduces my opportunity
to see the software, by erecting barriers. It prevents proficient
developers from providing me with honest service, because they
depend on a management that
It thus increases the cost of software.

>> is not co-stable with proprietary software,
>> all the less as the software spreads and is used by more and more people.
> Then don't use it.

Exactly. I avoid to depend on any proprietary software,
unless there is no free software equivalent (e.g. my computer's BIOS).
And I do collaborate with developers of free software applications I use.

>> CL dooms itself in being a fringe language
>> if it claims providing this contact.
> This is a possible truth, but is not because of right or obligation.
> This is the first statement I've seen in here which was focused on effect
> rather than right.

Maybe you don't understand the direct relationship that exists
between right and effect, and that constitutes the very foundation
of Political Economy. If you don't see this relationship,
how can you say _anything_ rational concerning rights?
And if you do see it, then how can you consider right without
taking its effects into account?
May I risk to refer to Frédéric Bastiat?
http://www.tunes.org/~fare/books/Bastiat/

> Nothing I've said should be taken to mean that I don't
> think that a content producer doesn't have to meet a certain expectation
> level with their product in order to sell it. You can't make a paperweight
> and sell it for a hundred dollars; you have to motivate the public to buy
> it at that price (as with the "pet rock" marketing plan) or you have to
> drop the price. But that "have to" is not a law; it's just an economic
> reality.

Exactly. Access to source, in absence of intellectual property,
will not be a "right". It will be an economic reality.
If you do not disclose your source, no one will use your software
for any task they depend on. Because source is the very guarantee
that there be a free market of development services. Mind you,
this is already happening, now, before your eyes.
If, like Erik, you explain all the tremendous free software efforts
just as a "maneuver" against M$ (a bizarre conspiracy theory!),
then you are blinding yourself. If not, I'd like to read your explanation.

What I'm fighting against is so-called intellectual property.
It strongly biases the software market. It corrupts the minds of people.
It modifies prices. It prevents people from working honestly.

Note that I'm already convinced that free software is just a matter of time,
nowadays, and that the abolition of intellectual property will be a battle
fought and won the hard way by the turn of next century.
What I'm worried about, and the reason why I spend my time explaining it
on comp.lang.lisp is that by not acknowledging it, the LISP community
will miss a great opportunity to have the world benefit from dynamic
and reflective software as well as from free software;
and the world is missing a great opportunity to fully take advantage
of existing technology such as dynamic software.
I wish that at least one LISP vendor would join early the free software model.
Who'll be the CYGNUS of free LISP? Maybe CMUCL and/or Dylan hackers
should join into a company? I'm just sick of computer scientists
re-discovering LISP lore ten years after, and the industry re-discovering it
yet ten years after.

> I don't think it's any vendor's moral or ethical or legal obligation to do
> any price with me;

Neither would I, in a free market; what I think is immoral and unethical,
and should be illegal, is the intellectual property protection racket.
Now, if we are to keep this model of a monopoly on services related
to every single software, then prices of such services should be set by
independent institutions, as with all monopolies.
By the way, I am not against you right to keep your sources secret,
as long as you be the one to cover the cost of keeping it,
and as you assume the risk that it be unveiled.

> my argument is simply based on common sense

You have no monopoly on common sense.
I'm sorry I fail to see any arguments of yours here,
but only vague, unbacked intuitions, and lots of doubts.
You essentially say "I don't know, for I don't have arguments".
Well, I do know, for I do have arguments.
Of course, I may be wrong, but to convince me,
you need arguments, not just admission that you have none.
Of course, you may be unconvinced by my arguments,
but at least acknowledge them what they are,
instead of setting up a straw man
and founding your doubts on ground my arguments dispell.
I know you try to stay as objective as you can;
I know that it's difficult to argue by written messages,
because of the high latency and sudden information overload that happens;
but, independently from your agreeing or not with my arguments,
the main thing I regret is that (at least it seems to me) you're having
a bad internal representation of what free software people think,
and what our arguments are or are not (whereas, conceited as I may be,
I think I somehow grasp your position and its internal consistency).

> and not a
> "fear of vendors" but a "fear for them" because I care about them and want
> them to have many years of happy vending at a proper price point--one that
> is non-zero enough to get them life support money and not so high that it
> drives my employer to want to use Java instead. Free CL, btw, is NOT where
> my employer will go instead.

You don't have monopoly on care, either.
I do care for developers, for creators.
However, I do not care for rapacious IP-based management;
I wouldn't give a damn if they were all sent burning into the sun
(actually, I would care about for the wasted rocket).
I am confident that proficient developers and original creators
will be employed and free of the choice of their languages and tools
in absence of IP.

Have you proposed a single reason why they wouldn't?
Just what do you fear about your software being freely available?
That customers will look for support from unproficient programmers?
That suddenly, no one will be interested in your software anymore,
because it be free? That people will see how bad the code you write is?
That they will find bugs in it? If what you fear is loss of licensing
revenue, can you state how much of your revenue is due to licensing,
and how much is due to development, packaging, support, and other services?
What about other computer workers?
Do you fear that more users won't generate more demand for support services?
Do you fear that your software will so quickly become so perfect
and that all software problems will be solved so completely,
that you soon will be jobless?

>> With widely spread proprietary software,
>> developer contact is part of the cost structure,
>> and is fought against by management.
> This seems an arbitrary and statistically unsupported claim.

I contend that this has been the case of all "best-selling" software,
and otherwise software living by sales of licenses (the proprietary software
model) as opposed to sale of service (the free software model).
It has happened to just every proprietary software I've seen in the eighties.

>> With widely spread free software, developer contact is a service
>> that you sell; it's part of the profit structure and sought by management.
> This seems an arbitrary and statistically unsupported claim.
> I don't see any reason this can't be true of commercial companies.

It's obviously true. Free software businesses, by very definition,
live only by selling services. Proprietary software businesses,
by very definition, live at least partly on their license sale,
and found their whole business plans on the monopoly value of their licenses
(e.g. indirect license-generated revenue through increased service fees).

> Nothing about commercial software says that a company couldn't charge for
> developer access. If there are a small number of developers, it's likely
> that the inability to clone them creates the real upper bound on access to
> them, regardless.

Bzzzt! Wrong. You're confusing "commercial" and "proprietary" software.
RedHat, SuSE, GNU C, GNU Ada, Sendmail, are commercial free software.
And there are plenty of non-commercial "freeware" proprietary software.

>> [...] Dynamic software WILL win; it will win WITH free software,
>> not against it.
> This is a possible truth but not a necessary truth.

Everyone's one's opinion.

> There are strong
> reasons already cited elsewhere to believe Dynamic Software is more
> compatible with proprietariness than Static software is.

I have even stronger reasons to doubt it. I've developed some in
<http://www.tunes.org/~fare/articles/ll99/index.en.html>.
But more paradigmatically, the whole justification of the proprietary
software model is that software be a product that you sell,
with a well-defined producer (NOT author), and a well-defined consumer.
Dynamic software challenges this producer/consumer relationship;
it challenges the notion of a product; it makes a situation
of collaboration and service all too obvious; it undermines
the very foundations of the proprietary software paradigm,
unless strictly limited to well-defined third-party "plug-ins".

> It can be
> composed in a mix and match environment without opening the hood,
> pretty much like components in your stereo (where most people don't
> look inside either) and where a healthy cost per component doesn't
> keep the industry from thriving.

That's rigid black box component software,
not quite the same as malleable dynamic software.
People typically do it with static software components.

>> Proprietary software has brought upon us the domination of
>> FORTRAN, COBOL, PL/1, C, C++. Static languages.
>
> I don't know what this claim is based on. I thought some of these
> languages came free with operating systems and that all you paid for
> was the iron back in the days these things gained dominance. I might
> be wrong. Also, people made new languages every day back then and
> most of those new languages were not charged for. If free software
> had been such a win, it would have clobbered those languages.
>

Marginally free of charge (gratis) isn't quite the same as
free of intellectual property claims (libre).
If you still don't understand that,
you haven't been following any free software argument
(make that "open source", if your ears ring whenever you hear "free").
And yes, free software has been a win.
LISP has been developed as a free software, were anyone could come,
take the sources, and hack them; so have been C and UNIX;
albeit in all these cases, they were proprietarized post facto,
"thanks" to our wonderful IP laws that make employees
mind slaves of their employers.
You can see what languages survived the wars of the eighties.
BASIC and Pascal took the proprietary path, and after some success,
faded away to never exist again, but as lone implementations
with which they are identified, and with which they will eventually die.
Part of LISP took that path, and it took the other part and a lot
of technical excellence (and implementational simplicity) to make it survive.
Without free LISPs, there would have been no more new LISPers for ten years.
All in all, yes, free software HAS won.
Every other large company I know has developed
its own proprietary internal scripting language.
All these proprietary languages die.
The few proprietary languages that survive are those
that are commercialized in a way that fit the proprietary development model
of write, compile into something cryptic, sell.
Don't be fooled: the costability factor between static languages
and the proprietary software model is largely in the obscurity effect
of compilers, more than in their alledged efficiency factor.
And even then, these languages do not survive much as languages,
only as lone implementations.

> [...] It may be cool, but it's interest in accounting programs


> (largely business) and physics simulation software (largely DoD)
> that paid the bills for a long time, fueling the industry to live
> long enough to be able to generate people with computers at all and
> knowledge at all that allowed the creation of most of these other
> things.

Sure. But what has this to do with static vs dynamic software?
Static vs dynamic is not the feature of any application,
business or physics or teaching or research or whatever.
It's a feature of development environments.
It's not about computer programs, it's about computer programming.

>> On the other hand, there are static free languages (SML, OCAML, Haskell),
>> but even they have interactive top-levels,
>> and they have a hard time capturing free software developer mindshare.
> Possibly due to a lack of commercial market? Who wants to give away
> time if they can't figure out where the dollars will come from?

Certainly, there are cultural barriers to free software.
You seem to be the embodiment of them :) Which is why people involved
in free software feel the need to explain things and dispell misconceptions.
I just wish my messages have an overall positive effect.

> Why does your whole analysis seem to neglect the importance of money to
> these activities which consume large amounts of time and resources, even
> if only at one's house?

Where in my analysis don't you see money?
On the contrary, free software opens up a lot of money