HDTenEightyP/NetNews huggingface dataset:
From: dlove@cbnewsf.cb.att.com (Dave Love)
Subject: Re: software piracy question
Keywords: laws, software piracy
Organization: AT&T
Distribution: na
Date: Tue, 29 Dec 1992 22:35:47 GMT

In article <poland.725056032@cam2> poland@cam2.gsfc.nasa.gov (Jim Poland) writes:
>I recently (within the last 6 months) read an article in the Washington Post
>about software piracy.  The article stated that "on June 4, the Senate passed
>S.893, a bill to move the willful copying of a computer program from a 
>misdemeanor to a felony, and the bill is expected to be voted on favorably 
>by the House, possibly next week."
>
>I was wondering if anyone knows the status of this bill and the possible 
>penalties associated with this legislation.

S 893 was signed by George Bush on October 28th, 1992.  My understanding
is that it makes all copyrighted works subject to Title 18 (?) Felony
sanctions.  The penalties include:

 1.  up to five years imprisonment for at least 10 copies made during
     a 180-day period where the copies have a retail value in excess
     of $2,500,

 2.  up to 10 years for a second or subsequent offense,
 
 3.  up to one year imprisonment in any other case.

>Thanks in advance.

Welcome.

>Jim Poland

--
 Dave Love 
 att!ncsc5!dcl -or- dlove@cbnewsf.att.com

What a waste it is to lose one's mind, or not to have a mind is being
very wasteful.  How true that is.

    -- Vice President Dan Quayle (I'm gonna' miss him! ;)


Newsgroups: comp.security.misc,comp.org.eff.talk
From: bear@kestrel.fsl.noaa.gov (Bear Giles)
Subject: Re: Stupid Licenses (YUCK!)
Organization: Forecast Systems Labs, NOAA, Boulder, CO USA
Date: Tue, 22 Dec 1992 03:41:42 GMT

In article <1992Dec19.023609.26000@news2.cis.umn.edu> charlie@umnstat.stat.umn.edu (Charles Geyer) writes:
>
>... and whether product is simply
>not shipped with known serious bugs.

The trivial solution is to not test for bugs....

Seriously, in an ideal world the existing software would be bug-free and
you could afford to wait until your new release is bug-free... but today
the current version is _not_ bug-free.

