Json

[tera]

@taylorswift

i don’t remember if the JSON spec requires a particular string encoding

JSON RFC has this to say:

8.1. Character Encoding JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8 [RFC3629].

Previous specifications of JSON have not required the use of UTF-8 when transmitting JSON text. However, the vast majority of JSON- based software implementations have chosen to use the UTF-8 encoding, to the extent that it is the only encoding that achieves interoperability.

Implementations MUST NOT add a byte order mark (U+FEFF) to the
beginning of a networked-transmitted JSON text. In the interests of
interoperability, implementations that parse JSON texts MAY ignore
the presence of a byte order mark rather than treating it as an
error.

[Karl]

Just one thing: I find the MPL slightly off-putting.

MPL is a file-level copyleft license, and while it can be combined with other licenses as part of a larger work, my understanding is that any modifications to MPL-licensed files must also be made available to the public.

So if you fix a bug or add some custom behaviour to better integrate with your application or private libraries, you may be compelled to make those public. Extensions in other source files are apparently not considered "modifications", but the extent of the changes you can make without touching the original MPL-ed file(s) may be limited.

See Q9 and Q10 of the MPL FAQ.

It's not necessarily a deal-breaker if the library was incredibly unique and worth the hassle, but if I had a choice between an MIT/Apache-2.0 library and MPL-2.0 library of approximately equal quality, I'd pick the former. The MPL library would need to do something truly exceptional to make me consider it.

As an example, if async-http-client was under MPL2, and I used my WebURL fork in an AppStore app, I would have to make that fork public, even if I didn't want to, because I can't make changes of that level without modifying AHC's original MPL2 files. Personally, I like the freedom to make any changes I think my applications could benefit from, without the obligation to share that with the world, and I consider it important that others have that same level of freedom when using any code that I've written. My philosophy is that sharing should be encouraged, but it should also be a choice.

I remember that we had this discussion before about SwiftJPEG, which was originally licensed as GPLv3. MPL is better (looser) than GPLv3, but it is still copyleft. It's up to you whether you want to actually compel modifications to be open-sourced as a part of the license, but it is worth pointing out.

[taylorswift]

i don’t understand the details of the various licenses very well, so i just went with MPL because it sounds like a “middle-of-the-road” license between the GPL and Apache extremes. i understand swift itself is Apache, but Apple also has tons of lawyers to help them make that decision, and i don’t.

that said, i agree forcing everyone to make their forks public is unreasonable. i don’t know how anyone can enforce that anyway, if a fork is private. i don’t expect people to publish every modification, if they were maintaining a fork instead of submitting it as a PR (way less effort) it was probably because it was very specific to their application and not something that would make sense in isolation.

[taylorswift]

update: swift-json is now a normal SPM module, and you can test it out here!

[Saklad5 (Jeremy Saklad)]

@taylorswift

i don’t understand the details of the various licenses very well, so i just went with MPL because it sounds like a “middle-of-the-road” license between the GPL and Apache extremes. i understand swift itself is Apache, but Apple also has tons of lawyers to help them make that decision, and i don’t.

You assume, incorrectly, that they are extremes. Apple chose Apache for the same reason many do: it provides a useful array of legal rights. You could always read the license yourself, or use GitHub’s excellent help for choosing a license. Note that the latter advises choosing the same license the ecosystem normally uses: in Swift’s case, Apache.

Apache basically allows complete freedom of use, with the exception that you can’t mischaracterize the original work as your own or mischaracterize your own work as the original.