On Fri, 10 Oct 2025, Pali Rohár wrote:
On Friday 10 October 2025 19:12:44 Martin Storsjö wrote:
On Fri, 10 Oct 2025, Pali Rohár wrote:
On Friday 10 October 2025 14:32:21 LIU Hao wrote:
在 2025-10-10 03:59, Pali Rohár 写道:
I think if you would like to copy code from MUSL, you have to update
COPYING.MinGW-w64-runtime.txt to incorporate their license, same in the
source file. Otherwise if a user conveys a program that has mingw-w64 CRT
linked statically, they will not be including 'the above copyright notice
and this permission notice' which may be classified a violation.
mingw-w64 runtime already contains more code from MUSL, that is why I
chose to take the __tm_to_secs from MUSL too.
Calling "git grep 'Rich Felker'" can locate this MUSL code.
Maybe updating the COPYING.MinGW-w64-runtime.txt file could be done for
all MUSL code?
The existing musl code was added in
0d403d5dd13ce22c07418058f3b640708992890c, and it is currently only used in
libucrtapp.a, so the license doesn't really come into play in most cases.
But that being said, we clearly should make sure the license is honored for
the cases where it is used.
If we don't want the musl license to spread to more bits, we probably should
separate out the current musl code clearer, so that it doesn't accidentally
get intermixed in other scenarios than libucrtapp.a.
// Martin
It is also for wcstok since bafccb49a0a6b4676f748bb415aabe27212d12d7
which is used for msvcrt builds.
Right, I see.
What do others think - LH and Jacek? Should we add the Musl license to
COPYING.MinGW-w64-runtime.txt and embrace it? Or should we try to
remove/limit the use of Musl here?
According to our existing COPYING.MinGW-w64-runtime.txt we already have
some pieces of code included that do require attribution when
redistributed in binary form, so this is just another license in the list.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
