Date: Wed, 25 Sep 1996 10:16:24 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: jhs@FreeBSD.ORG Cc: current@FreeBSD.ORG, serious@FreeBSD.ORG, commercial@FreeBSD.ORG Subject: Re: Licensing Software Message-ID: <199609251416.KAA22427@skynet.ctr.columbia.edu> In-Reply-To: <199609250013.CAA02049@vector.jhs.no_domain> from "Julian H. Stacey" at Sep 25, 96 02:13:01 am
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Julian H. Stacey had to walk into mine and say: > I plan to soon sell a 3rd party commercial binary FreeBSD product. Joy. > I either need to : > - Develop alone, hooks for such things as > - constructing machine IDs (from poking around the system) Think hard about this. It's not as easy as it may first appear. With PCs, you can swap out practically all the hardware, particularly ethernet cards, so trying to find a hardware ID value that doesn't change is a real challenge. Another problem with using ethernet addresses is that you need to grovel around in /dev/kmem in order to get them. This would require your executable to be setgid kmem in order to work. And speaking of /dev/kmem, since we're dealing with an OS that comes with complete source, it would probably be ridiculously simple for someone to defeat a hardware identification scheme even if you could find a reliable one. That said, one solution that always works is a dongle, but this means sinking more money into the licensing scheme since dongles don't grow on trees. > - user count (for single workstation or multi user server pricing) If you intend to enforce usage limits in any way, you'll need a daemon. You can't restrict concurrent access using just a nodelock license file, so even your single workstation users will have to run a license server. The alternative (which doesn't work) is to have the executable keep a usage count in a file somewhere, and that approach is easily subverted. (Actually, it's possible that you could also use a really smart dongle, but then you're back to spending more money again.) > - link crippled-write, time limited, demo versions Link? No. Compile? Yes. > - make must be minimal hastle to authors, requiring no change to > - sources, just to Link flags Forget it. Some source changes will be required, otherwise how do you expect the license checking routines to get invoked? License servers can sometimes cause trouble for you since they often need to steal a file descriptor which stays open all the time so that the program and the server can send 'heartbeat' pings to each other. Sometimes the license routine in the client program also installs signal handlers which may interfere with the application unless special steps are taken. This means the programmer may have to make a few added changes to accomodate the licensing system. > - non availability to me (as distributor) of source, > but availability of .o files Well, we all know if there's no source, then it can't be any good anyway. :) > - Or I can maybe develop a mechanism with other interested commercial sellers, > so that FreeBSD would have some generic mechanism, & maybe unique > product & system keys. First you have to figure out how to positively identify a given PC. After that, it's not a problem to come up some software. > - Or I can even buy in such a solution if one's available ? You could, but then you'd have to 'pass along the savings' to your customers, who would be less than pleased. > I've read `Sun Expert' in the past, with horror stories of Sun lock managers > across nets, & I am not interested in any net strategies, > this will be local to the box. Like I said, you'll still need a license daemon to enforce usage limits. (Unless you want to be a nice guy and allow regular nodelocked licensing without charging an arm and a leg for it.) > I'm not into academic elegant lots-of-effort solutions, > I'm after a cheap dirty quick solution, I don't want to spend much > time on this, my budgeted work time on this is limited, > (& I'd prefer to spend my free on public source, not licence stuff) Hoodwink someone else into working on the licensed stuff. :) > I have to get something up quickly, & whatever I cobble together, > will be simpler to do alone (& keep secret :-), Doesn't matter if you keep the details locked in a vault: there is no software licensing system available that can't be broken. You may deter a few clueless people, but all it takes is one clueful person to find a way around the licensing and start passing it around to his friends, and so on, and so on and so on. > but if other vendors are thinking along similar lines, & interested in > some kind of generic mechanism, then I'll try to comply. [Subliminal message: "Conform... Conform... CONFORM.... Conform..."] > If anyone has something to give or even sell me, or wants to work with me, > please let me know. A while ago, I put together a very simple software licensing library using -- surprise -- RPC. I also used DES to generate license encryption strings however, so it may not be practical to distribute it. (And before anyone shouts 'MD5!' keep in mind that I have to decrypt the strings too.) I wanted to make a licensing system similar to FLEXlm, but which didn't necessarily require seperate vendor daemons. I also wanted to try to find a way around the awful flaw in FLEXlm that makes it practically worthless. It sort of worked, but I got bored with it after a while and let it languish. My license file format looks somewhat like theirs, except I added a 'vendor' field to the feature lines so that you could have more than one vendor using the same feature name, and I don't use vendor deamon specifications. The license can be either nodelocked, floating or demo (works anywhere until the expiration date hits). All the licensing information (including the hostid) is checksummed together and the checksum, along with a verification code is encrypted using a key which only the vendor and the application knows. The application then decrypts the string, verifies the checksum (to see if the licensing information is valid) and then hashes the verification code. If the hashed verification code matches its own hashed verification code, then it accepts the license as valid. For a nodelock license, it also compares the hostid in the license file to that of the local host and bombs if they don't match. For a floating license, the application also tries to contact the license server listed in the license file and communicates with the server (using encryption with keys derived from the license encryption strings) and tries checking out a license. The license server reads the same license file and also verifies the information before allowing licenses to be checked out. My original reason for using RPC was so that I could use clnt_broadcast() to dynamically locate servers so that there might be fewer configration hassles, but I never got around to implementing that. That said, I'm not going to give the code to you, because it's mainly just a toy and I wouldn't want you to get in trouble if it blows up, or if someone happens to find a trivial way to defeat it. (I wonder... can you sue a licensing software vendor if their software causes you to lose money?) -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609251416.KAA22427>