Would you postpone a release with known bugs (documented in a 'here there
be dragons' addendum) which would replace a previous, more buggy version?

What about a release with significant improvements which just happened
to crash if you had a really obscure combination of hardware and software?
What if the company offered you a free upgrade (or other compensation)
if its software twigged on this odd combination?

Or what if the software only had problems on really old systems which
should have been upgraded a long time ago? ("Gee, I'm running DOS 2.8
on a 5 MHz XT and your program doesn't seem to work!")  How long do
you need to keep providing upgrades for existing platforms?


Bear Giles
bear@fsl.noaa.gov/colorado.edu
From: kludge@grissom.larc.nasa.gov (Scott Dorsey)
Newsgroups: comp.security.misc
Subject: Re: Future OS virus immunity.
Date: 31 Dec 1992 16:35:36 GMT
Organization: NASA Langley Research Center and Reptile Farm
NNTP-Posting-Host: grissom.larc.nasa.gov

In article <bontchev.725813879@fbihh> bontchev@fbihh.informatik.uni-hamburg.de writes:
>Let's consider Unix - a typical system with memory protection,
>discretionary access control, and all that jazz. Absolutely nothing in
>this system prevents a virus from infecting ALL executable files of a
>particular user. Between the different users on one and the same
>system the virus will not spread that well, because users don't often
>execute programs that belong to other users. An exception is the
>"users" bin and root. Once one of those users executes an infected
>file, the virus will spread in the system like a wildfire. But again,
>those users do not often execute programs that belong to other
>users...

Actually, I wouldn't consider Unix to be typical either.  Yes, it's
possible for a user to infect his own personal executable, then share
that executable with another user who then gets his own executables
infected.  True enough.  But, it's not possible for them to infect
the operating system unless one of those user executables is run by
an account with permissions (which should never happen).  The chances
to spread are greatly reduced, and the chances of mass spread through
the operating system are eliminated.

>Between different systems the virus will have even less chance to
>spread, because the sharing of programs occurs mainly in the form of
>source code. You do not walk around with infected tapes and do not run
>the programs on them on different machines, as you do in the PC world.
>That's why, in multi-user systems the worms and the trojans are of
>much more concern than the usual viruses.

This is the case with current Unix systems, but it may not always be the
case, unfortunately.
--scott
Newsgroups: comp.security.misc,comp.org.eff.talk
From: jgd@dixie.com (John De Armond)
Subject: Re: Stupid Licenses (YUCK!)
Date: Sun, 03 Jan 93 05:58:17 GMT
Organization: Dixie Communications Public Access.  The Mouth of the South.

bhayden@teal.csn.org (Bruce Hayden) writes:


>The question is how much longer can we as a society accept buggy software.
>Sure - I know as well as anyone that with present technology it is almost
>impossible to get all bugs out. What I am advocating is that if you release
>software with (too many) bugs in it, you may face a competent plaintiff's 
>attorney who will use your failure to document your attempts at software 
>quality control against you in showing negligence.

"We as a society" doesn't have a thing to do with it.  How each of 
us tolerates bugs vs cost is the issue.  I suggest that most of us
can tolerate the current level of commercial software bugs pretty
much forever.  For example, I currently use some of the most buggy
software on the face of the earth in my business (DOS and Windows).
Nontheless I know how to work around most of the bugs with little 
trouble and produce a magazine using Windows-based tools.  Would I
like a bug-free environment?  Sure.  Could I afford it?  Not likely.

>Most everyone seems to be of the opinion that since everyone is doing it
>(releasing buggy software), it is ok (despite knowing how to at least
>minimize the number of bugs). Other areas of tort law have discarded this
>type of reasoning. Instead, the law seems to take the position that if
>you know how to mitigate a problem, and don't (especially for economic
>reasons), you are taking a gamble that the money saved will be greater
>than the money lost in litigation. You thus have no reason to complain
>when you are found liable for your failure to mitigate the problem.

Yep, that's just what we need, Bruce, is for the lawyers to make software
as unaffordable as the lawyers and the goverment have cars.  Do you 
REALLY want to have to take out a 5 year loan to buy a word processor
the same way you have to do to buy an econobox these days?  Suppose,
perhaps, that some of us would rather spend a bit less money and NOT 
pay for exhaustive proofs of correctness?  This will be like everything
else that lawyers stick their slimey noses into - thoroughly fucked up
and we'll all be worse off for it.

John
-- 
John De Armond, WD4OQC               |Interested in high performance mobility?  
Performance Engineering Magazine(TM) | Interested in high tech and computers? 
Marietta, Ga                         | Send ur snail-mail address to 
jgd@dixie.com                        | perform@dixie.com for a free sample mag
Need Usenet public Access in Atlanta?  Write Me for info on Dixie.com.
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.security.misc
Subject: Re: Stupid Licenses (YUCK!)
Date: 23 Dec 1992 00:26:52 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1992Dec22.151201.22766@kakwa.ucs.ualberta.ca> DMARTIN@vm.ucs.UAlberta.CA writes:
>Maybe I'm misunderstanding what you mean by a "bug level", but I'm having
>difficulty with what you propose. WHAT IS an "acceptable bug level", defined
>so that I know when I have reached it? You can't simply ask that there be
>no more than x "minor bugs" present in the software - that gets you into
>a variation of the issue of proving software correct (How can I possibly KNOW
>that I am down to x "minor bugs" and 0 "major bugs"?).

As several others have posted, the reasonable goal is not "less than N
bugs" but "less than N *known* bugs".  We all realize that software that's
powerful enough to be useful is too complex to be perfect.  But if a vendor
knows about a serious bug when they ship the software then they're clearly
giving higher priority to deadlines than to quality.

The question arises: how do you prove that the vendor knew about the bug?
And even if the vendor admits to knowing about it, they might not agree
that it's a serious bug.  If it only affects .1% of users, is it serious?
Maybe not to the vendor, but if you're in the .1% it probably seems so.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.security.misc
From: weingart@inf.ethz.ch (Tobias Weingartner)
Subject: Re: Looking for secure data link recommendations
Followup-To: poster
Reply-To: weingart@inf.ethz.ch
Organization: ETH - Switzerland
Date: Mon, 28 Dec 1992 10:17:25 GMT

|> Unless they've drastically changed the rules at NSA, DES is
|> *not* certified for any form of EO12356 [classified] material.

What is?  Can anyone tell me?

-- 
Tobias Weingartner  *    PGP2.1 Public Key available at     *
 +41'41'33'25'40    *   'finger weingart@tau.inf.ethz.ch'   *
SYSTEM-F-ANARCHISM, the operating system has been overthrown
Xref: sparky comp.security.misc:2350 comp.org.eff.talk:7863
From: bhayden@teal.csn.org (Bruce Hayden)
Newsgroups: comp.security.misc,comp.org.eff.talk
Subject: Re: Stupid Licenses (YUCK!)
Date: 21 Dec 92 14:16:38 GMT
Organization: Colorado SuperNet, Inc.

eoliver@ralph.cs.haverford.edu (Erik Oliver) writes:

>Proving software correct is extremely difficult to do, and making sure
>that there are no "bugs" is even harder.  For example, in the
>IBM-Compatible world, it is very hards to anticipate all of the possible
>setups that might have an incompatibility with your software.  If my new
>product XYZ-Works doesn't work on a SuperDuper486DX/2 is that
>necessarily reflective of a bug in my software or a glitch in some part
>of the SuperDuper product?

Agreed - you can't get all of the bugs out. You can however get the major
ones out, and the minor ones down below a certain, prespecified level.
I am not advocating proving all software correct. I am just advocating
somewhat well documented software quality control/assurance procedures.

>Because of the variety of IBM-Compatible products out there testing for
>every configuration is unrealistic, if not impossible.  Even in the Mac
>world, there are problems that occur because of interactions between
>INITs and CDEVs with applications.  Are these bugs?

I think that depends on how common the hardware and hardware combination
is. If the hardware is anywhere close to common, then I would contend
that it is a reasonable to test a major product on all of the common
hardware. 

I also would contend that once you have serious problems with a specified
hardware combination (with previous releases or products) then you may
potentially have a duty to duplicate that hardware combination for future
QC testing.

Obviously, you have a resource problem here. IBM can afford to basically
test almost anything imaginable (so why didn't OS/2 work on many non-IBM
platforms?) A small company can probably only afford to test on a limited
number of platforms and combinations.

>I think that if the manufacturers make good faith efforts to keep their
>product working and put out bug releases that is about as much as we can
>expect.  Personally I think that the software produced by organizations
>like the FSF is better than a lot of commerical stuff because they are
>not afraid to keep updating their product and release slews of fixes as
>necessary.

I disagree. We have the capability today to set an acceptable bug level
before the release, then not release until we have reached that level.
That isn't happening in many cases. Either we aren't setting the level,
or if we are, we are shipping before we get to that point.

Bruce E. Hayden
(303) 758-8400
bhayden@csn.org
Xref: sparky comp.security.misc:2383 alt.security:5241 comp.dcom.modems:18679
From: randy@ve6bc.ampr.ab.ca (Randy Pointkoski)
Newsgroups: comp.security.misc,alt.security,comp.dcom.modems
Subject: Re: Looking for secure data link recommendations
Date: Wed, 30 Dec 1992 04:13:37 GMT
Organization: COMPRESSION TECHNOLOGIES INC. EDMONTON, ALBERTA CANADA


You may want to consider using the encrytion features of 
 WARP 1 or WARP 2 DATA COMPRESSOR/DATA LINK OPTIMIZOR
to secure your data link. Throughputs up to 256Kbps
are no problem.




COMPRESSION TECHNOLOGIES INC.
EDMONTON, ALBERTA
TEL: (403)463-5310
FAX: (403)465-2113


RANDY J. POINTKOSKI P.ENG
-- 


Randy J. Pointkoski P.Eng.                       tel: (403) 437-5961
Edmonton, Alberta, Canada                        fax: (403) 436-1686
Newsgroups: comp.security.misc,comp.org.eff.talk
From: charlie@umnstat.stat.umn.edu (Charles Geyer)
Subject: Re: Stupid Licenses (YUCK!)
Organization: School of Statistics, University of Minnesota
Date: Sat, 2 Jan 1993 17:05:29 GMT

In article <bhayden.725514513@teal> bhayden@teal.csn.org (Bruce Hayden) writes:

> Again, if the vendor did legitimate regression testing before releasing
> the upgrade, you wouldn't have this problem. 

In article <1992Dec30.130805.28123@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com
(fred j mccall 575-3539) replies:

> Well, you wouldn't have it AS MUCH.  However, from reading your
> comments, it just doesn't seem that you've considered what kind of
> real-world problems you're talking about.

And in article <bhayden.725949329@teal> bhayden@teal.csn.org (Bruce Hayden)
replies:

> Well, I was in software development long enough (15 years) that I 
> have seen how it is done wrong more times than I can count. I have
> also seen it done right. My experience is that all it takes to do
> it right is proper planning and adequate resources. 

No doubt trying to do it right helps, but that's not enough.  The vast
majority of software suffers from Creeping Featurism or is Broken As Designed.
No amount of "good software engineering practice" will fix that.

You can't have quality software unless you put quality before featurality.

-- 
Charles Geyer
School of Statistics
University of Minnesota
charlie@umnstat.stat.umn.edu
Newsgroups: comp.security.misc
From: eronald@fml.tuwien.ac.at (Edmund Ronald)
Subject: Future OS virus immunity.
Organization: Technical University of Vienna
Date: Sat, 2 Jan 1993 23:07:30 GMT

  Since I posted a couple of days ago, regarding the directions of research
to make future systems virus immune, there have been a series of interesting,
albeit off-track reactions.
  Several people remarked that virues on Unix machines were "impossible"
because of the access control separating accounts. No one bothered to 
remember that the past ten years have proven Unix system security to be an
oxymoron, a topic that keeps graduate students entertained nights. In fact,
if I may venture some sarcasm, if administrators and vendors did not make
such exagerated claims about Unix security, then there would probably be
fewer attacks :)

  Also, I do not care particularly about Unix, a 25 year old system with
