I am about to embark on a project where the customer wants the product to be a “work for hire” and to own all the source code. I have no issues with that, but in the project I’ll be using a library of functions and custom tags I have written prior to the project, on my own time, and I don’t want the customer to decide that, just because the code for those libraries were included, that they have full rights to them. They are aware of the situation and it is in the contract, but is there any way to deploying my libraries without providing the source code, mixed with the new code I’ll be writing for them?
While I (like you) look forward to any clarification of Lucee support for that, I’ll note for you or others interested in the topic that CF does support such sourceless deployment. See the docs on the command line tool, cfcompile:
And in case anyone may identify a Lucee option, let me elaborate a bit on some things I’ve seem folks misconstrue about this cf feature.
First, cfcompile essentially facilitates conversion of the cfml code as a Java class, meant for distribution and execution in place of the CFML source. Things are obfuscated, but some strings remain clear text. Then again, while it’s true that Java tools exist to reverse java classes into source, in this care that would be Java source (that Cf code is converted to) rather than cfml code.
It may be those two characteristics still suit for the protection you sought.
Finally, to be clear, cfcompile is not to be confused with the other long-existing cf cmdline tool, cfencode. While the output of that is truly encoded (not human-readable at all), sadly it is indeed just encoded, and there have long been tools to decode that, which WOULD produce the original cfml source.
So if there is a feature like this for Lucee, it could be useful to know which of these its more like.
Hope that helps, Ross.
Compile the source codes into a .lar file (lucee archive) which you can register as a CFMapping. So, for instance
/foo is a CFMapping that points to the root of your archive. The code is compiled, so it’s just bytecode. The biggest issue here is that Lucee’s compiled bytecode often times won’t work on future versions of Lucee. It’s really meant to be more of a deploy tool where you’re re-creating the lar on the current version of Lucee, not a long-term tool that will create an artifact which will always work on future versions. So if you go the .lar route, it’s pretty much guaranteed to quit working after a few Lucee updates are applied to their servers.
Really, the contract is your way to go there. Declare all your existing libraries that you reserve your rights to in the contract and package a license file that declares that with the code.
Ross, make sure that you keep the future maintainers of the software in mind. If another developer needs to work on this software a couple of years from now, they’re going to need to be able to read the source of your libraries, possibly fix bugs, and make enhancements to the code. Shipping your code without the source (or heavily obfuscated) could make their job really difficult.
I think you need to be very clear about how that code is licensed for your client’s use. It sounds like you’ve already addressed this in your contract, but if you want to look at the contract language that my company uses, I’m happy to share it with you.