Hi Maxime,
Maxime Devos <maximede...@telenet.be> writes:
On 9/02/2025 2:06, Ian Eure wrote:
Hi Morgan,
Morgan Arnold via "Development of GNU Guix and the GNU System
distribution." <guix-devel@gnu.org> writes:
Hello,
If the issue is simply that the patch has not been rebased
against a
new enough version of Guix to be merged, I am happy to do that
rebasing. Additionally, please correct me if I have made any
incorrect
assertions above.
No. See the stuff about #:substitutable?. The reason I didn't
answer
back then, is that I don't want to keep being a broken record.
Could you help me understand the case where this becomes a
problem? Is it:
- If you have one machine with an operating-system which includes
a non-#:substitutable? out-of-tree kernel module in its initrd,
and
- A second machine with an identical initrd configuration, and
- The first machine is configured to serve substitutes, and
- The second machine uses the first as a substitute server
Then the non-#:substitutable? module would be distributed,
violating its license?
I’d also find it helpful to understand the line for specific acts
and entities in play, on a matrix of: allowing violations,
encouraging violations, or committing violations; and by
individual Guix users, or by the Guix project itself. For
example, I think the Guix project encouraging or committing a
violation is unacceptable.
I think this would help a great deal to make the bounds of the
problem clear, which is needed to solve them.
If 'make-linux-libre' in the presence of ZFS leads to
#:subsitutable?
problems, that doesn't mean it's fine to ignore the law for
#52231. It
means you need to:
Could you please help me understand how `make-linux-libre' is in
scope? I don’t believe any in-tree kernel modules have the
problematic license terms, so I think the issue is purely
out-of-tree stuff, whether that’s ZFS, nVidia drivers, "endpoint
protection" security systems, etc. Perhaps you meant
`make-initrd'?
More specifically, ZFS proponents (at least as a group, and when
limited to those visible in Guix) tend to be rather incoherent
in
their positions, in the sense that simultaneously do:
(snip)
I appreciate your perspective, however, I’m more interested in
understanding the problems so they can be solved. Any help in
that area would be greatly appreciated.
It does seem that #55231 ended up in a place where there was
concensus that it was acceptable, but didn’t get merged for
some
reason or other. I definitely could be wrong, but I suspect
the
issue is that when non-#:substitutable? packages are used in
places
other than package inputs, the downstream derivations don’t
carry
that information. I believe when used as a package input,
non-#:substitutable? packages do, in fact, poison all
downstream
derivations. Happy to be corrected if I’m wrong here.
Not quite - to my understanding, the downstream derivations
_also_
don't carry that information when it's in package inputs (at
least,
last time I checked there didn't seem to be any mechanism to set
#:substitutable? to #false when any of the inputs are
unsubstitutable
(whether non-bag(?) derivation inputs, implicit inputs,
native-inputs,
...)).
Ah, hmm. So these kind of violations are implictly prevented by
Guix not shipping things in combinations which would violate the
license terms?
For packages, in typical situations the #:substitutable? #false
of any
'native-inputs' of a package shouldn't impact the
substitutability of
the package. For 'inputs', it rather depends
(e.g. static/dynamic, the
particulars of the license, is it because of license reasons or
something else). Since it somewhat depends on the situation, if
you
implement a thing like this, I would recommend making it a
_default_
for #:substitutable?(*), that can be overridden by some method.
That’s a good suggestion, thank you.
I think it’s reasonable to merge this after it’s rebased on
current
master, and would be willing to do that unless Maxime or Ludo’
raise
an objection.
First you say you suspect the issue is that
#:substitutable?-related
behaviour isn't right yet, and immediately in the next paragraph
you
say it's reasonable to merge it. Given that the patches haven't
been
adjusted to solve this, this is rather incongruent.
While I agree that the fundamental #:substitutable? mechanism of
Guix could use improvement, I don’t believe these patches need to
wait for that work, becasue:
- This is a generic mechanism useful for any out-of-tree module
regardless of license[1].
- They won’t cause the Guix project to commit a license violation.
- They don’t encourage individuals to commit license violations.
- While they could /allow/ individuals to commit violations, many
things in Guix already do, because it’s infeasible to forbid.
To the last point:
- Right now, Guix allows a user to make a system image containing
compiled ZFS modules and distribute it.
- Guix ships DVD rippers and programs which can copy files, which
a user can commit copyright violations with.
- Guix ships numerous programs for file sharing, whose /primary/
purpose is committing copyright violations. The nicotine+
package is one example[1].
I am struggling to square objections to a patch whose intent and
primary use would be within the bounds of
non-binary-redistribution licenses, but which might enable an
individual to (most likely inadvertently) commit a license
violation with the significantly riskier things which are already
permitted. If I’m misunderstanding the situation here, I’d
appreciate further insight.
Some examples of other modules that could be used with this
facility are:
lttng, a GPL’d out-of-tree kernel tracing system
ddcci, a GPL’d out-of-tree module for controlling monitor settings
OpenRazer, a GPL’d out-of-tree module to suppot Razer HID hardware
I’m certain there are other cases where it’d be useful.
I already raised the objection several times in the past
(including
_before_ #55231), and none of the patch revisions attempted to
deal
with the objection. Issues don't simply magically resolve
themselves. I believe you can infer whether I would object to
the
current state of #55231 or not.
I haven’t been involved in this stuff in the past and don’t use
ZFS on Guix[2]. The issue I read, which this patch is for, it
appeared that your last objection was that the documentation gave
ZFS as an example, which is the Guix project obliquely encouraging
users to commit inadvertent violations. This problem was
addressed, therefore I believed your objections were resolved. I
apologize for midunderstanding the situation.
Thanks,
-- Ian
[1]: I distinguish between things with both legitimate and
illegitimate purposes (such as BitTorrent clients), and those
whose main purpose is clearly copyright violation.
[2]: I do use ZFS on Debian, where this issue is moot.
