OSI-approved license that assigns contributor copyright to me

[David Barrett]

(Brian -- Thanks for the excellent comments and I realize I didn't 
scroll far enough in your original reply -- sorry for making you answer 
twice!)

All your comments are great, and further evidence why I don't want to 
write a new OSI license.  My language was overly-restrictive, as you 
clearly pointed out.  My goal isn't to be a code nazi.  Rather, I'm 
looking for the safest way to release my code in an open-source fashion, 
without shooting myself in the foot by complicating possible future 
dual-licensing.

Now I understand that I can use any license (such as GPL) in a 
dual-license fashion so long as I execute individual agreements with 
each contributor to allow it.  But I'd really like to cut out the 
paperwork and have contributors implicitly pre-authorize any future dual 
licensing, *even if* I don't know what the precise terms of that license 
will be right now.


So this discussion is proving tremendously useful in helping me pick 
amongst the existing OSI-approved licenses, and the QPL looks to nearly 
do what I want with the clause:

http://www.opensource.org/licenses/qtpl.php
 > b. When modifications to the Software are released under this
 > license, a non-exclusive royalty-free right is granted to the initial
 > developer of the Software to distribute your modification in future
 > versions of the Software provided such versions remain available
 > under these terms in addition to any other license(s) of the initial
 > developer.

However, the final lines confuse me.  What are the "other license(s)" to 
which this refers?  For example, let's say I maintain two forks of the 
codebase: one that is publicly available under QPL, and the other that 
is proprietary.  What I *think* this is saying is that I can apply QPL 
contributions to both the QPL and proprietary fork, but I can't apply 
QPL contributions to only the proprietary fork.

For example, I can't have a "buggy open-source version" and a "good 
proprietary version" by simply accepting QPL bugfix contributions and 
only applying them to the proprietary fork.

However, I *can* have a "basic open-source version" and a "premium 
proprietary version" by applying all QPL contributions to both forks 
(and proprietary contributions only to the proprietary fork).

Is this correct?  If this is the case, need I explicitly state what the 
"proprietary license" is for QPL to allow this arrangement?  Need the 
proprietary license even be decided at the time of contribution, or can 
I -- as the "initial developer" -- re-release the codebase under any 
license I want, at any time in the future?

Thanks for your help!

-david