Hiding source code (in a country with no laws)

[diego_de_lima]

Hi Monks,

I know this topic is a very, very controversed one. Iīd like to hear your advice about it, considering that:

1. Itīs a web based ERP software, installed on a server on the clientīs location.
2. I donīt want to be 100% safe on hidding source. I want to make it harder to view/understand it - allowing me to put some limitations inside the source.
3. Good licences/contracts are useless: in my country (Brazil) government doesnīt care about intellectual property.
4. Iīve already had very bad experiences with that in the past - so that's why I know good contracts arenīt enoungth.

So, what are your advices on preventing a client to cancel a contract and simply keep the software installed in the server (cut my ssh access, etc. and keep the site running).

Hope not to start any long discussion, but just have some techinal advices in situations like that.

Thanks,

Diego de Lima

[brian_d_foy]

Hiding the source isn't going to stop the client from cancelling a contract or continuing to run the software without you.

It sounds like your question is more about how to keep a client giving you more money than anything technical. Instead of that, sell the software installation for a price that makes you happy even if they don't give you any more money.

If you want them to give you more money, improve the software and add features which make them come back to you. :)

[DaWolf]

I'm sorry but please don't blame our country or the government, since they have NOTHING to do with this.

Brazil have a very powerful and ever growing Open Source Community, and even in the copyright terrain there are tons of companies that work with licenses, including some who have special departments only for copyright issues involving software.

So I repeat: Please, ask your question, but DON'T put the blame on an entire country. Generalization is a bad thing, giving others wrong concepts is a bad thing and doing all this based on your past bad experiences is a bad thing, because EVERYONE in EVERY country has them, so just get over it.

Thank you,

[perlsen]

Good Comment given by you. because no one have the rights to blame an entire country. Because every country has its own originality and popularity.
we can raise or ask questions and suggestion, so every one will give their solutions.

In this question point of view


• First We should make good product, which could satisfy the customer most of the time.
• if we want to make good touch with customer, introduce new ideas or enhance your old product and deploy it in customer side.
• if you always go for updation and new ideas, the customer always get in touch with you and welcomes your ideas.
• Always, Try to make your Product more attractive.


Thanks,
Perlsen

[diego_de_lima]

Iīm not acctualy blaming the country, but when you are making a new business plan, you have to consider seriously your country, market, language and technology strenghts and weakness.

Based on the weakness, you have to find solutions. It's as simple as that.

Brazil has a big open source community: thatīs nice, but it's not the point now. In fact my company work with open source contracts, but now I have a contract which is not open source, and I want to protect it.

Iīve wrote "(in a country with no laws)" because most discussion about it I've seen end up with: "Make good contracts and you are safe".

Diego de Lima

[DaWolf]

Quote: Iīve wrote "(in a country with no laws)" because most discussion about it I've seen end up with: "Make good contracts and you are safe". End of quote



And this sentence continues to be true, here, there, anywhere. Put some clauses defining how the code should be protected, fines, punishments, everything. A good contract (whether is apllied here, in the U.S. or Mars) should always have that, being the code readable or not.

Again I repeat: your problem is not specific to the country you are in. Your problem is, as a matter of fact, every software company's problem. And most people solve it with good contracts.

I agree that your BP should consider everything including geographical, economic, social, anything that matters, but still I repeat: your problem has nothing to do with your country, it has with our market and the nature of our products.

Sorry man, I don't mean to offend anyone, but I'll never agree with you posting here and there about how our country has no laws and such. There are many brazilian programmers here and I never saw any of them doing such statements.

With all do respect,

[kwaping]

So, what are your advices on preventing a client to cancel a contract and simply keep the software installed in the server (cut my ssh access, etc. and keep the site running).

If that is your main concern, I suggest hosting the site yourself. If you can't or don't want to host the entire site, then maybe you can make your product into an RPC-type server (client makes remote calls to your server, which processes the information and returns results).

I'm sorry if this isn't an ideal solution, but in my mind it's the only real way to keep your product safe in a situation like that.

[acid06]

Actually, I find this kind of weird since here in Brazil copyright law is only enforced in the business world. Piracy rates are wild, but any medium-sized company has original software.

So the point is that, every company that's big enough to need an ERP software is big enough to worry about software piracy. Not to mention that contracts are enforced (the problem might be that you're not able to get them to sign a contract with you).

I know I'm not answering your specific question, but I think this might be slightly more relevant. As tirwhan wrote, the problem lies in your business model. As I understand you expect to provide them with a product, provide no support whatsoever, and still get a constant revenue stream.

