Hi all, i’ve recently released version 1.0.0 of Swift JPEG, a cross-platform pure-swift JPEG codec. The framework has no external dependencies, including on Foundation, so the core library should work on all Swift platforms. In addition, it has built-in file-system support on MacOS and Linux.
The library supports baseline, extended, and progressive-mode images, images with restart markers and DNL segments, and allows users to define their own color-space extensions to the JPEG format. Future work should mainly center on improving performance. It is also a long-term goal to update my related Swift PNG library to match the Swift JPEG API, as i have learned a lot about library design since releasing Swift PNG two years ago. It is available under the Mozilla Public License 2.0.
The Swift JPEG framework emphasizes flexibility and progressive disclosure so it provides interfaces at different levels of image format abstraction. I’ve written several tutorials and example programs going over how to use the framework to accomplish several common image-processing tasks:
Swift JPEG also has something that’s been missing from many Swift projects so far (because the tool that generates the standard library docs is private), which is an apple-style API documentation website. It is organized by topic, differentiates standard-library symbols from module symbols and type parameters, and indicates type relationships.
Right now, i am mainly looking for feedback on the kind of features that are most useful to Swift image codec users, and what areas people feel like UIImage is lacking in that regard. Help with testing and reviewing the generated API docs is also highly welcome. If you could please give it a star on github i would really appreciate that too!
But I have to ask... doesn’t GPLv3 require anybody using the package to also make their source available? I think they are also required to be GPLv3 (it’s kind of a closed little ecosystem, which is why the Linux kernel stayed at GPLv2), which could be a problem for many Swift apps.
you’re right, i just defaulted to GPL because it’s common. would it help if i relicensed it as Apache or MIT? I’m not really an expert on the nuances between the two
For Swift projects I tend to just default to Apache-2.0, as it's what Swift itself is licensed under (including the runtime, IIUC). Of course the choice is up to you.
I'm not a lawyer, I just know that GPLv3 is especially controversial because of that "parasitic" clause. IIRC, one of the main reasons Apple got invested in LLVM was because gcc moved to GPLv3, meaning they were stuck on the last GPLv2 release and didn't have a modern compiler (or at least that's the rumour). Same with the recent bash -> zsh switch.
I would support a switch to a more permissive license. As far as I understand, even dynamic linking with a GPL library requires disclosing the source code of the linked software. LGPL would work better if copyleft license is the preference, but seems like Apache 2.0 is the most popular non-copyleft permissive license in the Swift ecosystem.
This would still be a copyleft license, which could scare away some commercial users (I'm not one of them though), but at least it allows static linking with proprietary software as far as I understand.
the Swift source compatibility suite accepts MPL 2.0, so i figure it’s a good middle ground. I’ve taken the opportunity to relicense the library as MPL 2.0 while i am still the sole contributor.
Firstly I don't want anything I say to take away from the fantastic work you've done here. Thank you so much for your contribution.
The license is an issue for me. MPL is ambiguous as it has not been tested, for me at least even though I would not be using your library commercially I typically have library projects and wouldn't want to propagate the uncertainty to any of my consumers.
Apache 2.0 is my strong preference... but this is your work and your decision.
To me at least, the MPL2 seems like it has some of the most straightforward requirements it could have. All a downstream user has to do is provide a link to the original library repository which doubles as attribution. Tons of apps give credit to their dependencies in their “About” screen or something similar. I have a hard time seeing how this is an onerous requirement, unless your users do not want to know where the code they are using came from.
I’m curious as to how you generated the documentation. We use Jazzy for internal API documentation, but I’m always curious to see what others are doing as well.
i wrote a tool called Entrapta which generates the API reference website, and a Github action to automatically run and deploy it to github pages whenever a commit gets pushed to the library repository. i designed it to build really thoroughly-linked doc pages like you find in the standard library docs.
Entrapta is still very experimental (it doesn’t support some Swift features like overriding functions or weak/unowned ownership) and i haven’t really documented it that well, so i wouldn’t really call it ready for public consumption but i think the quality of the generated pages is ahead of Jazzy and other tools in the specific aspects that are important to my library architecture/coding style.
The syntax isn’t compatible with the xcode markdown doccoments style, but it should be at least somewhat familiar to people currently using that. if you have any questions i don’t mind answering them :)
