linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: Binary firmware in the kernel - licensing issues.
@ 2003-05-08 16:51 Adam J. Richter
  0 siblings, 0 replies; 32+ messages in thread
From: Adam J. Richter @ 2003-05-08 16:51 UTC (permalink / raw)
  To: joern; +Cc: linux-kernel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2934 bytes --]

Jörn Engel wrote:
>On Thu, 8 May 2003 08:59:52 -0700, Adam J. Richter wrote:
>> Jörn Engel wrote:
>> >For the kernel or the main CPU, the driver firmware is just data. The
>> >same, as the magic 0x12345678ul that gets written to some register
>> >because [can't tell, NDA]. In both cases, magic data gets written
>> >somewhere and afterwards, things just work.
>> 
>> 	I think you are confusing "the preferred form of the work
>> for making modifications to it" (the GPL's definition of "source
>> code") with "documentation."  In the case of poking a few values,
>> the preferred form for making modifications may be actually editing
>> the numbers directly in source code.  That quite likely is the way
>> that all developers maintain and modify that code, even if doing so
>> in an effective manner requires additional documentation.
>> 
>> 	In comparison, with the binary blobs of firmware, the preferred
>> form of the work for making modifications is, presumably, to edit
>> a source file from which the binary blob can be rebuilt using an
>> assembler or compiler.

>What's the difference? If the code uses 0x12345670ul, but 0x12345678ul
>would be correct, who is going to find the correct change without the
>documentation. Maybe someone reverse engineering the meaning of those
>bits. But most just accept the fact that one is better than the other
>without understanding why.

	I agree that documentation would be extremely useful in this
case and that distributing documentation shares a lot of the social
benefits of distributing source code, but the GPL does not require
shipping all forms of documentation, but it does require shipping
source code.  Maybe you think that a future version of the GPL
should require that.  The pros and cons of the discussion would
be interesting, but it is irrelevant to the question of what
version 2 (the version we are discussing) of the GNU General Public
License says.  GPL v2 only requires distribution of "the preferred
form of the work for making modifications to it."  Documentation
of magic numbers is often a separate work, often not even a
machine readable work.

>And one big binary blob is better than the other. Same here.

	"better" is a question for what you think the license
should be, not a question of the meaing of the current license.
The current license does not say "you must do whatever is better."

>Anyway, _should be ok_ is not _definitely legal in all countries_, so
>we basically both say "see a lawyer".

	Although I've never heard a lawyer tell me anything was
"definitely legal in all countries", I agree with your sentiment.
I am not a lawyer.  Please do not rely on this as legal advice.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Miplitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: Binary firmware in the kernel - licensing issues.
@ 2003-05-08 23:36 Adam J. Richter
  0 siblings, 0 replies; 32+ messages in thread
From: Adam J. Richter @ 2003-05-08 23:36 UTC (permalink / raw)
  To: root; +Cc: linux-kernel

>> 	Let's be clear: embedding binary firmware into a GPL'ed
>> work is fine if the firmware contains no additional restriction
>> beyond the GPL and complete source code for the firmware is
>> included.  I think you understand this much already, but I just
>> want to be clear about it.

>> 	All three distribution options in section 3 of the version 2
>> of the GNU General Public License require distribution or arrangments
>> for distribution "machine-readable source code", and defines
>> "source code" as "the preferred form of the work for making
>> modifications to it."  That seems pretty clear to me.

root@mauve.demon.co.uk wrote:
>So if you've got a CPU, that you have to load the microcode into before
>fully booting, you can't run linux on it natively, unless the CPU maker
>provides full microcode source? 

	I don't know of any such CPU, but I imagine you could run
Linux on it natively.  Just make sure that the microcode is not part
of a GPL'ed work.  For example, have the boot loader load the
microcode from a separate file before booting Linux.

	If the CPU can start boot Linux far enough to mount
a root file system and run some user space programs manually,
you could even have a separate user space program running under
Linux update the microcode.

>Presumably the "preferred form" clause would mean that there must 
>be hardware documentation too.

	No.  I just expalained the differences in these two
messages:

http://marc.theaimsgroup.com/?l=linux-kernel&m=105240981525737&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=105241295329617&w=2

>And when is a binary a binary, and not a string constant?

	When the developers create the binary from an assembler
rather calculating numbers manually, then the file that they
feed to the assembler is part of the preferred form of the
work for making modifications to it.

	All of the above is "in my humble opinion."  Also, remember
that I am not a lawyer, so do not rely on this as legal advice.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Miplitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: Binary firmware in the kernel - licensing issues.
@ 2003-05-08 16:35 Adam J. Richter
  2003-05-08 18:26 ` root
  0 siblings, 1 reply; 32+ messages in thread
From: Adam J. Richter @ 2003-05-08 16:35 UTC (permalink / raw)
  To: linux-kernel; +Cc: simon

Simon Kelley wrote:

>Briefly, the arguments that binary firmware which is copied into the
>hardware by the kernel is OK are these.
[...]
>5) There are current examples in the kernel of drivers with source-free
>    binary firmware blobs going back at least to version 1.3. This means
>    that someone might have considered this before and OKed it.

	I don't know who supposedly "OKed" what in the above
sentence.

>    It also
>    means that anyone who added code to the kernel since 1.3 had
>    evidence that for Linux the interpration of this GPL grey area
>    was to allow binary firmware. It is difficult to a contributor to
>    turn around now and claim copyright infrigement by distributing their
>    work with binary firmware when the kernel already had binary firmware
>    in it when their contribution was first made.

	I addressed this previously.  The fact that nobody has
litigated this yet, does not mean that everyone accepts in.

>6) AFAIK nobody has claimed that the existing firmware blobs in Linux
>    violate their copyright on GPL-licensed kernel contributions and
>    fairly certainly nobody has pressed this in law. (Since if they
>    had it would be well-known.)

	Just so you can never truthfully make this statment again,
for the record, I believe that the existing "firmware blobs"
in Linux that do not include source infringe Yggdrasil copyrights
on GPL-licensed kernel contributions (just as I believe they
infringe many other authors' GPL-licensed contributions).


>The arguments against allowing binary firmware are these.

	Let's be clear: embedding binary firmware into a GPL'ed
work is fine if the firmware contains no additional restriction
beyond the GPL and complete source code for the firmware is
included.  I think you understand this much already, but I just
want to be clear about it.

>1) The GPL is unclear on this point.

	All three distribution options in section 3 of the version 2
of the GNU General Public License require distribution or arrangments
for distribution "machine-readable source code", and defines
"source code" as "the preferred form of the work for making
modifications to it."  That seems pretty clear to me.

	By the way, I believe the FSF has already said that
the GPL prohibits these binary blobs without source code, and
I am confident that they would testify or submit a friend of
the court brief to that effect if necessary (and I believe it
would be usable by the court for interpreting a contract under
"the four corners rule").

>2) The intention of the GPL is to allow redistribution only
>    with source.
>3) Some contributors to the kernel might want their work distributed
>    only with all source, including firmware source. These people
>    would contend that their copyright had been violated and would
>    feel aggrieved or sue for lots of money.

	A problem with legal grey areas is that they create an
environment where vendors are made to choose between breaking the
law and perhaps being caught years later or going out of business
(because all the customers preferred less and less legal vendors).
So vendors may need to litigate GPL infractions more often and earlier
to avoid the "competition for the most illegal" dilemma, even
nobody in no individually actually feels that "aggrieved" in an
emotional sense.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Miplitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: Binary firmware in the kernel - licensing issues.
@ 2003-05-08 15:59 Adam J. Richter
  2003-05-08 16:09 ` Jörn Engel
  0 siblings, 1 reply; 32+ messages in thread
From: Adam J. Richter @ 2003-05-08 15:59 UTC (permalink / raw)
  To: linux-kernel; +Cc: joern

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

Jörn Engel wrote:
>For the kernel or the main CPU, the driver firmware is just data. The
>same, as the magic 0x12345678ul that gets written to some register
>because [can't tell, NDA]. In both cases, magic data gets written
>somewhere and afterwards, things just work.

	I think you are confusing "the preferred form of the work
for making modifications to it" (the GPL's definition of "source
code") with "documentation."  In the case of poking a few values,
the preferred form for making modifications may be actually editing
the numbers directly in source code.  That quite likely is the way
that all developers maintain and modify that code, even if doing so
in an effective manner requires additional documentation.

	In comparison, with the binary blobs of firmware, the preferred
form of the work for making modifications is, presumably, to edit
a source file from which the binary blob can be rebuilt using an
assembler or compiler.

	I am not a lawyer.  Please do not use this as legal advice.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Miplitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 32+ messages in thread
* RE: Binary firmware in the kernel - licensing issues.
@ 2003-05-08 13:20 Downing, Thomas
  0 siblings, 0 replies; 32+ messages in thread
From: Downing, Thomas @ 2003-05-08 13:20 UTC (permalink / raw)
  To: Simon Kelley, Filip Van Raemdonck
  Cc: Alan Cox, J. Bruce Fields, linux-kernel, torvalds

-----Original Message-----
From: Simon Kelley [mailto:simon@thekelleys.org.uk]

[snip]

My comments apply _only_ to firmware binaries for which the vendor
has given explicit license for free redistribution with GPL code.

> Briefly, the arguments that binary firmware which is copied into the
> hardware by the kernel is OK are these.
>
> 1) The GPL is unclear on this point.
> 2) The firmware is not linked with the kernel code and not executed
>     by the same processor as the kernel.

