Hi Kim,
Thank you so much for giving a real life example of damage due to source code theft regrettably out of your own experience.
Not everyone is willing to share their own bad experiences, so thank you.
Regards,
I think that the example that someone used of a car door is an apt one. Everyone knows that a competent car thief can be in your car and gone in under 30 seconds, regardless of what alarm system you have or what kind of locks. The point of an alarm system isn’t to keep out the really competent car thief; you want to keep out the kid walking down the street looking for an easy opportunity. If there is a perceived problem with our Servoy applications being “too open”, then I think that that is a worthwhile concern. In the long run, it is probably easier and cheaper to protect our apps in some way than to discover those who might have stolen from us and take them to court. Now, I’m not expecting Servoy to spend millions of dollars to come up with a way to prevent theft, but perhaps they could lead a discussion as to how to minimize the risk, using programming practices or 3rd party tools, or whatever. Their only expense in this might be time, and that is certainly a valuable and rare commodity, but one that would certainly be appreciated by the developer community.
Now as to the comment about how Servoy could not have something in place after all these years…That’s a legitimate question, but it really only comes into play if your platform is going to be distributed in an environment where there are not already other mitigating mechanisms in place. For example, if Servoy’s main business model (and I’m only speaking as an example and not as one with any actual knowledge of this) is to install lots and lots of clients into large corporate locations, you are dealing with an environment that is most likely already hardened against intrusion or unauthorized use. So, your app is protected by means outside of Servoy. That would make sense to me as a rationale. That model, of course, wouldn’t help ISVs, for example, like me, who sell their products to be used by individual users. My particular risk is mitigated by the fact that the niche I work in is served by only a small number of vendors, and it’s likely I’d notice something that started to look suspiciously like my system. However, if that did occur, I don’t know that I could afford to litigate other than sending a really nasty letter.
Now, if I’m anywhere near being correct in my assumptions (and I could be completely wrong), I can accept Servoy’s rationale for not seeing this as a really high priority relative to other things they might be doing. I would hope that in the nature of supporting us little guys out here, they would accept the invitation to lead or participate in a discussion to help us figure out ways to protect our intellectual property, and perhaps consider some additions to Servoy in a future release that would help accomplish this. That seems fair, and I, for one, rookie that I am, would welcome that.
I would be happy to initiate such a discussion here, but honestly, I’m not in a position right now in my learning of Servoy to do much more than ask questions.
Thanks and have a good day.
Ron
Johan,
I am not sure if your reply is directed at David or myself but in either case, his reply adequately summarizes the situation. If a customer deploys my solution on premise and they have access to a Servoy developer environment, there is nothing to prevent them using multiple copies of the software by modifying the source code to overcome any licensing scheme I come up with. If I deploy my solution through a third party SAAS environment, there is nothing preventing the third party from replicating the solution on multiple private clouds thus making the unauthorized use almost impossible to track. I believe that encryption of the source code will work and that is is a stronger method than obfuscation. I agree no system is hacker proof but the goal of deterrent systems is to make it expensive (time required, resources required, little value received in return for the resources expended) to hack a system and to force the hacker to leave a trail leading to their eventual detection. The method can be made as secure as the present Servoy licensing method and possibly more secure. Hack-proof no, strong deterrent yes. Compling the javascript would be a strong deterrent, having source-less solution exports would be a stronger deterrent, combining the first two with a developer supplied license scheme along with code modification detection schemes, call home functions, etc. would be the strongest deterrent. IMHO. I welcome the chance to continue this dialog in public or private to investigate objections and test our mutual understanding.
Hi Jan,
I was shocked by your idea to make (structurally) a profit / living out of taking source code thieves to court.
Please look good at the well thought points of view of Ron and rvpm and give us, non Saas Servoy ISV’s, a brighter future (with Servoy)…
Please comment,
Regards,
lwjwillemsen:
Hi Jan,I was shocked by your idea to make (structurally) a profit / living out of taking source code thieves to court.
Please look good at the well thought points of view of Ron and rvpm and give us, non Saas Servoy ISV’s, a brighter future (with Servoy)…Please comment,
Regards,
Lambert I did not say that, please reread my post. And also read my last line, as I stated we take this pretty serious and are in fact doing active r&d on these items.
btw ServoyWorld is a good place to talk. Make sure you all come.
Again encrypting source code doesn’t give you anything, it must be decrypted at one point to be executed.
At that point the source code is fully there. With the solution model it is also wide open
A simple js script doing an iteration over all the global en form JSMethods of your encrypted solution will give you the full source in a heartbeat
Now you can say, ok then the solutionModel shouldn’t be allowed to give that source back. Yes we can do that, but it is an open source piece of code
Its very easy to just remove that check or make a simple plugin that does exactly what the solutionModel does but then without the check…
So encrypting is really a no go, its a waste of time and effort, doesn’t bring you anything then a false sense of security.
Also if you have a module that others want to program against, we need good solution for that, that they don’t have the source but they do have the api and the runtime binary.
Encryption also doesn’t really help here. Compiling does.
Johan,
Right.
We would have a better (security) feeling when there only exists compiled js code in the repository and no source js code.
As an extra bonus the app.server does not have to compile the js code anymore.
jcompagner:
Also if you have a module that others want to program against, we need good solution for that, that they don’t have the source but they do have the api and the runtime binary.
Encryption also doesn’t really help here. Compiling does.
This is exactly the situation in my case. So if you can find a solution with compiled javascript, it would be the perfect solution
lwjwillemsen:
As an extra bonus the app.server does not have to compile the js code anymore.
I’m not sure the app.server is compiling the js code. It is probably interpreted.
Jan,
I’d love to come to ServoyWorld to discuss this with you folks further. Just can’t afford it right now. But, as soon as I’m rich and famous thanks to the Servoy-based business solutions I’m working to deploy, you can be sure that I’ll be there!
In the meantime, do those of you interested in this issue feel like it’d be worthwhile to open a thread or two discussing the individual issues? That might be a good way to start documenting potential risks, evaluating how “real” they are, and perhaps coming up with some potential solutions. This could include using different programming practices, suggested updates to the Servoy platform, etc. I’d be happy to kick off such a discussion if people feel it’d be worth while. I could prefix each thread with something like "IP protection - " and then follow with a question to be discussed. I could also collect responses into a single summary document that we could use of fuller discussions, and perhaps as a guide for others to use, if we gather enough useful information. At this point, all it’s costing us is time (which, granted, is in short supply), and I’m willing to pick the secretarial chores if we think it’s a worthwhile exercise.
I have a few questions in mind already, and we could start there, expanding as needed. I’m only suggesting this as a way to organize the discussion in a way that makes best use of our time, in an effort to sort of compartmentalize each part of the discussion.
Well, let me know what you think and I’ll kick it off if the interest is there.
Have a good day.
Ron
Ron feel free to open a new thread or discuss here.
Here goes solution #1
If you’re an ISV you can protect your on premise solution by:
- changing the default passwords of your repository database and not supplying them to your client
- not supply servoy-admin rights to your client
- automate your Servoy app to post to the admin pages updates
- not give .servoy files to your clients
Additionally r&d is looking into js compilation.
Thanks Jan, I’ll do that. I just thought it might be better to segregate individual scenarios within this topic in order to capture the information in more manageable chunks. We can give it a try and see how it goes. First topic going up right now…
Ron
Hi Jan (Aleman),
Today I attended a meeting concerning legal and technical protection of source code (at ICT / Office The Netherlands) so I thought :
Wasn’t there a Servoy forum thread concerning the technical side ?
So I found this one with your quote a year ago
Additionally r&d is looking into js compilation.
So what is the news / status on this ? In the ICT-business there is a saying : No news is bad news…
Kind regards,
Our approach is still working great for us.
lwjwillemsen:
Hi Jan (Aleman),Today I attended a meeting concerning legal and technical protection of source code (at ICT / Office The Netherlands) so I thought :
Wasn’t there a Servoy forum thread concerning the technical side ?
So I found this one with your quote a year agoAdditionally r&d is looking into js compilation.
So what is the news / status on this ? In the ICT-business there is a saying : No news is bad news…
Kind regards,
Hi Lambert
Great to hear that you attended a session at ICT Office. I’m actually in the steering committee of SaaS~Cloud within ICT Office so I know quite a bit of background about this session. What did you learn at the session and what are your action items? How do you feel they map against my and Johan’s earlier suggestions in this thread? What do you see as threats, concerns and take-aways?
Hi Jan,
Key points imo of that session :
Legal (Dutch) :
- To prove intellectual ownership of software : Documentation of your software ! A version control system (like SVN) is a strong tool for proving intellectual ownership.
- There still exist many bad IT-contracts. Never speak about ownership of software in contracts but speak about (your) intellectual ownership of software.
- Without a good contract a IT subcontracter (the author) becomes (by law) the intellectual owner of the software he writes for you.
- Obtaining and especially maintaining a patent on your product is very, very costly in Europe.
Technical :
- .Net and Java intermediate code is easy to re-engineer. (So don’t use hard coded texts like ‘Illegal license’ in your source.)
- With browser apps (ie Servoy Webclient) the end user can not touch your binaries if your server is secure.
- Technical protection does not make much sense if your code can easily be re-engineerd.
- The best you can do at this moment is real time in memory decryption of your encrypted binaries (jar’s). Performance penalty ?
I believe there are tools to do that for Java and Javascript.
Hence I thought it was a good time to inform about the security developments within Servoy…
PS about the earlier suggestions : They are useful and we are planning the automated solution update/import to develop so the servoy-file will not be exposed to the end-user.
How nice however would it have been if that was some kind of core Servoy functionality…
Regards,