lots of historical flaws -sorry, features :)
I was interested in FUTURE systems: How might these be rendered "resistant
 by design"?

Edmund 
-- eronald@cnam.cnam.fr

PS. I personnally use a NeXT computer, a Unix box with a wysiwyg GUI built
on top of a Display Postscript server that handles screen and keyboard, and
mouse. Mail on these can contain embedded Postscript, which is executed at
read-time by the server. Need I say more about how un-security can be buit
into a system?

Newsgroups: comp.security.misc,comp.org.eff.talk
From: bhayden@teal.csn.org (Bruce Hayden)
Subject: Re: Stupid Licenses (YUCK!)
Organization: Colorado SuperNet, Inc.
Date: Sat, 2 Jan 1993 23:52:37 GMT

>> Well, I was in software development long enough (15 years) that I 
>> have seen how it is done wrong more times than I can count. I have
>> also seen it done right. My experience is that all it takes to do
>> it right is proper planning and adequate resources. 

>No doubt trying to do it right helps, but that's not enough.  The vast
>majority of software suffers from Creeping Featurism or is Broken As Designed.
>No amount of "good software engineering practice" will fix that.

>You can't have quality software unless you put quality before featurality.

I don't see that we are in disagreement. My contention is that it is 
possible to "do it right". This means, amoung other things, "putting
software quality before featurability". The legal consequences of this
are that there may be legal liability when you do it the other way
(put featurability before software quality). 