These are two separate issues, and both are crucial.  Four ways to 
handle firmware have been discussed.  1.) firmware as data in the
module image, 2.) firmware as data in userspace image, 3.) firmware
as file loaded by module, 4.) firmware as file loaded by userspace.

The first option might be debatable (non-GPL stuff linked into GPL
module), but I think it parallels 'magic' values written to registers.
Likewise the second option might not fly, though this removes it from
the kernel, it still leaves open the question of distro's that won't
go along.

The third option (and even more so the fourth) seem to have no point at
which the GPL could apply.  The firmware is now _clearly_ not linked in
any fashion with any GPL code.  It's just data that the kernel or other
moves from A to B at the behest of the user.  This again leaves only
the question of distro's that won't go this way.

For such distro makers: if firmware continues to become more prevalent
in devices, and the vendors are ok with redistribution, then those
distro makers lose to some extent, in the long run.  To say that distro
X won't do it, so we can't is backwards.

The second half of the original point is crucial - firmware does not run
on the same CPU's as the kernel.

> 3) Not allowing binary firmware leads to technical decisions which would
>     not be made in the absence of prohibition.
> 4) The same hardware and firmware is unambiguously OK if the firmware
>     is held in flash rather than initialised by the host.
> 5) There are current examples in the kernel of drivers with source-free
>     binary firmware blobs going back at least to version 1.3. This means
>     that someone might have considered this before and OKed it. It also
>     means that anyone who added code to the kernel since 1.3 had
>     evidence that for Linux the interpration of this GPL grey area
>     was to allow binary firmware. It is difficult to a contributor to
>     turn around now and claim copyright infrigement by distributing their
>     work with binary firmware when the kernel already had binary firmware
>     in it when their contribution was first made.
> 6) AFAIK nobody has claimed that the existing firmware blobs in Linux
>     violate their copyright on GPL-licensed kernel contributions and
>     fairly certainly nobody has pressed this in law. (Since if they
>     had it would be well-known.)
>
> The arguments against allowing binary firmware are these.
>
> 1) The GPL is unclear on this point.
> 2) The intention of the GPL is to allow redistribution only
>     with source.