Things just don't work this way.
You can sell them your product and then they may choose to purchase future upgrades from you or hire another company of their choice in order to further develop the system, if they're not pleased with your services anymore.
The other way around is that, instead of selling the product, you sell the service. So you'll have a revenue stream provided you keep doing your job, which is to maintain the software.

Both of these models work pretty well. Anything else probably doesn't.

[samtregar]

The solution to your second requirement is a Perl obfuscator. None of them are perfect but I think a good one is likely to make the code harder to understand.

However, I doubt this will really improve your situation. Your clients will quickly realize what you're up to and most likely demand you cut it out. Giving your client something that they can't possibly maintain if you get hit by a bus isn't very nice.

-sam

[mattr]

1. Spend your time selling another copy to someone else.
2. Offer a monthly retainer contract or a case-by-case basis where they pay a minimum per incident, plus hourly fee if beyond 2 hours onsite. Or offer a discounted remote fix solution where they let you log in remotely, saves you time too.
3. If it is a complicated system, they would rather hire you than get someone else to dive in and wreck their system. Let them know it will cost extra thereafter for you to fix that guy's mistakes, and there is no more warranty if others touch your code.
4. Far more likely that a hardware, purchasing policy or other problem will make them stop using your system than that the system doesn't work or maintenance is expensive. For example I installed two turnkey search servers for a multinational, and serviced for 5 years plus added additional functions a few times. But maintenance done by an employee onsite, in fact I spent a lot of time on extensive manuals. I beat out Altavista and other solutions when I sold my system to them, but they stopped using it due to 1) reseller not supporting, and especially 2) lack of replacement RAID drives from a linux hardware manufacturer that stopped supporting their own system. There is also I think a 3) lack of reseller selling to other clients, so it cost me a lot to invent things for only one client. Even though it worked great.. a gigabyte comprised of 60 databases, searched with mod_perl and htdig in .1 seconds per query.
A superior solution to what they have now too, the missing ingredient is people enthusiastic to support the project either with sales or with hardware replacements. I think there is a lesson here for you too. If you have a good product get a steady list of clients who want to use you, offer additional development training and product updates, and stop thinking about obfuscation. Write some manuals and build a dialogue with the people in the customer organizations. Talk to the engineer using it and make them pay for you to come back and train people, etc.
My guess is an ERP system is complex enough that no sane client will think of bringing someone else in to service it. They will just throw your obfuscated garbage out the window and get a new one. While a client will usually not demand source code, they will be pissed if they have someone who finds out you are obfuscating. I've always offered manuals and full source code and you know what? They respect that and they also keep coming back.

[zentara]

If you are in a cut-throat business climate, why not build in some bugs that popup and disable the software on a regular schedule, requiring them to hire you to fix it. (Just like Microsoft :-) ) You could obfuscate your code enough to make sure that they would have to hire someone to de-obfuscate it, so they may as well pay you.

Another possibility is signing longer term agreements, with penalties for early cancellation.

If that fails, just put a higher price on your product, and tell them why.

[shotgunefx]

This was a long time ago, using a web based publishing platform.

Near the bursting of the dotcom bubble, I had already got screwed quite a bit by one overinflated dotcom going supernova.

So another e-whatever was starting to get shady with payments. Using the software was conditional on payment, but being a 3rd party service, I really couldn't enforce it without a real lot of legal wrangling.

As a precautionary measure, I set it to blow up about three weeks after payment was due. Not any real damage mind you, but just bail with an error message like "Something is wrong, contact blah, blah". (I was tempted to have it say "Pay me deadbeat!" )

So the date comes and passes, no payment, no suprise. Won't answer calls. About three weeks, I get a call. :)

They had tried to go through the service provider, but luckily I was tight with them. They called me up and asked me why they were going through them to try and troubleshoot it. I explained what I did and they told them, "Oh that's custom software, we don't support that, you'll have to contact the developer".

Needless to say I got my check overnight. Luckily, I had very few clients like that. Most were and are still viable and going on seven years, still working with them happily.

[dimar]

Luckily, I had very few clients like that. Most were and are still viable and going on seven years, still working with them happily.

I wonder how "happily" they would be working with you if you admitted to them that you see no ethical problem writing software with logic bombs, malware, and who knows whatever else in order to extort prompt payment from your "customers".

I would not knowingly buy a car with brakes that are intentionally designed to fail if the bank should happen to make a mistake and fail to submit my car payment on time.

I would not knowingly buy a meal with poison in it if I knew that getting the antedote was contingent upon my waiter being happy with the size of the tip.