The question is how much longer can we as a society accept buggy software.
Sure - I know as well as anyone that with present technology it is almost
impossible to get all bugs out. What I am advocating is that if you release
software with (too many) bugs in it, you may face a competent plaintiff's 
attorney who will use your failure to document your attempts at software 
quality control against you in showing negligence.

Most everyone seems to be of the opinion that since everyone is doing it
(releasing buggy software), it is ok (despite knowing how to at least
minimize the number of bugs). Other areas of tort law have discarded this
type of reasoning. Instead, the law seems to take the position that if
you know how to mitigate a problem, and don't (especially for economic
reasons), you are taking a gamble that the money saved will be greater
than the money lost in litigation. You thus have no reason to complain
when you are found liable for your failure to mitigate the problem.
 
Bruce E. Hayden
(303) 758-8400
bhayden@csn.org
From: frisk@complex.is (Fridrik Skulason)
Newsgroups: comp.security.misc
Subject: Re: Future OS virus immunity.
Date: 31 Dec 92 15:23:27 GMT
Organization: Frisk Software International, Iceland

kludge@grissom.larc.nasa.gov (Scott Dorsey) writes:

>Viruses aren't a real problem in any system that has memory protection and
>any way to prevent users from directly writing into system space.  In such
>a system, a user would be able to destroy his own area, but wouldn't be
>able to touch the OS.

Unless a virus is run by a privileged user, or the virus uses some loophole
in the system, or an infected program is installed with some privileges 
or....etc.  

No operating system can be 100% proof against stupidity.


