home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / tcl / 2095 < prev    next >
Encoding:
Internet Message Format  |  1992-12-11  |  2.6 KB
  1. Path: sparky!uunet!wupost!spool.mu.edu!agate!sprite.Berkeley.EDU!ouster
  2. From: ouster@sprite.Berkeley.EDU (John Ousterhout)
  3. Newsgroups: comp.lang.tcl
  4. Subject: Re: Commercial applications in Tcl?
  5. Date: 12 Dec 1992 00:33:16 GMT
  6. Organization: U.C. Berkeley Sprite Project
  7. Lines: 44
  8. Distribution: world
  9. Message-ID: <1gbc0cINNlr3@agate.berkeley.edu>
  10. References: <1gb1spINNicu@agate.berkeley.edu>
  11. NNTP-Posting-Host: tyranny.berkeley.edu
  12.  
  13. In article <1gb1spINNicu@agate.berkeley.edu>, joel@saffron.CS.Berkeley.EDU (Joel A. Fine) writes:
  14. |> Hi,
  15. |> 
  16. |> Has anyone given any thought to what it might take to create a
  17. |> restrictable commercial application in Tk/Tcl? Suppose that I want
  18. |> to do all of my programming in tcl, and just use "wish" as the binary,
  19. |> since others have already done all of the work to port it to various
  20. |> machines, make it robust, etc. But if I do that, I have to distribute
  21. |> source code. It's not clear to me how I could then restrict its use
  22. |> to those who have paid for it.
  23. |> 
  24. |> Is there such a thing as compiled tcl, for example? Are there companies
  25. |> actually doing commercial tk software? What do they do about this?
  26. |> 
  27. |> Perhaps this is a non-issue: since tk is a research project; is it
  28. |> unreasonable to expect that programmers will actually generate non-
  29. |> shareware tcl/tk applications?
  30. |> 
  31. |> - Joel Fine
  32.  
  33. I've occasionally thought about this, and here's an arrangement that I think
  34. would work (I haven't actually tried it, though):
  35.  
  36. (a) Change Tcl so that it can source encrypted files using some reasonable
  37.     encryption algorithm. Then a company could encrypt its Tcl scripts.
  38.  
  39. (b) Add a "secretproc" command to Tcl (or a -secret swith to "proc") which
  40.     makes a procedure definition secret, in that Tcl won't return its body
  41.     in "info" requests.  The encrypted source files would create their
  42.     procedures in "secret" mode so that they couldn't be extracted from the
  43.     interpreter.
  44.  
  45. (c) Finally, provide some sort of key distribution mechanism, e.g. add support
  46.     in Tcl for one or more of the standard UNIX license servers, so that Tcl
  47.     would only decrypt source files with a particular key after receiving an
  48.     OK from a license server.  Alternatively, it should be possible to use
  49.     a machine-id-based key system where a company could give a user a key that
  50.     would only work on a particular machine, but this would be a bit of a
  51.     hassle.
  52.  
  53. This involves a non-trivial amount of work in Tcl, but it isn't a huge task
  54. and it requires very few changes to the Tcl core (the -secret switch is the
  55. only change to the core, and that's a trivial change);  most of it could be
  56. done as an add-on file that provides the encryption support.
  57.