GNU Linux-libre 5.7-gnu

[Alexandre Oliva]

On Jun  1, 2020, Alexandre Oliva <lxoliva at fsfla.org> wrote:

> I unfortunately could not find correspoding sources for the new binary
> blobs introduced in such an old-fashioned way, and they're big enough
> and not regular enough that I could just assume them to be data rather
> than code, so I've removed them.  If you come across source code for
> those bits, or can explain to me how transparent and trivial they are
> once they're disassembled with existing Free tools, I'll be very glad to
> restore them.

Err, I could *not* just assume them to be data.


I'm told it's code indeed, and that source code is available under a
Free license.  Thanks!

https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commit/211151a39a5d5e204fff3d18a4b704aa478b7c07


Now, if I were to retain this, the object code for the i915 driver in
Linux would contain portions that were originally under the X11/MIT
License (ok so far), but because of conditions of the GNU GPL, the whole
of Linux, or even of the i915 driver, can only be distributed under the
GNU GPL, so these portions are distributed under the GNU GPL as well.

However, distributing the driver or the kernel Linux as object code,
along with corresponding sources, as required for certain forms of
distribution of GNU GPLed code, would be missing the source code for
these pieces of i915 GPU code.

Other pieces of Freely-licensed object code present in Linux have
corresponding source code also present in the Linux sources.  These are
enough for the source tarball to satisfy the corresponding source code
requirements of the GNU GPL on the whole.

IIRC, a significant reason for moving sourceless firmware previously
included in Linux as arrays of numbers to standalone binaries in the
firmware/ subtree, and then to a separate distribution, was precisely
because of legal concerns about meeting the requirements of the GNU GPL
in a combined distribution of the object code.

In the absence of the corresponding sources in the tarball, it seems to
me that the conditions for distribution of the combined object code
under the GPL are not be met.


I would thus feel a lot more comfortable having the asm sources for
these GPU compute kernels added to Linux sources before enabling them in
GNU Linux-libre, or having them distributed separately (ideally along
with sources) and loaded by i915 through the firmware-loading interface.

Though our cleaning-up infrastructure would make it pretty hard for us
to add the sources on our own, I guess I could arrange for the sources
to be downloaded from the above gitlab instance and included in the
Linux-libre sources during cleaning-up.  Downloading sources during
cleaning-up would be a first, though; I'd much rather be able to deblob
offline, and with reproducible results.


So, I'd appreciate if someone well-connected in the Linux community
would bring up this issue with them, perhaps with those who contributed
the object code files to Linux, so that the corresponding sources are
readily and safely available.  The object code encoded as numbers in the
Linux repo is in drivers/gpu/drm/i915/gt/{hsw,ivb}_clear_kernel.c; the
patch that brought them in is
https://patchwork.freedesktop.org/patch/msgid/20200306000957.2836150-2-chris@chris-wilson.co.uk

Alternately, if someone knowledgeable in licensing would let me know in
case the absence of source code for these code fragments wouldn't be a
problem for anyone's source and binary releases or redistributions of
GNU Linux-libre, if I were to bring the object code fragments back in.

Either way, it would be pretty important to confirm that the sources in
the gitlab link above are indeed corresponding sources for the object
code included in Linux.  Anyone with the gpu asm tools handy who could
vow for their correspondence?


Thanks in advance,

-- 
Alexandre Oliva, freedom fighter    he/him    https://FSFLA.org/blogs/lxo/
Free Software Evangelist              Stallman was right, but he's left :(
GNU Toolchain Engineer           Live long and free, and prosper ethically