OVPL and open ownership

[David Barrett]

Alex --

Thanks for taking the time to explain it to me (I'm eager to use the 
OVPL, but have lingering concerns).  Please consider my ignorance of 
open source law as an opportunity to "trial run" your ideas before Joe 
Coder.  With this in mind, this part is where I'm still confused:

Alex Bligh wrote:
> David,
> So in
> practical terms, if a contributor submits a one-line bug fix to the ID's
> code, that cannot stand alone as an original work, so is only going to be
> licensed on an OVPL basis (in practical terms), as the BSD license isn't
> worth a lot to a community member who wants to make a Proprietary Version
> because they'd still need a license to the ID's code, which has only been
> granted on open terms. But if the contributor adds an entire new module,
> ANYONE can use that (to the extent it doesn't rely on the ID's code) under
> any license.

Basically, you outline a spectrum, with adding "an entire new module" on 
one side (which is contributed under BSD) and adding "a one-line bug 
fix" (which is "in practical terms" (meaning, not technical terms) 
contributed under OVPL) on the other.  There's a *huge and scary range* 
between these extremes where lawyers reign supreme.  As a potential OVPL 
license user, I'm filled with fear, uncertainty, and doubt.

My FUD is partially mitigated when you state that a contribution is 
licensed under BSD only if it can "stand alone as an original work". 
Granted this is a judgment call (made by a judge, presumably), but at 
least it gives *some* structure to the decision.

But this mitigation is blown out of the water when you then defend the 
ability to BSD-license only the spaces when converted from tabs.
Which is it?  How can each individual character be licensed under BSD, 
but not a whole line?  What about 10 lines?  Or 1 line that took 500 
hours of analysis and tweaking using a nuclear reactor and a team of 
scientists?

Basically, if you can argue such a wide range of positions in good 
conscience and with a straight face, won't everyone else (and their 
lawyers) be able to, too?  Maybe there's a clear explanation, and I just 
haven't understood it correctly.  But at this point it sounds like 
whoever has the best lawyer (and the deepest pockets) wins.

Overall, I'd summarize your argument (as I am hearing it) as: "Well yes, 
technically, if they replaced all spaces with tabs they could claim BSD 
on the tabs, but really -- who would do that?  And yes, technically, 
they could claim BSD on the one line fix, but again, they probably 
won't.  I mean, how valuable is one line of code?  But if they add a 
whole module, then they will almost certainly claim it under BSD."

This isn't a reassuring argument (assuming you're even making it, which 
I'm not sure you are); it's full of subtle, subjective gradients.  I'd 
like something a bit more obvious and objective.


>> So again, I hope I'm just misunderstanding the intent of the BSD idea.
>> But if the above is accurate, then it's far more extreme than what I'm
>> proposing.  If we make section 3.3 opt-out, then:
> 
> No, that doesn't work. It does not give certainty, and it does not
> achieve the desired objective.

Ok, I accept you believe that, but I haven't heard why.  Forgive my 
nagging, but I thought making 3.3 opt-out was a stroke of brilliance, so 
I'm reluctant to give it up until I know why it won't work.

Were I to guess, I think my proposal's use of whole-file license changes 
is what is holding you up.  I originally proposed this as I believe it's 
the only option that makes practical sense.  *However* I see now that 
this is not a universal view.  So, let me restate my proposal (not 
verbatim license text; just my statement of intent) as follows:

	"The contributor is given the option to redistribute any modification 
to OVPL-licensed code under a modified license (OVPL') that does not 
contain 3.3.  The contributor signals his intent to exercise this option 
by clearly indicating the use of OVPL' at the top new submitted files, 
and within modified files using comments bracketing the changed region 
of source code.  If there is no clear indication of intent to contribute 
the new file or modification under OVPL', then the code is contributed 
under OVPL."

Personally I'd hate to get a bunch of patches with legalese embedded in 
the comments.  But the primary reason that this would happen under my 
proposal is that the contributor has lost faith in me, so I have little 
cause to complain.  (And in either way, I'd prefer legalese in the code 
than ambiguity and vague inferences.)

So given this, my comparison between the plans would be:

Re: Granularity of contributor license
- Opt-out 3.3 (OO3.3): Per new file, or per marked block. (Objective)
- Contribute BSD (CBSD): Whenever the contribution "stand(s) alone as an 
original work". (Subjective)

Re: Auditing which license is in affect
- OO3.3: Look for clear notice at the top of each new file, or 
surrounding each block. (Objective)
- CBSD: Review the 'standaloneness' of all patches contributed to file 
and decide the license on a character by character basis. (Subjective)

Re: License of random patch received via email
- OO3.3: Unless the use OVPL' has been explicitly indicated, the 
contribution is still under the original terms of OVPL. (Objective)
- CBSD: Depending on [someone]'s perception of value and standaloneness 
of the patch, it may or may not be licensed under BSD. (Subjective)


To be clear, I'm entirely skeptical of both the logistical feasibility 
and legal clarity of partial-file licensing.  *However* should 
partial-file license changes be determined both possible and necessary, 
that's entirely compatible with my proposal.  I don't like polluting 
code with legalese, but given that it will only happen in an extreme 
situation (the contributor doesn't like the ID), it's making the best of 
a bad situation.

Furthermore, please take note that were we to mandate a similar hint in 
the code for BSD contributions, then the code would quickly become 
polluted *even if everyone still likes the ID*.  Because *every* 
contribution produces a license conflict (and not just the extreme case 
of disgruntled contributors opting out) you're damned to polluting your 
codebase if you use hints, or leaving licensing ambiguity if you don't.


Anyway.  I feel like I'm fundamentally misunderstanding something in 
your proposal, and that you might be missing the something in mine.  Can 
you explain to me where my reasoning is off in my analysis of the BSD 
proposal, or where you disagree with mine?

-david