Subject: Re: myrinet drivers
To: None <email@example.com>
From: None <firstname.lastname@example.org>
Date: 04/21/2003 12:35:31
David Brownlee writes:
> Have you tried asking the original authors if they would be
> willing to re-release all or part of the code under a more
> open licence?
I have now asked Myricom about the possiblity of rereleasing their
drivers under a new license. Their response is that a specific
request should be submitted to them. I am glad to draft a request,
but I would like some guidance to make sure that everything is covered
From the NetBSD perspective, I see the following issues.
- The licensing terms need to be reasonable. Below I have reproduced
the licensing terms and added two slight changes to seek agreement
from Myricom. Are they sufficient for NetBSD?
- There is access to some level of programming information. I believe
that everything needed is available either in the source code or in
one of the following documents:
I suspect that no engineering time would be required on the part of
Myricom, but perhaps someone could peruse this and see if that is
the case. Alternatively, can one expect them to agree to provide
any level of technical support from their engineering team?
- Obtain specific written permission from Myricom to use their name in
promoting the native NetBSD drivers. This should satisfy the
licensing clauses requiring acknowledgment and requiring permission
for use of derived code. Other derivative code (e.g., products that
modify the NetBSD drivers) would need to be covered by their own
permission negotiated with Myricom.
From the Myricom perspective, I see the following issues:
- Avoiding commitment of engineering resources to yet another task.
If their documentation is complete enough, a commitment might not be
required at all.
- Avoiding commitment to support software they have no direct control
over. If this is integrated into the NetBSD kernel, doesn't that
obviate the need for their support (so long as they provide
reasonable technical documentation)? Doesn't the NetBSD team
provide the support for all the drivers in the kernel? Two subcases
exist here, I think.
o One concerns the native NetBSD drivers. Presumably, these could
be fed back to Myricom so they could at least be aware of them and
perhaps integrate them into future versions. (Is it the role of
NetBSD to assist in the integration of their various drivers?)
Any commercial products using NetBSD but not changing the Myrinet
portion could advertise the Myrinet capability, Myricom would be
aware of the drivers, and things would be fine (hopefully).
o The second concerns products that have modified the Myrinet
drivers. I suspect they wish to prevent anyone from advertising
such a product as Myrinet and I'm sure they do not wish to support
Do the licensing clauses below help support this distinction?
Should there be additions to clarify the second case above?
- Interest in enhanced revenue streams. It seems inherently
impossible to suggest a large new revenue stream coming from this
(unless there is a large community unknown to me who would be
inclinded to purchase more hardware if NetBSD supported Myrinet).
How can this point be addressed? Or is it only the case that they
are not really providing anything new, so there is no marginal cost
to this, so there doesn't need to be an identified new revenue
stream? Is that convincing to a commercial enterprise? Another
angle is to remind them of the range of hardware supported by
NetBSD; with NetBSD drivers, they could build Myrinet clusters with
anything containing a PCI bus.
What other issues have I missed?
Anyone with experience composing requests such as this, please let me
know how to make an effective request.
Thanks for your help.
Below is the existing license. I've added a few changes (in caps) to
make it seemingly more in line with the NetBSD license. Are those
changes sufficient to make it acceptable into the kernel? Should the
license be rewritten instead?
* Myricom GM networking software and documentation *
* Copyright (c) 1994-2001 by Myricom, Inc. *
* All rights reserved. *
* Permission to use, copy, modify and distribute this software and its *
* documentation in source and binary forms for non-commercial purposes *
REMOVE "for non-commercial purposes" ABOVE
* and without fee is hereby granted, provided that the modified software *
* is returned to Myricom, Inc. for redistribution. The above copyright *
REMOVE ", provided that ... for redistribution" ABOVE
* notice must appear in all copies. Both the copyright notice and this *
* permission notice must appear in supporting documentation, and any *
* documentation, advertising materials and other materials related to *
* such distribution and use must acknowledge that the software was *
* developed by Myricom, Inc. The name of Myricom, Inc. may not be used *
* to endorse or promote products derived from this software without *
* specific prior written permission. *
* Myricom, Inc. makes no representations about the suitability of this *
* software for any purpose. *
* THIS FILE IS PROVIDED "AS-IS" WITHOUT WARRANTY OF ANY KIND, WHETHER *
* EXPRESSED OR IMPLIED, INCLUDING THE WARRANTY OF MERCHANTABILITY OR *
* FITNESS FOR A PARTICULAR PURPOSE. MYRICOM, INC. SHALL HAVE NO *
* LIABILITY WITH RESPECT TO THE INFRINGEMENT OF COPYRIGHTS, TRADE *
* SECRETS OR ANY PATENTS BY THIS FILE OR ANY PART THEREOF. *
* In no event will Myricom, Inc. be liable for any lost revenue or *
* profits or other special, indirect and consequential damages, even if *
* Myricom has been advised of the possibility of such damages. *
* Other copyrights might apply to parts of this software and are so *
* noted when applicable. *
* Myricom, Inc. *
* 325 N. Santa Anita Ave. *
* Arcadia, CA 91006 *
The "zlib" source is copyright (C) 1995-1996 Jean-loup Gailly and Mark
Adler. See the file "zlib/README" for the copyright notice.
The GM configure scripts were produced by the Gnu Autoconf package and
are redistributed as permitted by that software's documentation,
There are no restrictions on how the configuration scripts that
Autoconf produces may be distributed or used. [...]
Of the other files that might be used with `configure',
`config.h.in' is under whatever copyright you use for your
`configure.in', since it is derived from that file and from the public
domain file `acconfig.h'. `config.sub' and `config.guess' have an
exception to the GPL when they are used with an Autoconf-generated
`configure' script, which permits you to distribute them under the same
terms as the rest of your package. `install-sh' is from the X
Consortium and is not copyrighted.