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. > > 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 > -- Best regards, Igor Stasenko.