My bet is you would not like those things either, but the tactics you boast about here don't seem much better.

If someone is late paying you money, there is *always* a remedy: more money. If someone pays late, along with interest and whatever penalties for the lateness, then you have gotten the full benefit of what you bargained for, perhaps even more.

If, however, someone delivers a unique good or service, and intentionally misrepresents a concealed defect for the purpose of 'future leverage', that represents a risk to someone's *business, reputation, and livelihood* with potential damages that can never be restored with mere money.

Sure, perhaps no lives were at stake in your particular scenario, and perhaps they were "deadbeats" ... but it is also possible that your opinion might be wrong, and you could be opening yourself up to all kinds of liability with your 'vigilante' justice, breach of contract, and misrepresentation.

[shotgunefx]

Did you even read the post? Contractually, they had no right to use the software the day I didn't get paid. Their use was contingent on paying me on time. That's the deal, in writing.

So making the software refuse to publish 3 weeks after the payment date is far from malware. It's no different then having a trial evaluation of software expire after the period is up. And yes, they were deadbeats. They were obligated to pay me and they didn't. They didn't answer any communications for weeks. The day they couldn't use it, was the day they paid.

They didn't call and make arrangements. I certainly would have worked with them, but they didn't. But magically they have the money in the mail an hour after we "talked" when they had to.

This isn't something I always did. It's something I did once. I wish I did it to a few more. I ended up losing at least $30K that year to people doing things like that. Even before I knew better, I didn't trust the gimmicky companies who were sprouting up in that time. Didn't see how you could blow through $70,000,000 a year and think you could survive selling t-shirts on commision.

The point about "my other clients" was that he should try and build better relationships so you don't have to deal with crap like this.

When my mother and brother got cancer, basically everyone I worked for (some big companies too), put all their plans on hold for six months while I took care of my family. The VP of one of them came to the funerals. That's the point. You can build good working relationships and ultimately, that's what you should try to be doing. Because unless you have to, dealing with people you're worried about screwing you isn't worth it.

So how would my other clients feel if I told them that story?, they'd laugh about it because they know it's not something I'd do to them.

[tirwhan]

My technical advice: look for a new business model.

Other than that, do a Super Search on this site, this topic has been discussed repeatedly.

[jbrugger]

I'd create a key (like an md-5 hash) based on the current local time.
In the app, id set the date on what the md5 hash is based, and keep the software check the current date against the date set in the application (if altered, the md5 key has to change as well), and keep it working for as long as your contract is. eg, set a timeout date (second md5 hash).
This way, you can force your customer to renew it's license, and then you have to set two new dates in the application and create a new license file with the md5 keys in it.
But just like with any key, software etc. it's far from perfect.



#pseudo:
my $sDate="01-01-2005";
my $eDate="01-01-2006";

checkKey( $sDate, $eDate );

# obfuscate this sub.
sub checkKey() {
  my ($sDate,$eDate) = @_;
  require Digest::MD5 qw(md5_hex);

  # md5 keys of your license file:
  my $k1 = "deda6aea2f525d96806cb8fa18998d94";
  my $k2 = "00026573e6a61456bb57336800bf663e";
  my $k3 = "9533f158f330713d6e7e2cbdeaf245ea";
 
  if(
    md5_hex($sDate) eq $k1 &&
    md5_hex($eDate) eq $k2 &&
    md5_hex($sDate . $eDate) eq $k3 &&
    $eDate < $currentdate 
  ) { 
  return 1; #allowed to run
  } else {
  return 0; #renew your license!
  }

}

[samtregar]

That may be the dumbest copy-protection scheme I've ever seen! What's to stop the client from editing just one line of your routine to read:

   return 1; #renew your license - NOT!

Or better yet, just edit out the call to the subroutine in the first place!

-sam

[jbrugger]

Perhaps you did not uderstand me.
It's just dummy code that gives an idea of what you could do, returning either 1 or 0 is just a boolean expression or calling it as a sub is just to help me explain what i ment to do, this is not a final solution, just an idea on how you could do something like this. How you implement it in your code is up to the programmer.

The thing i ment to do, is showing a way to use dates to see if you've got a valid license, not the implementation itself.

Anyway, using a license code is not an ideal idea anyway (as i said before), it allways can be hacked out. The OP however did ask not to be 100% safe on hidding source, just make it more difficult.

The idea of calling for certin functions to your own server is a bad idea as well, it's not failsafe. It however gives fresh ideas to the OP so he can think of a proper solution to his problem.

[sanPerl]

