Tolkin, Steve said:
> (Also posted to comp.lang.perl.moderated)
> 
> My company has given me permission to distribute a perl program to 
> some people outside the company.  It is not open source,
> but it is our first step in that direction.
> The text of the "license" is standard boilerplate, as modified
> slightly by the company lawyer, e.g.
> # THIS SOFTWARE CARRIES NO WARRANTY, EXPRESSED OR IMPLIED. THE USER
> # ASSUMES ALL RISKS, KNOWN OR UNKNOWN, DIRECT OR INDIRECT, ... etc.

First, I'd go to debian-legal (there's a debate going on over their right 
now about this).   Second, IANAL.
> 
> The question is, how can we ensure that the user of the software
> sees this text, and agrees to it?

Bottom line - you can't.  Contracts have to be done before they get the 
SW.  UCITA is an attempt to change this (and thus screw the consumer, for 
a variety of reasons).

> 
> One idea is to print this text out the first time the program is run.  
> The program would then prompt the user to agree and if he did would
> save a file somewhere, e.g. in $HOME or maybe in the current
> directory.  Subsequent runs would find this file and suppress the
> prompt.  There are various things that can go wrong here, e.g. not
> being able to write the file to that directory.

Not to mention the person running it from cron, and not being there.

> 
> Are there any better ways to do this?
> Is there some code I could reuse to handle the prompting, etc.

Yep, include it in the licensing and read me, and don't worry about them 
seeing it, because you can't guarantee it, nor will it protect you anyway 
(your giving away the product does more to disclaim warranty than the 
boilerplate, unless other things in the license might get the lawyers 
involved)

> 
> I suspect that most users will be running this in a DOS box (aka
> command window) on Windows NT.  One problem is that the text is more
> than 25 lines, and so the top would scroll off the screen.  I think I
> could expect most users will have the 'type' and 'more' commands but I
> do not really want to start another process.  I assume there is some
> way to display this in my perl program itself, about 20 lines at a
> time, and then get the user to press the Y key.  But I do not want to
> write all that code, it being outside the realm of my experience.
> (Almost all my perl is server side with no user interface at all.)
> 
> Right now the program is a single file.  Maybe the license should be
> shown as part of the "install" process.  But then an install program
> would need to be written.
> 
> Another approach might be to always write to stderr a one line message
> reminding users that they agree to the license, which they can see the
> full text of by entering the --license option.  (I use Getopt::Long so
> this could be abbreviated down to -l.)  Even this one line message
> could be suppressed if the user provided e.g. the --agree option.

Talk to the lawyers about the elements of a contract.  Fundamentally, any 
Usage license is not a contract, because you have no way of verifying if 
the user agreed to the license prior to running the SW, 
or was using it in the way you want because they're a nice guy.  

> 
> Any other ideas, and code snippets, would be appreciated.
> 
> Thanks,
> Steve
> -- 
> Steven Tolkin          [EMAIL PROTECTED]      617-563-0516 
> Fidelity Investments   82 Devonshire St. R24D    Boston MA 02109
> There is nothing so practical as a good theory.  Comments are by me, 
> not Fidelity Investments, its subsidiaries or affiliates.
> 

Good luck on this.  Seriously, though, ask on debian-legal, and get some 
contract lawyers involved.  If at all possible (I know you said it wasn't 
open source, but bear with me), use one of the standard Open Source 
contracts (already vetted by lawyers) or contact the EFF or FSF for access 
to their lawyers.

jeff

-----------------------------------------------------------------------
Jeffry Smith      Technical Sales Consultant     Mission Critical Linux
[EMAIL PROTECTED]   phone:603.930.9739 fax:978.446.9470
-----------------------------------------------------------------------
Thought for today:  scruffies n. 

 See neats vs. scruffies.




Reply via email to