Re: [GNU-linux-libre] Good practices for removing nonfree code found in source code.

[bill-auger]

On Sun, 3 Oct 2021 20:01:19 +0200 Denis wrote:
> On Sat, 2 Oct 2021 11:15:01 -0400
> bill-auger wrote:
> > users should never need to see "how the sausage is made", unless they
> > choose to "get their hands dirty"; and the FSDG requires neither  
> Thanks a lot, I wasn't sure if that practice was ok.

to be clear, what i meant, was that as long as users can get
everything needed to reproduce the system, the distro is not
obligated to share intermediary liberation procedures (unless the
software in question is on the "LOSTDNRTFSDG" ugly-list, then
they should be shown to this work-group) - if the liberation
procedures in the replicant VCS are necessary for users to
reproduce the system; then they probably must be disclosed in an
obvious way

the second part was to say, that distros are not required to
accept help from users - distros are only required to accept bug
reports from users

"transparency" is a nice bonus; but is not required


On Sun, 3 Oct 2021 20:01:19 +0200 Denis wrote:
> I'm not a lawyer but as I understand it is probably legal to remove the
> nonfree bits from the corresponding source code that we provide.

remove, yes, probably; but as jean pointed out, publishing diffs
which represent the copyrighted code, is probably still a
copyright violation - in the case of VCS, i think you would need
to deep purge the offending code, so that the VCS contains no
trace of it


On Sun, 3 Oct 2021 20:01:19 +0200 Denis wrote:
> Sometimes the GPL is completely legit: In several out of tree drivers
> for WiFi adapters, I found that the firmwares were included as
> hexadecimal arrays inside the C source code, and the file where that
> happens even has a header stating that it's GPLv2 or GPLv2+.
> 
> In cases like that, the firmware is typically GPLv2(+) but lack the
> corresponding source code. And since the hardware vendor who published
> that firmware is usually the copyright holder, it won't sue itself.
> 
> However anyone getting a copy of that source code can leverage the
> rights given by the GPLv2(+) to make it way easier to produce a free
> firmware: In many jurisdictions, there are heavy legal requirements
> around reverse engineering, decompilation, using (semi-)automatic tools
> to reconstruct source code, etc, but as I understand the GPLv2(+)
> removes many of these requirements.

how is that legit? - if the copyright holder does not provide
the source code to _someone_ who is using the software under the
supposed GPL, then it is impossible for _anyone_ to comply with
the GPL - that surely invalidates the GPL

i think i get your point; but firmware is not a representative
example - firmware is an edge case, where efficiency is
paramount - the author could always claim that it was written by
hand in machine code; so no CCS exists - the blob is already in
the "preferred form for modification" - it is reasonable to
extend the benefit of doubt, for something so specialized to
drive a very specific piece of hardware - for most software
though, that same claim would be very weak


On Sun, 3 Oct 2021 20:01:19 +0200 Denis wrote: 
> So in cases like that it would also be a good idea to archive that
> source release somewhere, ideally in projects like Archive.org or
> Software Heritage

but only the copyright holder could publish proprietary code,
_anywhere_ - it seems to me that automated archivers such as
Software Heritage have a huge liability there - people who
publish code on the hosts which Software Heritage pulls from
(github for example), grant permission to that one host (per
their TOS), to publish code on their behalf, which is otherwise
proprietary; but do not extend such permission to anyone else
(look but dont touch)

if Software Heritage notices any proprietary code in their
repos, presumably they would delete it - so, i dont think it
could be used for the purpose as you describe, without consent
of the copyright holder


On Sun, 3 Oct 2021 20:01:19 +0200 Denis wrote: 
> Since linux-libre removed older releases recently, did some FSDG
> distributions had to deal with that in some way?

unfortunately, this mailing list, is the best and appropriate
place to ask that question, you are not likely to get many
responses

the only distros which i have seen participating in this
work-group in the past 3 years, are replicant, parabola,
proteanos, and some others which are waiting for review (and you
are a member of two of those three endorsed projects) - the
linux-libre team, though not a distro, deserves an honorary
mention for participating (AFAICT, this was originally their
mailing list)

... which (not to trail off-topic) prompts my next (long overdue)
thread ... thanks :)