The intention of the GPL is to allow redistribution _of GPL code, or
code linked to GPL code_ with source.

Makes a big difference.  Hence the distinctions made above.

> 3) Some contributors to the kernel might want their work distributed
>     only with all source, including firmware source. These people
>     would contend that their copyright had been violated and would
>     feel aggrieved or sue for lots of money.

That position would be a little inconsistent - as long as the code they
personally hold the copyright for was not involved.  There are vendors
shipping systems that use Linux, but are shipped with non-GPL
applications.  Is anyone aggrieved?  (Probably, but hardliners aside...)

> Anybody  want to write a better summary?

No, just some maundering nitpicking...


^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: Binary firmware in the kernel - licensing issues.
@ 2003-05-07 17:14 Adam J. Richter
  0 siblings, 0 replies; 32+ messages in thread
From: Adam J. Richter @ 2003-05-07 17:14 UTC (permalink / raw)
  To: simon; +Cc: linux-kernel

	I am not a lawyer, so please don't rely on this as legal advice.
I'm only explaining my layman's understanding.

Simon Kelley wrote:
>If many copyright holders don't agree then clearly firmware blobs
>shouldn't go into the kernel. It is difficult to argue that just one is
>enough for a veto [...]

	I don't think that should be difficult to argue.  Let's see.

	One objecting developer is enough for a lawsuit.  If a court
