Hello everyone,
Licenses have been always quite confusing to me, so I’m hoping you might be answer this:
The notice file mentions some used library using GPL. What does this imply for an application I build with crystal? Let’s assume my application would not use any 3rd party shards, and just use whatever Crystal offers out of the box.
Would I have to comply with GPL if my application is statically linked?
Would it have to comply with GPL if my application is just built via ‘crystal build someSourceFile.cr’?
Thanks in advance!
Looks like Readline was removed from std-lib in 0.32 (Release 0.32.0 · crystal-lang/crystal · GitHub) and NOTICE file just wasn’t updated.
1 Like
Thanks.
So, would that mean, that as long as I stick to dynamic linking, I’m “safe” in avoiding (L)GPL restrictions?
I really would prefer to ship just one executable and not have to think about anything else, but I guess I can live with it.
BTW: Is it the same on FreeBSD? Or does it use FreeBSD’s less restrictive libraries?
It always depends on what libraries you use. The Crystal distribution packages usually don’t ship binary libraries. The only exception is a patched version of libgc (MIT license). (Although we can probably drop that in the future as well).
So it’s up to you which libraries you have available on your system. Most of them will probably be system libraries (such as libc or libiconv) and you probably don’t have much choice over them. Others are more flexible and allow different implementations (for example libssl).
Which libraries your Crystal program actually links is also very flexible. Even if you only use stdlib, depending on which parts of stdlib you use, there might be different lib dependencies.
So it’s hard to give a general statement on licenses of linked libraries, because it depends a lot on your code and system.
And I this is a general problem with linking libraries. It’s not specific to Crystal.
I think we can provide some help with improving documentation as suggested in Licensing for stdlib dependencies · Issue #11488 · crystal-lang/crystal · GitHub
But when you link libraries into your program and distribute them with it, it’s up to you to make sure the terms of the respecitive licenses are met. Which first means to figure out which are even affected.
With dynamically linked libraries, this is quite easy as ldd will tell you which ones are used. And you can decide if and which you want to distribute them with your program or expect users to install them themselves.
For static libraries, it’s more complicated. There’s no way to tell which static libraries have been linked into a binary file after the fact. You can look at the symbols and relate them to the libraries that provide them, but that’s not very practical or reliable (especially when different libraries expose the same symbols).
Which libraries are actually linked is best observed at the linker stage.
For that you can just look at the linker arguments (visible with --verbose flag, although that comes with a lot of noise; I recommend --cross-compile instead - but then you still have to run the printed command). That should give you a good overview of the linked libraries. But it might not tell the full story, depending on linker sorcery behind the scenes.
Alternatively, you can ask the linker to print information about which libraries it links together. For that you need to pass -Xlinker -Map=a.map to the linker (via --link-flags "-Xlinker -Map=link.map" for crystal build). This generates a link.map file wich should contain all linked libraries.
4 Likes