3 ms·

Show HN: libpgn – Tiny C library for parsing PGN files (Chess Game Records)

3 points by youkwhd 2y ago

lifthrasiir 2y ago
Wait, are you sure that you want to license your library in terms of GNU GPL, not LGPL? That would make it virtually impossible to use in any non-GPL-licensed softwares, as any linkage will count as a derivative in the majority view [1] and thus it has to be available according to GPL. Technically speaking this is trivial to do if the software itself uses more permissive licenses, but it still gives some annoyance even when it doesn't harm. Reconsider your license choice if this is not your intent. It will be also good to make the whole library into a single header-only library, as it is reasonably small (<1k LoC). And avoid using identifiers starting with two underscores as they are reserved by ISO C [2]. [1] But this view hasn't been fully tested in court yet, see: https://opensource.stackexchange.com/questions/2157/is-it-allowed-to-dynamically-link-a-gpl-licensed-library-for-commercial-use https://opensource.stackexchange.com/questions/2157/is-it-al... [2] https://en.cppreference.com/w/c/language/identifier#Reserved_identifiers https://en.cppreference.com/w/c/language/identifier#Reserved...
- youkwhd 2y ago
  I've been thinking about this, I did license one of my library [1] as LGPLv3 before. I really don't know what to do for now [2]. I'm not a fan of making libraries in a single header, I know it makes it easy to just copy, paste, and use. I designed libpgn to have small seperate 'modules' each serving functions (pgn_metadata_*, pgn_moves_*, etc) to parse a small portion of the file, that way the root pgn.h just calls and builds the block with all the small parsers. [1] libtmdb: https://github.com/youkwhd/libtmdb https://github.com/youkwhd/libtmdb [2] https://www.gnu.org/licenses/why-not-lgpl.html https://www.gnu.org/licenses/why-not-lgpl.html
  - lifthrasiir 2y ago
    I generally think that GNU GPL is best used for applications, mainly because users of applications will generally find it much harder to replace your applications with alternatives, which is usually not the case for libraries. This is not the hard-and-fast rule though; there are some classes of applications which can be replaced easily, like compilers and command-line utilities with easy migration paths. Pretty much every library is designed for developers and inherently replacable if its license doesn't fit well, so its license has to be also developer-friendly if you want it to be used by many developers. (In fact, I even don't use permissive licenses for libraries nowadays, the public domain dedication works for me.) Of course whether you actually want that or not is up to you. > I designed libpgn to have small seperate 'modules' each serving functions (pgn_metadata_*, pgn_moves_*, etc) to parse a small portion of the file, that way the root pgn.h just calls and builds the block with all the small parsers. C doesn't really have any module system and any such notion has to be entirely logical. It should be easy to keep the current structure but amalgamate all files into a single physical file.

3 points by youkwhd 2y ago

Wait, are you sure that you want to license your library in terms of GNU GPL, not LGPL? That would make it virtually impossible to use in any non-GPL-licensed softwares, as any linkage will count as a derivative in the majority view [1] and thus it has to be available according to GPL. Technically speaking this is trivial to do if the software itself uses more permissive licenses, but it still gives some annoyance even when it doesn't harm. Reconsider your license choice if this is not your intent. It will be also good to make the whole library into a single header-only library, as it is reasonably small (<1k LoC). And avoid using identifiers starting with two underscores as they are reserved by ISO C [2]. [1] But this view hasn't been fully tested in court yet, see: https://opensource.stackexchange.com/questions/2157/is-it-allowed-to-dynamically-link-a-gpl-licensed-library-for-commercial-use https://opensource.stackexchange.com/questions/2157/is-it-al... [2] https://en.cppreference.com/w/c/language/identifier#Reserved_identifiers https://en.cppreference.com/w/c/language/identifier#Reserved...

youkwhd 2y ago
I've been thinking about this, I did license one of my library [1] as LGPLv3 before. I really don't know what to do for now [2]. I'm not a fan of making libraries in a single header, I know it makes it easy to just copy, paste, and use. I designed libpgn to have small seperate 'modules' each serving functions (pgn_metadata_*, pgn_moves_*, etc) to parse a small portion of the file, that way the root pgn.h just calls and builds the block with all the small parsers. [1] libtmdb: https://github.com/youkwhd/libtmdb https://github.com/youkwhd/libtmdb [2] https://www.gnu.org/licenses/why-not-lgpl.html https://www.gnu.org/licenses/why-not-lgpl.html
- lifthrasiir 2y ago
  I generally think that GNU GPL is best used for applications, mainly because users of applications will generally find it much harder to replace your applications with alternatives, which is usually not the case for libraries. This is not the hard-and-fast rule though; there are some classes of applications which can be replaced easily, like compilers and command-line utilities with easy migration paths. Pretty much every library is designed for developers and inherently replacable if its license doesn't fit well, so its license has to be also developer-friendly if you want it to be used by many developers. (In fact, I even don't use permissive licenses for libraries nowadays, the public domain dedication works for me.) Of course whether you actually want that or not is up to you. > I designed libpgn to have small seperate 'modules' each serving functions (pgn_metadata_*, pgn_moves_*, etc) to parse a small portion of the file, that way the root pgn.h just calls and builds the block with all the small parsers. C doesn't really have any module system and any such notion has to be entirely logical. It should be easy to keep the current structure but amalgamate all files into a single physical file.