find copyright infringement and that developer registered the
copyright (a form TX from the copyright office and a $35 registration
fee, if memory serves), then I believe statutory damages would be
something like $750-30k per copy (see
http://www4.law.cornell.edu/uscode/17/504.html).  Theoretically,
there might be the potential for criminal prosecution of
for-profit distributors (see
http://www4.law.cornell.edu/uscode/18/2319.html).

	See how easy that was easy to argue?

>, especially since at least one driver (Advansys) has
>been there, complete with its "bucket of bits" since 1.3.x days at 
>least.

	This is the first I've heard of it.  In this case,
it appears that the copyright is GPL compatible, but it does
not appear that the GPL's requirement for the "preferred form of
the work for making modifications to it" has been satisfied
with respect to this binary blob of firmware.  If the source is
not included in the kernel, I think that binary blob should be
removed and replaced with some user level facility for loading that
array.  I wonder if it really is necessary to load the microcode
at all, as I would assume that there would have to be some
initial firmware loaded for the control to act as a boot
device (or can't it do that?).

>Any contributor to the kernel since then who cared could have 
>been aware of that as evidence of a de-facto interpretation of the GPL
>source clause as not applying to firmware in Linux.

	There are all sorts of obscure facts that one "could have
been aware" of, but that doesn't show that one _was_ aware of them
if you're trying to argue that one implicitly agreed to something.

>The technical advantages you give are not compelling for the Atmel 
>driver. The driver has international roaming support built-in and the
>firmware size is than 20k. In general though they may be good points.

>I suggest that having a driver which "just works" without needing
>extra files and configuration steps would trump minmizing legal
>exposure to the Linux copyright holders, for most people in the real
>world.

	It's not just the copyright holders who have the legal
exposure.  It would be anyone who distributes your driver.

	Again, I want to emphasize that I'm not a lawyer, and I
wouldn't want anyone to rely on my incomplete and potentially
quite incorrect layman's understanding as legal advice.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Miplitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: Binary firmware in the kernel - licensing issues.
@ 2003-05-07 11:59 Adam J. Richter
  2003-05-07 14:08 ` Simon Kelley
  0 siblings, 1 reply; 32+ messages in thread
From: Adam J. Richter @ 2003-05-07 11:59 UTC (permalink / raw)
  To: simon; +Cc: linux-kernel

Simon Kelley wrote:
>Now Linus could say "I consider that the kernel copyright holders 
>did/didn't give permission to combine  their work with firmware blobs" 
>and I contend that practically all the copyright holders would go along
>with that judgement, just as they went along with Linus's judgement
>about linking binary-only modules with their work.

	I am not a lawyer.  So, please do not rely on this as legal advice.

	I think you are confusing people having a strong distaste
for suing their fellow developers with people agreeing to something.
Also, your theory would require explicit unanimous agreement of the
contributors of GPL'ed kernel code if you actually want to guarantee
anything.

	By the way, there are some additional advantages to not compiling
in the firmware that perhaps you might not have contemplated.  Reducing
people's perceived legal exposure would most likely help adoption of
your driver.  Separate firmware loading also offers more upgradability
and, therefore, maintainability and perhaps extensibility if people
want to try firmware improvements (for example the WiFi frequencies
available for use are different in different countries and there may
also be different power limits or other requirements).  Finally, you
would avoid the need to keep a copy of the firmware in unswappable
kernel memory if your driver supports hot plugging (since a device
could be plugged in at any time, not just at driver initialization).

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Miplitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Re: Binary firmware in the kernel - licensing issues.
@ 2003-05-06 15:04 Adam J. Richter
  0 siblings, 0 replies; 32+ messages in thread
From: Adam J. Richter @ 2003-05-06 15:04 UTC (permalink / raw)
  To: linux-kernel, simon

Simon Kelley wrote:
>Maybe this is the sort of thing I need:
>
>http://www.keyspan.com/support/linux/

	I believe that the keyspan drivers that compile GPL-incompatible
firmware into the kernel or kernel modules are illegal.  I tried
being a nice guy about it, to the point of wring a user level
firmware loader could be invoked automatically via hotplug:
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=98758846106843&w=2.
You can look in the linux-usb-devel archives at about that time
for further discussion of the copyright issues.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Miplitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

^ permalink raw reply	[flat|nested] 32+ messages in thread
* RE: Binary firmware in the kernel - licensing issues.
@ 2003-05-06 12:54 Downing, Thomas
  2003-05-06 12:46 ` Alan Cox
  0 siblings, 1 reply; 32+ messages in thread
From: Downing, Thomas @ 2003-05-06 12:54 UTC (permalink / raw)
  To: Alan Cox, Simon Kelley; +Cc: Linux Kernel Mailing List

-----Original Message-----
From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
>
> So you can't distribute it at all unless there is other paperwork
> involved.
>
>> Given the current SCO-IBM situation I don't want to be responsible for
>> introducing any legally questionable IP into the kernel tree.
>> 
>> This situation must have come up before, how was it solved then?
>
> The easiest approach is to do the firmware load from userspace - which
> also keeps the driver size down and makes updating the firmware images
> easier for end users.
>
> (Debian as policy will rip the firmware out anyway regardless of what
> Linus does btw)
>
> The hotplug interface can be used to handle this.

I am writing a USB driver for a well-known vendor's USB device which
requires firmware download.  The vendor is considering allowing me
to publish the driver under GPL.  They will _not_ allow me to include
the binary firmware under any conditions.

So I will be loading the firmware from userspace - but the user must
obtain the firmware as a part of a larger application package.
(Complete crap IMO, but what can I do...)

PS:  what would be the preferred place to load the firmware
from, if no option giving the firmware pathname is passed to the 
module at load time?

^ permalink raw reply	[flat|nested] 32+ messages in thread
* Binary firmware in the kernel - licensing issues.
@ 2003-05-06 11:38 Simon Kelley
  2003-05-06 11:15 ` Alan Cox
                   ` (2 more replies)
  0 siblings, 3 replies; 32+ messages in thread
From: Simon Kelley @ 2003-05-06 11:38 UTC (permalink / raw)
  To: linux-kernel

I'm currently working on the drivers for Atmel PCMCIA and PCI wireless
adaptors with the aim of getting up to snuff for inclusion in
the mainline kernel.

I'm working from source drivers released by Atmel themselves last
year under the GPL so there are no problems with the code - each
source file from Atmel has a GPL notice at the top.

BUT. These things need firmware loaded, at least the ones without
built-in flash. The Atmel drivers come with binary firmware
as header files full of hex, with the following notice.

------------------------------------------------------------------
             Copyright (c) 1999-2000 by Atmel Corporation

This software is copyrighted by and is the sole property of Atmel
Corporation.  All rights, title, ownership, or other interests
in the software remain the property of Atmel Corporation.  This
software may only be used in accordance with the corresponding
license agreement.  Any un-authorized use, duplication, transmission,
distribution, or disclosure of this software is expressly forbidden. 


This Copyright notice may not be removed or modified without prior
written consent of Atmel Corporation. 


Atmel Corporation, Inc. reserves the right to modify this software
without notice.

Atmel Corporation.
2325 Orchard Parkway               literature@atmel.com
San Jose, CA 95131                 http://www.atmel.com
------------------------------------------------------------------

It isn't clear what the license agreement referred to in the above
actually is, but I don't think it's reasonable to just assume it's the
GPL and shove these files into the kernel as-is.

I shall contact Atmel for advice and clarification but my question for
the list is, what should I ask them to do? It's unlikely that they will
release the source to the firmware and even if they did I wouldn't want
firmware source  in the kernel tree since the kernel-build toolchain
won't be enough to build the firmware. What permissions do they have to
give to make including this stuff legal and compatible with the rest of
the kernel?

Given the current SCO-IBM situation I don't want to be responsible for
introducing any legally questionable IP into the kernel tree.

This situation must have come up before, how was it solved then?

Cheers,

Simon.


^ permalink raw reply	[flat|nested] 32+ messages in thread

end of thread, other threads:[~2003-05-08 23:24 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-08 16:51 Binary firmware in the kernel - licensing issues Adam J. Richter
  -- strict thread matches above, loose matches on Subject: below --
2003-05-08 23:36 Adam J. Richter
2003-05-08 16:35 Adam J. Richter
2003-05-08 18:26 ` root
2003-05-08 22:19   ` Alan Cox
2003-05-08 15:59 Adam J. Richter
2003-05-08 16:09 ` Jörn Engel
2003-05-08 13:20 Downing, Thomas
2003-05-07 17:14 Adam J. Richter
2003-05-07 11:59 Adam J. Richter
2003-05-07 14:08 ` Simon Kelley
2003-05-06 15:04 Adam J. Richter
2003-05-06 12:54 Downing, Thomas
2003-05-06 12:46 ` Alan Cox
2003-05-06 11:38 Simon Kelley
2003-05-06 11:15 ` Alan Cox
2003-05-06 13:28   ` Simon Kelley
2003-05-06 12:44     ` Alan Cox
2003-05-06 13:42   ` Simon Kelley
2003-05-06 12:19 ` Matti Aarnio
2003-05-06 15:16   ` J. Bruce Fields
2003-05-06 15:42     ` Simon Kelley
2003-05-06 15:21       ` Alan Cox
2003-05-07  6:52         ` Simon Kelley
2003-05-07  9:07           ` Filip Van Raemdonck
2003-05-07  9:54             ` Simon Kelley
2003-05-08  8:01               ` Filip Van Raemdonck
2003-05-08  9:44                 ` Simon Kelley
2003-05-08 10:56                   ` Alan Cox
2003-05-06 15:48     ` Richard B. Johnson
2003-05-06 15:19       ` Alan Cox
2003-05-08 10:20 ` Jörn Engel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).