1 |
On Sun, 2021-07-25 at 01:57 +0900, Alice wrote: |
2 |
> On 7/25/21 1:56 AM, Michał Górny wrote: |
3 |
> > Dnia July 24, 2021 4:52:28 PM UTC, Alice <alicef@g.o> napisał(a): |
4 |
> > > On 7/24/21 3:30 PM, Ulrich Mueller wrote: |
5 |
> > > > > > > > > On Sat, 24 Jul 2021, alicef wrote: |
6 |
> > > > |
7 |
> > > > > On July 24, 2021 3:21:56 AM GMT+09:00, Ulrich Mueller |
8 |
> > > <ulm@g.o> wrote: |
9 |
> > > > > > > > > > > On Fri, 23 Jul 2021, Alice wrote: |
10 |
> > > > > > |
11 |
> > > > > > > > GNU FSDG-compliance require not only removing non-free code but |
12 |
> > > also |
13 |
> > > > > > > > to disable loading of known non-free firmware. |
14 |
> > > > > > |
15 |
> > > > > > So they actually remove code that by itself is free software. I had |
16 |
> > > > > > suspected that. (By what logic does removing an option add to the |
17 |
> > > > > > user's freedom and choice, though? :) |
18 |
> > > > > > |
19 |
> > > > > > > I also point you to some other information from the mailing list |
20 |
> > > > > > > |
21 |
> > > https://www.fsfla.org/pipermail/linux-libre/2020-August/003400.html |
22 |
> > > > > > > https://www.fsfla.org/pipermail/linux-libre/2021-May/003419.html |
23 |
> > > > > > |
24 |
> > > > > > Thank you. Looks like there's no issue with the LICENSE="GPL-2" |
25 |
> > > label |
26 |
> > > > > > for recent kernels then. |
27 |
> > > > |
28 |
> > > > > that's not what they are saying. |
29 |
> > > > |
30 |
> > > > The first posting references a discussion on Wikipedia (which I think |
31 |
> > > is |
32 |
> > > > a third party with a more neutral point of view than Linux-libre): |
33 |
> > > > |
34 |
> > > https://en.wikipedia.org/wiki/Talk:Linux_kernel/Archive_7#RfC_on_the_Linux_kernel_licensing_rules |
35 |
> > > > |
36 |
> > > > I tend to agree with their conclusion, which resulted in the |
37 |
> > > following |
38 |
> > > > wording: |
39 |
> > > > |
40 |
> > > > "The official kernel, that is the Linus git branch at the kernel.org |
41 |
> > > > repository, does not contain any kind of proprietary code; however |
42 |
> > > Linux |
43 |
> > > > can search the filesystems to locate proprietary firmware, drivers, |
44 |
> > > and |
45 |
> > > > other executable modules (collectively known as "binary blobs"), then |
46 |
> > > it |
47 |
> > > > can load and link them into the kernel space." |
48 |
> > > > https://en.wikipedia.org/wiki/Linux_kernel#Firmware_binary_blobs |
49 |
> > > > |
50 |
> > > > > but I repeat again please open a thread to their own mailing list |
51 |
> > > not |
52 |
> > > > > here. |
53 |
> > > > |
54 |
> > > > Sorry, but I don't care about the Linux-libre patches, only about the |
55 |
> > > > mainline kernel. So if anything, I would start a thread on the LKML |
56 |
> > > > about concrete files that violate the GPL. Then again, I don't have |
57 |
> > > > evidence of any such files (see above). |
58 |
> > > > |
59 |
> > > |
60 |
> > > You are complain against linux-libre not mainline kernel so you should |
61 |
> > > ask their opinion on this topic. linux-libre@×××××.org |
62 |
> > > |
63 |
> > > My modest opinion on the topic is: |
64 |
> > > As far that is free software and there are users that use deblob, I |
65 |
> > > don't see any reason on why we should not support this and give them |
66 |
> > > the |
67 |
> > > choice. Gentoo is about choice. |
68 |
> > |
69 |
> > Then why does none of the supported kernels offer that choice? |
70 |
> > |
71 |
> |
72 |
> why they shouldn't ? |
73 |
> |
74 |
|
75 |
That's my question. Apparently deblob is only supported for rt-sources. |
76 |
Last I heard, only gentoo-sources are officially supported. |
77 |
|
78 |
-- |
79 |
Best regards, |
80 |
Michał Górny |