It's Your Code: We Just Run It
by Peter Coffee on January 27, 2007 at 07:44 PM
In a discussion on another thread here, I questioned some of the measures that are being taken in the name of digital rights management. I described my concerns about complex crippleware replacing the "universal machine" of the PC -- but another participant suggested that my stance was in conflict with the whole idea of Apex, since developers have to believe that their intellectual property will be protected as Apex partners.
I'm really glad that this question was asked, because it's likely that one person asking means tens of people wondering. It seems to me that putting code on an on-demand platform, and giving people access to its function but not to the code itself, is about the best thing that's ever been done to let independent developers protect their work without treating their customers as their enemies.
When a customer takes actual delivery of software, it had better be accompanied by a choir of lawyers singing a chorus of "licensed, not sold." That refrain would still be easy for the customer to forget, and tempting to overlook -- since the customer is asked to deploy the code, configure the installation, perhaps install patches down the road, and may be under pressure from users to go beyond the bounds of the license to save some money.
When the customer runs an application in on-demand mode, physical possession of the code is never granted to the customer -- so the need to chant "licensed, not sold" just doesn't come up. The only third party that could possibly access the actual code -- salesforce.com, for example -- is the one with the greatest interest in helping to protect it, and thus protecting the reputation of the multi-tenant platform that supports it.
This is very different from the way that software has long been licensed in theory, while appearing to be sold in every other respect that matters. It seems high time for this better way.
TrackBack
TrackBack URL for this entry: http://www.typepad.com/services/trackback/6a00d8341cded353ef00d8342deb4a53ef
Listed below are links to weblogs that reference It's Your Code: We Just Run It:
All rights reserved Various trademarks held by their respective owners.
General Enquiries: 415-901-7000 | Fax: 415-901-7040 | Sales: 1-800-no-software
Comments
Posted by fact check on January 28, 2007 05:17 AM:
I dont quite see your point, if i add something from appexchange into my environment, i generally can see all the code (scontrols, apex). just like regular software. what keeps me from duplicating it?
Posted by Peter Coffee on January 28, 2007 03:09 PM:
An S-control using JavaScript runs that JavaScript code in the browser -- but server-side code, including what's written with Apex Code technology, is not exposed to the client.
When I mentioned to Apex guru Adam Gross that this issue had come up here, he pointed out that S-controls can also have their implementation concealed from the user by using a technology such as Flash, rather than the most-used Ajax/JavaScript model -- further improving the intellectual property protection available to developers.
Posted by fact check again on January 30, 2007 04:46 PM:
okay, i understand a *user* isnt going to see my code, but the admin that downloads an app from appexchange most certainly can see what i am adding to his environment, correct? so the administrator of the customer org can see my code, etc.
perhaps i am wrong, but then again, if i am, then how would an administrator ever feel safe to allow it in?
i do agree that s-controls made out of flash would work, but we're talking about the "on demand language" of apex, not Adobe developer tools. or are we?
still seems like the user of the appexchange app can see quite a bit of IP. not saying that this is bad, but to proclaim that "licensed, not sold" no longer needs to be explained to the customer seems like a bit of a stretch.
by the way, CONGRATS on the new gig and am very glad to see you posting here. look forward to many more great topics!!
Posted by Peter Coffee on January 30, 2007 06:06 PM:
You ask, "the admin that downloads an app from appexchange most certainly can see what i am adding to his environment, correct? so the administrator of the customer org can see my code, etc."
Do you see the code of the salesforce.com applications that you use? That code runs on our systems, not on the client device. That's what makes Apex Code so special: we give you access to the same technology that we use ourselves.
When Marc Benioff says, "now you can create the next salesforce.com," don't think of that as mere metaphor. Take it literally. This is new.
Posted by Jan Sabelstrom on May 28, 2007 09:44 AM:
Unless I have missed some announcement, I still do not see how the Apex code will be protected from view by the installing org. I asked this specific question as well back in January and the answer was that it was recognized as an issue and was being addressed (but no answer yet, to my knowledge). You can see the code in an Apex package by finding the Triggers on buttons and looking at Build>Code>Packages. Of course, an org that creates their own in-house Apex code should be able to see this. But what of the 3rd party installed packages, once Apex Code goes GA?
As for s-controls, not all functions they can perform can be accomplished with Flash, and some of the most useful may very well contain a significant degree of 3rd party IP. Given cross-domain scripting restrictions in browsers (a good thing), one cannot simply contain the IP javascript, etc. in a page within an iframe and reference it from the containing s-control HTML page. What would be most helpful is if salesforce.com would be willing to allow partners to host this on its web servers and provide for some sort of encryption (e.g., http://www.protware.com/ ).
These are significant issues that I cannot imagine do not give many partners pause. Consequently, I think the SFDC community also suffers as some of the smartest solutions are not yet making their way to market.
The comments to this entry are closed.