On Mon, 3 Jul 2017 at 13:06:41 -0700
Rick Moen <rick@???> wrote:

> Quoting Alessandro Selli (alessandroselli@???):
>
> > On Sun, 2 Jul 2017 at 17:51:48 -0700
> > Rick Moen <rick@???> wrote:
> >
> > > Quoting Alessandro Selli (alessandroselli@???):
> > >
> > >> 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: dhatarattha@???
Chiavi PGP/GPG keys: B7FD89FD, 4A904FD9