236108 - Relicensing Rhino under the MIT license

Status: RESOLVED FIXED

(Rhino Graveyard :: Core, defect)

Description

[Igor Bukanov]

I think this should be resolved once and for all.

Comment 1

[Igor Bukanov]

CC Brendan and Gervase as well:

No matter what would be the outcome of the discussion about APL and other
license schemas, I think at least MPL/LGPL/GPL should be put in place. 

For practical matters I would suggest to finish this work first as gven the
previous experience any too generic question would rsult in nothing done.

So the question is: who should authorise this?

Comment 2

[Brendan Eich [:brendan]]

We're thinking of relicensing under an MIT-X style license, which means there is
no point in multi-licensing under copyleft licenses.  It's a break from
Mozilla's licensing policy to date, but one that we would like to make for
Rhino.  So I don't see any point in fixing this bug as summarized.  Here is a
counterproposal:

Igor, from the emails with Cocoon folks, it sounds like you have no objection to
an MIT-X-style license.  The ASL (not APL, my typo, sorry) is one such and it
fits the bill for Apache projects using Rhino.  I'll follow up with Mitchell to
make sure it's the right license, and wait for agreement here.

Then, we need to get agreement from all the copyright holders, as discussed with
the cocoon folks.  This is work.

Once everyone is agreed, we can morph this bug, make a special case in Mozilla's
licensing policy documents, and get on with relicensing.  Should be soon.

/be

Comment 3

[Igor Bukanov]

Changing title to be more generic to reflect recent discussion.

Comment 4

[Igor Bukanov]

Attachment: List of Rhino contributors from Steven Noels

From Steven Noels email:

On 12 Mar 2004, at 22:57, Brendan Eich wrote:

