gopher licensing

117 views
Skip to first unread message

JQ Johnson

unread,
Feb 25, 1993, 2:23:55 PM2/25/93
to
I am quite concerned about the licensing stance described by Mark Cahill
in his recent posting to this news group. Although I understand and even
endorse the goals of U Minn's development group in recouping its costs by
taxing commercial use, I'm concerned that the policies as stated are
sufficiently vague to scare off lots of people.

I was pleased to see in the Network World article that U Minn plans to
allow "free use of its client/ server software as long as the information
on the server is made available free of charge on the Internet." I think
this is a very reasonable and pragmatic definition of "commerical use."
However, it's not a statement by U Minn, and it's not legalese. I'll hold
my breath until I see the educational-use contract I expect to need to
sign with the U. of Minn. Absent such a contract, I'll need to
disassemble my gopher server, since our university, like many, makes some
information available only on-campus due to licensing restrictions.

As an example of another remaining problem, it is not clear to me just
what is claimed to be copyright. Certainly the document describing the
gopher protocol. Certainly the source code for the various clients
developed at U Minn (note that this includes derivative works including
all the bug fixes contributed by the rest of us). I have no problems with
this. However, is it U Minn's position that the protocol itself is
protected? How about independently developed clients and servers?

We in the networking community and in the "open systems" community are
stuck with a few proprietary protocols. Examples include IPX and DECnet.
But there is a very strong sentiment that protocols should be public and
freely available, even if implementations are protected. The successful
ones in the Internet community are the ones that are non-proprietary; look
at Sun's NFS for a nice clear example of this success.

We've been burned by vendor-proprietary protocols in the past. If the
University of Minnesota planned to try to make the gopher protocol
proprietary, then I for one would start looking for an alternative, and
would stop contributing to the gopher development effort.

--
JQ Johnson Office: 250E Computing Center
Director of Network Services Internet: j...@ns.uoregon.edu
University Computing, Univ. of Oregon voice: (503) 346-1746
Eugene, OR 97403-1212 fax: (503) 346-4397

Paul Lindner

unread,
Feb 25, 1993, 7:03:09 PM2/25/93
to
j...@duff.uoregon.edu (JQ Johnson) writes:

>I am quite concerned about the licensing stance described by Mark Cahill
>in his recent posting to this news group. Although I understand and even
>endorse the goals of U Minn's development group in recouping its costs by
>taxing commercial use, I'm concerned that the policies as stated are
>sufficiently vague to scare off lots of people.

True, the vagueness does cause unecessary confusion.. We really
haven't had any lawyers really look at it. We've taken the common
sense approach. If you use gopher to make money, then the U of Minn
wants something in return. That can be free access to information, or
it can be a fee of some sort.

>I was pleased to see in the Network World article that U Minn plans to
>allow "free use of its client/ server software as long as the information
>on the server is made available free of charge on the Internet." I think
>this is a very reasonable and pragmatic definition of "commerical use."
>However, it's not a statement by U Minn, and it's not legalese. I'll hold
>my breath until I see the educational-use contract I expect to need to
>sign with the U. of Minn. Absent such a contract, I'll need to
>disassemble my gopher server, since our university, like many, makes some
>information available only on-campus due to licensing restrictions.

You're higher-ed, you provide open information. You don't make money
off of gopher. You are bound by your own licensing agreements that
don't allow you to make some information available to the internet
(clarinet being a good example of this)

>As an example of another remaining problem, it is not clear to me just
>what is claimed to be copyright. Certainly the document describing the
>gopher protocol. Certainly the source code for the various clients
>developed at U Minn (note that this includes derivative works including
>all the bug fixes contributed by the rest of us). I have no problems with
>this. However, is it U Minn's position that the protocol itself is
>protected? How about independently developed clients and servers?

Using the protocol and redistributing the document are a totally
different matter. Basically we don't want someone to commercially
embrace the protocol, file the serial numbers off of it and claim it
to be their own. (aka coming soon, MicroSoft Gopher using our
revolutionary Gopher protocol!) (In fact someone almost did this,
removing all references to the University of Minnesota and trying to
sell it as a package to a vendor to remain unnamed)

BTW Gopher and POPmail are both TradeMarks.. Guess I should be
putting in those TMs..

>We in the networking community and in the "open systems" community are
>stuck with a few proprietary protocols. Examples include IPX and DECnet.
>But there is a very strong sentiment that protocols should be public and
>freely available, even if implementations are protected. The successful
>ones in the Internet community are the ones that are non-proprietary; look
>at Sun's NFS for a nice clear example of this success.

