Subject: RE: For Approval: Broad Institute Public License (BIPL)
From: "Lawrence Rosen" <lrosen@rosenlaw.com>
Date: Fri, 14 Jul 2006 08:46:45 -0700
Fri, 14 Jul 2006 08:46:45 -0700
Karen Rivard wrote:

2.  There is a lack of parity in treatment of the Originator of the code and
future contributors to the code.  This is true.  MIT will not offer the
patent license; however, the requirement on contributors was an attempt to
procure for users as many "freedom to use" rights as possible.  If this
disparity in treatment is so abhorrent to OSI, it is easily remedied.  MIT
will delete from the BIPL all references to any patent grants from
contributors.  Thus the BIPL will simply be another open source license that
is silent on patent rights.



That would be an unfortunate solution to a real problem. Going backwards
into history to emulate licenses that ignore patents entirely will leave the
community even more uncertain in today's patent-filled world than they would
be WITH your license. As John Cowan points out, many people hope that the
old BSD- and MIT-style licenses have "implicit patent licenses," but that's
a thin reed from which to build a basket that's to hold valuable software.
All modern, professionally-written open source licenses, including the
proposed new GPLv3, contain explicit patent grants.

 

You may not be able to put the genie back in the bottle. You have announced
to everyone here that MIT (probably) has patents that you won't license with
your software, and that the university or others may come after users if we
use your software. If you leave out a patent grant entirely, that will make
not only your license, but your software, very risky. I am aware of no
modern, large open source project that would accept your contributions under
such terms.

 

I also want to point out that MIT's situation as a large, diverse
institution where no one person knows everything that others are inventing,
is not that unique. IBM, Sun, HP, Apple, etc., are also large institutions,
and they all have dealt with this problem in some fashion. I also note that
W3C, hosted at MIT and with close ties to the inventive community at MIT,
has also solved this problem in its patent policy, not by ignoring patents,
but by committing its members to license patents when necessary to practice
industry standards. 

 

As Russ Nelson suggested, maybe MIT can make a more valiant attempt to solve
this patent problem, rather than passing it on to users to deal with in the
absence of patent information that only MIT has at its disposal. Other
universities and their technology licensing departments are trying to
address this problem in a more comprehensive way. Perhaps MIT can help us
create a better solution than a license that places risky software into the
stream of commerce.

 

/Larry Rosen

 

Lawrence Rosen

Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)

Stanford University, Lecturer in Law

3001 King Ranch Road, Ukiah, CA 95482

707-485-1242  *  fax: 707-485-1243

Author of "Open Source Licensing: Software Freedom and 

                Intellectual Property Law" (Prentice Hall 2004)

  _____  

From: Karin Rivard [mailto:rivard@MIT.EDU] 
Sent: Friday, July 14, 2006 7:43 AM
To: license-discuss@opensource.org
Cc: Rory Pheiffer
Subject: Re: For Approval: Broad Institute Public License (BIPL)

 

Dear BIPL Discussion Group:

I am writing on behalf of MIT.  It's not clear to me if this is how the
process works, but the group has raised a few issues on which I would like
to comment.

It appears from discussion that there are three concerns raised about the
BIPL license:

1.  MIT does not explicitly license MIT-owned patent rights that might cover
the open source software. 
2.  The license isn't fair because the BIPL requires "contributors" to
license their patent rights that cover their contributions, while MIT does
not do the same. 
3.  The license is unlikely to be "used."

Here are my comments:

1.  The requirements for OSI certification do not include a requirement that
the originator of the software offer a license to originator owned patents.
As has been pointed out in the discussion group, MIT's position  on not
offering a patent license in the BIPL is consistent with the GPL, the BSD
license, the MIT license, the Educational Community License, and others.

2.  There is a lack of parity in treatment of the Originator of the code and
future contributors to the code.  This is true.  MIT will not offer the
patent license; however, the requirement on contributors was an attempt to
procure for users as many "freedom to use" rights as possible.  If this
disparity in treatment is so abhorrent to OSI, it is easily remedied.  MIT
will delete from the BIPL all references to any patent grants from
contributors.  Thus the BIPL will simply be another open source license that
is silent on patent rights.

3.  I do not understand the last comment from the list.  The software is
what is used.  The license is the mechanism by which the software is used.
If no one contributes to the development of the software because they do not
like the license terms, that is ok.  The fact remains that the software
remains freely and openly available for use by the public, which I thought
was the goal.  Further, "use" or "usability" is not one of factors that is
stated as a requirement for OSI approval.  

General comment:  MIT's BIPL license, as submitted, complies with each and
every factor listed on the OSI site for achieving approval.  Nevertheless,
if the approval committee demands parity of treatment among MIT and the
contributors, MIT will delete all references to patent licenses in the BIPL.
If this remedy is acceptable to OSI in order to achieve approval, please let
me know and the change will be made.

Thank you.
Karin Rivard



