[bug#61950] lint: Add 'copyleft' checker.

* guix/lint.scm (check-copyleft, input->package, report-copyleft-violation,
linking-exception?, copyleft?): New procedures.
(%local-checkers): Add 'copyleft' checker.
* tests/lint.scm ("copyleft: incompatible copyleft input"): New tests.
* doc/guix.texi (Invoking guix lint): Mention it.
---
This new linter checks for copyleft license violations, where a copylefted
package is linked by a package with an incompatible license.
It found 2818 incompatible packages.
For example, GNU readline (GPL) is being linked by 71 permissively
licensed packages.

 doc/guix.texi  |   4 ++
 guix/lint.scm  | 109 +++++++++++++++++++++++++++++++++++++++++++++++++
 tests/lint.scm |  10 +++++
 3 files changed, 123 insertions(+)
  

Hello!

Antero Mejr <antero@mailbox.org> skribis:

> * guix/lint.scm (check-copyleft, input->package, report-copyleft-violation,
> linking-exception?, copyleft?): New procedures.
> (%local-checkers): Add 'copyleft' checker.
> * tests/lint.scm ("copyleft: incompatible copyleft input"): New tests.
> * doc/guix.texi (Invoking guix lint): Mention it.
> ---
> This new linter checks for copyleft license violations, where a copylefted
> package is linked by a package with an incompatible license.
> It found 2818 incompatible packages.
> For example, GNU readline (GPL) is being linked by 71 permissively
> licensed packages.

I’m skeptical for a couple of reasons:

  1. It’s entirely fine for, say, a BSD-3 package to link against
     Readline (GPLv3+).  The combination is effectively GPLv3+, but
     that’s perfectly valid legally speaking.

  2. It’s tempting to view devise a “licensing calculus” of sorts and
     automate assessments of licensing compatibility.  However, I think
     it’s overestimating both law and our own licensing annotations: how
     law applies in a specific case isn’t entirely clear until one goes
     to court, and our ‘license’ fields fail to represent all the
     relevant nuances anyway (subcomponents having different licenses,
     dual/multiple licensing, etc.).

But really, #1 is the main point here.

WDYT?

Ludo’.
  

Ludovic Courtès <ludo@gnu.org> writes:

>   1. It’s entirely fine for, say, a BSD-3 package to link against
>      Readline (GPLv3+).  The combination is effectively GPLv3+, but
>      that’s perfectly valid legally speaking.

It's fine for FOSS packages, but if you have proprietary-licensed Guix
package where the code can't be open-sourced, bringing in a GPL
dependency is an issue.

This copyleft linter goes along with the other patch where guix lint
exits 1. So you can do something like this in a CI pipeline:

'guix lint -c copyleft my-proprietary-package'

to block developers from adding copyleft dependencies to a non-free package.

>   2. It’s tempting to view devise a “licensing calculus” of sorts and
>      automate assessments of licensing compatibility.  However, I think
>      it’s overestimating both law and our own licensing annotations: how
>      law applies in a specific case isn’t entirely clear until one goes
>      to court, and our ‘license’ fields fail to represent all the
>      relevant nuances anyway (subcomponents having different licenses,
>      dual/multiple licensing, etc.).

True, this linter check is basic and would not constitute legal advice.

It's more of a broad "software license auditing" sort of thing,
to allow engineers to do quick compliance checks. In my experience
it's useful for development in regulated applications of software.

Thanks for the feedback, lmk what you think.
  

On Mon, Mar 06, 2023 at 04:53:40PM +0100, Ludovic Courtès wrote:
>   2. It’s tempting to view devise a “licensing calculus” of sorts and
>      automate assessments of licensing compatibility.  However, I think
>      it’s overestimating both law and our own licensing annotations: how
>      law applies in a specific case isn’t entirely clear until one goes
>      to court, and our ‘license’ fields fail to represent all the
>      relevant nuances anyway (subcomponents having different licenses,
>      dual/multiple licensing, etc.).

I emphasize this point. We should not overestimate our understanding of
free / open-source software licensing. The territory is uncharted and
largely untested in the courts.
  

Antero Mejr <antero@mailbox.org> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>>   1. It’s entirely fine for, say, a BSD-3 package to link against
>>      Readline (GPLv3+).  The combination is effectively GPLv3+, but
>>      that’s perfectly valid legally speaking.
>
> It's fine for FOSS packages, but if you have proprietary-licensed Guix
> package where the code can't be open-sourced, bringing in a GPL
> dependency is an issue.

Maybe, but it’s not an issue for the Guix project.  :-)