The protocol documents will always be free. Heck, we're even better
than ISO, at least we don't charge you for copies of them.

>We've been burned by vendor-proprietary protocols in the past. If the
>University of Minnesota planned to try to make the gopher protocol
>proprietary, then I for one would start looking for an alternative, and
>would stop contributing to the gopher development effort.

I know that the UofMN will take a moderate stance on these matters.
You're not going to see another IPX etal here.

Greed would kill gopher, believe me..
--
| Paul Lindner | lin...@boombox.micro.umn.edu | Slipping into madness
| | Computer & Information Services | is good for the sake
| Gophermaster | University of Minnesota | of comparison.
///// / / / /////// / / / / / / / / //// / / / / / / / /

John Franks

unread,
Feb 25, 1993, 11:04:44 PM2/25/93
to
In article <C3145...@news2.cis.umn.edu> lin...@mudhoney.micro.umn.edu (Paul Lindner) writes:
>j...@duff.uoregon.edu (JQ Johnson) writes:
>
>>I am quite concerned about the licensing stance described by Mark McCahill

>>in his recent posting to this news group. Although I understand and even
>>endorse the goals of U Minn's development group in recouping its costs by
>>taxing commercial use, I'm concerned that the policies as stated are
>>sufficiently vague to scare off lots of people.
>
>True, the vagueness does cause unecessary confusion.. We really
>haven't had any lawyers really look at it. We've taken the common
>sense approach. If you use gopher to make money, then the U of Minn
>wants something in return. That can be free access to information, or
>it can be a fee of some sort.
>

This sounds very reasonable.

>
>>As an example of another remaining problem, it is not clear to me just
>>what is claimed to be copyright. Certainly the document describing the
>>gopher protocol. Certainly the source code for the various clients
>>developed at U Minn (note that this includes derivative works including
>>all the bug fixes contributed by the rest of us). I have no problems with
>>this. However, is it U Minn's position that the protocol itself is
>>protected? How about independently developed clients and servers?
>
>Using the protocol and redistributing the document are a totally
>different matter. Basically we don't want someone to commercially
>embrace the protocol, file the serial numbers off of it and claim it
>to be their own.

This doesn't really answer Johnson's questions. At present there are
at least three clients for the Mac that were not developed at U of
Minn. There is also the xgopher client developed at Univ of Ill, the
xmosaic browser developed at NCSA, and various flavors of DOS/Windows
clients. Also there are servers developed at Rice and elsewhere.
These all represent a great deal of work by a substantial number of
people.

What are the obligations of these people to U of Minn? Will people
continue to do this development if they are subject to restrictions or
obligations? In particular, McCahill explained that the Minnesota
group felt entitled to a "revenue stream" if someone is going to use
gopher commercially and said that some deals have already been done.
Do the people who have done client and server development elsewhere
have the same rights?

These questions really need to be addressed explicitly. Saying that
the Univ of Minn will "take a moderate stance on these matters" is
hardly the way to eliminate what you call the unnecessary confusion
caused by vagueness.
to meaningless.

Surely it is not impossible to prevent anyone from stealing the
protocol and calling it their own while still allowing anyone who wants
to develop software using it to do so.

John Franks Dept of Math. Northwestern University
jo...@math.nwu.edu

Mark P. McCahill

unread,
Feb 26, 1993, 5:36:41 PM2/26/93
to
Subject: Re: gopher licensing
From: John Franks, jo...@hopf.math.nwu.edu
In article <1993Feb26.0...@news.acns.nwu.edu> John Franks,

jo...@hopf.math.nwu.edu writes:
>
>At present there are
>at least three clients for the Mac that were not developed at U of
>Minn. There is also the xgopher client developed at Univ of Ill, the
>xmosaic browser developed at NCSA, and various flavors of DOS/Windows
>clients. Also there are servers developed at Rice and elsewhere.
>These all represent a great deal of work by a substantial number of
>people.
>

We think its great other people are writing implimentations
of the protocol. We don't have the resources to do it all. We
depend on other people doing implimentations for platforms
we can't cover.

>What are the obligations of these people to U of Minn? Will people
>continue to do this development if they are subject to restrictions or
>obligations? In particular, McCahill explained that the Minnesota
>group felt entitled to a "revenue stream" if someone is going to use
>gopher commercially and said that some deals have already been done.

Let me get really explicit:

We own the implimentations of gopher we wrote. We want a
revenue stream for commercial use of our code (our implimentations).
If someone independently develops an implimentation of gopher, they
can do whatever they like with that implimentation. We do retain
rights for works derived from our code... so an "independent
implimentation" means that you did more than just change the copyright
notice on our work. :-)