Since you have to expose your code to your customer. It seems there is NO real technical solution. So Create two copies of your code(Your copy and Customer's copy). Your copy should be well commented, well indented. And in Customer' copy
1) Convert complete code to a single line
2) Remove all good comments
3) Insert wrong comments, which would add to the confusion.
4) define non-sense variables with some mis-leading names, subroutines/classes/Modules with some mis-leading names and don't use them in code.
5) Increase size of the code by writing non-sense comments.
6) Take care that these things would NOT affect the output by any means.

Most probably customer would prefer to give you maintainance part rather than debugging your code. However a real debugger would still extract your logic, but you can always make his life difficult.

Regards,
Sandeep

[spiritway]

As I read through the many interesting answers, especially the ones debating the ethics of using a logic bomb, it occurred to me that there may be an ethical way to do this. How about simply telling the company that the software is time-limited, much as is done with trialware? That would at least eliminate the problem of using shady tactics - they'd know beforehand that the software would need to be renewed at the end of the contract term. You could set it up to respond to more than one activation key, perhaps, or just make the new working version available once they've paid. Just a thought.

I'm thinking that if they have a problem with that, they probably have no intention of paying you anyway.

[polettix]

I do agree, forcing clearness from the beginning always pays.

If the business model does not allow for a full sell of the software (as suggested by someone, but it implies higher up-front costs for the buyer company) and doesn't fall in the Open Source "support" model, one can sell it on a time based license, making it clear in the contract and including also clear schedules for:

• expected renewal of the license;
• end of service if a new licence is not agreed in time (which should be a fair amount of time after the expiration of the first bullet).

In this case, I'd encapsulate some central functionality inside a XS module, together with the limiting code.

The OP should also consider how long all this should go on before they acquire the right to use the software without limitations. There are softwares (like a popular GSM planning tool I once used) that are basically "rented" for limited times, but this timed scheme could just be used to divide the price that makes *the OP* happy in chunks that make *the customer* happy.

[walto]

Have you considered to deliver your application in binary form? You can make a binary using pp. Then you just have to be creatve about your limitations (date, regular contact to your server ...)

[Anonymous Monk]

pp doesn't obfuscate code. In fact, when you make a pp executable, it's just an executable zip file, so if you rename the .exe (assuming windows) to .zip, you can extract the code, and read it with vi!

[turo]

and what's about to do a kind of

client                               some server of yours
                                   at some place
======                             ======================
send(petition to you server) .
                              \____ Annotate that date for 
                                    later use.
timeout(wait(response))             All is okay (they has 
                       |            pay you, and so):
                       |____________send(ACK to client)


i don't know how to call it, ^_^>, but it could be your solution:
1. You install a script that sends a request every week or day or hour or even every 60 or 30 seconds (whatever you want).
2. If you have a server (you must have a server for this scheme to work), then logs the client request (something like this: [Sat, 11 Feb 2006 10:29:55 +0100] ID:SOME_ID_YOU_ASSIGN_TO_THE_CLIENT received from the ip:x.x.x.x an acknowledge request
3. Your server sends a reply to your client.
4. If the client didn't receive the ack whitin X secs, then, it sums one to some counter ($counter++).
5. If the client, didn't receive any ack in X succeed times ($counter > X); then do something for preventing the client to use the program (this could be a thing a little bit nasty ... like to auto-rm, to introduce some extrange byte, to make the perl compiler to abort, or to make the binary not to execute ...)
6. Everytime the client have a response ($counter=0); not worries and continuing serving

So, when your are not agree with the client, you disconnect your application or filter the client ID you assigned. If the client, filters your ip, the application will autoremove (or so). If the clients, changes its IP, you can know it, and the application will work. If the ...

Uff, i feel bad, guilty and dirty ... i must pray at the oratorium for expiating my sins ... ugh

turo

update Sat, 11 Feb 2006 11:50:31 +0100
i feel really bad for, this ... the dark side is possessing me ...

[Perl Mouse]

Hire some tugs to break your clients kneecaps, shoot their wives and rape their dogs.

[kutsu]

Though dropping a tug on someone may break their kneecaps (and several other bones) - I fail to see how it would be capable of doing the latter two.

[demerphq]

I think he meant 'thug', although what the mouse has against followers of an obscure Indian cult of death I don't know. ;-)

[blazar]

I've been using (La)TeX¹ for quite a few years now and I had no incident of sort nor did I cause any to others. That I know of. Well, not by means of TeX or TUGs, that is...

---

¹ You either have to already know TeX or check the link to understand the joke.

[Anonymous Monk]

That's cruel!!! The dogs didn't do anything wrong! :-(