Are implicit dual-licensing agreements inherently anti-open?

[David Barrett]

Alex Bligh wrote:
> And also no because someone (you David B!) said 3.3 was incomprehensible.
> I suggested a fix (deleting the second half of the long sentence starting
> at the words "PROVIDED THAT"). I'd prefer it was comprehensible by
> non-lawyers if this is not at the expense of useful functionality.

*sheepish grin*  Well, to be honest, it'd take a lot more than removing 
that paragraph to make it comprehensible by me.  This discussion has 
gone a very long way to helping me understand it, but obviously few are 
going to take the same effort.

I think if you simply provided a clear (non-binding) summary that I can 
understand, along with clause-by-clause annotated version mapping the 
summary to the license, *and* have it OSI certified, I could be 
confident in using it.

Ideally, the shorter and sweeter you make the summary, the better. 
Something like:

"For contributors, using OVPL'd code is essentially the same as using 
GPL'd code.  You can use, modify, and redistribute the code without 
restriction, in commercial or non-commercial applications, so long as 
you make your modifications available upon request.

The primary difference is that the 'initial developer' is not required 
to redistribute modified code, and can at any time relicense the entire 
body of code -- including your modifications -- under new terms.  To 
repeat, the 'initial developer' can modify your contributions in a 
closed version of the software, and is under no obligation to release 
the modifications to you.

The overall intent of this is to enable an open-source community to 
contribute to a project, without preventing the initial developer -- who 
typically has invested and continues to invest much more into the 
project than any single contributor -- from selling the code under a 
different license in the future."

The summary needn't be exact -- after all, it's a summary.  And it 
certainly isn't legally binding.  Furthermore, it needn't be written to 
an audience that is wholly new to open-source licensing.  Rather, it 
needs to convey to someone who is already comfortable contributing to 
open-source projects under other licenses (such as the GPL) what is 
different when contributing under the OVPL.  Then by a combination of 
trusting me (the initial developer, who picked the license), seeing the 
OSI mark, and reading the annotated version, he can accept that the 
license actually does this and contribute in an informed manner.

I merely spell this out to state that it is *not* a requirement that the 
typical Joe Coder be able to read the license and understand it on first 
try (though that would be preferable).  Rather, there needs to be some 
simple resources made available so I can point my contributors to the 
OpenVendor website and have their questions answered in a crisp and 
efficient fashion.

-david