Igor Stasenko wrote:
On 30 May 2012 16:04, Ben Coman <[email protected]> wrote:
What ideas are floating around about mixing open source and closed source
using Pharo? I am implementing an IEC Standard object model for electrical
power systems to provide a platform for developing electrical applications.
I am considering the case where a company may maintain the model of their
electrical power distribution network in the open source platform, but then
buy various commercial plug-ins perform different calculations upon the
shared model. Here are the options I can imagine...
1. Using fuel to load binary packages within the one image without the
source. Currently available technology but viewing and decompiling bytecode
is still possible - but to what degree this enables reverse engineering I am
not sure.
Decompiler is able to fully reproduce the source code of method.
only variable names is lost, but you can see everything else quite clear.
2. Having VM support for restricting displaying/decompiling bytecode. To
avoid the ease of switching to another VM without this restriction, the fuel
package could be encrypted with a key match one compiled inside the required
VM.
this is not an option.
A current Debugger implementation implies that you have access to CM bytecodes.
A required implication of (2.) would be that you could not debug
"through" that package. While this might be unfortunate from an
open-source debugging view point, in comparison to having the whole
application delivered closed-source with development tools stripped - I
would still consider this to be a step up. Ignoring the current
implementation of Debugger, could something like this be reasonably
achievable?
To expand on this with a specific use case... The VM could internally
generate a public/private key pair. When requesting a plug-in from an
App Store, the public key is sent which the App Store uses to encrypt
the bytecode of the plug-in. Once downloaded into the image, upon
execution the VM receives the encrypted bytecode, decrypts it with its
private key and caches the decrypted bytecode internally, such that it
is never visible to the image.
(btw, I'm assuming CM bytecodes was a typo meant to be VM bytecodes? or
otherwise what is CM?)
3. Running multiple images on a single VM such that the VM passing message
calls efficiently between the two images like an "enterprise bus*" - one
open source and one closed source. Any common base objects between the
images might be shared on a copy-on-write basis.
What are your thoughts?
I think option 3 is most vital:
you can communicate between two images like between two parties who
don't trust each other (so images should handshake, use encryption
key(s), and try to log-in one to other), then if succeed, one can be
able to see source code use remote debugger etc
Nothing new under the sun...
cheers -ben
