Mechanics of Contributing with a New License

[Chris Zumbrunn]

On Jul 23, 2005, at 9:22 PM, David Barrett wrote:

> Chris Zumbrunn wrote:
> >
> > On Jul 23, 2005, at 8:23 PM, David Barrett wrote:
> >
> >> - At worst, a disgruntled developer could change every file (convert
> >> all tabs to spaces), call this a "contribution" and voila -- the
> >> entire codebase is irrevocably licensed under BSD.
> >
> > No, no... that disgruntled developer's contribution would be only the
> > spaces, not the rest on those lines or inside the file.
> >
> > So, only the spaces would be under BSD ;-)
>
> Actually, you bring up a good point.  Given that each file is 
> typically licensed as a whole, but modifications are done in part, if 
> you submit changes under a new license, how is this represented?
>
> For example, the OVPL is too long to copy verbatim into a header file. 
> Thus there will need to be some kind of reference such as "This file 
> is licensed under OVPL 1.0".  Anything can be contributed to the file 
> under the same license without extra effort.  But in order to 
> contribute a single line of code under a different license, it seems 
> that you need to relicense the entire file:
>
> - In the case of the BSD proposal, this line is replaced with the BSD 
> text (is it copied verbatim, or done similarly with a reference?).
>
> - In the case of my proposal, anyone who "opts out" of 3.3 would 
> update this text to be something like "This file is licensed under 
> OVPL' 1.0 -- The initial developer license does not extend to this 
> file.", with "OVPL'" defined somewhere as OVPL without section 3.3.
>
> In either case, it seems to me that because licensing is done on a 
> whole-file basis, simply changing the license in effect changes the 
> entire file and thus constitutes a "modification".
>
> (And thus there's no reason to fool around with the space/tab 
> conversion after all.)

A contributor cannot relicense code covered under the OVPL. This is the 
case with any license. Only the copyright holder can relicense code. 
The idea is that when the ID receives a modification from a 
contributor, it receives this modification under a BSD style license, 
which allows for reuse inside the OVPL licensed project. In theory, the 
modifications would remain licensed under BSD, while what was modified 
stays licensed under OVPL. If a single statement is modified, then that 
statement continues to be OVPL. It's just the modification inside of it 
that is BSD. In practice, the BSD modifications would become part of 
the OVPL licensed project whenever the ID releases a new version 
containing such modifications.

Note that I had an explicit BSD license-back clause in early drafts of 
the Copyback license. I removed it based on discussions on this list 
because I came to the conclusion that it was an unnecessary 
requirement. That's true with the Copyback license because it allows 
for use in larger works that are proprietary. This would almost also 
work with the OVPL, since it gives special treatment to the original 
ID. But while the non-verbose Copyback License can be non-explicit and 
appeal to the common sense of the ID, the contributors and the judge, 
the OVPL can not. Because it is a very verbose license it has to also 
be explicit in the way it defines the license-back.

Chris