The University of Minnesota doesn't care if other Universities use
our gopher implimentations as long as they aren't selling them or
using them to sell services to the general public (in those cases
we'd like to do a license agreement). The kind of CWIS use of
our gopher implimentations we see today is completely acceptible.

The Univerity of Minnesota doesn't care if other people write clients
and servers independently and we don't have any claim on independently
developed implimentations.

>Do the people who have done client and server development elsewhere
>have the same rights?
>

We own the stuff we wrote... you own the stuff you wrote.

>These questions really need to be addressed explicitly.

They just were.

By the way, we plan to wrte an informational RFC about the
base gopher protocol because that won't change. Gopher+ is
still under development, but once its done we plan to write
an informational RFC about it as well.

JQ Johnson

unread,
Feb 26, 1993, 6:44:24 PM2/26/93
to
I was pleased to see Mark McCahill's clarification of U Minn's position
on derivative works. I think it addresses my concerns. To summarize,
my understanding is that U Minn claims rights to the name "gopher"
(perhaps to "Internet Gopher"? I seem to recall that "Gopher" is also
the trademark for a different commercial product), to the specification
documents, and to code based on the various U Minn gopher
implementations, but not to code implementing the protocol but
developed only using the specifications and interoperability testing.

Note that the above is my understanding only. You legal beagles need
to read Mark's postings for yourselves, since only what he says as a
representative of the U of Minnesota carries any weight.

In private communications with Mark, I've also gotten a much better
sense for U Minn's position on what uses they plan to allow for free.
U Minn has not made what I would consider a definitive formal statement
on that yet, but the outline of their intent seems to me to be:
essentially unlimited internal use by universities (presumably even if
such use is restricted or makes the university money through tuition,
or charging for cpu time on timesharing systems, or whatever);
essentially unlimited use of server software obtained from U Minn by
anyone else as long as the information is freely available to the
Internet; essentially unlimited use of the client software as long as
you don't charge for the use. Presumably, U Minn will continue to
restrict redistribution to protect its copyright etc (these
restrictions are already pretty well spelled out in the copyright
notice).

I'm a bit concerned that I have so many "essentially" and "presumably"
caveats in the above. Mark has proposed that I (and by extension
anyone else interested) draft for him proposals as to a more formal
specification of the kinds of contractural relationship we'd want to
enter into with U Minn. Perhaps with some help from the community Mark
will have formal terms available in time for GopherCon.

Edward Vielmetti

unread,
Feb 26, 1993, 7:35:39 PM2/26/93
to

If anyone else will be at the Columbus IETF, I'd like to organize
a session to work out the details of issuing an RFC for Gopher,
to describe the protocol as it is in current use, and to work
out ways of publishing Gopher+ the same way.

This is not to take the work out of the hands of the Minnesota folks!
Far from it. Just an opportunity to work out a description and
spec in the common RFC language so that there's clear guidelines for
implementors, and to generally ensure the availability of neutral,
unbiased, readily available text so that people can build Gopher
clients and servers of their own from the spec.

Edward Vielmetti, vice president for research, Msen Inc. e...@Msen.com
Msen Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 998 4562 (fax: 998 4563)

John Franks

unread,
Feb 26, 1993, 10:04:11 PM2/26/93
to
In article <C32ut...@news2.cis.umn.edu> Mark P. McCahill <m...@boombox.micro.umn.edu> writes:
>
>We own the implimentations of gopher we wrote. We want a
>revenue stream for commercial use of our code (our implimentations).
>If someone independently develops an implimentation of gopher, they
>can do whatever they like with that implimentation. We do retain
>rights for works derived from our code... so an "independent
>implimentation" means that you did more than just change the copyright
>notice on our work. :-)
>
>The University of Minnesota doesn't care if other Universities use
>our gopher implimentations as long as they aren't selling them or
>using them to sell services to the general public (in those cases
>we'd like to do a license agreement). The kind of CWIS use of
>our gopher implimentations we see today is completely acceptible.
>
>The Univerity of Minnesota doesn't care if other people write clients
>and servers independently and we don't have any claim on independently
>developed implimentations.
>
>We own the stuff we wrote... you own the stuff you wrote.
>

This is very clear and a very reasonable position. Thanks for removing
any ambiguity. Unfortunately not everyone in the software world is as
enlightened as you and (fortunately) gopher is becoming very important
to a lot of people. We wouldn't want to have to start a "gnupher"
project :)

