OSI-approved license that assigns contributor copyright to me

[Brian C]

Hi David,

The ultimate decision will rest with OSI, but I don't think the sort of
license you propose will be approved as an Open Source license. As I
mentioned before, at the very least a template form would be required
that removed proper names so as to make it reusable. But there are more
fundamental problems below.

David Barrett wrote:
> Alex Bligh wrote:
> 
>> The OVPL is a modern license that does what you want I think. We are
>> in the process of applying for OSI approval. If you think the license
>> should be approved, please drop a note to this list.
>  
> I looked over the OVPL, but it seems larger and more complicated than I
> am looking for.  Rather, I'm looking for a more basic statement that can
> be comprehended by a non-lawyer, while still remaining binding. Here's a
> second draft of essentially what I want:
> 
> 1) The "software" includes all files bearing this license, as well as
>    all files listed in LICENSE.txt.
> 
> 2) The "unmodified form" of the software is the form in which you obtain
>    it directly from David Barrett.

Nothing wrong with defining this in general, but it seems clear you're
doing this because you intend to be the one and only source of
distributions of the software. That's not the way open source software
works. Others need to be free to modify and distribute the software even
in modified form.

> 3) You may use and redistribute the software in its unmodified form.

To be open source software requires more. One must be able to distribute
modified versions.

> 4) You may add to or modify the software so long as you:
>    a. Add this license to each new file, or add the new file to
>       LICENSE.txt.

This is almost OK. This is just copyleft except it kicks in upon mere
modification, whereas every open source license I can think of only
imposes such a constraint upon modification AND distribution. Private
modifications of any sort should be allowed so long as they are not
distributed. Once distributed then the original author can impose a
copyleft condition.

>    b. Leave this license unchanged in all files, and remove no files
>       from LICENSE.txt.

This is partially OK, but seems to suggest that if someone modified the
software such that one previously existing file was no longer needed,
they couldn't remove that file and its mention in LICENSE.txt.

>    c. Assign ownership of the copyright over the newly-added or modified
>       material to David Barrett.

My prior message explained why this might violate OSD #3 and #7 as well
as the practical problems it poses. Also, you don't need this in order
to dual-license your work under an OSI-approved license as well as a
proprietary license. If contributors simply give you a license to their
contribution that permits you to relicense in the ways you want, then
you can operate under a dual-license model.

>    d. Make no addition nor modification including material to which you
>       do not own the copyright, that depends on material outside of the
>       software, or that causes the modified software to infringe upon
>       any intellectual property or licensing rights of any other party.

The last part of this is OK. It's fine to forbid infringement, but the
first parts so limit the sorts of changes that people can make that it
makes the license incompatible with everything else, even including
software by you! That is, if as a developer I can only add my own
original work to your program, then that means even if I have some code
licensed under the BSD which I'm allowed to basically do what I please
with, I can't add it to your program. Why hamstring developers like
this? In fact, if YOU write more than one "software" package then I
can't even combine software from one package (by you!) with another (by
you!) because it would be "material to which [I] do not own the
copyright..." and it would also "depend[] on material outside of the
software..." which is forbidden. Again, this seems to unnecessarily
limit developers.

>    e. Agree in the future to immediately notify David Barrett should you
>       discover or suspect that your modification or addition cannot be
>       licensed under these terms.

This is generally OK, especially for assignment agreements, but as part
of an open source license it doesn't necessarily contravene the OSD, but
it would make the license non-free under the DFSG, as would anything
that requires those who make modifications to notify anyone in
particular. I think the FSF would also say such a term as part of a
license would make the license non-free, based on their comments about
the reciprocal public license:

http://www.fsf.org/licensing/licenses/license-list.html

> 5) You may redistribute the software in its modified form so long as:
>    a. You first submit your modifications to David Barrett.

Same as latter comment just made.

>    b. You clearly indicate to the end user of the software that it is in
>       a modified form (ie, has not been directly obtained from David
>       Barrett).

I think this is the only term so far that is clearly OK with open source
principles. Letting people know who made which modifications is a part
of many licenses.

>    c. You make the the modified software available by public download in
>       an uncompiled form.

Some people used to gripe about specifying the manner of distribution
because times and technology change and because for some it could pose
an undue hardship. Generally source must be provided to anyone who
receives the binary, but requiring it be available to the public
generally might make some object.

> 6) You may not use any file in the software as a component in anything
>    other than the software itself.

I would say this is an explicit violation of OSD #3.

> Or something like that.  Is there truly no existing OSI license that
> accomplishes something like this?  This seems like a straightforward way
> to grant open-source rights to contributors while maintaining maximum
> dual-license opportunities for the original author.

There isn't an OSI license that does this because it contravenes open
source principles and unnecessarily limits developers in so many ways.
However, there are plenty of ways to use OSI-approved licenses in a
dual-licensing model. Many companies are doing this successfully right
now. If you're willing to think about the ways that you can still
achieve your goals while giving up a little bit more control, I think
you'll find you don't need a new license to do the things most important
to the success of a dual-license business model.

True success for the project will also probably require an active
community of users and developers. Think about this from a developer's
perspective: Why contribute to a project that limits you in so many
ways, making your work harder than it needs to be?

Brian

> Alex Bligh wrote:
> 
>> From an open-source point of view, OSI definition aside, if you are
>> going to get people to contribute modifications (and without that,
>> something is open-source merely in name) you will need to come to an
>> equitable arrangement which balances the rights of the contributor and
>> the ID, and in practical terms, the nearer the extremes you go, the
>> less likely that is to be the case.
> 
> 
> I agree, but of course "equitable" is in the eye of the beholder.  It's
> not my goal here to convince you to contribute under these terms, or
> even that others will.  Rather, I'm asking if such an OSI-approved
> license already exists, and if not, advice on how to craft a license
> that accomplishes my objectives.
> 
> As for OSI principles, I don't believe my above goals conflict with any
> of the 10 criteria listed at:
> 
> http://www.opensource.org/docs/definition.php
> 
> To repeat, my goal is to enable immediate open-source distribution of my
> application while maintaining maximum opportunity for future
> dual-licensing.
> 
> -david
> 
>