Question: would you consider a more permissive license for libaaruformat?

[kwinsch]

First of all — thank you for the hard work on this library. It's a well-designed container and we've been happily building on top of it some proof of concepts. Until now, we could solve all archive problems and have encountered 0 issues in the writing part of the format.

We'd like to implement lightweight, read-only libraries derived from libaaruformat that could be integrated into third-party software (emulators, archive tools, etc.). However, the current LGPL license is not compatible with all target projects — some have license requirements that prevent linking against LGPL code.

Would you be open to re-licensing libaaruformat under a more permissive license (MIT, BSD, or similar)?

Completely understand if the answer is no — no hard feelings either way.

[claunia]

We would but we have a concern.

As you know the intention of this format is to offer an open, documented, and clear specification and source available, format for data preservation.

We're worried the availability of a more permissive license would make forks proliferate and incompatibilities appear.

We need to find a way, to get some, compromise, of centralization, to ensure we keep that promise and intention.

Obviously we cannot guarantee a smooth future of perfect collaboration but we shall, at least, intend to.

That's our only concern, besides that we do not have any problem to relicense the code under a license like MIT or similar.

[kwinsch]

Thank you for the thoughtful response and we completely share the concern about format integrity. Preservation only works if everyone reads (and writes) the same format.

I'd like to propose an approach that I believe addresses the fragmentation concern while enabling broader adoption:

Dual-library, dual-license

The idea: produce two libraries from the same source tree.

• libaaruformatread (MIT) — read-only, no ability to create or modify images
• libaaruformat (LGPL) — full read/write, as today

The code already separates cleanly along this boundary read.c, verify.c, identify.c, blocks/*, index/* are purely reader-side. The write path (write.c, create.c, most of close.c) is self-contained. A few shared files (close.c, metadata.c) would need minor splitting, but the API already distinguishes aaruf_read_*/aaruf_get_* from aaruf_write_*/aaruf_set_*.

Why this addresses the fragmentation concern

A read-only library cannot produce files, so it cannot produce incompatible files. Format integrity is preserved because only the LGPL writer can create images, keeping the write path more under your control and license preference.

At the same time, the permissive reader enables integration into any software regardless of the licenses, which is what drives adoption of the format.

Keeping the format consistent long-term

Even with a permissive reader, there are practical ways to keep the ecosystem aligned:

• Spec stays licensed as is.
• Adding a conformance test suite that ensures that any implementation tests against the same test cases.

On independent implementations

With a well-documented, public specification, independent implementations will appear over time regardless of the library's license, because some may need to optimize the behavior, not the format itself, to their needs. Example may be that for some applications the reader caching may not be ideal. That's a natural consequence of the format's success. A permissive reference reader gives those implementers a well-tested starting point rather than a blank page, which means less room for subtle divergence in edge cases and a more natural path for bug fixes to flow back upstream.

Practical next steps (if you agree)

1. I'd refactor the three files that need minor modifications (close.c, metadata.c, compression/*.c encode/decode separation)
2. Add a second CMake target for the reader-only build
3. Add MIT license headers to reader-only sources, LGPL stays on writer sources. The readers files would be dual licensed MIT/LGPL.
4. Submit as a PR for your review

Happy to discuss further or adjust the proposal to your liking.

[claunia]

also adding some words encouraging collaboration on the readme may be ideal. besides that proceed with your next steps, I agree