>
>By the way, we plan to wrte an informational RFC about the
>base gopher protocol because that won't change. Gopher+ is
>still under development, but once its done we plan to write
>an informational RFC about it as well.

This is an excellent idea too.

Prentiss Riddle

unread,
Feb 27, 1993, 8:40:42 AM2/27/93
to
Mark P. McCahill <m...@boombox.micro.umn.edu> writes:
>
> We own the implimentations of gopher we wrote. We want a
> revenue stream for commercial use of our code (our implimentations).
> If someone independently develops an implimentation of gopher, they
> can do whatever they like with that implimentation. We do retain
> rights for works derived from our code...
>
> The University of Minnesota doesn't care if other Universities use
> our gopher implimentations as long as they aren't selling them or
> using them to sell services to the general public (in those cases
> we'd like to do a license agreement). The kind of CWIS use of
> our gopher implimentations we see today is completely acceptible.

This is pretty clear when it comes to universities, but there are still
some unanswered questions. What about other non-profit and for-profit
organizations? Are the servers at places like O'Reilly Publishing,
Texas Internet Consultants, etc. in violation of what UMinn wants done
with Gopher? What if a for-profit company emulated what is commonly
done at universities and put up an internal-use-only server for
site-licensed data? What if a for-profit consultant charged money to
set up a gopher server for a non-profit university (i.e., charged to
install and configure UMinn code while making it clear that s/he wasn't
charging for the code itself)?

I agree that there is a need for a highly explicit document detailing
the answers to these and related questions and I like the idea that the
Gopher community will have a voice in defining the terms at GopherCon.
I believe that whatever language we come up with will still need to
pass through the hands of some "legal beagles" before it is tight enough
to avoid future legal hassles from ambiguities that we non-lawyers
might naively leave in place.

-- Prentiss Riddle ("aprendiz de todo, maestro de nada") rid...@rice.edu
-- Unix Systems Programmer, Office of Networking and Computing Systems
-- Rice University, POB 1892, Houston, TX 77251 / Mudd 208 / 713-285-5327
-- Opinions expressed are not necessarily those of my employer.

Edward Vielmetti

unread,
Feb 27, 1993, 8:58:55 PM2/27/93
to
John Franks (jo...@hopf.math.nwu.edu) wrote:

: This is very clear and a very reasonable position. Thanks for removing


: any ambiguity. Unfortunately not everyone in the software world is as
: enlightened as you and (fortunately) gopher is becoming very important
: to a lot of people. We wouldn't want to have to start a "gnupher"
: project :)

On the contrary, it sounds like a project that aimed at building servers
that were under a gnu license would be a good thing in the long run;
that would protect the property rights of those people who expect to
contribute to the code base, without restricting their ability to
provide commercial services.

At this point I'm hesitant to start working on commercial services
using gopher+; even though it seems like it would be the right thing to
do as far as building something useful, I think the only sane way to
approach it is to build an entirely new server code base that's not
dependent on the U Mn stuff.

It would be nice to be clear on which of the vast assemblage of
code that has gone into the Gopher project has a U Minnesota copyright
on it, which is effectively uncopyrighted, and which is available
under a GNU or similar license. Can I run go4gw without paying
a tithe to Stanford? Can I even use the code that I contributed
to the project without having to buy it back?

sigh. Mark, I *hope* you have really and truly sat down with your
University lawyers and that they know and understand what it going on
here. When I look at the code base as of (say) 1.03 there was no
hint, no clue that there were any commercial restrictions on the code, no
notices of anything except that you borrowed code from nntp and from
elm and from the Stevens book.

JQ Johnson

