Greetings all! If I have made a program in Zig and produced a compiled binary on Windows, what do I need to do in order to comply with Zig’s license? And as far as Zig’s license goes, is it more than just the portion in the LICENSE file? Searching through the source code shows that many of the math headers mention being ported from MUSL, along with linking that project’s license. Per the MIT license, would I also need to make sure I include MUSL’s license as well?
The below is only my understanding, so take it with a grain of salt. (I am also not a lawyer.)
Zig itself is licensed under MIT and has “Copyright (c) Zig contributors” as its only copyright notice, but it includes and depends on code that is licensed under other (compatible) permissive licenses and which may have their own attribution requirements.
For simplicity, let’s assume that all licenses are similar to MIT and only require that you must include the full license text and any copyright notices when distributing your binary.
In theory, all distinct licenses/notices across all source files that get compiled into your final binary must be reproduced. This means that you will first need to figure out which files went into the compilation (most compilers have some sort of option for generating a list of all file dependencies, but I don’t know how to do this with Zig) and then determine which licenses/notices apply to which files. Don’t forget about C headers! Tooling that scan files for license identifiers and copyright notices in comments can be helpful (e.g. reuse).
Once you have determined the full set of license texts and notices, you need to reproduce them with your binary. Merely providing a URL to a web page with license information is not enough. If your distribute your binary as a regular file download, simply including all license information as a plaintext file alongside the binary is usually enough. But if you’re distributing e.g. a smartphone app, where the user doesn’t have direct access to the file system, you might need to get a bit creative and reproduce the licenses in an “about” screen within the app itself.
In practice, however, most people won’t be anywhere near as meticulous as reproducing each unique license text and each unique “(c) John Doe” from each C header file, and will instead probably only reproduce the main Zig license. For permissively licensed hodgepodges of ancient C header files, you kind of have to consider the spirit of the law and ask yourself “what practical risks am I subjecting myself to by not being pedantically thorough?”. Be pragmatic. Because Zig is open-source, as long as you’re transparent about the fact that your software uses Zig and that Zig is licensed under MIT, all the information is out there. In the extremely unlikely event that someone who wrote one of those random headers emails you and asks why their notices weren’t included, you can just answer “apologies, genuine mistake!” and fix it for your next version.
Looks we need additional section in zon file
It’s good sign - devs are thinking about distribution
You must include a copy of the license with your software, because the (MIT) LICENSE applies to the zig standard library.
You might need to comply with more licenses, depending on the libraries compiled into your program.
If you use the -windows-msvc target (not included in the zig distribution), then Microsoft Visual Studio commercial license applies.
If you use the default windows target (i.e you don’t use the -windows-msvc target) then the following licenses might apply:
lib/libc/mingw/COPYING(ZPL-2.1), for C standard library (if you link the C library)lib/libcxx/LICENSE.TXT(Apache-2.0), for C++ (if you link the C++ library)
I can’t find any such mentions in the standard library. If you believe that musl code is used in your compiled program, please point out which source file it is.
For code pulled into a build from Zig stdlib, this sounds like something the Zig compiler could optionally generate, since it already knows which bits have been included or pruned?
This is why I consider BSD to have a tiny edge over MIT, it uses clearer language about this, e.g.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
MIT says
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Note in, not with, and BSD is “with documentation or other materials provided”, this can with near certainty be fulfilled by an app linking to online documentation which includes the licenses. MIT it’s less clear, that’s not really “in… the Software”.
This is true in my experience, if they even go this far that is. Generally permissive licenses are treated as “do whatever you want”, attribution requirements are frequently ignored.
I know we just talked about this, but since it’s on-topic I wanted to point to my BSD variation, which is meant to align with current practice by making compliance as simple as including the copyright string in the manifest. A binary-only distribution can then simply include the manifest in the “documentation and/or other texts provided with the distribution”.
Doesn’t help here, and as you pointed out in the thread, nonstandard licenses are not without disadvantages. But they only become standard one way, says I.
It’s pretty easy to @embedFile a license if one wants to be 100% about everything, that’s _in_the software by any definition. MIT doesn’t say anything about it being legible without resorting to strings(1).
A few examples of the math headers with mentions of musl: std/math/log.zig, std/math/atan.zig
Looking at the license for libcxx, would the LLVM exception not apply here?
I missed them because I was looking for “Copyright” without ignoring the case.
You must also include musl COPYRIGHT (MIT).
The LLVM exception for the Apache License also applies for libcxx and all the other llvm libraries that are included (e.g. libunwind, libcxxabi, etc.)