Deblob instructions, was: Linux-libre architecture and how to modify it for other uses cases?

[Denis 'GNUtoo' Carikli]

On Sun, 31 Oct 2021 22:25:52 -0300
Alexandre Oliva <lxoliva at fsfla.org> wrote:

> On Oct 25, 2021, "Denis 'GNUtoo' Carikli" <GNUtoo at cyberdimension.org>
> wrote:
> 
> > I'll try to be more careful next time
> 
> Thanks.  No objections to the logic in the Makefile, just to its
> containing a link to non-Free code.  If it took the URL as a
> command-line parameter, it would have been just fine.
That's a good idea for next time (if there is one).

> > Parabola has such deblob instructions (with the URL) in several
> > packages.
> 
> IMHO, cleaning up should be separated from building.  I favor making
> cleaned-up souces available, along with cleaning-up logic if it
> exists, and sharing build recipes that start from cleaned-up sources.
>  This avoids sharing links to proprietary stuff.
In practice they are in two different functions. So while it's in the
same file, it's still clearly separated. 

Having scripts instead (and running them in the mksource function) could
also be an option as it would enable to share the script more broadly. 

[...]
> But I would like nonfree bits to be treated like, let's see, an
> experimental pathogen in a lab setting.  Keeping it safely contained
> is better than allowing to spread at will; even if others are
> negligent or malicious, I don't wish to have a share in the blame for
> it.
I think the analogy is really good. 

As I understand you might be "infected" (have agreed to their license)
if you redistribute such software. 

This is because you need a license to redistribute software, and if the
license is nonfree and forbid you to do things (like reverse
engineering) then it could be problematic in some jurisdictions (and
free software is distributed around the world).

Where I live we have strong laws to allow reverse engineering for
interoperability purposes, though I personally still like to limit the
risks as much as I can (for instance I already traveled to go to
Libreplanet and there the laws aren't the same), and in any case these
laws allowing reverse engineering for interoperability don't apply
everywhere to everybody so we still need to protect people and
projects around the world. 

I also hope that not agreeing to such licenses would decrease the
probability of being able to have a lawsuit as lawsuits cost money
(even if I'm pretty much guaranteed to win them in cases like that in
the EU). Though I've no idea how effective it is.

Also you might be "infected" (tainted) if you look at software that are
not under free licenses. So I do everything I can to avoid doing
that, and I try to make sure that other people who I work with in
FLOSS projects don't accidentally do that either as it could put such
projects at risk.

Even if I'm unsure of the legal validity of that (for instance we don't
have such extreme interpretation of the laws within free software),
doing that seems to put the projects at risk so I've also to follow
what is more or less collectively decided.

In any case, just downloading software containing nonfree bits, looking
at their licenses and automatically processing them seems to be safe.
Links also look safe as long as it doesn't steer people into
using, installing, or redistributing nonfree software.

Though at the end of the day you never know for sure as laws can be
extremely complex, vague, or even used for other purposes than they were
originally meant (for instance when laws that were supposed to cover a
specific case and are abused to crack down on political opposition).

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20211101/68573109/attachment.sig>