unread,
Feb 27, 1993, 10:44:22 PM2/27/93
to
The copyright law answers some of the questions raised by Ed. In
particular, it doesn't matter whether or not a copyright symbol appears
on a work; you can still claim copyright (though you may not be able to
get damages for infringement if you haven't adequately marked the work
as copyright). If a work is copyright, derivative works are
copyright. I believe that Mark has waived any claim to "derivative
work" rights for something like go4gw, which can stand on its own fairly
independent of gopherd, but I assume that any changes to gopher or
gopherd made by any of us are covered by the derivative work
principal. Now, an interesting question: could the authors of WAIS
or hytelnet claim copyright to Unix gopherd as a derivative work (I
don't think so)?

Stephen C. Trier

unread,
Mar 1, 1993, 9:56:25 AM3/1/93
to
In article <C32ut...@news2.cis.umn.edu> Mark P. McCahill <m...@boombox.micro.umn.edu> writes:
>Gopher+ is still under development, but once its done we plan to write
>an informational RFC about it as well.

Has there been any thought given to fixing some of the base limitations
of gopher, such as its one-character types and the large overhead involved
in opening and closing a new TCP connection for what may be a single
packet of data?

It would seem that a backwards-compatible mechanism would be easy to
design, thanks to the stateless nature of the current Gopher. (Just
define a type in the new system that means "original gopher" and a type
in the original gopher to mean "new gopher".)

--
Stephen Trier "They didn't seem to be acting out of
Network software type malice, but they were, at best,
Case Western Reserve University differently clued."
tr...@ins.cwru.edu - John Perry Barlow

John Franks

unread,
Feb 28, 1993, 11:13:43 PM2/28/93
to
In article <1mp69k...@nigel.msen.com> e...@msen.com (Edward Vielmetti) writes:
> it sounds like a project that aimed at building servers
>that were under a gnu license would be a good thing in the long run;
>that would protect the property rights of those people who expect to
>contribute to the code base, without restricting their ability to
>provide commercial services.
>
>At this point I'm hesitant to start working on commercial services
>using gopher+; even though it seems like it would be the right thing to
>do as far as building something useful, I think the only sane way to
>approach it is to build an entirely new server code base that's not
>dependent on the U Mn stuff.
>

I agree it would be nice to have a server under the GNU license, but
that's easy to say when someone else did all the work. And as long as
the protocol is not proprietary I don't see any insurmountable
problems.

There are several possible scenarios for commercial gopher use besides
licensing from U of Minn. Maybe U of Minn pricing will be cheap enough
that no one will mind paying. But if not, it wouldn't be too expensive
for a commercial service to hire a programmer to write a minimal server
(say type 0 and 1 only). The recent arrival of a new server for the
Mac as an add on to ftpd shows this is not totally unreasonable. The
only drawback here is the server would not be likely to be a gopher+
server and if this kind of development became widespread it could be
factor working against the adoption of gopher+.

Another possibility if there is sufficient demand for a server with no
licensing entanglements is that the Committee for Networked Information
Discovery and Retrieval (CNIDR) will get involved. This is the group
leading the project to maintain WAIS and develop new Z39.50 clients and
servers. They are funded by the NSF, but I believe much of the work is
done by volunteers. If demand is sufficient they might well do a
gopher server. It would have been nice if U of Minn could have got
funding like CNIDR for their development efforts and not felt the need
to license the server.

It is tempting for those of us in academia not to concern ourselves
with commercial uses of the gopher protocol, but, in fact they may well
have an important effect on us. I would like to see academic
electronic journals published via gopher. Not just the free ones like
those currently on the CICNet gopher (very nice by the way), but also
those with paid subscriptions. Licensing the gopher server makes this
much less likely to happen and, sadly, the alternative is a host of
different proprietary schemes -- one from each publisher -- which will
surely be much more awkward to use than gopher. One of the U of Minn
postings in this thread suggested the possibility that they might grant
a server license to a publisher in exchange for a subscription for U of
Minn. This sounds like a great idea -- I hope it happens. I think
publishers would go for it.

On a related topic, as commercial services using gopher are starting to
arrive, I am glad to see they are not using Kerberos-like authenication
services (which I gather is what Admit1 is). Instead they are opting
for subscription by internet address or IP subnet. This facility,
which is already built into the UNIX server, is much simpler and *very
much* less obtrusive for the end user. It is so much cheaper to
maintain and so much nicer for the user that it is hard to imagine it
won't become the dominant way electronic subscriptions are done, but I
still encounter a lot of the "password mentality."

Jerry M. Carlin

unread,
Mar 1, 1993, 3:39:00 PM3/1/93
to
In article <1993Mar1.0...@news.acns.nwu.edu> jo...@hopf.math.nwu.edu (John Franks) writes:
>On a related topic, as commercial services using gopher are starting to
>arrive, I am glad to see they are not using Kerberos-like authenication
>services (which I gather is what Admit1 is). Instead they are opting
>for subscription by internet address or IP subnet. This facility,
>which is already built into the UNIX server, is much simpler and *very
>much* less obtrusive for the end user...

This facility is also subject to trivial stealing of services just like
the problems with cellular phones. I have to disagree that having an
easy to subvert mechanism is better in the long run. Setting up Kerberos
does take a bit of admin work but is transparent to the end user if done
right and the extra effort is well worth it if one cares about charging
people for services or providing confidental access to specific data.
The current situation is similar to the cars of the era in which
Ralph Nader wrote "Unsafe at any Speed"; the title could be changed to
"Insecure at any Speed" and it would represent the 'state of the art' (sic).
--
Jerry M. Carlin (510) 823-2441 jmc...@srv.pacbell.com
Alchemical Engineer and Virtual Realist

Paul Lindner

unread,
Mar 1, 1993, 11:52:37 PM3/1/93
to
tr...@slc6.ins.cwru.edu (Stephen C. Trier) writes:

>In article <C32ut...@news2.cis.umn.edu> Mark P. McCahill <m...@boombox.micro.umn.edu> writes:
>>Gopher+ is still under development, but once its done we plan to write
>>an informational RFC about it as well.

>Has there been any thought given to fixing some of the base limitations
>of gopher, such as its one-character types and the large overhead involved
>in opening and closing a new TCP connection for what may be a single
>packet of data?

Gopher+ fixes the one character typing limit with longer descriptors
called VIEWS.

And, contrary to popular belief, the opening and closing of the TCP
connection is a design feature, not a flaw. It minimizes the server
resources required.

Our lowly Mac IIci has done a pretty good job so far for the entire
internet...

>It would seem that a backwards-compatible mechanism would be easy to
>design, thanks to the stateless nature of the current Gopher. (Just
>define a type in the new system that means "original gopher" and a type
>in the original gopher to mean "new gopher".)

The \t+ that follows an item means that it's a gopher+ type..

John Franks

unread,
Mar 1, 1993, 9:07:29 PM3/1/93
to
In article <1993Mar1.2...@PacBell.COM> jmc...@srv.PacBell.COM (Jerry M. Carlin) writes:
>In article <1993Mar1.0...@news.acns.nwu.edu> jo...@hopf.math.nwu.edu (John Franks) writes:
>>On a related topic, as commercial services using gopher are starting to
>>arrive, I am glad to see they are not using Kerberos-like authenication
>>services (which I gather is what Admit1 is). Instead they are opting
>>for subscription by internet address or IP subnet. This facility,
>>which is already built into the UNIX server, is much simpler and *very
>>much* less obtrusive for the end user...
>
>This facility is also subject to trivial stealing of services just like
>the problems with cellular phones. I have to disagree that having an
>easy to subvert mechanism is better in the long run. Setting up Kerberos
>does take a bit of admin work but is transparent to the end user if done
>right and the extra effort is well worth it if one cares about charging
>people for services or providing confidental access to specific data.
>--
>Jerry M. Carlin (510) 823-2441 jmc...@srv.pacbell.com
>Alchemical Engineer and Virtual Realist


I don't understand this. Surely for the average user (and even the not
so average) it is "trivial" to give away a password and not at all
"trivial" to get domain name service to believe your computer has an IP
number which really belongs to someone else or to believe that your
computer is on a different class B or C network than it really is.
It may be possible to do these things, but I don't know how and I am
sure the average network user doesn't either.

