If someone saves out your source code, then they can. You can put a copyright notice on it.

If they use it on their web site without permission, they're violating copyright. However, that isn't why it's not a problem.

All of your:

* Version history (except for public versions) * Unit tests, test plans, test data, test results * Bug trackers * Developers notes; QA engineers notes * Code maintenance manuals * Developers brains; QA engineers brains etc.

Are private, and someone leeching your content cannot obtain them.

Not to mention the fact that, if there are any server-side components, they'd need to reimplement them.

The time it would take them to understand your code, reproduce all the missing parts, they could just as well develop it themselves.

In fact, if they hired engineers with the calibre required to do that, the engineers would probably WANT to implement it themselves, not rip yours off.

Do not consider that the .js files are all of your development information. They aren't.

Additionally, the version that they leech is always going to be "behind" the one you're developing, right?

So in the time they take to figure out how your code works and how to integrate it with their own back-end systems, you'll have released a better (At least hopefully better) version. So they're permanently behind you, with an inferior product.

My main conclusion became server side processing is the black box at least in my case where the value add is through the REST APIs the javascript works with to present the right data to the user.

If it's like a javascript web game without much of a server component, you could try to hide a lot of the execution of the code within in a closure. dynamically loading the code with a script would add to this obfuscation.

in the end you are probably fine.

one final bit of obfuscation that i have always wanted to try was to load the JS via a web-socket on a worker process. that should even hide a lot of the js file being loaded.

if you needed to go farther some people have even done some degree of encryption. again all of this is probably way more than you need. I've never worried about this. if someone has the time to steal your code and work with it you should probably hire them or go have coffee with them and ask for feedback.

it's a great honor for someone to read and interact with your code.

Anyone trying to steal your code would simply remove those tests. As MarkR42 said, your main protection is that your production code, by itself, just isn't worth that much.

I'm sure it exists but 90% of it is a mess and it would be easier to reimplement. The other 10% is beautiful but only works if you have all the proper server side code.