Live data from Hacker News

Crockford on JSON license (2011)

gist.github.com

21–30 of 65 posts

Re: Crockford on JSON license (2011)

#21
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…

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.

Re: Crockford on JSON license (2011)

#22

I was talking with a small startup founder about a project I had licensed under AGPL. He asked, "How do you know if someone uses your project against your licence though?" with a smile. His point wasn't anything new, but I still didn't have a great answer. I just said that it would require the company being honest and purchase a commercial license, and that I have personally worked at companies that evaluate their li…

For what it’s worth - we had to audit/list all licenses for OSS components & dependencies on at least 3 separate occasions during fundraising diligence processes. I would guess nobody read it too closely but GPL code would definitely have stuck out. I imagine bigger companies have this process pretty well structured.

Re: Crockford on JSON license (2011)

#23

Amazing writing. Question, is there any US judicial precedent for what is evil and what is not?

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.

Re: Crockford on JSON license (2011)

#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...

Re: Crockford on JSON license (2011)

#25
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…

Can confirm DOE labs work on military adjacent things all the time

Yes my question was, itself, tongue-in-cheek. I've been told that a customer insisted the packages in question be removed because although they did nothing military-related, they did happen to have a customer that is well-known for being a contractor on military projects and they didn't want to be getting in trouble just because their civilian service was used by a civilian company that did military-adjacent work.

And even if LBL isn't developing nuclear weapons they seem a mite closer to it than that.

Re: Crockford on JSON license (2011)

#26
post #17

Amazing writing. Question, is there any US judicial precedent for what is evil and what is not?

Probably. Most of the US has a legal system based on common law. I think it would really depend on the context though, because I don't know how you can use a linting program "for evil."

Have it lint PHP?

Re: Crockford on JSON license (2011)

#28
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…

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

Re: Crockford on JSON license (2011)

#29
It's little wonder that javascript is such a fraught, inferior language and ecosystem given it was so heavily influenced by Crockford and Eich. In a way I'm glad that the future of compute in the browser (such as WASM, et. al), will be dictated by corporate overlords so we don't have to deal with such mercurial personalities.

Re: Crockford on JSON license (2011)

#30
Cryptographers often tell software engineers that they shouldn't roll their own crypto. I think lawyers would tell software engineers that they shouldn't roll their own license. If you really intend or want other people to be able to use the software you wrote, for the love of god please pick a sane, well-known license so that people can use your software with full knowledge of the legal implications.
Post reply on HN