On the other hand if my university subscribes to an electronic journal
which is protected by a password scheme then either they have to give
the password to every potential user (keep in mind we are talking about
use largely on Macs and PCs here) or the users have to go to the library
and enlist the aid of a librarian who knows the password. I suppose
I could be required to login to a UNIX host running an authentication
service and access the journal from there, but then I have to use the
UNIX gopher client rather than, say, one of the nice Mac clients.
Maybe I'm missing something, but I don't see this as very transparent.

If you are talking about encrypting information supplied by gopher so
that it is impossible to steal the packets as they cross the network,
that is a totally different subject. This is not what Admit1 does (as
I understand it) and I haven't heard anyone discuss this possibility.

Chris Shenton

unread,
Mar 2, 1993, 12:06:40 PM3/2/93
to
A couple nits/questions.

I do not work for/at an educational institution. Most of the
discussion about licensing has centered around the ``Commercial''
versus ``Educational'' dichotomy. Would NASA, a non-commercial and
non-educational institution be required to procure a license?

While Mr. Linder's explanations sound reasonable, well-intentioned,
etc, I wonder how similar they are to the legalese that must
necessarily be issued by U of MN. Rarely do techies and lawyers agree
on things: I am very concerned that the latter may usurp the freedom
espoused by the former.


In summary: before we commit much more time/effort to Gopher(tm), I
would like to analyze a *legal* document describing the licensing
policy. If too restrictive we would have to bail, no matter how open
the developers of Gopher(tm) wish it to be. And that would be a shame.
--
-- Chris Shenton she...@nsisrv.gsfc.nasa.gov NASA/GSFC/HSTX 301-286-7905

