Re: FSDG-compatibility of APSL-2.0

[Philip McGrath <philip@philipmcgrath.com>]

[-- Attachment #1: Type: text/plain, Size: 4391 bytes --]

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 <maximedevos@telenet.be> 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


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]