> This copyleft linter goes along with the other patch where guix lint
> exits 1. So you can do something like this in a CI pipeline:
>
> 'guix lint -c copyleft my-proprietary-package'
>
> to block developers from adding copyleft dependencies to a non-free package.

I recommend having this out-of-tree.  If it helps, changing ‘guix lint’
to it can discover new “checkers”, using (guix discovery), might be okay.

>>   2. It’s tempting to view devise a “licensing calculus” of sorts and
>>      automate assessments of licensing compatibility.  However, I think
>>      it’s overestimating both law and our own licensing annotations: how
>>      law applies in a specific case isn’t entirely clear until one goes
>>      to court, and our ‘license’ fields fail to represent all the
>>      relevant nuances anyway (subcomponents having different licenses,
>>      dual/multiple licensing, etc.).
>
> True, this linter check is basic and would not constitute legal advice.
>
> It's more of a broad "software license auditing" sort of thing,
> to allow engineers to do quick compliance checks. In my experience
> it's useful for development in regulated applications of software.
>
> Thanks for the feedback, lmk what you think.

Thanks for explaining.  I think I understand the need now but (1) I
think this need is outside the scope of Guix, and (2) I remain wary of
conclusions drawn from automated ‘license’ field inspection.

I hope that makes sense!

Ludo’.
  

Hello Antero,

Antero Mejr <antero@mailbox.org> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>>   1. It’s entirely fine for, say, a BSD-3 package to link against
>>      Readline (GPLv3+).  The combination is effectively GPLv3+, but
>>      that’s perfectly valid legally speaking.
>
> It's fine for FOSS packages, but if you have proprietary-licensed Guix
> package where the code can't be open-sourced, bringing in a GPL
> dependency is an issue.
>
> This copyleft linter goes along with the other patch where guix lint
> exits 1. So you can do something like this in a CI pipeline:
>
> 'guix lint -c copyleft my-proprietary-package'
>
> to block developers from adding copyleft dependencies to a non-free package.

I think that goes against the spirit of the GNU project: it's a tool
that helps finding licensing concerns for proprietary software, with the
end goal of weeding out GPL components.  We may be better off if no such
tool exists and more companies embrace the idea that is GPL instead of
helping them spot GPL dependencies so they can rewrite them under some
non-copyleft license.

>>   2. It’s tempting to view devise a “licensing calculus” of sorts and
>>      automate assessments of licensing compatibility.  However, I think
>>      it’s overestimating both law and our own licensing annotations: how
>>      law applies in a specific case isn’t entirely clear until one goes
>>      to court, and our ‘license’ fields fail to represent all the
>>      relevant nuances anyway (subcomponents having different licenses,
>>      dual/multiple licensing, etc.).
>
> True, this linter check is basic and would not constitute legal advice.
>
> It's more of a broad "software license auditing" sort of thing,
> to allow engineers to do quick compliance checks. In my experience
> it's useful for development in regulated applications of software.
>
> Thanks for the feedback, lmk what you think.

I think I'd rather not see this tool in Guix, but I think it could live
happily as a channel or as an extension.
  

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> I think that goes against the spirit of the GNU project: it's a tool
> that helps finding licensing concerns for proprietary software, with the
> end goal of weeding out GPL components.

I see this completely differently: this is a harm-reduction tool for
those who would violate GPL, possibly unknowingly. By adding compliance
auditing abilities to Guix, developers can avoid that.

> I think I'd rather not see this tool in Guix, but I think it could live
> happily as a channel or as an extension.

Yes I am making this patch (and a couple other compliance features) into
Guix extensions out-of-tree. I would like to upstream the extensions as
a package when they are ready, since the extensions would be FOSS. So I
think this issue can be closed.

> We may be better off if no such
> tool exists and more companies embrace the idea that is GPL instead of
> helping them spot GPL dependencies so they can rewrite them under some
> non-copyleft license.

Making companies rewrite GPL software is a good thing. It forces them to
pay programmers, then those programmers can contribute to Guix in the
evenings :-). Not many people can work on open source full-time,
unfortunately. That said I understand the concerns with merging this
patch, thank you both for taking the time to look at it.
  

Hey,

Antero Mejr <antero@mailbox.org> writes:

[...]

> Making companies rewrite GPL software is a good thing. It forces them to
> pay programmers, then those programmers can contribute to Guix in the
> evenings :-). Not many people can work on open source full-time,
> unfortunately. That said I understand the concerns with merging this
> patch, thank you both for taking the time to look at it.

OK; I'm thus closing this issue, thanks for sharing this endeavor with
us!