Yes. Now, more concreately still:
Bakeware, for instance, will make an application less performant, won’t it?
Isn’t there a library out there that obfuscates Elixir code? The way the libraries do it with JavaScript code.
I remember when I was searching for a code obfuscation solution for Adobe flash byte code.
I couldn’t find one for Elixir.
Technical solutions can only put minor obstacles in the way. The correct tool for this is called “contract law”, and it doesn’t involve any software changes.
Anecdotally (I don’t have a source to back this up, I just heard it from an old coworker), Github’s on-prem enterprise employs this solution. They strcitly monitor ssh access to the box that runs GHE, and you’ll get an angry phone call wanting to know why you SSH’d in if you do so for an unknown reason. Their stuff is all Ruby, so I have to imagine the same reasoning is at play here.
Some posts have been removed.
@tirana, please be considerate towards those taking time out of their busy day to contribute to a thread you’ve posted. If somebody replies with something that wasn’t quite what you were looking for you can just ignore it - it’s quite possible that that same piece of information might help someone else reading the thread in future. Please keep in mind we are a nice friendly community here 
This leads me to think Elixir is your first compiled language. Use a release, and there will be no source code, just .beam files. Yes, they’re vulnerable to disassembly, but it is some sort of barrier.
To add to the comment from @gregvaughn
A release doesn’t have source code. mix release compiles the code and transfers it to the release folder. Pretty much all the files bundled into the release folder are required for it to run. The release task goes to some effort to remove unnecessary stuff. From the docs on “why releases?” (mix release — Mix v1.14.2):
Self-contained. A release does not require the source code to be included in your production artifacts. All of the code is precompiled and packaged. Releases do not even require Erlang or Elixir in your servers, as it includes the Erlang VM and its runtime by default. Furthermore, both Erlang and Elixir standard libraries are stripped to bring only the parts you are actually using.
The main downsides of building and shipping releases that I’ve experienced are:
runtime.exs are different for each installation (highly likely) you need to remember to apply them again after each update, or (better) use environment variables for the settings.
Just to pile on.
1.1) mix release does that. Note that bundled in a release is the VM itself (:include_erts option defaults to true), this is probably contributing to the ‘so many files’ you see. As mentioned above there should be no source/docs in there, but I’m not an expert on releases.
1.2) I’m not aware of any Elixir obfuscation software, but at a minimum debugging symbols are already stripped from the release (:strip_beams option defaults to true) which may help make decompiled code less readable.
As mentioned above, if you packaged up a release in bakeware/burrito, that would increase the barrier… but if the customer is going to go as far as understanding decompiled BEAM, then something equivalent to an app.tar.gz isn’t going to provide much challenge.
Hey guys,
Is Firefly from Dockyard going to help?
Firefly (formerly known as Lumen), gives developers an alternative compiler to the BEAM. It allows developers to capitalize on Elixir’s inherent distributed systems capabilities and offers new levels of efficiency and speed for compiling Elixir applications.
To echo what’s already been said, your absolute best bet is to ensure your legal agreement with the client clearly specified who owns the source code and what permitted use looks like. You can even have two versions of the contract, and use it as an up-sell e.g it will cost X if I retain the rights, or Y if you want to own the source.
If the client chooses to purchase the rights, give them access to a git repository. If not, don’t.
Either way, use mix releases to deploy your code. While it’s theoretically possible to reverse-engineer the compiled code in your release, in 99% of cases it will be far more expensive than just paying you for the rights.
Reverse-enginering compiled code is really not something to be undertaken lightly, and the Elixir community is still small enough that finding a developer able and willing to do so is going to be neither cheap, nor easy.
It’s possible that your specific situation is the exception that proves the rule, but unless you have incontrovertible proof that there is a very high risk that your client will try to decompile your releases, I really wouldn’t worry about it. Remember YAGNI!