No claim was made that it is not open source. The contention was over if it was a free license or not:

> not free software

which it is. As F3nd0 said, it's both.

The Unlicense isn't "just" public domain though, it also has a fallback clause that explicitly lists things you are allowed to do ("copy, modify, publish, use, compile, sell, or distribute"). So I think the intent is, even if PD isn't recognized and line 1 is invalid, you're still granting a license to the same effect.

SQLite on the other hand just says

    The author disclaims copyright to this source code.  In place of a legal
    notice, here is a blessing:

      May you do good and not evil.
      May you find forgiveness for yourself and forgive others.
      May you share freely, never taking more than you give.

From an American perspective, there’s no mechanical difference between that and the MIT license when it comes to security.

They care more about the package being maintained, bug-free, and their preferred vulnerability database showing no active exploits.

At least in my experience, anyway. Other companies may have stricter requirements.

Who cares? Seriously. Whether a commercial entity who wants to be able to benefit from your work accepts the license you choose for work you do is as much a concern as whether or not the prime minister of Liechtenstein accepts the color you paint the outside of your house in the USA. That is: none.

I think you are mistaken; neither is a subset of the other. At the very least, there are licences which are recognised as open source by the OSI, but not as free by the FSF, and vice versa [1]. I think it’s more appropriate to say they are two fundamentally separate definitions with a massive overlap.

[1] https://spdx.org/licenses/

> Edit: I was not aware of the FSF's definition. I was using a definition of free software being software that you can use without having to pay for it.

That’s called freeware. Also, open-source software can be paid (with the caveat that if someone buys it, you must allow them to redistribute it for free).

> Not all free software is open sourc

Depends on which "free software" definition you're referring to.

The FSF definition of "free software" requires it to be open source.

You have recited a successful incantation to summon the Stallman acolytes.

To add an additional suggestion, gratis can also be used to refer to free as in free beer. Comes from a latin root and is common in spanish speaking countries to refer only to free of charge, and not as in freedom.

It was enshittified because there was nothing defending it.

I didn’t say it’s the author’s problem. It’s a problem with the code.

A standard clause you can find in every open source license? It doesn't say anything about how serious the project takes security

...and what open source software license in the world makes the author liable for damages?

Refer to the original comment. Seems like you are incapable of connecting the comment chain.

This is a serialization library. The entire point is to communicate with data that's coming from out of process. It should be safe by default especially if it's adding a quick check to avoid overflow and undefined behavior.

Massively agree. Remember this thinking being everywhere with databases back in the day, not every text field is hooked up to a Wordpress comment section.

> Not everything needs to be absolutely 100% secure so long as you control the system.

Isn't that a bit like saying "you don't have to worry about home security as long as you are the only person who has the ability to enter your house"?

Untrusted doesn’t always mean adversarial IMO, even a bitrot can invalidate your entire input and possibly also trigger undefined behaviour if you aren’t prepared to handle that.

You probably didn't control the other end, as otherwise you would've used something more sane than JSON?

Obviously I just did review it, and my conclusion was to not use that code.

In the spirit of the article you linked, I’d rather write my own version.

If it has limitations they should be documented though right? especially if they’re security concerns.

If you review libraries, why do you need to quick scan the issues? You would have already identified all the issues right? Right?

> Most Rust or Java programmers would make the same mistake.

Detecting these mistakes in Rust is not too difficult. In debug builds, integer overflow triggers a panic[1]. Additionally, clippy (the official linter of Rust), has a rule[2] to detect this mistake.

[1] https://doc.rust-lang.org/book/ch03-02-data-types.html#integ...

[2] https://rust-lang.github.io/rust-clippy/master/index.html#ar...

Yes but those languages have defined overflow.

Less than INT_MAX, more accurately. But since the library contains a check when decreasing the counter, it might as well have a check when increasing the counter (and line/column numbers).

I've seen much bigger, though technically that wasn't valid json, but rather structured logging with JSON on each line. On the other hand, I've seen exported JSON files that could grow to such sizes without doing anything weird, just nothing exceeding a couple hundred megabytes because I didn't use the software for long enough.

Restricting the input to a reasonable size is an easy workaround for sure, but this limitation isn't indicated everywhere, so anyone deciding to consume this random project into their important code wouldn't know to defend against such situation.

In a web server scenario, 2GiB of { (which would trigger two overflows) in a compressed request would require a couple hundred kilobytes to two megabytes, depending on how old your server software is.

Or fork and make a few modifications to handle it? I have to admit I haven't looked at the code to see if this particular code would allow for that.

Not really. I deal with this everyday. If the library has a limit on the input size, it should mention this.

The primary point was that the code doesn't ensure correct processing (or returning an appropriate error) for all JSON. Even if behavior is defined by the C implementation, the overflow can lead to parser mismatch vulnerabilites, if nothing else. There are likely other "defined" failure modes the overflow can enable here.

UB was a secondary observation, but it also can lead to logic errors in that vein, without involving memory safety.

I'm not sure I agree that UB usually leads to memory safety violations, but in any case, the fact that signed integer overflow is UB isn't what makes the code incorrect and unsafe in the first place.

That is what I like Common Lisp libraries. They are mostly about the algorithms, leaving data structures up to the user. So you make sure you got those rights before calling the function.

Extracting the data into objects. Libraries like Serde and Pydantic do this for you. Hell the original eval() JSON loading method did that too.

Why don’t you look at the source code, it’s only 150 lines?

The nesting is limited by using an int as the depth counter. The C standard guarantees that MAX_INT is at least 32767, so that’s a limit on portable nesting depth. Nowadays int is typically 32 or 64 bits, so a much higher limit in typical C implementations.

If I see correctly, the library doesn’t check for overflow, however. This might conceivably be an exploitable vulnerability (and such an overflow would constitute UB).