-- 
--
Fridrik Skulason      Frisk Software International     phone: +354-1-694749
Author of F-PROT      E-mail: frisk@complex.is         fax:   +354-1-28801
Xref: sparky comp.security.misc:2393 alt.security:5243
From: unruh@physics.ubc.ca (William Unruh)
Newsgroups: comp.security.misc,alt.security
Subject: Re: New virus report: "Ryan Erik Hoff"
Date: 31 Dec 1992 01:13:22 GMT
Organization: The University of British Columbia
Distribution: world
NNTP-Posting-Host: physics.ubc.ca

 Yeah, I found one of those but it was already out over 8 years ago. It's
 still pretty infectious, and no cure has been discovered. I'm afraid 
 prevention is the only cure for this strain. ( Oh and it goes under
 different names as well, so don't count on a universal id string.)
 Congrats on the identification.
Newsgroups: comp.security.misc
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: Future OS virus immunity.
Reply-To: bontchev@fbihh.informatik.uni-hamburg.de
Organization: Virus Test Center, University of Hamburg
Date: 31 Dec 92 18:50:59 GMT

bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:

> :-). You are off by a factor of ten... Currently we recognize at least
> 592 different virus families for MS-DOS... They might be slightly more
> - something about 600, but you get the idea... The last time I looked,

Oops, silly me, I completely forgot the 56 families of boot sector
viruses... :-)

Regards,
Vesselin
-- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
Newsgroups: comp.security.misc,alt.security,comp.dcom.modems
From: johnson@trwacs.fp.trw.com (Steve Johnson)
Subject: Re: Looking for secure data link recommendations
Organization: TRW Systems Division, Fairfax VA
Date: Wed, 23 Dec 1992 15:22:18 GMT

breinhar@rams.srg.af.mil (Bob Reinhardt) writes:


>In article <murakami.9@hac2arpa.hac.com>, murakami@hac2arpa.hac.com (Gary A. Murakami) writes:
>|> I have a requirement for secure (DOD Secret) data communications between
>|> two sites.  Having been away from the market for while I don't know
>|> what is currently available.  Using STU-III serial port is an option
>|> but if there is something better (same ease of operations but maybe
>|> faster data rates or designed solely for data comm) then I would be
>|> interested in knowing about them.
>|> ----
>|> Gary Murakami       |  murakami@hac2arpa.hac.com
>|> Hughes Training Inc.|  murky@hti.hac.com
>|> West Covina, Calif. |

>-- 
  Motorola has a network encryption system that you might want to look at.
The last set of business cards I had for them listed Joe Marino as the
Secure Products Manager, Communications Products Office, Government
Electronics Group in Scottsdale, AZ.  The phone number on the marketing
glossy was (602)441-2185.  I haven't had occasion to use their stuff
(they didn't do DES at the time) since they were only DOD COMSEC oriented.
HTH.

------- Any views expressed are those of myself and not my employer. --------
Steven C. Johnson, WB3IRU / VK2GDS      |
TRW                                     | johnson@trwacs.fp.trw.com
FP1 / 3133                              |         [129.193.172.90]
1 Federal Systems Park Drive            | Phone:        +1 (703) 968.1000
Fairfax, Virginia  22033-4412  U.S.A.   | Fax:          +1 (703) 803.5189
-- 
------- Any views expressed are those of myself and not my employer. --------
Steven C. Johnson, WB3IRU / VK2GDS      |
TRW                                     | johnson@trwacs.fp.trw.com
FP1 / 3133                              |         [129.193.172.90]
Newsgroups: comp.security.misc,comp.org.eff.talk
From: charlie@umnstat.stat.umn.edu (Charles Geyer)
Subject: Re: Stupid Licenses (YUCK!)
Organization: School of Statistics, University of Minnesota
Date: Tue, 29 Dec 1992 20:08:32 GMT

In article <1992Dec28.002314.21233@news2.cis.umn.edu>, I wrote:

   Why can't they just provide a release that fixes the old bugs without
   introducing (known) new ones?  Featurality first is the only explanation.

In article <1992Dec28.011729.27192@ulysses.att.com> smb@research.att.com
(Steven Bellovin) replies:

> I suggest that you read Fred Brook's ``The Mythical Man Month'' for
> a better explanation.

I understand the principle of "two steps forward, one step back" if that's
what you were referring to.  What bothers me is

       two steps forward, one step back
       + creeping featurism
       = one step forward, one step back

or worse.

-- 
Charles Geyer
School of Statistics
University of Minnesota
charlie@umnstat.stat.umn.edu
Newsgroups: comp.security.misc,comp.org.eff.talk