Stephen C. Trier

unread,
Mar 2, 1993, 11:53:08 AM3/2/93
to
In article <C38w8...@news.cis.umn.edu> lin...@mudhoney.micro.umn.edu (Paul Lindner) writes:
>And, contrary to popular belief, the opening and closing of the TCP
>connection is a design feature, not a flaw. It minimizes the server
>resources required.

And requires six packets of overhead for a two-packet data connection.

Networking bandwidth is cheap, yes, but I really don't understand why
a better protocol couldn't be built that permits either stateful
connections if the server is willing to handle them.

>Our lowly Mac IIci has done a pretty good job so far for the entire
>internet...

True enough. It's a question of balancing the server memory use against
network bandwidth use. I assume UM has a T1 connection to the Internet
or else you might be more concerned about the overhead. :-)

>The \t+ that follows an item means that it's a gopher+ type..

That is _not_ what I mean, and neither are the VIEWS.

Why have three types for a menu item? Right now, you are storing types
in three places: the type character, the Gopher+ suffix, and the Gopher+
typing mechanisms. This doesn't seem very well-designed.

Why not define a new Gopher, which I'll call Gopher- for now, substituting
"type\t" for the type byte? At that point, you could tell people to use
"x-type" for any experimental types, letting you cleanly regulate the list
of official types.

Such a mechanism could be used to move most of the advantages of Gopher+
into a much simpler protocol.

I don't want to continue to discuss this in public. Please direct any
replies to me personally. Thanks.

Stephen

Jerry M. Carlin

unread,
Mar 2, 1993, 12:13:11 PM3/2/93
to
In article <1993Mar2....@news.acns.nwu.edu> jo...@hopf.math.nwu.edu (John Franks) writes:
>In article <1993Mar1.2...@PacBell.COM> jmc...@srv.PacBell.COM (Jerry M. Carlin) writes:
>>In article <1993Mar1.0...@news.acns.nwu.edu> jo...@hopf.math.nwu.edu (John Franks) writes:
>>>On a related topic, as commercial services using gopher are starting to
>>>arrive, I am glad to see they are not using Kerberos-like authenication
>>>services...
>>
>>... Setting up Kerberos

>>does take a bit of admin work but is transparent to the end user if done
>>right...

>
>I don't understand this. Surely for the average user (and even the not
>so average) it is "trivial" to give away a password and not at all
>"trivial" to get domain name service to believe your computer has an IP...

For one thing, giving someone else a password means that you will be charged
for the service whereas the other is unauthorized. My comparison with
cellular phones was deliberate. A sufficiently large number of people
reprogram the NVRAM of cell phones and steal services and the spoofing of
an IP address is of the same order of difficulty IMHO; that is, it can
be done by a sufficiently large number of people to be a real problem.

Besides, you don't need to login to each service in a well set up Kerberos
world. One of the big benefits of such an environment is a 'single login'
service where logging in at one place automagically sets up all the services
you need by getting tickets from a server and I believe that this is
what will happen long-term.

Mark P. McCahill

unread,
Mar 1, 1993, 9:33:30 PM3/1/93
to
In article <1993Mar1.0...@news.acns.nwu.edu> John Franks,

jo...@hopf.math.nwu.edu writes:
>There are several possible scenarios for commercial gopher use besides
>licensing from U of Minn. Maybe U of Minn pricing will be cheap enough
>that no one will mind paying.

That is our intent.

>But if not, it wouldn't be too expensive
>for a commercial service to hire a programmer to write a minimal server
>(say type 0 and 1 only). The recent arrival of a new server for the
>Mac as an add on to ftpd shows this is not totally unreasonable.

Yeah. I'd like to see a bunch more of these sort of servers...
We would much rather have a small piece of a large pie than
100% of a teeny-tiny pie. This is part of why we don't mind if other
people impliment gopher clients and servers. We also understand
that its pretty easy to write a server... which ought to keep the
price of software licenses down.

>The
>only drawback here is the server would not be likely to be a gopher+
>server and if this kind of development became widespread it could be
>factor working against the adoption of gopher+.
>

Not too big a problem since gopher+ is upward compatible with
base gopher implimentations. After there are a couple reference
gopher+ implimentations, I expect to see it pretty widely implimented.

>Another possibility if there is sufficient demand for a server with no
>licensing entanglements is that the Committee for Networked Information
>Discovery and Retrieval (CNIDR) will get involved. This is the group
>leading the project to maintain WAIS and develop new Z39.50 clients and
>servers. They are funded by the NSF, but I believe much of the work is
>done by volunteers.

