Hi, On Friday, June 17, 2022 10:37:07 AM EDT zimoun wrote: > > On the other hand, I refuse to judge the intent behind a software. It > appears to me a slippery slope. The only way is to set a clear frame > and then scrutinize using this very frame. Debian defines a frame, GNU > defines another frame, etc. and each project qualifies via this frame. > > Guix is part of GNU and the GNU project lists the acceptable and > unacceptable licenses. > > Again, if the Guix project would like to apply a more stringent license > policy than the GNU one, then the question is according to which frame. > Yes: I think the most ideal license policy has yet to be invented, and I'm glad the Debian Free Software Guidelines and the Free System Distribution Guidelines both exist and provide some valuable critiques of each other. (Neither is a subset of the other!) I do think the guidelines should be open to (good faith) discussion and debate. But forking the license standards caries big costs: maybe even some literal ones, but certainly in terms of effort—from idealists who think about these principles, from distributions who have a smaller set of collaborators among whom to share the work of evaluating license issues, and from freedom-loving upstream developers who want to publish software everyone can accept without patching. At least for me, whatever marginal improvement could be made (with respect to my idiosyncratic opinion) just doesn't seem worth it. > > On Fri, 17 Jun 2022 at 11:39, Maxime Devos wrote: > > ... currently Guix isn't using the APSL2.0 anywhere (according to git > > grep -F aspl), so it seems quite practical and effortless to just > > remove apsl2 from (guix licenses). > > It is maybe used by Chromium. > > I have nothing against removing APSL2.0 if it is not currently used. > However, I think the Guix project should continue to accept all software > using the licenses on GNU list [1]. > > About patch#55998, the question is about dependencies and linking > because APSL is incompatible with the GPL. If all is fine, then let > include ’cctools’ in Guix. > I'll say just a bit about the practical motivation for this patch. Assuming we agree that it's beneficial for at least some free software to be able to run on non-free operating systems, that means some free software developers have to build software for those systems. For Windows, MinGW lets us do so without having to leave the free world. For Apple platforms, the status quo is that someone has to buy or get access to a piece of hardware sold the nonfree os. Maybe, with a lot of effort, you can cross-compile by downloading a nonfree binary bundle. Patch 55998 doesn't solve that problem, but it at least takes a step toward being *less* reliant on a nonfree toolchain. The particular utility that I've used so far [1] is significant enough that part of its functionality (unfortunately not the part I needed) had been implemented in Racket [2], and I believe other compilers or package managers have done similarly. (I plan to write more about how this experiment worked out once various loose ends have been tied up.) This is possible because we *do* have the freedom to use, study, modify, and distribute major components of the toolchain and operating system kernel. Requiring something other than those freedoms would perversely increase the reliance on nonfree systems for building free software. I think the dependency and linking issues, to whatever extent they existed, are resolved by v2 of the patch. The only GPL file was a header from GDB which seemed to be left over from before Apple switched to an LLVM/Clang toolchain: it wasn't actually used by anything, so just deleting the file worked out fine. (Not being a lawyer, I can only speculate about whether it might have been fair use anyway under Google v. Oracle.) There are a few files or parts of them under miscellaneous permissive Expat- or BSD-like licenses. The only linking is with things like libc that have sufficiently permissions. -Philip [1]: https://github.com/LiberalArtist/native-libgit2-pkgs/tree/build-scripts [2]: https://github.com/racket/racket/blob/master/racket/src/mac/ install_name_tool.rkt [3]: https://issues.guix.gnu.org/55998#23