I tried to get approval to use an (entirely IBM-developed) open source library at IBM. The process took months and hadn't finished when I finally left. If I remember correctly, it was going to take approval from the team lead, 3 lawyers, and a VP (and possibly someone else, I can't remember). And that's after spending about a week or two running code scans to check for "suspicious" keywords like 'evil'^ and then individually checking each of the ~10,000 issues.
I know why IBM has to these issue so seriously but remember this when you wonder why big companies can't execute as quickly as startups. And remember, the library I wanted to use only had contributions from IBM developers and was under the favoured Eclipse licence.
^ As an aside, putting 'evil' in your licence is pretty dumb. There is no definition of evil which can be argued over in any court. What you consider 'good', someone else almost certainly considers 'evil'
> As an aside, putting 'evil' in your licence is pretty dumb. There is no definition of evil which can be argued over in any court. What you consider 'good', someone else almost certainly considers 'evil'
People keep arguing that the license is bad because "evil" is ambiguous. But there's a legal concept called "Contra proferentem", which stipulates that ambiguity in a contract (or license) benefits the party which did not draft it. Crockford's clause has no force because he drafted it.
> Crockford's clause has no force because he drafted it.
Am I the only one who finds it concerning that a clause which legally cannot be enforced is placed into a license anyways? I'm not sure how this helps the complaints against the JSLint license.
^ As an aside, putting 'evil' in your licence is pretty dumb. There is no definition of evil which can be argued over in any court. What you consider 'good', someone else almost certainly considers 'evil'
Actually, one of the real dangers is if a court does recognise an act as evil, which they do all the time, just search court records for "evil". (For example, if a rapist uses your code, that would probably count as evil to a court)
The license refers to evil actions, not evil people. If a rapist uses your code to rape people, your example might be more true, but I don't see how JSLint helps with that.
Oh, no, its not. That's not even close. Round up lots of people, under whatever excuse, put them in camps, make them work hard as slave labor. Use software to automate and manage the process, keeping track of productivity, and torturing/executing anyone who drops below the minimum threshold. Or using them for medical experiments. Use software to open/close their cell doors, herd them to meals and work, track their every move. I think you lack imagination.
Software is a tool. Like other tools, it can make any process more efficient, for better or worse. Damn, I've been in management too long.
Yes, no-one's suggesting that the software developer is guilty of what ever the code does. But if you grab JSLint and bundle it with your software, that person X uses for evil, then person X is guilty of whatever they did, and you might be guilty of copyright infringement.
"The Software shall be used for Good, not Evil." is a separate clause in license, permission for distribution is granted above it. So only person who use software for evil is violator of license.
At first, I was surprised by this. If IBM wants to use 100% IBM developed and owned open source code, then the licence of the original project is irrelevant.
However, the use of a copyleft licence for the project leaves open the possibility that it includes code from a copyleft project authored by someone else.
Was the point of the approval process to ensure that contributions had not come from anywhere other than IBM?
I used to work for a company that made hardware/software that IBM would resell under their own branding. I had to fill out one of the IBM documents describing all 3rd party software we used, licenses of those packages, how they are used, etc...
The take-home is don't do that. Don't modify a standard open source contract on a whim as it will inevitably cause serious hassle later. Okay if you have some major ethical/legal objection, then just beware it will cause some major hassle.
JSON is an exception. It came along when the programming world was desperate to be liberated from XML bondage...a fine solution surfaced at the right place and right time. And also at a time when people cared less about open source license specifics. For any average project, you're adding more barriers to adoption than you probably realise.
I disagree that JSON has "liberated" most of the programming world from XML. In many, many, many places where XML has been used in the past, it is still used because JSON is a very poor substitute in those cases.
I don't think that mmahemoff was claiming that JSON liberated the programming world from XML, but that it was widely adopted by people sought to be free from the more verbose benefits of XML. Those who wanted or needed these characteristics did not switch.
Thus, I don't think you two really disagree (though with so much XML bashing I think you make a valuable point).
Pretty much all APIs from web/tech/startups now are JSON-based, I think. I'm sure XML is still used in enterprise and legacy situations, but it would have been a lot more widespread if JSON didn't come along.
Of course JSON caught on with startups who are mostly targeting web users, whose programmers are mostly web developers who write a lot of Javascript.
XML is used for far more than just APIs though. However, I suspect that you personally weren't thinking "just APIs" when you wrote that the programming world was desperate to be liberated from XML bondage.
Be honest. You think JSON is far superior to XML in almost every way and you would never consider XML for any task. Also tell us what kind of programming you do most of the day and who you do it for.
Me - I write operations software for a pharmaceutical services company to run a warehouse, call center, marketing and miscellaneous. I float between writing web, desktop and back-end services apps. Most of our clients and partners (big pharmaceutical companies) are working with XML - even for new services and data exchanges. We barely ever see JSON coming from those companies.
I'd argue that there are more of these enterprises out there than there are web startups. If you had said "web programming world", I might not have disagreed.
Yes, I'm mostly focused on the web programming world (which includes the enterprise, though not my current project) and I can't account for how much XML is used behind firewalls, versus JSON, YAML, protocol buffers, or anything else. When I previously worked in finance and logistics industries, I constantly found the theoretical benefits of XML never translated into reality due to a range of problems (e.g. even XML schema left ambiguities if it hadn't been spec'd right, horrendous Java library dependency issues, complexity of XPath). Maybe it's a better situation now.
There's plenty of people using JSON for data exchange outside of web and JavaScript developers. It's surely convenient that JSON is valid JS, and some might say they have the same "father", but it's real benefit is as a lightweight data format. Example - I'm using it right now to interface from a Java/Android client to a Rails server. There are 3000-odd SO questions on "Android JSON" (http://stackoverflow.com/questions/tagged/json+android) and I'm guessing most of those Android devs aren't interfacing with JS.
JSON describes objects in compact notation, XML describes the world in terms two computers talking to each other can understand and it is very readable for humans who need to debug it and it can be validated with a DTD.
IBM seek repeated permission like this for lots of reasons, but mainly to avoid possible problems in the future. I've been through this process a few times getting permission to include 3rd party packages in our products. It's long and drawn out but I can see why they do it.
It all boils down to the fact that it's not just as simple as IBM trusting the license terms as shown.
For example, someone can take some code protected by GPLv2, naughtily strip off that license and apply a completely different (friendlier) license such as MIT or Eclipse. If IBM trusted this code (and license) as supplied then it (IBM) could get sued because it is (unknowingly) using GPLv2 licensed code and not honoring the conditions. It matters not one bit that they thought it was MIT or Eclipse licensed. It matters not one bit that someone else did the naughty thing of changing the license. IBM can still get sued, and theoretically be forced to publish source code that they may not want to, and people love suing IBM.
Another example question is: Did all contributors to the code have permission from their employers (if appropriate) to participate in the development of the package and relinquish their (the employer's) rights to any claim for the code?
The license is only as strong as its weakest link.
I know I've had a package turned down because we weren't able to get in contact with every contributer in order to convince the legal team that this wasn't a risk.
In other words, IBM want to be absolutely sure that including this code isn't ever going to come back and bite them in the ass if they do use this package.
The genius of this license is that not only does it stop semi-evil people (because truly evil people don't care about the author's wishes), it stops stupid people. Which, in a long about way, is a type of unintended evil.
I know why IBM has to these issue so seriously but remember this when you wonder why big companies can't execute as quickly as startups. And remember, the library I wanted to use only had contributions from IBM developers and was under the favoured Eclipse licence.
^ As an aside, putting 'evil' in your licence is pretty dumb. There is no definition of evil which can be argued over in any court. What you consider 'good', someone else almost certainly considers 'evil'