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 , 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.
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.
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.
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.
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.
* 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.
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.
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.
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.
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.
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 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.