__________________________________________________
Karin K. Rivard, Asst. Director and Counsel
MIT Technology Licensing Office, Room NE25-230
Five Cambridge Center, Kendall Square
Cambridge, MA 02142
Phone:  (617) 253-6966; Fax: (617) 258-6790
Email:  rivard@mit.edu



Karen Rivard wrote:

2.  There is a lack of parity in treatment of the Originator of the code and future contributors to the code.  This is true.  MIT will not offer the patent license; however, the requirement on contributors was an attempt to procure for users as many "freedom to use" rights as possible.  If this disparity in treatment is so abhorrent to OSI, it is easily remedied.  MIT will delete from the BIPL all references to any patent grants from contributors.  Thus the BIPL will simply be another open source license that is silent on patent rights.

That would be an unfortunate solution to a real problem. Going backwards into history to emulate licenses that ignore patents entirely will leave the community even more uncertain in today's patent-filled world than they would be WITH your license. As John Cowan points out, many people hope that the old BSD- and MIT-style licenses have "implicit patent licenses," but that's a thin reed from which to build a basket that's to hold valuable software. All modern, professionally-written open source licenses, including the proposed new GPLv3, contain explicit patent grants.

 

You may not be able to put the genie back in the bottle. You have announced to everyone here that MIT (probably) has patents that you won't license with your software, and that the university or others may come after users if we use your software. If you leave out a patent grant entirely, that will make not only your license, but your software, very risky. I am aware of no modern, large open source project that would accept your contributions under such terms.

 

I also want to point out that MIT's situation as a large, diverse institution where no one person knows everything that others are inventing, is not that unique. IBM, Sun, HP, Apple, etc., are also large institutions, and they all have dealt with this problem in some fashion. I also note that W3C, hosted at MIT and with close ties to the inventive community at MIT, has also solved this problem in its patent policy, not by ignoring patents, but by committing its members to license patents when necessary to practice industry standards.

 

As Russ Nelson suggested, maybe MIT can make a more valiant attempt to solve this patent problem, rather than passing it on to users to deal with in the absence of patent information that only MIT has at its disposal. Other universities and their technology licensing departments are trying to address this problem in a more comprehensive way. Perhaps MIT can help us create a better solution than a license that places risky software into the stream of commerce.

 

/Larry Rosen

 

Lawrence Rosen

Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)

Stanford University, Lecturer in Law

3001 King Ranch Road, Ukiah, CA 95482

707-485-1242  *  fax: 707-485-1243

Author of "Open Source Licensing: Software Freedom and

                Intellectual Property Law" (Prentice Hall 2004)


From: Karin Rivard [mailto:rivard@MIT.EDU]
Sent: Friday, July 14, 2006 7:43 AM
To: license-discuss@opensource.org
Cc: Rory Pheiffer
Subject: Re: For Approval: Broad Institute Public License (BIPL)

 

Dear BIPL Discussion Group:

I am writing on behalf of MIT.  It's not clear to me if this is how the process works, but the group has raised a few issues on which I would like to comment.

It appears from discussion that there are three concerns raised about the BIPL license:

1.  MIT does not explicitly license MIT-owned patent rights that might cover the open source software.
2.  The license isn't fair because the BIPL requires "contributors" to license their patent rights that cover their contributions, while MIT does not do the same.
3.  The license is unlikely to be "used."

Here are my comments:

1.  The requirements for OSI certification do not include a requirement that the originator of the software offer a license to originator owned patents.  As has been pointed out in the discussion group, MIT's position  on not offering a patent license in the BIPL is consistent with the GPL, the BSD license, the MIT license, the Educational Community License, and others.

2.  There is a lack of parity in treatment of the Originator of the code and future contributors to the code.  This is true.  MIT will not offer the patent license; however, the requirement on contributors was an attempt to procure for users as many "freedom to use" rights as possible.  If this disparity in treatment is so abhorrent to OSI, it is easily remedied.  MIT will delete from the BIPL all references to any patent grants from contributors.  Thus the BIPL will simply be another open source license that is silent on patent rights.

3.  I do not understand the last comment from the list.  The software is what is used.  The license is the mechanism by which the software is used.  If no one contributes to the development of the software because they do not like the license terms, that is ok.  The fact remains that the software remains freely and openly available for use by the public, which I thought was the goal.  Further, "use" or "usability" is not one of factors that is stated as a requirement for OSI approval. 

General comment:  MIT's BIPL license, as submitted, complies with each and every factor listed on the OSI site for achieving approval.  Nevertheless, if the approval committee demands parity of treatment among MIT and the contributors, MIT will delete all references to patent licenses in the BIPL.  If this remedy is acceptable to OSI in order to achieve approval, please let me know and the change will be made.

Thank you.
Karin Rivard


Karin K. Rivard, Asst. Director and Counsel
MIT Technology Licensing Office, Room NE25-230
Five Cambridge Center, Kendall Square
Cambridge, MA 02142
Phone:  (617) 253-6966; Fax: (617) 258-6790
Email:  rivard@mit.edu