Hello.
A supplier of a PCI mezzanine digital IO card has provided a linux 2.4
driver as source code. They have provided this code source with a
license stating I won't redistribute it in anyway.
My concern is that if I build this code into a module, I won't be able
to distribute it to customers without violating either the GPL (by not
distributing the source code), or the proprietary source code license
as currently imposed by the supplier.
>From what I have read, this concern is only valid if the binary module
is considered to be a 'derived work' of the kernel. The module source
directly includes the following kernel headers :
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/fs.h>
#include <linux/errno.h>
#include <linux/wrapper.h>
#include <linux/module.h>
#include <linux/iobuf.h>
#include <linux/highmem.h>
#include <asm/uaccess.h>
#include <linux/mm.h>
#include <asm/unistd.h>
Does this make the compiled module a derived work? Are the 'static
inlines' from the headers substantial enough?
I really want to have a clear understanding of the issues before
contacting the supplier. Any advice would be very much appreciated.
Kind regards,
Alex
Alan Cox and others have publicly stated that drivers, if complied stand
alone with NO DEPENDENCIES ON KERNEL HEADERS (i.e. they do not
incorporate in any way any kernel headers or source code tagged GPL) do
not violate the GPL when provided with Linux. DSFS, NVidia, and several
folks build kernel modules which are stand alone and are not objected to
by the majority of folks.
If these drivers include kernel headers as part of the build, then the
drivers violate the GPL. Period. Check the code. If the vendor is
including **ANY** GPL kernel headers, then they are required to open
source the drivers. There are some zealots and GPL bigots that disagree
with this, but Linux folks seem to be reasonable on this point.
Jeff
Alexander Fisher wrote:
>Hello.
>
>A supplier of a PCI mezzanine digital IO card has provided a linux 2.4
>driver as source code. They have provided this code source with a
>license stating I won't redistribute it in anyway.
>My concern is that if I build this code into a module, I won't be able
>to distribute it to customers without violating either the GPL (by not
>distributing the source code), or the proprietary source code license
>as currently imposed by the supplier.
>>From what I have read, this concern is only valid if the binary module
>is considered to be a 'derived work' of the kernel. The module source
>directly includes the following kernel headers :
>
>#include <linux/kernel.h>
>#include <linux/types.h>
>#include <linux/fs.h>
>#include <linux/errno.h>
>#include <linux/wrapper.h>
>#include <linux/module.h>
>#include <linux/iobuf.h>
>#include <linux/highmem.h>
>#include <asm/uaccess.h>
>#include <linux/mm.h>
>#include <asm/unistd.h>
>
>Does this make the compiled module a derived work? Are the 'static
>inlines' from the headers substantial enough?
>
>I really want to have a clear understanding of the issues before
>contacting the supplier. Any advice would be very much appreciated.
>Kind regards,
>Alex
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
On Tuesday 01 November 2005 18:49, Alexander Fisher wrote:
> Hello.
>
> A supplier of a PCI mezzanine digital IO card has provided a linux 2.4
> driver as source code. They have provided this code source with a
> license stating I won't redistribute it in anyway.
> My concern is that if I build this code into a module, I won't be able
> to distribute it to customers without violating either the GPL (by not
> distributing the source code), or the proprietary source code license
> as currently imposed by the supplier.
> From what I have read, this concern is only valid if the binary module
> is considered to be a 'derived work' of the kernel. The module source
> directly includes the following kernel headers :
Take the code and write a specification for the device.
Should be fairly easy.
Someone else will pick up the spec and write a clean GPLed driver.
Like these, without the reverse engineering part:
http://en.wikipedia.org/wiki/Clean_room_design
http://en.wikipedia.org/wiki/Chinese_wall#Computer_science
--
Greetings Michael.
No, don't take the code without the suppliers permission. It contains
trade secrets and you can get into a ot of trouble if there's an
agreement between the two of you. Contact the supplier. Tell them to
abstract away thre kernel headers, or rewrite to remove them, or grant
you persmission to open source the driver. The UK is the land of
frivilous lawsuits (I should know a lot about this :-) ), so don;t
expose yourself and breach any agreements.
Jeff
Michael Buesch wrote:
>On Tuesday 01 November 2005 18:49, Alexander Fisher wrote:
>
>
>>Hello.
>>
>>A supplier of a PCI mezzanine digital IO card has provided a linux 2.4
>>driver as source code. They have provided this code source with a
>>license stating I won't redistribute it in anyway.
>>My concern is that if I build this code into a module, I won't be able
>>to distribute it to customers without violating either the GPL (by not
>>distributing the source code), or the proprietary source code license
>>as currently imposed by the supplier.
>>From what I have read, this concern is only valid if the binary module
>>is considered to be a 'derived work' of the kernel. The module source
>>directly includes the following kernel headers :
>>
>>
>
>Take the code and write a specification for the device.
>Should be fairly easy.
>Someone else will pick up the spec and write a clean GPLed driver.
>
>Like these, without the reverse engineering part:
>http://en.wikipedia.org/wiki/Clean_room_design
>http://en.wikipedia.org/wiki/Chinese_wall#Computer_science
>
>
>
On Tuesday 01 November 2005 18:44, you wrote:
> No, don't take the code without the suppliers permission.
I interpreted his text as if he already has permission to use the code.
> It contains
> trade secrets and you can get into a ot of trouble if there's an
> agreement between the two of you. Contact the supplier. Tell them to
> abstract away thre kernel headers, or rewrite to remove them, or grant
> you persmission to open source the driver.
I did not say he should open source the driver. That will give trouble.
I suggested to write a _device_ specification. Driver specific things do not
care.
> The UK is the land of
> frivilous lawsuits (I should know a lot about this :-) ), so don;t
> expose yourself and breach any agreements.
Sure.
> Jeff
>
>
> Michael Buesch wrote:
>
> >On Tuesday 01 November 2005 18:49, Alexander Fisher wrote:
> >
> >
> >>Hello.
> >>
> >>A supplier of a PCI mezzanine digital IO card has provided a linux 2.4
> >>driver as source code. They have provided this code source with a
> >>license stating I won't redistribute it in anyway.
> >>My concern is that if I build this code into a module, I won't be able
> >>to distribute it to customers without violating either the GPL (by not
> >>distributing the source code), or the proprietary source code license
> >>as currently imposed by the supplier.
> >>From what I have read, this concern is only valid if the binary module
> >>is considered to be a 'derived work' of the kernel. The module source
> >>directly includes the following kernel headers :
> >>
> >>
> >
> >Take the code and write a specification for the device.
> >Should be fairly easy.
> >Someone else will pick up the spec and write a clean GPLed driver.
> >
> >Like these, without the reverse engineering part:
> >http://en.wikipedia.org/wiki/Clean_room_design
> >http://en.wikipedia.org/wiki/Chinese_wall#Computer_science
> >
> >
> >
>
>
>
--
Greetings Michael.
On Tuesday 01 November 2005 16:43, Jeff V. Merkey wrote:
> Alan Cox and others have publicly stated that drivers, if complied stand
> alone with NO DEPENDENCIES ON KERNEL HEADERS (i.e. they do not
> incorporate in any way any kernel headers or source code tagged GPL) do
> not violate the GPL when provided with Linux. DSFS, NVidia, and several
> folks build kernel modules which are stand alone and are not objected to
> by the majority of folks.
If you even take 2 minutes to actually inspect the NVIDIA video driver sources
(extract the .run file with --extract-only, and cd to usr/src/nv) you'll find
the "glue" which is provided as source, but not under the GPL, does indeed
#include kernel headers at compile time.
It does not distribute them, however, but it is completely nonsensical to
class this as having "no dependency". It has a compile time and runtime
dependency on the current kernel. What driver wouldn't?
> If these drivers include kernel headers as part of the build, then the
> drivers violate the GPL. Period. Check the code. If the vendor is
> including **ANY** GPL kernel headers, then they are required to open
> source the drivers. There are some zealots and GPL bigots that disagree
> with this, but Linux folks seem to be reasonable on this point.
There's clearly a grey area here, but I have no understanding of the law so I
will not comment beyond stating fact. But you are at least wrong about the
NVIDIA driver.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
On Tue, 2005-11-01 at 20:00 +0100, Michael Buesch wrote:
> On Tuesday 01 November 2005 18:49, Alexander Fisher wrote:
> > Hello.
> >
> > A supplier of a PCI mezzanine digital IO card has provided a linux 2.4
> > driver as source code. They have provided this code source with a
> > license stating I won't redistribute it in anyway.
> > My concern is that if I build this code into a module, I won't be able
> > to distribute it to customers without violating either the GPL (by not
> > distributing the source code), or the proprietary source code license
> > as currently imposed by the supplier.
> > From what I have read, this concern is only valid if the binary module
> > is considered to be a 'derived work' of the kernel. The module source
> > directly includes the following kernel headers :
>
> Take the code and write a specification for the device.
> Should be fairly easy.
> Someone else will pick up the spec and write a clean GPLed driver.
Seems excessive, why not just use a kernel debugger to capture all PIO
traffic to the device and write a driver based on that?
Lee
On Tue, 2005-11-01 at 09:43 -0700, Jeff V. Merkey wrote:
>
> Alan Cox and others have publicly stated that drivers, if complied stand
> alone with NO DEPENDENCIES ON KERNEL HEADERS (i.e. they do not
> incorporate in any way any kernel headers or source code tagged GPL)
can you give a reference to that? I can't imagine Alan saying that
(probably the negative of the opposite).. since even without using any
kernel headers you can be a derived work (when/how/what is up to
lawyers, but I assume you can agree that it is possible to create a
kernel module that is a derived work even without the condition you
describe) and in that case it HAS to be GPL. Alan isn't alone in the
position to make that exception, you'd need permission from all kernel
authors, but I also find it sort of hard to believe he said that.
On 11/1/05, Michael Buesch <[email protected]> wrote:
> On Tuesday 01 November 2005 18:44, you wrote:
> > No, don't take the code without the suppliers permission.
>
> I interpreted his text as if he already has permission to use the code.
>
> > It contains
> > trade secrets and you can get into a ot of trouble if there's an
> > agreement between the two of you. Contact the supplier. Tell them to
> > abstract away thre kernel headers, or rewrite to remove them, or grant
> > you persmission to open source the driver.
>
> I did not say he should open source the driver. That will give trouble.
> I suggested to write a _device_ specification. Driver specific things do not
> care.
I've got the source code to the device firmware too. So despite the
fact the driver has been written in c++, it might be possible to write
a usable specification. This isn't something I want to do. I'd
imagine this sort of action can really ruin a supplier/customer
relationship. What good is a GPLed driver if no one is prepared to
sell you the hardware?
So if the conclusion is that the driver can't be distributed under
anything other than the GPL (further opinions/confirmations welcome),
I think I've got two options. Find a different hardware vendor or
convince the current supplier to relicense their code.
I'm hoping that the opinions from one or two major linux kernel
copyright holders will help me in convincing them to do this.
Thanks,
Alex
Ah, top posting. Not a techie then...
On Tuesday 01 November 2005 10:43, Jeff V. Merkey wrote:
> Alan Cox and others have publicly stated that drivers, if complied stand
> alone with NO DEPENDENCIES ON KERNEL HEADERS (i.e. they do not
> incorporate in any way any kernel headers or source code tagged GPL) do
> not violate the GPL when provided with Linux. DSFS, NVidia, and several
> folks build kernel modules which are stand alone and are not objected to
> by the majority of folks.
>
> If these drivers include kernel headers as part of the build, then the
> drivers violate the GPL. Period. Check the code. If the vendor is
> including **ANY** GPL kernel headers, then they are required to open
> source the drivers. There are some zealots and GPL bigots that disagree
> with this, but Linux folks seem to be reasonable on this point.
>
> Jeff
I'd like to point out that the kernel headers are also part of the
standard /usr/include headers for a Linux system, and that if you include
something like <errno.h>, it eventually tunnels down to get its definition
from asm-generic/errno.h. Thus it can be hard to build _any_ linux binary
without including linux-kernel headers, but no properly briefed judge would
be likely to consider a strict posix binary a drived work of the Linux
kernel. So the above advice is kinda stupid.
What the headers have that a module does not is that they implement a defined
Application Programming Interface. (Posix, susv3, etc.) The code is not a
derived work of that specific implementation of the API, but of the API
itself. And since the API is an open and documented standard, life is good.
Also, this API can be expressed in english rather than code: keep in mind
that translating code into an english description and then having a complete
separate team translate it back again with nothing else passing between them
is what clean room reverse engineering does. It's pretty well established
that copyright doesn't cross that kind of barrier. So a documented and
standardized API is a strong barrier for copyright purposes. If challenged
in court, you can point to the API as a defense, as well as being
demonstrably derived from _documentation_, not from code. (Even when there
are inevitable deviations from the documented API to use platform-specific
features, it's a lot easier to sweep them under the rug of the API and claim
they're insignificant when there IS an API, and it covers the vast majority
of the code. A certain amount of optimization is understandable, and falls
under "tweaking" rather than structural/central/fundamental.)
Now let's look at the module. The above legal theory of non-infringement of
userspace programs is the existence of a barrier between userspace and the
kernel, with a well-defined and intentionally exported API, that makes you
definitely not a derived work. As a further defense, normal practice is to
write userspace code from API documentation, not from an examination of the
kernel source code. (General practice is to only look at the kernel or
headers to figure out why something isn't working, not to figure out what it
is you need to do in the first place. There are man pages, web pages, and
books galore as nont just viable but preferable alternatives to deriving your
code from any GPLed text.)
Does this apply to your module? No. What API is it conforming to? None.
The only module API in the Linux kernel is the implementation of the linux
kernel, and that's so fluid and changing that the same module is unlikely to
work without changes even one year later. There are periodic attempts to
document this stuff (such as Jonathan Corbet's Linux Device Drivers, third
edition), but they don't even claim to be documenting a standard or stable
API, they claim to be documenting the internal implementation details of a
specific version of the Linux kernel. The best documentation for the
Linux-kernel interface is reading the linux kernel source code, and the
leading alternatives are also in the linux-kernel tarball: the kernel's own
Documentation directory, and the documentation automatically generated from
the linux-kernel source code. Unfortunately for would-be API sniffers, these
are clearly intended as "aides to understanding the linux-kernel source",
_not_ as replacements for reading the source itself. They're not stable,
they're not complete, and they're not even always accurate. You MUST read
the code.
That means if your module's status is ever challenged in court, proving the
module is not a derived work would kinda suck. There is no standard you're
coding to. There's no other (non-linux) environment this module can run in
(not without significant modification; and yes the difference between
tweaking and structural changes can be important when determining what is and
isn't a derived work). This module is completely useless except as an
extension to a specific version of the Linux kernel. Without that linux
kernel, the module cannot perform any of its functions. (And yes, this
matters. What is the module's nature, why was it created, how is it normally
used? Books are read, art is viewed, video is played, plays are performed,
but modules are _run_.)
And then there's the killer: the module itself is highly specific to
individual _versions_ of the linux kernel. Your userspace program would run
on Linux 2.2, 2.4, or 2.6, with at most a couple tweaks. Your module may
require extensive modification to move from 2.6.9 to 2.6.14. That smells an
awful lot like "derived work". And a derived work of the GPL cannot be
distributed except under the terms of the GPL.
Since the license the module is under is not compatible with the GPL, and this
sounds like a module that was custom-designed and built to run in one and
only one environment, that's setting you up for a license conflict leading to
no ability to distribute, at all.
Now on a purely pragmatic level, what _matters_ is what enforcement actions
are you likely to face? The current (totally unofficial) attitude seems to
be that if the module doesn't include any GPL_ONLY exports, people are much
less motivated to bother with an enforcement action. (This is not a
guarantee, just a rule of thumb.) The enforcer might be able to win a court
battle against the enforcee, but there would be a battle, probably long and
drawn out, and that's that's not very appealing. It's a court case that
they'd have to work to prove, and we're generally a pretty lazy lot. (Mostly
because we're all have to-do lists of doom and you're item #873 on it, but it
comes across as lazy and we're too busy to argue.)
Now if the module uses any GPL_ONLY exports, it's clearly (and intentionally)
violating something that is actually documented as NOT being an API barrier.
There's a warning right there in the symbol: use this and you have crossed a
bright line beyond which we consider you not just grey but definitely a
derived work. Any module that includes one of those almost certainly _will_
see an enforcement action, because it's not a whole lot of work on our part
to point out a smoking gun.
So if your question is "are this module's license terms at all safe", the
answer is pretty clearly "no". Not safe. If your question is "will anybody
bother to do anything about it in the 2-3 years before this product is
obsolete and forgotten", the answer is "probably not, especially if you're
not very successful and never attract any attention to yourself or your
product".
If you'd like to base business decisions on that risk analysis, that's your
call. This isn't even getting into the fact that a binary-only module taints
the kernel (so nobody on this list will ever support your product), it means
upgrading your product to new kernel versions is a serious pain, so from a
security standpoint you potentially open yourself to liability if the sucker
is ever connected to the internet exactly _because_ you knew you'd be
crippling your customers' ability to upgrade, service, or even diagnose the
product if they (or their IT support contractor) cared to do so. (Although
this is an avenue nobody's been greedy enough to try to sue over and create a
precedent about yet. "There was clearly a better way, you intentionally
chose against it, and then a customer's machine got cracked and it cost them
lots of money" does not _automatically_ translate into liability for you.
Tends to weigh against you in procurement decisions when your customers
aren't stupid, though...)
Rob
P.S. In case anything I said made people feel too comfortable, IANAL. Just an
educated laybeing who has followed this stuff as a hobby for years. I can
spot the _obvious_ avenues of attack. Real Lawyers can spot the non-obvious,
or jurisdiction-specific ones. If you care about the above potential
liability issue of putting closed-source modules into a system widely
advertised as open source, knowing that this will denying your customers the
standard level of community technical support and upgrades associated with
their expectations for "Linux" or "Open Source", by all means talk to your
company's lawyer about it. :)
On 11/1/05, Lee Revell <[email protected]> wrote:
> On Tue, 2005-11-01 at 20:00 +0100, Michael Buesch wrote:
> > On Tuesday 01 November 2005 18:49, Alexander Fisher wrote:
> > > Hello.
> > >
> > > A supplier of a PCI mezzanine digital IO card has provided a linux 2.4
> > > driver as source code. They have provided this code source with a
> > > license stating I won't redistribute it in anyway.
> > > My concern is that if I build this code into a module, I won't be able
> > > to distribute it to customers without violating either the GPL (by not
> > > distributing the source code), or the proprietary source code license
> > > as currently imposed by the supplier.
> > > From what I have read, this concern is only valid if the binary module
> > > is considered to be a 'derived work' of the kernel. The module source
> > > directly includes the following kernel headers :
> >
> > Take the code and write a specification for the device.
> > Should be fairly easy.
> > Someone else will pick up the spec and write a clean GPLed driver.
>
> Seems excessive, why not just use a kernel debugger to capture all PIO
> traffic to the device and write a driver based on that?
Interesting, I hadn't thought of that. Alternatively, if I really
wanted to upset them (which I don't), I could use one of the very
expensive PCI bus analysers we've bought off them in the past!
Alex
On Tue, 1 Nov 2005, Alexander Fisher wrote:
> On 11/1/05, Michael Buesch <[email protected]> wrote:
>> On Tuesday 01 November 2005 18:44, you wrote:
>>> No, don't take the code without the suppliers permission.
>>
>> I interpreted his text as if he already has permission to use the code.
>>
>>> It contains
>>> trade secrets and you can get into a ot of trouble if there's an
>>> agreement between the two of you. Contact the supplier. Tell them to
>>> abstract away thre kernel headers, or rewrite to remove them, or grant
>>> you persmission to open source the driver.
>>
>> I did not say he should open source the driver. That will give trouble.
>> I suggested to write a _device_ specification. Driver specific things do not
>> care.
>
> I've got the source code to the device firmware too. So despite the
> fact the driver has been written in c++, it might be possible to write
^^^^^^^^_________
So you must have some user-mode code (which may not have to be GPL)
plus something that gets installed in the kernel??? Certainly you
don't have a working kernel driver written in C++, do you???
> a usable specification. This isn't something I want to do. I'd
> imagine this sort of action can really ruin a supplier/customer
> relationship. What good is a GPLed driver if no one is prepared to
> sell you the hardware?
> So if the conclusion is that the driver can't be distributed under
> anything other than the GPL (further opinions/confirmations welcome),
> I think I've got two options. Find a different hardware vendor or
> convince the current supplier to relicense their code.
> I'm hoping that the opinions from one or two major linux kernel
> copyright holders will help me in convincing them to do this.
>
> Thanks,
> Alex
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Lee Revell wrote:
>On Tue, 2005-11-01 at 20:00 +0100, Michael Buesch wrote:
>
>
>>On Tuesday 01 November 2005 18:49, Alexander Fisher wrote:
>>
>>
>>>Hello.
>>>
>>>A supplier of a PCI mezzanine digital IO card has provided a linux 2.4
>>>driver as source code. They have provided this code source with a
>>>license stating I won't redistribute it in anyway.
>>>My concern is that if I build this code into a module, I won't be able
>>>to distribute it to customers without violating either the GPL (by not
>>>distributing the source code), or the proprietary source code license
>>>as currently imposed by the supplier.
>>>From what I have read, this concern is only valid if the binary module
>>>is considered to be a 'derived work' of the kernel. The module source
>>>directly includes the following kernel headers :
>>>
>>>
>>Take the code and write a specification for the device.
>>Should be fairly easy.
>>Someone else will pick up the spec and write a clean GPLed driver.
>>
>>
>
>Seems excessive, why not just use a kernel debugger to capture all PIO
>traffic to the device and write a driver based on that?
>
>Lee
>
>
>
That's legal, and good advice.
Jeff
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
On Tuesday 01 November 2005 11:44, Jeff V. Merkey wrote:
> No, don't take the code without the suppliers permission. It contains
> trade secrets and you can get into a ot of trouble if there's an
> agreement between the two of you. Contact the supplier. Tell them to
> abstract away thre kernel headers, or rewrite to remove them, or grant
> you persmission to open source the driver. The UK is the land of
> frivilous lawsuits (I should know a lot about this :-) ), so don;t
> expose yourself and breach any agreements.
>
> Jeff
Translation to what a sane person might have said:
Make sure you aren't bound by any non-disclosure agreements before posting a
driver specification for public viewing. Writing up such a spec from the
source code (if the supplier didn't give you one) is probably a darn good
idea either way, for your own internal maintenance purposes. If you have the
spare cycles...
Rob
On 01-Nov-2005 Alexander Fisher wrote:
> I've got the source code to the device firmware too.
Maybe they only care on keeping the firmware secret. Try asking
them if you can disclose the driver sources only. The firmware
can be used in binary form.
> So despite the fact the driver has been written in c++, it
> might be possible to write a usable specification.
Linux 2.6 doesn't accept c++, so you have to rewrite it anyway.
You should ask them if you can publish your own driver based
on infos you extract from their driver.
--
Giuliano.
>
>
> > So despite the fact the driver has been written in c++, it
> > might be possible to write a usable specification.
>
> Linux 2.6 doesn't accept c++, so you have to rewrite it anyway.
> You should ask them if you can publish your own driver based
> on infos you extract from their driver.
>
without exeption c++ code can be used at drivers.
On 2 Nov 2005, Alex Lyashkov moaned:
>> > So despite the fact the driver has been written in c++, it
>> > might be possible to write a usable specification.
>>
>> Linux 2.6 doesn't accept c++, so you have to rewrite it anyway.
>> You should ask them if you can publish your own driver based
>> on infos you extract from their driver.
>>
> without exeption c++ code can be used at drivers.
The rather important `struct class' may give you trouble there.
--
`"Gun-wielding recluse gunned down by local police" isn't the epitaph
I want. I am hoping for "Witnesses reported the sound up to two hundred
kilometers away" or "Last body part finally located".' --- James Nicoll
? ???, 02.11.2005, ? 17:29, Nix ?????:
> On 2 Nov 2005, Alex Lyashkov moaned:
> >> > So despite the fact the driver has been written in c++, it
> >> > might be possible to write a usable specification.
> >>
> >> Linux 2.6 doesn't accept c++, so you have to rewrite it anyway.
> >> You should ask them if you can publish your own driver based
> >> on infos you extract from their driver.
> >>
> > without exeption c++ code can be used at drivers.
>
> The rather important `struct class' may give you trouble there.
Long time ago (over 4 years ago) i work with poring VPN and firewall
NDIS driver from Win32 to Linux. Only small kernel interface was writeln
at pure C, all other at C++. How i remember need only create operator
new and delete, also don`t use [out|in]stream.
--
FreeVPS Developers Team http://www.freevps.com
Positive Software http://www.psoft.net
On Wed, 2 Nov 2005, Alex Lyashkov wrote:
> > Linux 2.6 doesn't accept c++, so you have to rewrite it anyway.
> > You should ask them if you can publish your own driver based
> > on infos you extract from their driver.
> >
> without exeption c++ code can be used at drivers.
No, it can't. There is not support at all for c++ in the kernel. Even if
you don't use exceptions and you redefine all new() operators, when you
try to load the module it will not find several symbols that are defined
inside user space libraries. Under 2.4 I managed to use c++ code in a
module, but I had to define some 100% bogus symbols in the sources to make
the loader happy (those symbols are gcc- and architecture-dependent).
Furthermore, c++ code can crash because c++ hides too many things,
expecially temporary stuff which is allocated on the stack. Stack space in
*very* limited in kernel space. Finally, linux 2.6 do not permit loading
c++ code anymore.
--
Giuliano.
From: Alexander Fisher [[email protected]]
> A supplier of a PCI mezzanine digital IO card has provided a linux 2.4
> driver as source code. They have provided this code source with a
> license stating I won't redistribute it in anyway.
It seems to me that the supplier is violating the GPL.
They've distributed a linux driver.
There are rare exceptions, but most linux drivers are considered
derived works of the kernel and must also be licenced under the GPL
(GPL 2.b).
As such, further restrictions on the rights that come with the driver
are prohibited (GPL 6.). Or, this may count as sublicencing, which is
also prohibited (GPL 4.).
So their licence prohibiting redistribution is in violation of the GPL.
Since no one else has commented on this, I'm wondering if I'm wrong.
Comments?
If I'm right, I believe that GPL 4. allows you to proceed with the
driver as per the GPL...
> My concern is that if I build this code into a module, I won't be able
> to distribute it to customers
..and you can redistribute it.
> without violating either the GPL (by not
> distributing the source code), or the proprietary source code license
> as currently imposed by the supplier.
In my mind, this is exactly what the GPL is designed to prevent.
..Stu
On Wed, 2 Nov 2005, Nix wrote:
> On 2 Nov 2005, Alex Lyashkov moaned:
>>>> So despite the fact the driver has been written in c++, it
>>>> might be possible to write a usable specification.
>>>
>>> Linux 2.6 doesn't accept c++, so you have to rewrite it anyway.
>>> You should ask them if you can publish your own driver based
>>> on infos you extract from their driver.
>>>
>> without exeption c++ code can be used at drivers.
>
> The rather important `struct class' may give you trouble there.
>
1. A couple of symbols would have to be artifically generated
to keep the loader happy.
2. New and delete are a bitch.
3. Link will fail because of the hidden stuff C++ needs that it
can't find. Okay, just generate some dummy symbols in asm,
all pointing to the same junk.
4. Once you got it to load, gigantic stack usage will crash.
So much for C++. Just use C. He probably didn't remember that
it's a simpler variant. If he knows C++, he knows C, but just
needs to do more things that C++ did for him.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Wed, 2 Nov 2005, [email protected] announced authoritatively:
> 2. New and delete are a bitch.
s/a bitch/trivial/
they're wrappers around the appropriate kernel memory allocators.
> 3. Link will fail because of the hidden stuff C++ needs that it
> can't find. Okay, just generate some dummy symbols in asm,
> all pointing to the same junk.
Obviously if you try using EH it will always crash hard. That
would be really stupid.
> 4. Once you got it to load, gigantic stack usage will crash.
Er, C++ does not imply `gigantic stack usage'.
However, C++ *will* be discomfited by `struct class', and unless you
want to rule out use of sysfs you're going to have to use it at some
point. And *that* is a bit of a killer unless you want to write half
your app in C and half in C++, which is getting a bit silly.
> So much for C++. Just use C. He probably didn't remember that
> it's a simpler variant.
It's a quite different language which happens to share a lot of ancestry
with C, and which happens to make link-time compatibility with C fairly
easy. Therefore it looks fairly similar; but it is *not* that similar,
not any more. Good C code and good C++ code look utterly different,
and good C++ code probably has no place in the kernel (making, as it
does, heavy use of the templated standard C++ library).
But, no, it doesn't belong in the kernel. (If you're writing a
filesystem, though, filesystem drivers in C++ --- or, for that matter,
Perl, Java or Haskell --- are quite practicable, thanks to the merging
of FUSE.)
--
`"Gun-wielding recluse gunned down by local police" isn't the epitaph
I want. I am hoping for "Witnesses reported the sound up to two hundred
kilometers away" or "Last body part finally located".' --- James Nicoll
Amongst the various arguments here for declaring a binary kernel
module a drived work based on including kernel headers, please
take a step back and remember that what's sauce for the goose is
sauce for the gander.
The basic question is, does the user of the headers require the permission
of the author of the headers to distribute the resultant object code?
If the answer is "no", then the question of the terms of that permission
(the GNU GPL or otherwise) doesn't arise.
I'd like to argue that people interested in free software should want
the answer to be "no", and should not try to establish precedents to
the contrary, and that asserting the claim could boomerang unpleasantly.
Suppose EvilCo produces an EvilOS and provides a series of headers for
interfacing to EvilOS. Further suppose that EvilOS is not very good
about enforcing user/kernel separation and a lot of the headers describe
kernel-internal data structures that a user might nonetheless want to
hook into.
Now, if I write a piece of software that runs on EvilOS, or even a
device driver to connect some hardware to EvilOS, do I want to need
EvilCo's permission to distribute a percompiled version? Do I want
them to claim proprietary rights in the source code because it refers
to symbols defined in their headers?
Or would I rather that such names and references are considered "Scenes
a faire" (standard boilerplate) for software that runs on EvilOS, and
as such not subject to copyright law?
Looking at all the crap companies are trying to impose about publishing
benchmarks, think before claiming that copyright law gives you some
authority, lest that claim be used against you. I don't see such claims
being widely asserted by commercial companies, so I'm strongly disinclined
to try to start an arms race in that direction.
(There is a bit of that in the game console market, but that's enforced by
not giving you the headers until you agree to an NDA with lots of conditions.)
In particular, it's a lot harder to argue that such a claim is ridiculous
if you're making the same claim yourself. And it's not at all clear to me
that the benefit is worth that cost.
Feel free to argue that the cost is worth it; what worried me was that it
wasn't clear that people were considering the flip side of the arguments
at all. (Of course, there are a lot more mailing list archives than I've
read; I may just have missed it.)
On Wed, 2 Nov 2005 [email protected] wrote:
> Amongst the various arguments here for declaring a binary kernel
> module a drived work based on including kernel headers, please
> take a step back and remember that what's sauce for the goose is
> sauce for the gander.
>
> The basic question is, does the user of the headers require the permission
> of the author of the headers to distribute the resultant object code?
> If the answer is "no", then the question of the terms of that permission
> (the GNU GPL or otherwise) doesn't arise.
>
> I'd like to argue that people interested in free software should want
> the answer to be "no", and should not try to establish precedents to
> the contrary, and that asserting the claim could boomerang unpleasantly.
>
> Suppose EvilCo produces an EvilOS and provides a series of headers for
> interfacing to EvilOS. Further suppose that EvilOS is not very good
> about enforcing user/kernel separation and a lot of the headers describe
> kernel-internal data structures that a user might nonetheless want to
> hook into.
>
> Now, if I write a piece of software that runs on EvilOS, or even a
> device driver to connect some hardware to EvilOS, do I want to need
> EvilCo's permission to distribute a percompiled version? Do I want
> them to claim proprietary rights in the source code because it refers
> to symbols defined in their headers?
>
> Or would I rather that such names and references are considered "Scenes
> a faire" (standard boilerplate) for software that runs on EvilOS, and
> as such not subject to copyright law?
>
>
> Looking at all the crap companies are trying to impose about publishing
> benchmarks, think before claiming that copyright law gives you some
> authority, lest that claim be used against you. I don't see such claims
> being widely asserted by commercial companies, so I'm strongly disinclined
> to try to start an arms race in that direction.
>
> (There is a bit of that in the game console market, but that's enforced by
> not giving you the headers until you agree to an NDA with lots of conditions.)
>
> In particular, it's a lot harder to argue that such a claim is ridiculous
> if you're making the same claim yourself. And it's not at all clear to me
> that the benefit is worth that cost.
>
>
> Feel free to argue that the cost is worth it; what worried me was that it
> wasn't clear that people were considering the flip side of the arguments
> at all. (Of course, there are a lot more mailing list archives than I've
> read; I may just have missed it.)
This is certainly one of the most intelligent discourses I've heard
in some time about the subject. Some claim that if it runs inside
the kernel, it's "obviously" a derived work. It really isn't so
obvious at all.
In fact, if the design of a driver, and its implementation requires
a knowledge of only the driver's kernel interface and the hardware
for which the driver is written, it is not derived by any stretch
of the imagination. It's like writing code to interface with any
API. You only need to understand the published interface and not
its underlying principles of operation.
On the other hand, if you were to take an existing driver and
modify it to control some new hardware, then it is obviously
a derived work. The work was derived from the previous driver.
Anything else is not "obvious", but simply conjecture which
may or may not be correct.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Wednesday 02 November 2005 16:21, [email protected] wrote:
> Amongst the various arguments here for declaring a binary kernel
> module a drived work based on including kernel headers, please
> take a step back and remember that what's sauce for the goose is
> sauce for the gander.
I think we've noticed the past few years of foaming looney attacks from SCO,
yes. And Microsoft's own attempts to license its header files, and such.
> The basic question is, does the user of the headers require the permission
> of the author of the headers to distribute the resultant object code?
> If the answer is "no", then the question of the terms of that permission
> (the GNU GPL or otherwise) doesn't arise.
Are you creating your source code based on somebody else's source code, or are
you creating your source code based on something else (documentation, a
defined API, etc).
Whether or not you include the header files is a relatively minor issue,
really.
> Suppose EvilCo produces an EvilOS and provides a series of headers for
> interfacing to EvilOS.
Been there, done that, watched it spawn groklaw.
> Now, if I write a piece of software that runs on EvilOS, or even a
> device driver to connect some hardware to EvilOS, do I want to need
> EvilCo's permission to distribute a percompiled version?
Ask Microsoft. They were flirting with this kind of thing years ago. (Trying
to make it so that their development tools couldn't be used to create open
source.) This effort was about as widely ignored as their shrinkwrap license
terms from the 1980's.
> Do I want
> them to claim proprietary rights in the source code because it refers
> to symbols defined in their headers?
Are those symbols documented? Or did they have to deeply study a copyrighted
work in that claims rights over derived works in order to find out about
those symbols in the first place?
> (There is a bit of that in the game console market, but that's enforced by
> not giving you the headers until you agree to an NDA with lots of
> conditions.)
There's a difference between grounds for a lawsuit and a slam-dunk easy case
you're confident you can win in a finite amount of time. If you're trying to
prevent Foaming Nutballs, Inc. from ever having the slightest trumped up
grounds for a suit, you're not going to be doing much.
> In particular, it's a lot harder to argue that such a claim is ridiculous
> if you're making the same claim yourself. And it's not at all clear to me
> that the benefit is worth that cost.
I don't think anybody with a brain is arguing that #including the userspace
(/usr/include) header files puts your Linux program under the GPL. And
there's never been any alternative but to include the GPL linux kernel header
files in those...
> Feel free to argue that the cost is worth it; what worried me was that it
> wasn't clear that people were considering the flip side of the arguments
> at all. (Of course, there are a lot more mailing list archives than I've
> read; I may just have missed it.)
I've been considering the flip side of all these arguments for about five
years, and considering them especially closely for the last two. :)
Rob
On Maw, 2005-11-01 at 17:49 +0000, Alexander Fisher wrote:
> Hello.
>
> A supplier of a PCI mezzanine digital IO card has provided a linux 2.4
> driver as source code. They have provided this code source with a
> license stating I won't redistribute it in anyway.
> My concern is that if I build this code into a module, I won't be able
> to distribute it to customers without violating either the GPL (by not
> distributing the source code), or the proprietary source code license
> as currently imposed by the supplier.
You need to ask a lawyer in the part of the world you plan to do this.
The area of law in question is quite murky and at the moment there is no
direct linux kernel caselaw of relevance that helps (at least that i
know of).
I suspect all kernel modules are probably derivative works but I am not
a lawyer and when you look at code which is large, shared with other
OS's and uses minimal kernel services it gets more complex.
For user space it isn't a problem and the kernel specifically clarifies
this in the copyright notice so as to avoid confusion or risk.
There is a second consideration however - your module will work only
with the exact gcc/kernel/options configuration you selected. That makes
binary modules problematic anyway as the kernel has an API not an ABI.
It would be far better to understand what the suppliers concern is and
to see if you can find an amicable way to distribute a GPL driver or
even get it into the base kernel that does not cause concerns for the
vendor. You may find the linux lab project and other digital I/O cards
with open drivers useful in persuading them of course ;)
Rob Landley <[email protected]> wrote:
> On Wednesday 02 November 2005 16:21, [email protected] wrote:
> > Amongst the various arguments here for declaring a binary kernel
> > module a drived work based on including kernel headers, please
> > take a step back and remember that what's sauce for the goose is
> > sauce for the gander.
>
> I think we've noticed the past few years of foaming looney attacks from SCO,
> yes. And Microsoft's own attempts to license its header files, and such.
[...]
> > Do I want
> > them to claim proprietary rights in the source code because it refers
> > to symbols defined in their headers?
> Are those symbols documented? Or did they have to deeply study a
> copyrighted work in that claims rights over derived works in order to
> find out about those symbols in the first place?
To /study/ a copyrighted work to find out how it works and then write code
against what you learned, you are /not/ copying anything. Sure, the
original code's license might forbid such activities, but in Linux' case it
certainly doesn't.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
>> So despite the fact the driver has been written in c++, it
>> might be possible to write a usable specification.
>
>Linux 2.6 doesn't accept c++, so you have to rewrite it anyway.
It does, to a limited degree. Just look at the VMware vmmon/vmnet driver
sources.
>You should ask them if you can publish your own driver based
>on infos you extract from their driver.
Jan Engelhardt
--
On Thu, Nov 10, 2005 at 08:02:55PM +0100, Jan Engelhardt wrote:
> It does, to a limited degree. Just look at the VMware vmmon/vmnet driver
> sources.
At least version 4.5.2 appears to be entirely c code to me. What looks
like c++ to you in there?
Len Sorensen
> If you even take 2 minutes to actually inspect the NVIDIA video
> driver sources
> (extract the .run file with --extract-only, and cd to usr/src/nv)
> you'll find
> the "glue" which is provided as source, but not under the GPL,
> does indeed
> #include kernel headers at compile time.
>
> It does not distribute them, however, but it is completely nonsensical to
> class this as having "no dependency". It has a compile time and runtime
> dependency on the current kernel. What driver wouldn't?
If I write source code that includes "stdio.h", I can do whatever I want
with that source code, and I'm not bound by the license of any particular
file that happens to be called "stdio.h". On the other hand, if I compile
that source code including *your* "stdio.h" file, the resulting compiled
output is likely a derived work of your file.
So the source code is not a derivative work of any GPL'd files. The
compiled driver may be, precisely because it contains bits and pieces of the
header files.
DS
David Schwartz wrote:
>>If you even take 2 minutes to actually inspect the NVIDIA video
>>driver sources
>>(extract the .run file with --extract-only, and cd to usr/src/nv)
>>you'll find
>>the "glue" which is provided as source, but not under the GPL,
>>does indeed
>>#include kernel headers at compile time.
>>
>>It does not distribute them, however, but it is completely nonsensical to
>>class this as having "no dependency". It has a compile time and runtime
>>dependency on the current kernel. What driver wouldn't?
>>
>>
>
> If I write source code that includes "stdio.h", I can do whatever I want
>with that source code, and I'm not bound by the license of any particular
>file that happens to be called "stdio.h". On the other hand, if I compile
>that source code including *your* "stdio.h" file, the resulting compiled
>output is likely a derived work of your file.
>
> So the source code is not a derivative work of any GPL'd files. The
>compiled driver may be, precisely because it contains bits and pieces of the
>header files.
>
> DS
>
>
>
>
>
Correct.
Jeff
Building for VMware Workstation 5.0.0.
Using 2.6.x kernel build system.
make -C /lib/modules/2.6.13-AS20/build/include/.. SUBDIRS=$PWD
SRCROOT=$PWD/. modules
CC [M] /usr/lib/vmware/modules/source/vmmon-only/linux/driver.o
CC [M] /usr/lib/vmware/modules/source/vmmon-only/linux/hostif.o
CC [M] /usr/lib/vmware/modules/source/vmmon-only/common/cpuid.o
CC [M] /usr/lib/vmware/modules/source/vmmon-only/common/hash.o
CC [M] /usr/lib/vmware/modules/source/vmmon-only/common/memtrack.o
CC [M] /usr/lib/vmware/modules/source/vmmon-only/common/phystrack.o
CC [M] /usr/lib/vmware/modules/source/vmmon-only/common/task.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
Ada/C/ObjC but not for C++
cc1plus: warning: command line option
"-Werror-implicit-function-declaration" is valid for C/ObjC but not for C++
cc1plus: warning: command line option "-Wdeclaration-after-statement" is
valid for C/ObjC but not for C++
cc1plus: warning: command line option "-Wno-pointer-sign" is valid for
C/ObjC but not for C++
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
Ada/C/ObjC but not for C++
cc1plus: warning: command line option "-ffreestanding" is valid for C/ObjC
but not for C++
include/asm/bitops.h: In function ■int find_first_bit(const long unsigned
int*,
unsigned int)■:
include/asm/bitops.h:334: warning: comparison between signed and unsigned
integer expressions
[...]
>> It does, to a limited degree. Just look at the VMware vmmon/vmnet driver
>> sources.
>
>At least version 4.5.2 appears to be entirely c code to me. What looks
>like c++ to you in there?
Jan Engelhardt
--
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/
On Thu, Nov 17, 2005 at 10:23:21PM +0100, Jan Engelhardt wrote:
> Building for VMware Workstation 5.0.0.
Well I only looked at 4.5.2
> Using 2.6.x kernel build system.
> make -C /lib/modules/2.6.13-AS20/build/include/.. SUBDIRS=$PWD
> SRCROOT=$PWD/. modules
> CC [M] /usr/lib/vmware/modules/source/vmmon-only/linux/driver.o
> CC [M] /usr/lib/vmware/modules/source/vmmon-only/linux/hostif.o
> CC [M] /usr/lib/vmware/modules/source/vmmon-only/common/cpuid.o
> CC [M] /usr/lib/vmware/modules/source/vmmon-only/common/hash.o
> CC [M] /usr/lib/vmware/modules/source/vmmon-only/common/memtrack.o
> CC [M] /usr/lib/vmware/modules/source/vmmon-only/common/phystrack.o
> CC [M] /usr/lib/vmware/modules/source/vmmon-only/common/task.o
> cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
> Ada/C/ObjC but not for C++
> cc1plus: warning: command line option
> "-Werror-implicit-function-declaration" is valid for C/ObjC but not for C++
> cc1plus: warning: command line option "-Wdeclaration-after-statement" is
> valid for C/ObjC but not for C++
> cc1plus: warning: command line option "-Wno-pointer-sign" is valid for
> C/ObjC but not for C++
> cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
> Ada/C/ObjC but not for C++
> cc1plus: warning: command line option "-ffreestanding" is valid for C/ObjC
> but not for C++
> include/asm/bitops.h: In function ???int find_first_bit(const long unsigned
> int*,
> unsigned int)???:
> include/asm/bitops.h:334: warning: comparison between signed and unsigned
> integer expressions
> [...]
Whyever is anything calling cc1plus when the file appear to all be .c?
Len Sorensen
>Whyever is anything calling cc1plus when the file appear to all be .c?
The makefile explicitly adds "-x c++" for this one.
Jan Engelhardt
--
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/
Lennart Sorensen wrote:
> On Thu, Nov 17, 2005 at 10:23:21PM +0100, Jan Engelhardt wrote:
>
>>Building for VMware Workstation 5.0.0.
>
>
> Well I only looked at 4.5.2
>
>
>>Using 2.6.x kernel build system.
>>make -C /lib/modules/2.6.13-AS20/build/include/.. SUBDIRS=$PWD
>>SRCROOT=$PWD/. modules
...
>> CC [M] /usr/lib/vmware/modules/source/vmmon-only/common/task.o
>>cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
>>Ada/C/ObjC but not for C++
>>cc1plus: warning: command line option
>>"-Werror-implicit-function-declaration" is valid for C/ObjC but not for C++
>>cc1plus: warning: command line option "-Wdeclaration-after-statement" is
>>valid for C/ObjC but not for C++
>>cc1plus: warning: command line option "-Wno-pointer-sign" is valid for
>>C/ObjC but not for C++
>>cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
>>Ada/C/ObjC but not for C++
>>cc1plus: warning: command line option "-ffreestanding" is valid for C/ObjC
>>but not for C++
>>include/asm/bitops.h: In function ???int find_first_bit(const long unsigned
>>int*,
>>unsigned int)???:
>>include/asm/bitops.h:334: warning: comparison between signed and unsigned
>>integer expressions
>>[...]
>
>
> Whyever is anything calling cc1plus when the file appear to all be .c?
It is vmmon from my vmware-any-any-updates, not from VMware itself. I use
templates from C++ to compile same C code against different structures
(different ABI), so you can use same vmmon module for all VMware's products.
Using templates instead of including same sources with random #define before
looked fine at that time when kernel did not use these additional options and/or
c++ did not complain about them.
Now it seems that I should return back to compiling same sources with different
#defines as it seems impossible to get rid of these warnings without declaring
own rules... (and with g++ 4.0 it now even emits incorrect warnings about using
uninitialized struct members, which is another reason to get rid of c++ compiler
for me).
So if I would be making decision now and not five years ago, I would not pick
c++ templates to do the job.
Petr Vandrovec