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
correctly.

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:

  http://www.myri.com/open-specs/
  http://www.myri.com/myrinet/PCI64/programming.html

  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
    it.  

  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.

Cheers,
Brook

===========================================================================
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,
     which states,

	    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.