Do not assume that Linux is using LGPL GNU libc about openseachest

[xbjfk]

Hello,
Thanks for your response

I think that the best way forward is not to check for every libc, but check only for glibc. This is because:

• It seems that the only prebuilt binary releases for linux are using glibc.
• If the user/distro builds with another libc, it falls on the user to ensure they follow the license of the libc.
• Musl upstream is MIT licensed, and they are specifically against adding a __MUSL__ macro

(Obligatory I am not a lawyer and this is not legal advice)

[vonericsen]

Hi @xbjfk,

That seems like a good reason to only check glibc. I have seen the musl macro discussions in the past, so it was going to be some kind of #if glibc ... #else... approach anyways. I was searching to see if there were any other likely libc's that would be encountered...it looks like it is not likely that anything else will come up...and if it does, that can be a new issue 😄

When the linux macro check was first added, it was because one of our customers used the strings tool to search for lgpl and gpl and were not wanting to find those licenses anywhere in the FreeBSD build, so the solution will likely keep the Linux macro for now and add a second layer below for detecting libs to preserve this functionality so that the MIT license isn't shown when it isn't used in one of the other OSs that openSeaChest supports.

Something like:

#if defined (__linux__)
     #if defined (__glibc__)
           //show lgpl
     #else      
          //show mit for musl
     #endif     
#endif

I'm also considering a way to add a preproccessor definition, such as LIBC_MIT or LIBC_LGPL to force a specific license to allow for setting the correct license in other odd builds where autodetect looks off.

I'm happy to hear other ideas, but want to make sure that the licenses shown in each build of openSeaChest is reasonably accurate. I have a contact in Seagate I can verify legal questions with if I need to since I'm not a legal expert either 😄

[xbjfk]

I personally do not think that assuming that non-glibc linux systems are using musl. I'd say just to print nothing if compiled with linux but not glibc, because the binary releases are using glibc, and I do think that it is the responsibility of the person compiling the code to ensure they fall under the libc's license

[vonericsen]

Hi @xbjfk,

I did some testing of the commit I pushed yesterday in a few machines that I have and an Alpine linux docker container and it works.
A preprocessor flag can be added to the makefile for musl (-DUSING_MUSL_LIBC), but others are not defined at this time. Other libc support can be added in the future as needed.

Let me know if this solves this, or if you think I need to tweak it some more first.

[vonericsen]

Excellent 😄

I merged it into our develop branch this morning.
The last thing I added yesterday allows for making this even easier:
make release USING_MUSL=1

[vonericsen]

Hi @xbjfk,
Thanks for creating this issue. I've been meaning to update and investigate compiling with musl for a while now.

Using the glibc macro seems reasonable. I will do some additional research and see what looks like the best solution since the tool should display the MIT license for musl when it is used instead of glibc.

[xbjfk]

I think is the best solution, Thank you!