Live data from Hacker News

Crockford on JSON license (2011)

gist.github.com

51–60 of 65 posts

Re: Crockford on JSON license (2011)

#51
post #35
post #28

Earlier quoted context omitted.

Hmm, doesn't the LGPL allow you to remove any additional restrictions?

Interesting - do you mean because of the "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed" clause? I wonder.

No, the GPLv3 includes this language:

> All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.

And the LGPLv3 incorporates the GPLv3 by reference, then grants additional permissions.

Re: Crockford on JSON license (2011)

#52
post #47

I think it's pretty funny that the lawyer suspects some of their clients are probably evil and his response is just to try to fix the clause so that evil is allowed. Rather than trying to find a job that doesn't involve evil.

The correct reading is that the lawyer recognizes, correctly, that “evil” has no clear legal meaning and therefore wants to clarify what the author actually meant before deciding whether to use his software.

Re: Crockford on JSON license (2011)

#53
post #28

Earlier quoted context omitted.

Hmm, doesn't the LGPL allow you to remove any additional restrictions?

It says it does, but in at least one lawsuit courts have outright said that this language does not apply to copyright holders. Which is explicitly opposed to the FSF's own intent drafting the license, which was to prohibit copyright owners from calling their license "GPL plus (insert nonfree clause here)"

It is like the license needs a bootstrapping license

Re: Crockford on JSON license (2011)

#54

Earlier quoted context omitted.

No, which is why this license is probably much more restrictive than its author intended. Many serious organizations simply won’t use something for which the meaning of the license terms is unclear to this extent. That of course doesn’t mean they “plan on using it for evil” or anything of the sort.

I’d think that it wouldn’t make for a very restrictive license. Since there’s no agreement on what “evil” means whatsoever, it doesn’t seem that different from putting “You can not use this code to hooplebop shanglefronks” Edit: I guess there’s that TV show “Evil”. It would be funny if IBM had that production company as a client.

IBM did assist the nazis with the holocaust so

Re: Crockford on JSON license (2011)

#55
post #21

Earlier quoted context omitted.

I mean... no? There is nothing compelling these organisations to use that particular piece of software. When contacted the author could just shrug and say "not my problem" and the organisation would just have to find some other software to use. The author has no obligation to make things easier for people that don't know if they are doing evil or not, or if they are military or not.

There's nothing compelling the author, no, except for in the situation outlined above they're really doing nothing to prevent military use, but they are hampering adoption among companies scrupulous or careful enough to not run afoul of a poorly defined legal term. Seems counter-productive to the apparent motives.

Can you be certain about that? Has anyone tried to test a no military use clause in court?

Re: Crockford on JSON license (2011)

#56
post #6

While this is funny, it does highlight that you should probably have an actual legal opinion if you decide to write your own license. A less tongue-in-cheek example that I've run into is https://dst.lbl.gov/ACSSoftware/colt/license.html . "any usage related to military applications is expressly forbidden", which is still poorly defined enough that it makes lots of corporate lawyers nervous and you end up having to re…

This sort of confusing 'anti-pentagon' license goes back to way back when, and was supposedly one of the reasons RMS established "Freedom Zero" to run the software "for any purpose". But yeah, high energy physics just might have military applications...

Re: Crockford on JSON license (2011)

#57
post #24

The license was from 2002[0], and the IBM update was from 2011[1]. What's the point of this gist which only vaguely mentions Douglas Crockford (through a lawyer quote and a the gist name)? [0]: https://codedocs.org/what-is/douglas-crockford [1]: https://web.archive.org/web/20170722132351/https://dev.hasen...

Best I can tell, neither the video linked from TFA nor an earlier version submitted previously to HN remain online. See: https://news.ycombinator.com/item?id=36809645>

Whether or not there's a more definitive source I haven't investigated.

Re: Crockford on JSON license (2011)

#59
post #7

It is sort of interesting how there are practical logistical issues with making bespoke licenses. I would not want my work to end up being used by weapons manufacturers[0]. I honestly would like to put this into licenses. But there would be endless kvetching at such a license being used, of course. But so much OSS tooling is relying on how we have ended up with a lot of mutual compatible licenses, and having any sort…

I like the “open source will be enforced” nature of GPLv3 for that reason. Yes,it does mean that a developer some some huge company will have to write their own version of your project instead of just using yours and thus your code would be less widely used than if it hadn’t, but on the other hand if I choose to work on something for free and available to everyone you making the thing you made also free and available to everyone is completely reasonable, benefitting open source projects and community use while also making it disproportionately harder for people trying to hide the software in a different evil program of some sort. Obviously it’s not perfect but I’ve always viewed the relative exclusivity of the GPL to be one of its pros.
Post reply on HN