Portecting IP of Appexchange Packages
I was just getting my laptop ready for Dreamforce and noticed changes to the Eclipse Apex plugin. It’s one of those times when I see something and say, “I’m pretty darned sure it didn’t used to be that way.”
You’ll see that S-Controls from packages that are installed from the Appexchange are displayed separately in the “Installed Packages” folder. I’ve got Vertical Response installed.
S-Controls that I’ve written are all under the S-Control folder.
So, I think this is how Salesforce.com is planning on protecting S-Controls that are installed from the Appexchange. Before this release, once you installed an S-Control from the Appexchange you had full access to the source code. You could modify it, even repackage it and share that link with your friends.
Now, I suspect, Appexchange package vendors will be able to flag their code as protected. Then it won’t be modifiable, and may not even be visible. So vendors can write S-Control code without having to worry about it being copied. And as vendors start writing Apex, which will live in your instance, it seems like a requirement for this business model to work.
All speculation, but I know this is a feature they’ve wanted to deliver for a long time, so I think it’s pretty likely.
Update: Simon Fell made the valid point in the comment that it’s pretty much impossible to protect S-Controls because they are text scripts interpreted by the browser. So the break out seen above probably relates only to Apex blocks and triggers.
September 15th, 2007 at 11:03 am
As s-controls are client side technology, you can’t protect them, even if the server side doesn’t let you see them in the setup tree, or from eclipse, they get downloaded to the client to run, so they’re pretty much a lost cause if you care about protecting your source code.
September 15th, 2007 at 11:26 am
So true. Most of my web programing comes from viewing source and then stealing the best ideas I find!
September 18th, 2007 at 7:09 am
We tried a simple version where we obfusticated the java script source and then served it in response to an calculated key (only if the key matched a hash of the session ID would it serve the right code). Made it harder to read (but also harder to code, slower to run, debug etc.). In the end, an interesting idea that didn’t really work.