tts@ttank.ttank.com (Karl Bunch) (04/04/91)
Our company has just recently gotten into PostScript programming from a customer stand point. (We've already setup invoices etc. for our in-house needs). Now that we are starting to create all kinds of PostScript forms logos etc. we are concerned about the basic "Source" form that we must give to the customers. So as to avoid priracy is there a way we can use eexec or some such to encode the PostScript source? It doesn't have to be fullproof. Just something that would stop the average PostScript programmer because of the "Complexity" of having to decode it etc etc. BTW to all the people that replied to my questions about "Curl" on our HP LJIII, Thanks! I'm armed with lots of good ideas.. Now all I need is a little time to test them out. :-) Thanks for any ideas, Karl -- % ---------------------------------------------------------------------------- % Karl Bunch ||| UUCP: ..!uunet!zardoz!ttank!karl % Think Tank Software ||| INTERNET: karl@ttank.com % "...you'd be suprised how far a hug will go with Geordi, even Worf!" -- Riker
rcd@ico.isc.com (Dick Dunn) (04/04/91)
tts@ttank.ttank.com (Karl Bunch) writes: > ...Now that we are starting to create all kinds of PostScript forms > logos etc. we are concerned about the basic "Source" form that we must > give to the customers. So as to avoid priracy is there a way we can use > eexec or some such to encode the PostScript source? It doesn't have to > be fullproof. Just something that would stop the average PostScript > programmer because of the "Complexity" of having to decode it etc etc. Well, start with a correct copyright notice, of course! Since the definition of the PostScript language is easily available, and since there is freely-redistributed code for PostScript interpreters, you're definitely in a "Locks are for honest people" situation. eexec probably fits what you want. It's an obstacle to a duffer; it's a mild annoyance to someone who knows PostScript. The real point is that it sufficiently obscures the code that nobody can "just happen to" read code that's been eexec-encrypted, nor "accidentally" decrypt it. You can add to that a process to "shroud" the code before encryption--things like com- pressing out all unnecessary white space and using the shortest possible names for objects. You probably want to do that anyway just to minimize the size of the file you send to the printer. Neither of these do any- thing about verbatim copying; they just slow down the process of making it understandable. Other than that, the best way to protect a product is to move faster than the folks who think "xyzzy-compatible" means "copy it and sell it." -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...Lately it occurs to me what a long, strange trip it's been.