So, allow me to reply to all of you in a single mail on the list, and
try to briefly summarize the way I now see things.
My question was:
>So is there a clear distinction between the kind of binary modules
>that are accepted in the kernel sources, and those that are not ?
>Personally, I cannot see the big, conceptual difference between a
>binary module that contains "firmware", and a binary module that
>contains the equivalent of firmware, but is executed by the host CPU
>rather than some embedded processor.
As several of you have pointed out, the big difference is with
platform independence. Firmware rarely changes, and a device that has
firmware downloaded onto it will continue to work, regardless of what
platform it is being used with. A binary library or module breaks when
the platform (host CPU) changes, and you cannot fix it yourself - you
must have the author of the library do it for you.
Therefore, firmware without sources is OK in the kernel. Binary
libraries are not.
I must admit this is a pretty good argument. In fact, it has convinced
me that you are right, and I was wrong.
Now, that only goes for me personally. Whether or not I can persuade
the managers at Olicom to release source for our library, I don't
know; it took me 4 years to convince them to support Linux at all
(using the binary library), so people shouldn't hold their breath
waiting for a full-source release of the Olicom driver. But at least I
have been given some good arguments for why this is necessary, if we
want to be included in the standard kernel sources.
But until that happy day arrives when Olicom releases full sources, we
will just ship what we have now: The binary module (which we developed
ourselves - neither Linux nor GPL code was used for it, as one of the
objectives was to have a fully OS independent library), and source
code for the driver that builds on top of the binary module. Alan Cox
raised doubts as to whether or not Olicom could release the
source-part of the driver under GPL; I would be very surprised if this
was not allowed - Olicom wrote the driver, has all rights to it, and
therefore can do pretty much what we like with it, including giving it
out to people on GPL terms. I even believe Linus has used such an
argument on several occasions.
Some of you made a couple of other points that I noted with
interest. Several people pointed out that releasing source does have
some benefits: It is good "image-wise", Linux users are more likely to
buy hardware from vendors who support Linux by releasing specs or
sources, and you get more people to debug the code - examples included
companies like NCR, DEC and BusLogic. Rik van Riel took this a step
further and suggested that a company could "sow the specs" for their
hardware, and the come back after a while and "harvest" a driver. An
interesting suggestion - maybe we do need to see driver development as
a task that can be delegated to volunteers, rather than having to take
all responsibility for it ourselves.
Leonard Zubkoff provided an insight into his experiences with
BusLogic, who it seems had the same kind of worries over releasing
source code as Olicom does, but finally decided to do so. As Leonard
writes, "Despite dire predictions of a few people internally, the world
has not collapsed due to their having done so." It is precisely those
'dire predictions' that I am struggling with.
Leonard also argued that developing a driver that relies on a non-GPL
binary module would be acceptable as "work for hire", but not as a
volunteer effort. I quite agree, and indeed development of the Olicom
driver was done in exactly this way, and Olicom is responsible for
(and pays for) support of the driver. Just to clear up any confusion
that might have arisen about that.
On the legal side, Craig Milo Rogers both pointed me to the
gnu.misc.discuss newsgroup, which I ought to have checked first, and
then gave a good (from my not-a-lawyer point of view) presentation of
the legal issues involved, in essence stating that there is a great
degree of uncertainty on the legal side, since the GPL has never been
"on trial". But apart from the legal technicalities, what really
matters is what Linus will accept into the kernel.
Thanks to everyone who helped clear up this matter for me. Although my
argument didn't win the case, I do not really feel like I "lost" - I
came out wiser, and that is always a win.
Now, I'll go bother some bosses.
-- Henrik Storner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu