Sign in to follow this  

Linux and Mac shareware 30 day trial

This topic is 4689 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm a Windows person, so be gentle. Under Windows it is pretty straight-forward to make a 30 day trial for software. Windows has a myriad of locations to hide all sorts of crazy information: The registry, the Windows subsystem, Program Files, and user data areas. Where, on a Linux system, is a good spot for such information (i.e. what is the typical industry stance on where such information should be put or, if that is uncomfortable to share, just specify areas where such information should NOT be put)? Linux doesn't have a registry, so it has to go somewhere on the hard drive. One thing I can do is require the software to be installed as root or as someone with sufficient privileges to any area of the drive. I assume that whatever goes for Linux goes for Mac as well, but there might be specialized APIs that allow software to do the installation of a trial thing. Note that I'm not trying to stop people from pirating my application - I just need to be able to port an existing system to Linux and Mac in a Linux- and Mac-"acceptable" fashion.

Share this post


Link to post
Share on other sites
Ok, I'll try to be gentle. [smile]

I'm no great linux expert, but I'd sure get mad if your application went and pooped timestamp files in "random" remote locations of my filesystem. Asking for root privileges if they aren't really needed (e.g. to install the application for all the users on the system) would be even worse. You'd either have to be content with sticking dot files in the user's home directory, or find a license managing system.

FWIW, here's a document on the "standard" filesystem hierarchy. That should give you a clue to where not to put your application files.

Share this post


Link to post
Share on other sites
After a quick glance at the aforementioned document, /var/games and /var/libs both seem to be "safe" places to squirrel away data and seem to be "FHS-compliant" locations according to the document you pointed me to.

Frankly, from a purely shareware perspective, most shareware authors will have zero qualms about writing to any ol' doggone place on your hard drive to enforce a 30 day trial (even /sbin - now _there's_ a scary thought for you - you're probably frantically scanning /sbin now). Irregardless of whether the Linux community wants shareware or not, they are going to have it because there are plenty of developers who want to make shareware for Linux. I was merely asking out of courtesy and because someone might show up via Google to read this thread.

BTW, if Linux provided a set of APIs to use for trial software, that would make shareware developer's lives so much simpler - the community could dictate how the APIs would work and they would fit into the existing Linux architecture cleanly. Of course, the issue of piracy would have to be addressed because a common trial API suite would exist, but that's another story better left for another discussion.

Oh, and thanks for the information. It is good to have something to go off of, which is better than the nothing I had. I had already scoured Google for hours on this topic and kept coming up empty-handed before I came here.

Share this post


Link to post
Share on other sites
Quote:
Original post by FunnyMonkey
After a quick glance at the aforementioned document, /var/games and /var/libs both seem to be "safe" places to squirrel away data and seem to be "FHS-compliant" locations according to the document you pointed me to.


The downside with /var/games is that the user will need to be a member of the games group to get access to it:

var $ ls -la
drwxr-x--- 3 games games 144 Aug 18 10:10 games


Anything but a library would stick out as a sore thumb in /var/lib. [smile]

Quote:
Frankly, from a purely shareware perspective, most shareware authors will have zero qualms about writing to any ol' doggone place on your hard drive to enforce a 30 day trial (even /sbin - now _there's_ a scary thought for you - you're probably frantically scanning /sbin now).


Well, they can try.

Quote:
Irregardless of whether the Linux community wants shareware or not, they are going to have it because there are plenty of developers who want to make shareware for Linux. I was merely asking out of courtesy and because someone might show up via Google to read this thread.


I have nothing against shareware developers per-se. Installers pooping files all over the place and demanding root access is probably a show-stopper to any halfway serious system administrator, unless they are actually installing a system-wide application. Even then, they'll expect it to be well-behaved and to either stick itself under /opt or /usr/local, or to prompt for an install location.

Quote:
BTW, if Linux provided a set of APIs to use for trial software, that would make shareware developer's lives so much simpler - the community could dictate how the APIs would work and they would fit into the existing Linux architecture cleanly. Of course, the issue of piracy would have to be addressed because a common trial API suite would exist, but that's another story better left for another discussion.


That's part of what DRM is all about; it's not a linux-specific issue. In the current state of things, there is no way, on Windows or Linux, to make sure that the system doesn't get circumvented.

Quote:
Oh, and thanks for the information. It is good to have something to go off of, which is better than the nothing I had. I had already scoured Google for hours on this topic and kept coming up empty-handed before I came here.


Glad to be of service.

Share this post


Link to post
Share on other sites
Since most linux users are not stupid, i doubt hiding a file called timestamp_for_my_program.txt in some remote location will stop users from abusing a 30-day limit. You should probably look into steganography which is the art of hiding information, usually in very obvious places.

