5 comments so far and 4 have either missed the point or are distracting the discussion into lessons on semantics. I'll definitely fail to put it as well as the author did, but I believe the point wasn't "surprise, copyright doesn't exist", the point was client-side js by nature shares code, and sharing code is good, so this community is in a great position to fully embrace open source, and it should.
It's funny that one can make the opposite point. As I wrote a couple of years ago [1], we're getting to a point where many sites actually have obfuscated source, as there's much more attention paid to perfromance optimisations. View Source is becoming a thing of the past, at least as far as high-scale production sites go.
While you can still inspect the DOM and so on, but it's not as accessible if the source isn't there. So in fact, open source code on GitHub and so on is the best hope for learning and reusing, but that puts JavaScript in the same basket as every other language.
One thing I do in my daily job for the current project is to automate form submissions on various websites. I deal with obfuscated Javascript all the time.
It's really not a problem. It's also quite amusing when I see "protections" in place, like my local Yellow Pages that encrypts phone numbers that get decrypted when shown by a local Javascript routine, done of course to prevent crawling.
Obfuscated code is not readable. However a smarter view-source can take care of that - imagine a view-source that worked like an IDE. It could beautify the source-code (I'm sure you can already find plugins for this) and once you figure out what a variable / method does, you can then automatically refactor the code, renaming that variable/method.
It takes a bit of engineering, but obfuscated Javascript is still high-level enough to be useful.
This makes it no different from most programming languages. De-obfuscated code still takes a ton of work when you've lost all variable names, comments, and formatting.
Except most client-side applications are distributed in binary form. Grokking obfuscated assembly language is an order of magnitude harder than doing the same thing with Javascript.
On the other hand, browsers already allow for reformatting minimized code, I'm fully expecting better renamings/un-minifyting later on (patterns-based).
All installable/downloadable software also shares code. It just happens to be machine code, which adds a little hurdle, just like a good javascript minifier does.
All of those lessons you learned are important, but you didn't learn the most important lesson of them all. At least, when it comes to writing web based software.
The software package that I'm working on has about 100K lines of javascript. I don't obfuscate or play games. White space is removed, but that's to save bandwidth.
All of that code is object oriented, certainly, but it is still tightly dependent and interwoven. You can't take a single piece out and make it work by itself. All the pieces are dependent on each other.
Most importantly, that code is non-functional without the server-side components. Completely. The code is about 75% client-side and 25% server-side.
So for somebody to steal my client-side code, they would need to reverse engineer my server-side code to even start to use it. That effort would take them just as long as to write everything from scratch, if not longer.
Now, can they steal my design ideas? Sure. Copying is the best form of flattery and I enjoy being flattered. But, in the end, nobody can be a better you than you, by definition, so don't worry about copying. Either way, you don't own ideas. Where do you think you get your own ideas from, anyway? From a vacuum? No! From other people! Your ideas are simply improvements on ideas you got from other people.
I would also argue that the code delivered to your browser when loading a page is absolutely useless to anyone or anything but the browser that parses it.
You can nab a copy of jQuery or another third party lib and that won't make a difference, but the non-generic code that actually forms the substance of the app, or the experience on the page, is worthless, because that's inextricably bound to the specific design the developers had in mind - something no one on the outside will know about - and is anything but re-usable in its public form.
Maybe if you spend enough time looking at it, you can start to reproduce the idea, just like if you spent enough time analysing the actual behaviour without even looking at the code. Anyone with enough skill or talent can do something like this by eye, and they won't start with a copy/paste of the original source.
Of course, this might all be beside the point, and I do like how we're seeing more *.js libs and fewer jQuery specific plugins, and in some ways I can't help but think the progress github has made is conducive to that.
I'm not sure I completely agree - just because the code is visible, doesn't mean anyone has the rights to take it. Obviously you can obfuscate things, and add licenses - and in the end, someone can still come along and take your code and do with it as they please while ignoring any licenses you have put around the code - but you can't assume that all visible code is yours for the taking either.
You also state "Your code is your signature, and someone else's never can express your unique type of art. When it does happen (which it does), it is a matter of ethics, not law or government." - if licensed in a specific manner there are legal routes available as well. So whether you are the one writing the code, or you are the one taking the code this should be kept in mind.
Agreed. Case in point: I'm (successfully) selling a JavaScript Game Engine[1]. It's trivial to steal the code, yet I haven't had any problems with "pirates".
Of course it depends whether you're talking about a "cool blinking mouse cursor trail" or a framework that takes a bit of understanding from the people who want to use it. The former will be "pirated" far more often, just because the target demographic isn't as aware of licensing and copyright issues (or doesn't care).
You'd hate for this to come across as controversial, like there was a reasonable other side to the argument. How much of your code you reveal to end-users is simply orthogonal to whether it enjoys copyright protection. Code tends to be copyrighted by default.
This comes up in just about every talk on HTML5 to general app and game developers. People reasonably want to know how their application code and content will be protected. Some points:
* The best form of protection lies outside the code. There are a million Twitter clones out there, so Twitter's value lies not in the source code. It's in the service, branding, and user base.
* You can indeed obfuscate code. It's true though that DRM is not as acceptable as Flash (which is security by obscurity anyway) to content owners. People are working on this, e.g. the various JavaScript crypto standards.
* Fortunately, the people who will outright steal your code are rarely the people you have to worry about. They usually can't innovate (though there are exceptions to be sure) and will always be following behind you.
Obfuscation is perhaps DRM, but a very specific subset of DRM.
Obfuscation: "I will provide a functional copy of my code that is not (human) reader-friendly; I want people to execute my code but present a barrier to extensive understanding or modification of its implementation."
When someone says DRM, I usually think of its least pleasant incarnations- platform lockdown software that must be installed to play a game or (interestingly) take a test, content that may only be accessed after phoning home and verifying that one is in good standing with the rights holder, etc.
To my mind, JS obfuscation protects IP in a way that more closely resembles compilation.
Well, I was referring to obfuscation as a means of protecting the code part, and DRM as protecting the content part. But true, it's a fine line between the two.
there absolutely is proprietary client-side javascript. it is protected by copyright like anything else. you can't just go and steal google's js, and google can't open up my website and steal my js. that's the point of laws. indie nobodys can violate the laws as long as they are small enough to fly under the radar, but you can't become successful with stolen code.
the author wasn't suggesting that her code was 'stolen' or copied verbatim, but reviewed and implemented in a similar fashion. she could have offset this possibility by obfuscating her code, using minimizers etc but the functionality is there for the world to see and from her article i got the impression that she approves of this.
consider:
1. small scrappy startup uses a copied snippet of code, gets successful and rewrites code better which original author gets to enjoy.
2. big company wants to save implementation time and knows they can't copy code. asks author for licensing fee.
And that just shows how pointless copyright law is in this particular example. It's analogous to someone inventing a device that causes food to rain from the sky across a large area, then passing laws which state that no one can eat the food that rains onto their property (without permission of that inventor).
I'm all for trade secrets (which really already exist as consequences of employee contracts and trespassing laws), but prohibiting anyone from using code that you deliberately share with the world seems so backwards to me.
They've already done that, only with patent law. The company in question is Monsanto. In their case, they sue you if their crops spread into your fields and start growing without you paying.
Of course you are correct, copyright protects code. But I didn't think that was her point.
I could be wrong, but what I took from it was that (1) the code is there, so you can learn from it, and (2) that there is a culture of tolerance to people learning and using some amount of other people's code. Both of these are true, and they made the web a better platform to develop for IMO.
And it's a particularly relevant observation at a time when some segments of the industry are pushing for a VM or native code execution facilities in the browser. Having a universal client that works from human-readable code -- and having a `view source` feature for easy reading -- has provided a platform (and atop it, a culture) where every instance serves as an example and it's likely a significant portion of the reason why the web as grown and moved forward the way it has.
The other point behind the piece may be that the value "owning" an idea is limited at best; good execution generates a lot more value, both for you and your customers and the market at large. You could spend a lot of time trying to protect your ideas either by holding your cards close to your chest or through legal strategies, but the last 20 years seem to indicate you're likely to do a lot better by going to market well.
It doesn't make any sense from my perspective as a JS developer to steal code. Each JS code is tailored to fit the website particular HTML and CSS structure. Unless it's a jQuery plug-in or something in these lines.
If the developer doesn't put the comments, it'll be a hell more difficult to find out how to use the code and what the code actually does.
At the end of the journey, it's not these lines of code that make a difference for my client website. It's the solution I bring.
A lot of javascript code doesn't have anything to do with the DOM. Not just jQuery plugins. See underscore.js and backbone.js and handlebars.js for example.
I think the comments here illustrate pretty well that this post doesn't really have a clear point. Sure it has a title, but she doesn't really say anything in it. It's just a collection of random thoughts about... stuff. It seems like a sort of justification for why it was okay that her app got ripped off.
The headline is a misrepresentation of the article. In fact, my takeaway from it is captured in the quote "There is no such thing as disruption from the couch".
As an aside to everyone calling "COPYRIGHT!" on this:
I remember implementing proprietary client-side Javascript function or two in a Opera for Devices web browser in a software product used on many cable set top boxes the world over.
It was to make the holes work you see the TV image through on the guide.
Completely ignores the point of the article, but I came here from RSS with that. I doubt anyone outside the software vendor ever looked at that javascript code.
I'm not sure if you're trying to say that calling an argument childish is itself childish, or something else, but if you're asking what "I" was thinking, it's "it's time for people to stop leaving dumb comments about the color schemes and decorations of blog posts on threads ostensibly dedicated to discussing the contents of blog posts".
"it's time for people to stop leaving dumb comments about the color schemes and decorations of blog posts on threads"
Design is personally my biggest weakness and any feedback on my site designs is welcomed. Yes this feedback given here is poorly worded, but its user feedback none the less.
It's also time for us to stop nerding our way out of common sense. The comment to which you're referring reads, "Aside: Did someone vomit out that design?". That's not "feedback".
For the third time I find myself pointing out to a site newcomer that there are guidelines linked to the bottom of every page, and the comment we're discussing violates the very first of them.
I absolutely understand --- being myself a nerd --- the pleasure commenters here take in contrariness. I can also understand that smug corrective comments might rankle and prompt objections. But I don't care. If you want to form the opinion that I'm smug and self-regarding for calling people on comments like this, that's fine, as long as the bullshit mean comments stop.
(My take) There's a subtle difference between constructive criticism and nonconstructive criticism. Constructive criticism involves advice that builds off the idea that the thing being criticized is fixable, whereas nonconstructive criticism assumes that it's not fixable and contains traces of strong, sometimes insulting, disgust of or not liking the idea without advice.
If the purpose of criticism is to prevent the person from making the same mistakes twice, then it is constructive criticism, even if the advice is 'I didn't enjoy the way you sang that song.' and doesn't suggest how to fix it or suggests the idea is not fixable. This type of criticism implies that criticizer did not like the idea (or in this case, song,) but does not imply that the person is "horrible" nor that anyone who hears the song will dislike it.
"Your singing is horrible.' is nonconstructive criticism; so is "That code is shitty, don't become a programmer"
"Did someone vomit out that design?" is nonconstructive criticism that, although points out a possible problem, doesn't suggest any advice and is too strong to be helpful.
tmcw's comment "Is it just me or is this design kind of awesomely baller?" is constructive (albeit not critical criticism) and also opens a path for discussion of the site's design instead of immediately and quite strongly crying out that the site is fundamentally right or wrong.