> Our CVS logs are open and complete (http://www.mozilla.org/cvs.html).
>
> You need to scour the CVS logs, not only for direct checkins, but especially
also for people checking in patches on behalf of others who originated those
patches, but who lacked CVS access.  Gerv (cc'd again) knows about this from
our experience relicensing the bulk of Mozilla's source code, but I don't know
how much time and motivation (if any) he has to help, especially for the Cocoon
tine of the fork.


Folks, before going off to think about administrative procedures (finding real,
current email addresses, how to officially record consent...), I'd like you to
do a brief sanity check of my current email address harvest from the CVS logs.

The format is a bit funny (it's a dump of a Python list), with the first field
containing the to-be-contacted email address, the second one is the guy who
actually committed, and then some administrative data (time of commit and
touched file). Please check attached file if it makes sense. I did automated
scanning for email addresses - I hope I catched most if not all. There's a few
duplicates and false hits in the list as well.

A quick look shows me that about 45 people should be contacted, which still
seems feasible.

On the code-side, some small progress has already been made in assembling a
task force for recruting JavaScript engine hackers. Batik, another ASF project
which uses Rhino (the official version, that is, not our fork) might be
interested in the same relicensing effort as well, since they would now be
obliged to not include Rhino in their shipping version anymore, and only refer
to it in their documentation. So even if the code reintegration is a bit slow
in the beginning, there's an incentive for both the Cocoon and Batik project to
have an ASF-shippable, MIT/X-licensed Rhino in the future.

Oh, in order to cut down on the recipient list: I'd like to have some main
contact on the Mozilla side, and am happy to keep others posted if they want -
just tell me who and what.

Comment 5

[Igor Bukanov]

(In reply to comment #2)
> Igor, from the emails with Cocoon folks, it sounds like you have no objection to
> an MIT-X-style license.  The ASL (not APL, my typo, sorry) is one such and it
> fits the bill for Apache projects using Rhino.  I'll follow up with Mitchell to
> make sure it's the right license, and wait for agreement here.

Yes, I have no objections and any of my contributions to Rhino can be relicensed
under MIT-X-style license. 

Now what exactly should it be? 

Comment 6

[Steven Noels]

(In reply to comment #5)
> (In reply to comment #2)
> Yes, I have no objections and any of my contributions to Rhino can be relicensed
> under MIT-X-style license. 
> 
> Now what exactly should it be? 

Igor, IIUC Brendan suggest a relicensing to ASL2.0, but wants to check with Mitchel. If he's OK with that, 
I'll proceed with putting up some page where people can check they effectively contributed to Rhino in 
the past, and post their (dis)agreement - possibly as a comment on this entry. Seems like Bugzilla is an 
appropriate way to record votes.

Comment 7

[Norris Boyd]

I looked through the attachment and I know some multiple emails are all due to
single people:

Kurt Westerfeld: '[e-mail]', '[e-mail]',
'[e-mail]', '[e-mail]', '[e-mail]',
'[e-mail]'

Norris Boyd: '[e-mail]', '[e-mail]'

Steven Lobo: '[e-mail]', '[e-mail]'

Igor Bukanov: '[e-mail]', '[e-mail]', '[e-mail]'

I'm fine with the relicensing scheme. 

Comment 8

[Igor Bukanov]

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #2)
> > Yes, I have no objections and any of my contributions to Rhino can be relicensed
> > under MIT-X-style license. 
> > 
> > Now what exactly should it be? 
> 
> Igor, IIUC Brendan suggest a relicensing to ASL2.0, but wants to check with
Mitchel. 

Sorry but I got another impression: the idea is to have MIT-X-style license
which is compatible with MPL/GPL/LGPL/APL. Since APL 2 is not compatible with
GPL (well, according to FSF and I prefer to trust FSF is that area), the license
can not be APL 2.0. 

Comment 9

[Gervase Markham [:gerv]]

According to:
http://www.gnu.org/philosophy/license-list.html
- the ASL 1.0 is incompatible with the GPL due to its advertising clause
- the ASL 1.1 is incompatible with the GPL
- the ASL 2.0 is incompatible with the GPL due to the patent clauses

Therefore, none of these licenses have the four-way compatibility we seek.

It is true that the ASF claims the ASL 2.0 is compatible with the GPL; however,
it's the copyright owner of the GPLed code who has (potential) standing to sue,
whoever they may be. As this issue is unclear, relicensing under the ASL 2.0 is
probably not the best choice.

If we want compatibility with MPL, GPL, LGPL and ASL, I would suggest the
traditional MIT license:
http://www.opensource.org/licenses/mit-license.php

It has the advantage of compatibility, being a well-known name (saying "X
license" these days can be confusing due to the recent XFree86 1.1 license
issue), and simplicity.

Gerv

Comment 10

[Gervase Markham [:gerv]]

Mechanism.

It is not sufficient to email all the people who have checked into the codebase.
You need to take into account:

- Copyright in some of those people's contributions may be owned by their
employer or employers during the time they contributed. Their employers
therefore need to give permission.
- Others without checkin access will have contributed; they may or may not be
mentioned in checkin comments. They will be mentioned in bugs.

Gathering the list of people to ask is a time-consuming task.

You then need to put together an email, and send it out. Collect the bounces,
and try and find new email addresses for those people. Deal with the replies,
and keep track of who hasn't got back to you. Chase them up, over months if
necessary. 

Once you have a hard core of uncontactables, you have to evaluate their
contributions by reading old bugs and patches, and see if it's still possible to
go ahead, and how much code you have to rewrite.

You do have one trump card. If the code is under the NPL or a license including
the NPL, the Mozilla Foundation can relicense it by decree, without a need for
permission. You need to decide whether you want to do that, and risk annoying
people, or ask and risk getting a No.

And, before you ask, I am happy to advise as necessary, but I would like to
finish one relicensing project (Mozilla) before starting another one. :-)

Gerv

Comment 11

[Brendan Eich [:brendan]]

Now that I review email, I see that Brian Behlendorf did suggest MIT; probably I
confused things by suggesting ASL.  Thanks, Gerv.

If http://www.opensource.org/licenses/mit-license.php is agreeable (need
Mitchell here, her agreement is necessary), then we can settle this issue and
approach the remaining copyright holders.

/be

Comment 12

[Mitchell Baker]

Yes, the MIT license does seem a good choice.  Looks OK to me.

mitchell

Comment 13

[Steven Noels]

(In reply to comment #12)
> Yes, the MIT license does seem a good choice.  Looks OK to me.

Great. Then I propose to go further down the road, contacting people and asking for a relicensing of 
their contributions to MIT. Thanks!

Comment 14

[Igor Bukanov]

Changing the title: I assume that there is agreement to change Rhino license to
http://www.opensource.org/licenses/mit-license.php

Now how it should be done practically? Assuming that copyright holders for a
particular file agrees to chnage the license, should the license header be
changed to the MIT license? But how then the the current copyright holder and
contributor information should be altered to fit MIT style? And since the
license text is itself copyrighted, how should it be properly included?

Comment 15

[Steven Noels]

(In reply to comment #14)

> But how then the the current copyright holder and
> contributor information should be altered to fit MIT style?

IIUC, they should be preserved.

Just fyi: ASF licensing & (c) works slightly different. Contributors are required to sign a license 
agreement that makes sure their contributions become (c) ASF. We have a NOTICE or CREDITS file to 
capture names of contributing entities which want to be credited explicitely.

I don't know whether obtaining such an agreement from the old Rhino contributors should be part of 
this relicensing operation, requiring contributors to "give up" (c) to the Mozilla Foundation. This of 
course would make future license changes a lot easier - but I understand that's not how Mozilla works.

> And since the
> license text is itself copyrighted, how should it be properly included?

---------------

Copyright (c) ???? <names of current copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and 
associated documentation files (the "Software"), to deal in the Software without restriction, including 
without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 
copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to 
the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial 
portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR 
PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE 
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT 
OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR 
OTHER DEALINGS IN THE SOFTWARE.

--------

We might add some reference to that, stating the license is "the MIT license".

Thoughts?

Comment 16

[Gervase Markham [:gerv]]

The license text isn't really itself copyrighted. The copyright line is for you
to add the names of those who own the copyright on the software.

We could ask for copyright attribution at the same time - but it's an
administrative hurdle, and we'd have to keep doing so going forward. It also
might hold up the process, particularly if people have moved employers. Whether
we do this or not is probably up to the person doing all the hard work :-)

BTW, please don't anyone start contacting anyone until we've drawn up a plan of
action. :-) 

Gerv

Comment 17

[Gervase Markham [:gerv]]

So Steven, are you willing to take a lead on this? Someone has to :-)

Gerv

Comment 18

[Steven Noels]

(In reply to comment #17)

> So Steven, are you willing to take a lead on this? Someone has to :-)

Sure thing, Gerv, just had some busy days. Let me try and figure out some plan in the next few days.

Comment 19

[Morten Moeller]

Just to ask, what exactly (if any) does this proposed lisence change do for
commercial usage of Rhino?

Comment 20

[Brendan Eich [:brendan]]

> Just to ask, what exactly (if any) does this proposed license change do for
> commercial usage of Rhino?

It removes requirements on the licensee, to the point where you have only to
preserve the copyright and license notices in the source files.

/be

Comment 21

[Gervase Markham [:gerv]]

Steven: ping? ;-)

Gerv

Comment 22

[Igor Bukanov]

Ping and ricing the original issue one more time due to yet another comming
Rhino release:

> No matter what would be the outcome of the discussion about APL and other
> license schemas, I think at least MPL/LGPL/GPL should be put in place. 
> 
> For practical matters I would suggest to finish this work first as gven the
> previous experience any too generic question would rsult in nothing done.
> 
> So the question is: who should authorise this?

Due to the nature of NPL As discussed above mozilla.org can relicense
NPL-licensed files under MPL/LGPL/GPL trio and since it was done for the browser
codebase without asking contributors is it possible to apply such treatment to
Rhino sources? And who should say the final answer for this?

Comment 23

[Gervase Markham [:gerv]]

Igor: yes, that's true. However, when adding the GPL and LGPL to the MPL, it was
in some ways less contentious because we were not reducing the amount of
copyleft protection on the files. Using an MIT-based license would be reducing
the copyleft, which some contributors may not like. Therefore, you should
probably make sure you have support among major Rhino contributors before making
this move (you may already have this.)

The final say probably officially comes from Mitchell but if the module owners
are all in agreement, you have a broad base of support, and given comment 12,
you should just go ahead with an MIT-like license.

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

Gerv

Comment 24

[Igor Bukanov]

(In reply to comment #23)
> Igor: yes, that's true. However, when adding the GPL and LGPL to the MPL, it was
> in some ways less contentious because we were not reducing the amount of
> copyleft protection on the files. Using an MIT-based license would be reducing
> the copyleft, which some contributors may not like. Therefore, you should
> probably make sure you have support among major Rhino contributors before making
> this move (you may already have this.)

I guess I was not clear in my last comment: I simply suggest to replace NPL/GPL
by MPL/LGPL/GPL tripple in all Rhino sources that carry one and fix license info
in Rhino documentation. 

At this point I simply do not care about MIT license switch: if somebody is
willing to do that, it is very welcome, but for me the ability to redestribute
Rhino under LGPL is useful for some particular reasons.

So I repeat the question:

Is it OK to replace NPL/GPL by MPL/LGPL/GPL tripple in all Rhino sources that
carry such notice in the same way as it was done for the browser code base???

AFAICS it could not hamper the switch to MIT licsense later since all files with
NPL/GPL duo are copyrighted by Netscape so after the switch mozilla.org IMO can
still change the license at will.

Comment 25

[Gervase Markham [:gerv]]

> AFAICS it could not hamper the switch to MIT licsense later since all files 
> with NPL/GPL duo are copyrighted by Netscape so after the switch mozilla.org 
> IMO can still change the license at will.

mozilla.org has not, as far as I am aware, had Netscape's copyrights assigned to
it, so this doesn't work. Even if it had, Netscape only retains copyright on the
parts of the code it wrote - if I insert ten lines into a file that says "(C)
Netscape" at the top, the copyright on those ten lines is still mine, not
Netscape's.

So, switching Rhino to an MPL-based tri-license would in effect fork it, because
if we wanted to MIT-license it, we could only do so for the last version that
was NPLed, and not for the latest version. Either that, or request permission
from every contributor who contributed after the change to the tri-license.

The correct thing to do is for the Rhino module owners to choose a license
(which I believe they have; the MIT one), make sure (in this case) that the
major players are onside, and then relicense the code once and for all.

Igor: does your urgency translate into being able to provide manpower for this
process?

Gerv

Comment 26

[Igor Bukanov]

(In reply to comment #25)
> > AFAICS it could not hamper the switch to MIT licsense later since all files 
> > with NPL/GPL duo are copyrighted by Netscape so after the switch mozilla.org 
> > IMO can still change the license at will.
> 
> mozilla.org has not, as far as I am aware, had Netscape's copyrights assigned to
> it, so this doesn't work. Even if it had, Netscape only retains copyright on the
> parts of the code it wrote - if I insert ten lines into a file that says "(C)
> Netscape" at the top, the copyright on those ten lines is still mine, not
> Netscape's.
> 
> So, switching Rhino to an MPL-based tri-license would in effect fork it, because
> if we wanted to MIT-license it, we could only do so for the last version that
> was NPLed, and not for the latest version. Either that, or request permission
> from every contributor who contributed after the change to the tri-license.

I see. But then here is my understanding of the situation.

1. If a file contains NPL notice, then mozilla.org can at will change its
license to anything. 

2. Using such power to change the license from NPL/GPL into MPL/GPL/LGPL trio is
OK since it does not change the spirit of the license.

3. It is not OK despite the legal possibility to change the license to MIT one
unless ALL the contributors to a particular file agree about it since it does
change the essence of the license significantly.

But then I do not see how changing NPL/GPL into MPL/GPL/LGPL now would hamper
the the relicensing later under MIT license. If the intention is to get the
agreement from all contributors in any case, then additional license step in
between should not matter, right?

> Igor: does your urgency translate into being able to provide manpower for this
> process?

No: as I wrote I do not care about MIT license for Rhino. It is useful to have
LGPL option for me since it would simplify packaging of Rhino together with LGPL
code in a comercial product. 

MIT license, of cause, would simplify the packaging even more but I do not see
how it would ever happen.

Comment 27

[Gervase Markham [:gerv]]

> 3. It is not OK despite the legal possibility to change the license to MIT one
> unless ALL the contributors to a particular file agree about it since it does
> change the essence of the license significantly.

That's not quite right. It's legally fine to change the license; my _advice_ to
the maintainers of Rhino would be, to avoid splitting their community and losing
contributions or getting damaging PR, to make sure all they key contributors are
happy first. 

However, if the Rhino module owner does not want to do that, we can go ahead and
change straight to MIT without it.

Gerv

Comment 28

[Igor Bukanov]

I attach recent mails for records:

-------- Original Message --------
Subject: Re: [Fwd: Re: Licensing Question]
Date: Fri, 27 Aug 2004 09:42:40 +0200
From: Steven Noels <[e-mail]>
To: Mitchell Baker <[e-mail]>,	Brendan Eich <[e-mail]>, Igor
Bukanov <[e-mail]>,	shaver <[e-mail]>, Brian Behlendorf
<[e-mail]>,	[e-mail]
CC: Cocoon PMC List <[e-mail]>
References: <[e-mail]> <[e-mail]>
<[e-mail]> <[e-mail]>
<[e-mail]>

On 27 Aug 2004, at 00:06, Gervase Markham wrote:

> Brian Behlendorf wrote:
>> ISTR the problem was that to relicense, we needed to track down all 
>> prior contributors and ask them to approve a relicense.
>
> That's not actually true. See the position outlined in the bug.
> http://bugzilla.mozilla.org/show_bug.cgi?id=236108
>
> I said:
>
> "That's not quite right. It's legally fine [due to the code being 
> NPLed] to change the license; my _advice_ to the maintainers of Rhino 
> would be, to avoid splitting their community and losing contributions 
> or getting damaging PR, to make sure all they key contributors are 
> happy first.
>
> However, if the Rhino module owner does not want to do that, we can go 
> ahead and change straight to MIT without it."
>
> So as far as I'm concerned, we're awaiting a decision from the Rhino 
> module owner (I'm not actually sure who that is) on this question. If 
> they say they have all the people they care about on-side, we can go 
> ahead and relicense. I can provide tools for that, and it's a mostly 
> automated job.

This change of plans has been added a few weeks ago, and I figure this 
could be helpful, *if* the reintegration issue is tackled as well - 
which is still to be doubted upon.

Frankly, the reason why I didn't pursue further efforts wrt. contacting 
original contributors (and their eventual employers) was partly because 
of a serious lack of time on my behalf, even though I did produce a 
list of all email addresses to be contacted from Rhino's CVS log 
history 
(http://bugzilla.mozilla.org/attachment.cgi?id=144038&action=view).

Also, even though Gerv repeatedly offered his kind assistance with the 
process of contacting the original copyright owners, comments like 
http://bugzilla.mozilla.org/show_bug.cgi?id=236108#c26 left me wary on 
the eventual success of such an effort.

On the issue of reintegration, I think I can safely state that no such 
effort is currently underway, and that this isn't likely to happen any 
time soon - due to the complexity of the effort, the effect that Rhino 
itself has moved on since then, and that a few alternatives for the 
library's functions are starting to appear in other venues 
(non-JavaScript-based continuations). However, the Rhino fork is still 
in heavy use by many Cocoon users - not all of them interested in doing 
pure Java-based continuations nor in pursuing Groovy-based 
continuations ATM.

While the issue of having a fork around is not to be applauded upon, 
having a MIT-licensed Rhino would at the very least still legalize the 
situation, in the sense that we might then be able to safely import our 
fork into ASF CVS and work from there. However, I assume the 
relicensing would happen for the current version of Rhino, which is not 
the version the fork has been based upon, and I'm pretty sure 
relicensing can't go back in time.

<off-topic>Optimistically thinking, and proposing something which has 
been commented upon already earlier, the chances for more people 
working on Rhino, and perhaps offering continuations support in the 
official version so that our fork becomes obsolete, might increase if, 
facilitated partly through the MIT-relicensing, Rhino would become part 
of the bigger and more Java-centric development community of 
Apache.</off-topic>

Ah: I see Norris isn't on the recipients list - shouldn't he be made 
aware of what we are conversing about?

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source Java & XML            An Orixo Member
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org

Comment 29

[Igor Bukanov]

For the records:

-------- Original Message --------
Subject: Re: Rhino Licensing Question
Date: Fri, 27 Aug 2004 08:49:18 -0400
From: Norris Boyd <[e-mail]>
To: Igor Bukanov <[e-mail]>
CC: Steven Noels <[e-mail]>,	Mitchell Baker
<[e-mail]>,	Brendan Eich <[e-mail]>, shaver
<[e-mail]>,	Brian Behlendorf <[e-mail]>, [e-mail],
Cocoon PMC List <[e-mail]>
References: <[e-mail]> <[e-mail]>
<[e-mail]> <[e-mail]>
<[e-mail]>
<[e-mail]>
<[e-mail]>

Yes, I'd agree to change the license of Rhino source files with NPL/GPL 
license header to MIT-style license without contracting all the 
contributors.

I don't know the legal ins and outs, but seems like we'd need the 
approval of someone from the Mozilla foundation who presumably inherited 
the legal rights associated with being the "Initial Developer" from 
Netscape/AOL/Time Warner.

--N

Igor Bukanov wrote:

> Hi, Norris!
>
> The issue about Rhino license 
> (http://bugzilla.mozilla.org/show_bug.cgi?id=236108) was resurrected 
> once again so I include you on on the list.
>
> Now the question is would you agree to change license of Rhino source 
> files that have NPL/GPL license header to MIT-style license without 
> contacting all the contributors?
>
> But I will ask John Schneider from AgileDelta if he would accept that 
> for E4X contribution.
>
> Regards, Igor
>
>
> Steven Noels wrote:
>
>> On 27 Aug 2004, at 00:06, Gervase Markham wrote:
>>
>>> Brian Behlendorf wrote:
>>>
>>>> ISTR the problem was that to relicense, we needed to track down all 
>>>> prior contributors and ask them to approve a relicense.
>>>
>>>
>>>
>>> That's not actually true. See the position outlined in the bug.
>>> http://bugzilla.mozilla.org/show_bug.cgi?id=236108
>>>
>>> I said:
>>>
>>> "That's not quite right. It's legally fine [due to the code being 
>>> NPLed] to change the license; my _advice_ to the maintainers of 
>>> Rhino would be, to avoid splitting their community and losing 
>>> contributions or getting damaging PR, to make sure all they key 
>>> contributors are happy first.
>>>
>>> However, if the Rhino module owner does not want to do that, we can 
>>> go ahead and change straight to MIT without it."
>>>
>>> So as far as I'm concerned, we're awaiting a decision from the Rhino 
>>> module owner (I'm not actually sure who that is) on this question. 
>>> If they say they have all the people they care about on-side, we can 
>>> go ahead and relicense. I can provide tools for that, and it's a 
>>> mostly automated job.
>>
>>
>>
>> This change of plans has been added a few weeks ago, and I figure 
>> this could be helpful, *if* the reintegration issue is tackled as 
>> well - which is still to be doubted upon.
>>
>> Frankly, the reason why I didn't pursue further efforts wrt. 
>> contacting original contributors (and their eventual employers) was 
>> partly because of a serious lack of time on my behalf, even though I 
>> did produce a list of all email addresses to be contacted from 
>> Rhino's CVS log history 
>> (http://bugzilla.mozilla.org/attachment.cgi?id=144038&action=view).
>>
>> Also, even though Gerv repeatedly offered his kind assistance with 
>> the process of contacting the original copyright owners, comments 
>> like http://bugzilla.mozilla.org/show_bug.cgi?id=236108#c26 left me 
>> wary on the eventual success of such an effort.
>>
>> On the issue of reintegration, I think I can safely state that no 
>> such effort is currently underway, and that this isn't likely to 
>> happen any time soon - due to the complexity of the effort, the 
>> effect that Rhino itself has moved on since then, and that a few 
>> alternatives for the library's functions are starting to appear in 
>> other venues (non-JavaScript-based continuations). However, the Rhino 
>> fork is still in heavy use by many Cocoon users - not all of them 
>> interested in doing pure Java-based continuations nor in pursuing 
>> Groovy-based continuations ATM.
>>
>> While the issue of having a fork around is not to be applauded upon, 
>> having a MIT-licensed Rhino would at the very least still legalize 
>> the situation, in the sense that we might then be able to safely 
>> import our fork into ASF CVS and work from there. However, I assume 
>> the relicensing would happen for the current version of Rhino, which 
>> is not the version the fork has been based upon, and I'm pretty sure 
>> relicensing can't go back in time.
>>
>> <off-topic>Optimistically thinking, and proposing something which has 
>> been commented upon already earlier, the chances for more people 
>> working on Rhino, and perhaps offering continuations support in the 
>> official version so that our fork becomes obsolete, might increase 
>> if, facilitated partly through the MIT-relicensing, Rhino would 
>> become part of the bigger and more Java-centric development community 
>> of Apache.</off-topic>
>>
>> Ah: I see Norris isn't on the recipients list - shouldn't he be made 
>> aware of what we are conversing about?
>>
>> </Steven>
>
>

Comment 30

[Gervase Markham [:gerv]]

Replying to Norris' email (which, for some reason, I didn't get as an email):

It's not about who is the Initial Developer, it's about who has a right to
arbitrarily relicense NPLed code. The Foundation inherited this right from
Netscape, and we are happy to use it in this case to relicense Rhino under the
MIT license.

If your statement "I'd agree to change the license.. to MIT-style license
without contracting all the contributors" is the voice of all the Rhino module
owners (still, no-one has told me who they are and how many), then we can go ahead.

The person who wishes to do the work should contact me by email for
instructions, tips and scripts.

Gerv

Comment 31

[Mitchell Baker]

I'm not sure Gerv is right about this.  I want to look at the actual language
about what we can do with code.  I'm just back from vacaton this evening and
don't have the documents in front of me.  My recollection is that the Mozilla
Foundation has the right to use the previously NPL'd code under the MPL and of
course to change the terms of the MPL.  But I don't recall anything that says
that Netscape's special rights under the NPL are somehow transferred to the
Mozilla Foundation.  

I think this is what Gerv is saying.  Gerv, please correct me if you are saying
something else.  

Mitchell 

Comment 32

[Gervase Markham [:gerv]]

I've emailed Mitchell to clarify the situation.

Gerv

Comment 33

[Igor Bukanov]

(In reply to comment #32)
> I've emailed Mitchell to clarify the situation.
> 
> Gerv

Grev, did you get any information regarding the license issues?

Comment 34

[Igor Bukanov]

(In reply to comment #32)
> I've emailed Mitchell to clarify the situation.
> 
> Gerv

Gerv, did you get any information regarding the license issues?

Comment 35

[Gervase Markham [:gerv]]

Mitchell is of the view that the special NPL relicensing ability remains with
Netscape. Netscape started a relicensing project for the Mozilla code - the
question is whether that included Rhino or not. It's rather hard to say, as
Mitchell doesn't have all her old records any more. 

On 29/08 she said she'd have a look; I haven't heard back since. I'm not
surprised - it's one of those open-ended jobs that never reaches the top of the
list ;-)

Perhaps it would be best to assume that we need to seek permission from
everyone. That's not necessarily as arduous as task as you might think. If
someone still has the cycles to take this forward, they should email me to
discuss it. We can at least work out the size of the problem.

Gerv

Comment 36

[Igor Bukanov]

(In reply to comment #35)

> Perhaps it would be best to assume that we need to seek permission from
> everyone. That's not necessarily as arduous as task as you might think. If
> someone still has the cycles to take this forward, they should email me to
> discuss it. We can at least work out the size of the problem.

But before any such process can start I think it is necessary to reach the
conclusion on the following issues:

1. Should the license change happen once for all files or is it OK to have a
mixture? 

2. Exact license policy for the new source files and how the future
contributions to them has to be handled.

3. License policy for contributions to the current sources with NPL/GPL headers.
I.e. how exactly that has to be marked and documented?

If there is a conclusion on these issue I can add that to Rhino documentation
and refer interested folks to it. 

Comment 37

[Gervase Markham [:gerv]]

IMO:

> 1. Should the license change happen once for all files or is it OK to have a
> mixture? 

Once for all. A mixture will just confuse.

> 2. Exact license policy for the new source files and how the future
> contributions to them has to be handled.

Future contributions under the same licence. What else needs deciding?

> 3. License policy for contributions to the current sources with NPL/GPL 
> headers. I.e. how exactly that has to be marked and documented?

I don't understand the question.

Gerv

Comment 38

[Igor Bukanov]

(In reply to comment #37)
> IMO:
> 
> > 1. Should the license change happen once for all files or is it OK to have a
> > mixture? 
> 
> Once for all. A mixture will just confuse.

But what if it would take many months to contact all contributors? And what if
someone just say no for a small patch? 

> 
> > 2. Exact license policy for the new source files and how the future
> > contributions to them has to be handled.
> 
> Future contributions under the same licence. What else needs deciding?

MPL pages at mozilla.org describe the procedure how the contribution should be
marked like "Conributors" section in the license header etc.. I guess MIT
license instructions can follow the same rules, right?

> 
> > 3. License policy for contributions to the current sources with NPL/GPL 
> > headers. I.e. how exactly that has to be marked and documented?
> 
> I don't understand the question.

The question is what should happen if during process of contacting contribors
for some file someone submit a patch against the file? Should a separated MIT
section be added to the file or is it enough top state in a documentation that
all contributions from the moment X are under MIT license?

Igor

Comment 39

[Gervase Markham [:gerv]]

> But what if it would take many months to contact all contributors? And what if
> someone just say no for a small patch? 

The trick here is to change your checkin policy to say "people contributing code
must consent to a future relicensing." This freezes the problem at its current size.

> > Future contributions under the same licence. What else needs deciding?
> 
> MPL pages at mozilla.org describe the procedure how the contribution should be
> marked like "Conributors" section in the license header etc.. I guess MIT
> license instructions can follow the same rules, right?

Actually, the MIT license header doesn't have a Contributors section.

> The question is what should happen if during process of contacting contribors
> for some file someone submit a patch against the file?

See above :-)

Gerv

Comment 40

[Zac Bowling]

What came of this? its been over a year or two since this was a topic?

Comment 41

[Gervase Markham [:gerv]]

From a practical point of view, the situation is that someone needs to step up and volunteer to take the time to do the work. I'd be happy to advise them as how to proceed.

Gerv

Comment 42

[Antonio Gallardo]

Perhaps we should close this issue. Rhino 1.6R5 was released on 2006-11-19 under MPL 1.1 which is compatible with Apache License. See:

http://www.mozilla.org/rhino/download.html

Comment 43

[Norris Boyd]

Agreed. 

Comment 44

[Norris Boyd]

Adding target milestone of 1.6R6 based on the date this bug was resolved FIXED.

Comment 45

[Norris Boyd]

This should be marked 1.6R5.