Just some thoughts: you could hide timestamp data in a file which has nothing to do with timestamps, in a comment in an image, or even in a few bytes padded onto the end of the executable itself (maybe). There are so many ways to hide it, then encrypt it with some clever, unintuitive, borderline-Satanic way. It's a fun field to look into. I wish i had a use for it :-)

Share this post


Link to post
Share on other sites
Quote:
Original post by FunnyMonkey
[...]BTW, if Linux provided a set of APIs to use for trial software, that would make shareware developer's lives so much simpler - the community could dictate how the APIs would work and they would fit into the existing Linux architecture cleanly. Of course, the issue of piracy would have to be addressed because a common trial API suite would exist, but that's another story better left for another discussion.[...]
You realize that if Linux came with such an API, it'd likely be part of an open-source library/kernel module/whatever, right? That would mean it'd be 'broken' in a few hours unless the whole community agreed to allow it (and considering the amount of commercial software for linux, I'd say that seems unlikely).

Windows user hate it bad enough when you crap all over their system (I personally would never buy a program that did such a thing) - I can't imagine how the average linux fanatic would feel about it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Extrarius
Windows user hate it bad enough when you crap all over their system (I personally would never buy a program that did such a thing) - I can't imagine how the average linux fanatic would feel about it.


Heh, most programs you buy do it anyway. [grin]

Share this post


Link to post
Share on other sites
Your game will presumably install some highscore list or something in /usr/games someplace

stat() this file. look at the creation date. add thirty days, compare and decide what to do.

Beyond that, trust your freaking users.

(I thought the shareware model was dead, btw. Didn't the spyware model replace it?)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
By executing an strace on the program (any idiot could do it), it is easy to find out which files it accesses. I would say, just store your information in the app configuration file (encrypted or otherwise). If you try to be sneaky, you might piss people off. One thing about linux users is that most of them are very honest about licenses and such.

Share this post


Link to post
Share on other sites
Anonymous, I don't know how honest Linux users are about licensing (most Linux users I know are about as honest as the Windows users I know). Now I said shareware, but that isn't exactly the licensing model I'm actually going for. What I am thinking about are two different licensing models. For things like tools and applications, I put in the 30 day trial simply because I need to "enforce" it. However, the idea being tossed around here is that people who use such things without commercial interest really aren't going to pay for it in the first place...or at least not willingly. So, I figure that if they try it out for 15-20 days and like it, they can register it for free if they fill out a feedback survey (and _maybe_ have them sign up to receive newsletters about the product). The feedback is potentially more valuable than the cost of the product...who knows - they might buy it anyway.

Thus for strictly personal use, the product is free. For any profit-oriented use, it isn't. I simply need the trial period in place to "enforce" the latter. I'm not trying to be sneaky here and I definitely don't want to upset a large number of the user base.

When I say "enforce", I mean something along the lines of "strongly encourage the purchase of the product".

To whoever wrote about DRM: That's not what I meant and I don't like the concepts surrounding DRM. I think Mac and Windows have the upper hand here in that they can provide said APIs at the kernel level and deny any attempt to proxy, inject, replace, read, or modify those API calls. A tall order, for sure, but DRM wouldn't be necessary then (it would just be a set of highly protected API calls). Those same platforms would have to deny debuggers and remote process access to any application registered to use the trial API system. Linux would be a lot harder because it is purely open source, but the kernel could theoretically offer the same feature set. I know far fewer Linux users who have rebuilt their kernel than those who just use it as-is (80-20 rule), so even if a "crack" was available, not many would dare apply it (i.e. security compromise) let alone build the kernel with it installed. It's a moot point anyway - all changes to the kernel have to pass through Linus...and he's probably fairly narrow-minded about this sort of idea.

Share this post


Link to post
Share on other sites
No matter where you hide the timestamp data (dot files, /var, /etc), it will be found and reset. You are better off releasing a feature limited version of the software that can be unlocked with a valid serial -- and then the only thing you have to worry about are leaked serials.

Share this post


Link to post
Share on other sites
if you'd forget the trial-idea, you could do it the opposite way, which is to write a "is_registered"-file after the program is registered. So the program would have cut-features if it can't find this file from specific location with correct keyword or something.. that's the way Borland CBuilderX does it at least, but you can't even use it before you get the registration-file.
That approach is little harder to crack, cause you don't know where the file should be, you don't know what it should be called and you don't know what it contains. But of course, unless you put some personal information about computer and user, someone who has registered the product could figure out the file and tell everyone about it.

Share this post


Link to post
Share on other sites

This topic is 4689 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this