Some work is volunteer and some is done by salaried employees.

>If demand is sufficient they might well do a
>gopher server. It would have been nice if U of Minn could have got
>funding like CNIDR for their development efforts and not felt the need
>to license the server.
>

It would be nice to get some funding out of CNIDR... maybe you
guys who want free stuff could suggest they send some money our way
and work funded by them can have a GNU-style license.

I'm really just looking for ways to better fund the development effort
we have now. As use of gopher has ramped up we haven't gotten more
resources... so either I need funding from someplace like CNIDR or from
commercial users.

>It is tempting for those of us in academia not to concern ourselves
>with commercial uses of the gopher protocol, but, in fact they may well
>have an important effect on us. I would like to see academic
>electronic journals published via gopher. Not just the free ones like
>those currently on the CICNet gopher (very nice by the way), but also
>those with paid subscriptions. Licensing the gopher server makes this
>much less likely to happen and, sadly,

I don't agree. If the license fee is low enough its not a big deal...
We are keeping the fees low... a without some sort of revenue stream,
its not possible to provide good support. Ask Peter Deutsch (of Archie
fame) about this :-).


>the alternative is a host of
>different proprietary schemes -- one from each publisher -- which will
>surely be much more awkward to use than gopher. One of the U of Minn
>postings in this thread suggested the possibility that they might grant
>a server license to a publisher in exchange for a subscription for U of
>Minn. This sounds like a great idea -- I hope it happens. I think
>publishers would go for it.
>

And this is the sort of thing we are very willing to do. Our position is
that money and information access are both valuable to us... we will
trade one for the other.

John Franks

unread,
Mar 2, 1993, 2:35:33 PM3/2/93
to
In article <1993Mar2.1...@PacBell.COM>, jmc...@srv.PacBell.COM (Jerry M. Carlin) writes:
>
> For one thing, giving someone else a password means that you will be charged
> for the service whereas the other is unauthorized.

This is only true if you assume charging by connect time, which makes no
sense with gopher, or charging by "hit", which is very unpopular. Charging
by subscription, just like paper journals, and like the new federal register
recently announced in this group would be very different. In that setting
it costs nothing to give away password.

> My comparison with
> cellular phones was deliberate. A sufficiently large number of people
> reprogram the NVRAM of cell phones and steal services and the spoofing of
> an IP address is of the same order of difficulty IMHO; that is, it can
> be done by a sufficiently large number of people to be a real problem.
>

It is not that hard perhaps to forge the source of the packets I send,
but getting a server to send packets to me while it thinks it is sending
them somewhere else is probably difficult. I don't see how to do this
without access to DNS at higher levels than my machine.

Mark Garrett Internet: mark@arvak.une.edu.au Phone: +61 66 20 3859

unread,
Mar 3, 1993, 2:34:58 AM3/3/93
to
From article <SHENTON.93...@troll.gsfc.nasa.gov>, by she...@troll.gsfc.nasa.gov (Chris Shenton):
> A couple nits/questions.

>
> In summary: before we commit much more time/effort to Gopher(tm), I
> would like to analyze a *legal* document describing the licensing
> policy. If too restrictive we would have to bail, no matter how open
> the developers of Gopher(tm) wish it to be. And that would be a shame.

I have to agree.

Also We the internet have put a lot of time if not money into
implementing servers/clients of gopher, not to mention debuging the cruddy
code and proving the U min a large amount of feed back. I think any sort of
licence other than GNU style will have many say bye bye to gopher.

All said IMHO and with a :) just to be nice.


Cheers
Mark :)
--
Mark Garrett Internet: ma...@arvak.une.edu.au Phone: +61 66 20 3859
University of New England, Northern Rivers, Lismore NSW Australia.

Garrett Wollman

unread,
Mar 4, 1993, 2:47:48 PM3/4/93
to
In article <1993Mar2.1...@news.acns.nwu.edu> jo...@math.nwu.edu writes:
>It is not that hard perhaps to forge the source of the packets I send,
>but getting a server to send packets to me while it thinks it is sending
>them somewhere else is probably difficult. I don't see how to do this
>without access to DNS at higher levels than my machine.

Standards-conmforming TCP implementations are required to
automatically invert any source-route options when responding to
incoming connections. On many operating systems, this means that IP
address spoofing is as simple as a call to setsockopt().

-GAWollman

--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wol...@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance.
uvm-gen!wollman | It is a bond more powerful than absence. We like people
UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant

Reply all
Reply to author
Forward
0 new messages