For Approval: Broad Institute Public License (BIPL)

[Ernest Prabhakar]

Hi Karin,

On Jul 14, 2006, at 9:27 AM, Karin Rivard wrote:
> It would be unfortunate if MIT could never receive an OSI approved  
> open source license because of this issue, but I understand that  
> OSI will apply its standards as it sees fit.  MIT can not change  
> its Policy for this one license.

Well, to be precise, MIT already has *one* OSI approved open source  
license. :-)

http://www.opensource.org/licenses/mit-license.php

I guess the question is, why do you want another?  (yes, I realize it  
is different a "you")

It sounds to me as if you *like* the fact that the MPL-style licenses  
provide i) patent protection and ii) mandatory giveback of  
modifications, but you don't want to make similar grants to the  
community.

Whether or not this violates the letter of the OSD, I think the  
various posters are correct that this redaction would be *perceived*  
as deliberate and suspicious by the community.  I realize that your  
policy is the legacy of hard-earned experience, but so is our  
paranoia!   I don't think anyone would be well-served by us approving  
a license under such terms, regardless of the technicalities.

Frankly, I think you would be better off with a "patent-neutral"  
license, where you dodge the question entirely.   The problem, I  
presume, is that you want something like the MPL/IBM licenses which  
require postbacks.  I am not aware of any such license (except the  
GPL, of course) which doesn't have explicit patent statements, but  
maybe somebody here can suggest one.

-- Ernie P.
MIT '88



>>
>> 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.
>
> Agreed.  But solutions take time and policy changes.  MIT's current  
> policy is the result of some past occurrences that were a problem  
> for us.  To change it would mean the possibility of the past  
> problem reoccurring.  The process for change is being looked into,  
> but it takes time.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20060714/bf6a605c/attachment.html>