On Mon, 3 Jul 2017 at 13:06:41 -0700 Rick Moen <r...@linuxmafia.com> wrote:
> Quoting Alessandro Selli (alessandrose...@linux.com): > > > On Sun, 2 Jul 2017 at 17:51:48 -0700 > > Rick Moen <r...@linuxmafia.com> wrote: > > > > > Quoting Alessandro Selli (alessandrose...@linux.com): > > > > > >> It cannot work if what you need to do is feeding the HD controller some > > >> proprietary firmware that cannot legally be embedded in the GPL driver. > > > > > > ITYM that the resulting derivative work cannot be lawfully > > > redistributed. But compiling the driver does not redistribute it. > > > > Devuan in a public, general-purpose distribution, not an OS tailored > > to the specific environment of a single individual's HW/layout. > > That's interesting, but you've just entirely changed the subject. Nope. > Your upthread hypothetical Not hypothetical at all, pretty real-life indeed. > didn't mention Devuan at all. Of course it did. Next time, before replying, please read at least the thread's object line. Hint: ASCII does not refere to the American Standard Code of Information Interchange. OK, the discourse was extended beyond Devuan's specific, it spread to the generic distribution and it's uses of initramfs, still it's very true that the topic was not "the specific environment of a single individual's HW/layout". > You made a very > specific legal claim about compiling proprietary firmware into a GPL > driver, Do you mean this case does not exist, that it's not of any concern to distro packagers? > and I pointed out that said hypothetical It's *not* an hypothesis, it's a real-life scenario. Again, the fact that you, in your tiny world, never came across this issue proves nothing else than you've been living in a closet. > didn't involve a right > reserved under copyright in the first place, Let me remind you GPL is a licence, and that it prohibits linking proprietary code with free code in the same binary file. > suggesting you were perhaps > thinking of redistribution, which you hadn't been talking about. The object was: Author: Gary Olzeke Date: 2017-06-22 23:02 +200 To: dng Subject: [DNG] some ASCII issues Writes about issues upgrading ASCII from the Jessie CD install; Author: Hendrik Boom Date: 2017-06-23 02:44 +200 To: dng Subject: Re: [DNG] some ASCII issues Wonders if that could be "a side effect of debian/systemd's fusion of /usr with /?" Author: Jaromil Date: 2017-06-23 16:01 +200 To: Hendrik Boom CC: dng Subject: Re: [DNG] some ASCII issues Wrote: "?!?!?! did they ?!?!?! how is this madness done, via mount -o bind ????" Author: Antony Stone Date: 2017-06-23 16:41 +200 To: dng Subject: Re: [DNG] some ASCII issues Replied with: "https://wiki.debian.org/UsrMerge [...] https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ if you want to start feeling annoyed as well as surprised." Author: John Morris Date: 2017-06-24 01:55 +200 To: dng Subject: Re: [DNG] some ASCII issues Commented: "Dunno, that one actually makes a lot of sense. Applying the logic of Chesterton's Fence here seems sound." Author: Steve Litt Date: 2017-06-24 03:08 +200 To: dng Subject: Re: [DNG] some ASCII issues "I'd love to boot without initramfs, which is a black box that's hard to look around in." Author: Didier Kryn Date: 2017-06-24 11:08 +200 To: Steve Litt, dng Subject: Re: [DNG] some ASCII issues "Anyway I think there's a simple method to live without the initramfs. Everything which is done from initramfs could be done the same way from a disk partition, which might make it easier to debug:" Author: Rick Moen Date: 2017-06-28 07:57 +200 To: dng Subject: Re: [DNG] some ASCII issues "Step 1. Compile a kernel that includes inline all key drivers including those needed to find the root filesystem." Author: Alessandro Selli Date: 2017-07-03 00:19 +200 To: dng Subject: Re: [DNG] some ASCII issues "It cannot work if what you need to do is feeding the HD controller some proprietary firmware that cannot legally be embedded in the GPL driver." The topic did evolve, but it never left the Devuan specific and the generic GNU/Linux distribution's filesystem layout and use of initramfs before you posted a "solution" that only works in very specific cases and ignores any legal concerns any distribution cannot overlook it it wants to be able to legally... distribute it's OS. > FYI, I've never hear of proprietary firmware BLOBs being embedded into > drivers. In every case I'm aware of, those are processed separately. Of course you did not, because embedding proprietary firmware inside GPL drivers violates the Linux kernel licence, GPLv2. Proprietary Linux drivers do, like Nvidia and several WiFi adapters, where the firmware is extracted to be usable by a free implementation (this is the case of the firmware for Broadcomm's USB WiFi adapters, see http://linuxwireless.sipsolutions.net/en/users/Drivers/b43/ ). >>> (I'm not necessarily endorsing your view about proprietary firmware. >> >> It's not *my* view, it's the law, it's the real world out there. > > I actually was making a particular point of not discussing your view > about proprietary firmware, It's not *my* view, it's the law, it's the real world out there. > pointing out that it's not necessary to do > so, to see that the act of compiling drivers does not involve exercise > of copyright holders' reserved rights, You are the first and only person who turned the discourse from Devuan's (or the generic GNU/Linux distribution's) filesystem layout and use of initramfs from the very special case of what you did on your PC ignoring any legal downturn was Devuan to adopt such a "solution" concerning the need of an initramfs. > hence cannot even in theory be copyright violation. It is, were any distribution adopt such a method (distribute kernels with everything, drivers and firmware compield in) they would violate the GPL. The fact that you do so on your personal PC proves nothing, it cannot be taken as a solution to the issue at hand. > If you wish to argue with someone about your views concerning > proprietary firmware, that's a separate discussion and I wish you luck > finding some other volunteer r to argue with you. I wish I could argue with people with at least a little of competence and capability to understand. >>> I'm just pointing out that your conclusion doesn't follow from the >>> premise.) >> >> They are not *my* conclusions, they are real-world issues. > > You seem to have not followed my point. Ah well. That's because you have no point. >> If you disagree, kindly point out what other method is available that >> allows a kernel to lawfully feed a controlelr a firmware before >> mounting the root FS. > > That is not the discussion we were having. It is, as I've duly documented above. -- Alessandro Selli http://alessandro.route-add.net VOIP SIP: dhatarat...@ekiga.net Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
