Re: Non-free (or dubious) firmware in linux driver modules, a lengthy analysis.
On Fri, Mar 11, 2005 at 11:55:42AM -0300, Humberto Massa wrote:
> Sven, the comments I will make here are more or less a compilation of
> many things I have said before on d-l and various other places on the
> Net.
Thanks for your reply.
> . Same question, with a "gotcha" variation: Is distributing the firmware
> together with the actual module in the same binary module enough to make
> it a "work based on the Program" on the terms of GPLv2 Section 0?
>
> (And this is the problem) Possibly _yes_. Albeit the "mere
> aggregation" clause *seems* to exempt those, it mentions
> explicitly "on a volume of storage or distribution medium" which
> is an expression that can or not be interpreted as encompassing
> "on the same (source|ELF) file"
Notice that i believe that what constitues an appropriate storage medium is
dependent on the context. In the kernel/driver/firmware context, it is usual
to place firmware in the actual driver, and thus the binary file constitutes
thus a "a volume of storage or distribution medium".
> Sven Luther wrote:
> >would cover these cases, but we run into the exception of the exception
> >when we face distribution of pre-installed linux machines, either
> >desktop computers, or embedded devices like those linux-running
> >routers.
>
> The problem, also worth noticing, is that Debian *is* the "operating
> system on which the executable runs" :-) so this exemptions falls down,
> because "this component itself accompanies the executable". At least in
> the case of some d-i or live CD.
>
> >I personally would like to say that this is the case, and make
> >binary-only modules as well as x86-binary only extension devices GPL
> >violations, but i have serious doubts that this would stand before a
> >judge.
>
> Yeah, I doubt it would stand too.
Some go down this path though.
> >2) Are the individual firmware blob distributable at all ?
> >
> >But the above doesn't tell us that those firmware blobs are free, just
> >that they can be distributed together with the linux kernel, either as
> >source code or as binary modules or even builtin the kernel. This is
> >clearly something that needs to be examined on a case per case basis.
>
> I.e, they can be distributed together with the kernel IF AND ONLY IF
> they can be distributed *at* *all*.
Yep, that is the real question, and i think the dubious copyright assignement
situation is a problem whcih needs solving for that, also in the upstream
mainline kernel. It is tedious work though, and needs to be redone for each
new upstream version, and i am not sure we really have the enthusiastic enough
people to do this drudge work.
> >I have not examined all the firmwares in details, others can maybe fill
> >in here, but i believe the problematic cases are the following
> >
> > a) firmware with source code, but some DFSG-non-freeness in the
> >licence on them.
>
> As per the SC and the recent resolutions, these could be in the kernel
> until post-sarge, when they would have to go to "non-free".
I disagree, but see below.
> This one, not only must be yanked from the kernel, but -- unless rights
> to distribute are acquired -- must be yanked now to protect Debian users
> and mirror network from possible lawsuits from the copyright owners of
> the firmware.
Yep, and possibly the whole module depending on it. I doubt it thouches debian
users though, only ourselves and our mirror network.
> >I am not entirely sure about the details, especially as said changes to
> >the social contract got disguissed in 'Editorial Ammendements', but i
> >believe that they included parts that where considered to be data and
> >not programs (like fonts, documentation, dictionaries, geographical
> >data and so on). I don't believe that those firmware blobs in question
> >can be in any way described as data, since they are clearly programs
> >destined to be run on the device cpu. It is true though that removing
> >them would have "grave consequences for the upcoming stable release, a
> >fact which does not serve our goals or the interests of our users", but
> >i don't believe this is enough to make us invoke the above GR to
> >include them in the sarge main kernel.
>
> I disagree with you on this. I think that as the 2004v003 was intended
> to the social contract, and (your (a) above) the SC was apparently being
> interpreted in the opposite way in earlier versions of Debian, then
> 2004v004 construes a way of saying "yes, the old interpretation was
> different then the new and we will go with the old one until after
> sarge".
Like i said, the plain ground was that the change was pushed in the editorial
changes, but if we follow the spirit of it, the change only applies to things
which previously where not considered as software, and now are, GDFL
documentation and the like. In both interpretations, firmware code can not be
mistaken as non-software though, so ...
That said, our previous RM did say that sarge would not need to strip said
firmware, and i think the new RM team follows that line (well at least one of
three does).
> >4) Technical solution ...
> >
> >So, given the above we need to make sure of the following :
> >
> > a) Firmware included in drivers in the same source file as the
> >drivers are clearly identified as such, and the copyright notice of
> >said file should clearly mention that the firmware in question is not
> >subject to the GPL, and only aggregated there for convenience. Ideally
> >the firmware in question should be in a separate file.
>
> Yes. If possible, the exact terms of the copyright license to the
> firmware should be added to the same place.
And in addition a list of affected modules placed in toplevel.
> > b) The individual modules containing the firmware are GPL compatible
> >and thus DFSG free, they can thus be shipped in main if the firmware is
> >stripped from them, or in non-free if the firmware is included.
>
> As I said before, this item I believe should be after done sarge.
Ok.
> > c) Should the modules be stripped of their firmware and kept in main,
> >or simply moved to non-free, which would be way easier? I believe
> >moving the whole of the binary modules into non-free would be better.
>
> It depends. IIRC some modules (A) do not work at all without loading the
> firmware in the device; some (B) work with severe limitations; some (C)
> work with the same level of quality, give or take a bug or two. At least
> in the cases B and C, I see as useful maintaing the module in main.
>
> My "neatness alert" would want to separate all firmware, put the
> non-free ones in non-free, etc. But that's just me.
I think it is also better for user support issues, since having modules which
differ from the upstream modules would be a pain, and it would make using the
non-free modules more difficult.
> > d) Can we keep the non-free firmware in the kernel-source in main,
> >and have only the non-free binary modules moved to non-free ? I believe
> >that this is more possible, since if we don't produce the binary
> >modules from them, the firmware blobs are only data, but it is limit.
>
> I have no strong opinion about this, except to say that in the ideal,
> neat world, nothing non-free should come from main... :-)
Yep. It is considerably less workload though, and unless we have someone doing
the work, it would be easier to move the whole kernel source code into
non-free (and thus the kernel-images into contrib :).
> In the hope that I contributed to this discussion,
I think so.
Friendly,
Sven Luther
Reply to: