Perry Metzger wrote:
> Frank da Cruz <fdc@watsun.cc.columbia.edu> writes:
> ...
> > Anyway, Kermit was here for a looooong time before the Open Source
> > definition, or for that matter the GPL or just about any other
> > similar concept you can think of,
> 
> Well, I don't know that the original Superbrain-to-Tops-20
> implementation of Kermit predated the GPL by more than five or six
> years, actually. Hell, I remember first reading Stallman's
> announcement of Project Gnu on a Columbia '20...
>
I thought your name looked familiar!

> ... (in MM, I suppose,
> though my memory isn't that detailed) in the early 80s.
>
Yes, it would have been MM (and yes, that's what I'm using to write this
message -- after the DEC-20s went away, we wrote a new MM for UNIX).  Old
habits die hard :-)

> At latest, it
> would have been 85. (Am I right about the first systems? I was only a
> wee undergrad at Columbia at the time and my memories are vague, but I
> distinctly remember the first use as being to link the stupid
> Superbrain CPM machines to the '20s.)
> 
The original Kermit implementations came out in early 1981 for the DEC-20 (a
big timesharing computer popular at most universities at the time), a CP/M
microcomputer (the one we chose had possibly the silliest name ever given to
any computer, yes, the Superbrain), and our IBM mainframe.  The MS-DOS
implementation followed soon, and then lots of others.  (Despite its name,
the "Superbrain" was the best choice at the time to put into public labs
because of its solid and massive 1-piece construction (no walking away with
keyboards -- let alone the entire system) and dual diskette drives (unlike
its closest contender, the Heath 89, if memory serves, which had only one).
We still have a couple of them in storage and last time I turned one on, it
still worked.)

For those who weren't around at the time and might be interested, the
original reason for developing Kermit was to let students get their files
off the central timesharing computers at the end of each semester, when the
disks were wiped clean of student files (because in those days student
computing was "free", and therefore there was no money to expand capacity).

> > so the Open Minded among us might be
> > willing to "grandfather" it :-)  I mean really, if somebody makes up some
> > new thing next week will we have to comply with that too?  Let's lighten
> > up on all this licensing purity!  What's it to you if some third person
> > can't take my work and sell(*) it without permission (unless you're that
> > person)?
> 
> Ah, but that's what the whole NetBSD project is about! We're very big
> on the fact that lots and lots of vendors use NetBSD in their products
> without having to talk to anyone -- everyone from Network Computer to
> mmEye uses NetBSD. (Yes, you can buy several brands of NCs that come
> with NetBSD under the covers). One of the points of NetBSD is that we
> *like* the fact that people can take the whole ball of wax and sell
> it. We regularly purge a remaining GPL'ed program or two from the tree
> to try to get the last pieces that can't be sold unrestricted out.
> 
> You might think we're weird people for wanting others to be able to
> sell our hard work without having to ask us and with barely any
> acknowledgement, but that's the way we are.
> 
I don't think it's weird -- it's generous and admirable.  We used to do 
it too.  We might still be doing it if somebody would pay us to do it.

The problem is that eventually everybody needs to have a real job so they
can support their families, send their kids to college, have medical
and retirement benefits, etc.  There are precious few jobs like that for
writing free software.  I'll grant you, there are some, but even then,
whoever pays you decides what you get to do, and so can change their mind
(and your task) at any moment, or can simply decide to stop paying you.
But most employers have not the slightest desire to have you creating free
software on their time, or even on your time using their equipment.

So this begs the question of what, exactly, we are trying to do with free
software.  Become famous as the author of some well-known package that
everybody uses because we let them have it for nothing?  So then we can get
a high-paying job in which we can no longer write free software, AND the
package we so lovingly created is orphaned?

This is not to say that software should not be given away -- after all, we
give Kermit away too.  But to allow the project to continue over the long
run (and I do mean long: when you consider the initial development period,
we are rapidly closing in on 20 years), with Kermit development and support
as the primary responsibility full-time professional staff, rather than
something they sneak away to nights and weekends, thus ruining their
personal lives), we require that those who make money from it as a commodity
share it with us.

Now, the irony in all this is that the companies who want to include Kermit
in a product do not mind paying at all.  Why?  Because this amounts to a
contract with us.  They have a claim on our time and attention, and some
reason to expect we'll be here in the future to continue serving their
evolving needs.  They don't have to feel guilty about calling us with
questions or problems since they are supporting us.  The only people who
object to Kermit not being free to these companies are the "free in the
sense of transitive freedom" license advocates, who are, in general, not
making money from selling other peoples' software.  Which makes me wonder,
why do they care about this issue so much?

Why is the welfare of companies that DO NOT WANT to recompense people for
their honest labor the greatest concern in this debate?  I can think of
dozens of causes that seem more worthy.

> I don't see any of this as being that big a deal, though, vis a vis
> Kermit. Kermit can't go on the official project CDs, but we'll leave
> it in pkgsrc forever, along with all of the other useful but not Open
> Source programs like it (such as ssh and company.) Those who need it
> can automatically download and build it within minutes, so its all
> probably a fine compromise.
> 
It probably is.  Thanks.

- Frank