Are implicit dual-licensing agreements inherently anti-open?

[David Barrett]

Michael Bernstein wrote:
> On Fri, 2005-07-22 at 01:49 -0700, David Barrett wrote:
> 
>>Michael Bernstein wrote:
> Severity: Reciprocal licenses (which on the face of it the OVPL is)
> exist largely in order to avoid this scenario. So, I would assume that
> many others would consider the severity of this loophole high,
> especially as the ID gets to relicense the work under it's own terms *to
> anyone else*. Effectively, the ID can become a paid proxy for anyone
> else's desire to violate the reciprocal spirit of the license.

I acknowledge that the OVPL leaves open the door to types of abuse that 
other licenses (such as the GPL) explicitly shut.  That's the risk part. 
  The reward part is that it opens the door for certain types of 
open-source projects that are shut out by existing licenses' restrictions.

On one hand there's the severity of an ID becoming a freeloader on a 
project that he started.  On the other hand there's the severity of the 
project never being opened at all.  Personally, I'm more scared of 
people never opening up their code, than people opening up their code 
and then doing wrong by the community.


> Probability: Likely low for any particular project, but near certainty
> overall if the license is at all widely adopted, 

Well, I'm glad we agree that for any particular project, the probability 
is low.  But... isn't that good?

(As for "near certainty", forgive my simplification, but are you just 
restating the mathematical truth that any nonzero probability, given 
sufficient opportunities, becomes probable?  I don't see how that is 
relevant here.  I think I didn't understand you.)


 >  and plenty of IDs *are*
> that Machiavelian, witness the continued attempts by various IDs to
> define their licenses as 'Commercial Open Source'. Besides, IDs have
> successors in interest, for a variety of reasons (death, buyouts, etc).
> It's not unreasonable to ask what such a successor could do in a worst
> case scenario.

Perhaps this is one point where we differ, but I see the many 
"commercial open source" attempts as clear evidence that *the existing 
licenses are insufficient*.  Personally, I see no conflict between open 
source code and sound business sense.  But it's striking how many do, 
and it seems reasonable to suggest that the selection of approved 
licenses is in part responsible.

Existing licenses are heavily weighted in favor of contributors -- 
that's great and for many projects (especially those that start out as 
community efforts) I think that's the right balance.  But not all 
projects emerge from the community, and thus it's reasonable to 
rebalance the risk in proportion to contribution.

An ID takes an up-front risk by releasing code under any open source 
license -- he's giving away actual value in the hopes of obtaining 
future value.  You might believe that risk is inconsequential.  But I 
believe it's significant, and thus it's not entirely unfair to ask that 
developers take a similar risk with their contributions.


>>In my case, "normal dynamics" do not suffice.
> 
> Hmm. Have you tried asking a lawyer whether electronic contributor
> agreements would be enforceable, especially if digitally signed?
> 
> If physical agreements are still needed, then a suitable proxy could
> surely be found, such as (perhaps) the Software Freedom Law Center.

Again, I don't dispute there are alternatives.  But my initial 
evaluation is that they add overhead to the contribution process that 
I'd just as soon do without.

Regardless, I wasn't aware of the "Software Freedom Law Center" -- 
thanks for the link.


> I am not yet ready to accept the need, and you should be trying to to
> convince me of that.

The need is simply reduce my overhead and lower the barrier for "one 
off" contributors who -- in my experience -- make up the bulk of 
developers.  My fear is that I'll receive an email with a great bugfix 
for some esoteric hardware configuration, and when I reply asking for 
him to sign a contributor agreement, I'll hear no reply.  Or I get 
through and find he thinks me knowing his true name and physical address 
is a privacy violation.  Or he agrees and says he actually did it, but 
it never arrives, and I need to pester him to do it again.  Or he 
actually does do it, and I need to record he did it so I don't ask him 
again, and somehow cross-reference his agreement to his contribution, so 
later I can audit my code.  And then later I actually *do* have to audit 
my code, which seems just unfathomably difficult and tedious.  And all 
the while, I'm not spending this same time coding, and I've got stacks 
of contributions sitting around in various states of "acceptability", 
which just complicates the already difficult task of managing an open 
source project.

In theory, harvesting contributor agreements should be easy.  But I fear 
it's not, for the same reason micropayment economies don't work.  The 
"mental cost" of making a $0.01 payment (or, in my case, licking a 
stamp) is astonishingly high.  Were I able to pay it, or were I offering 
a service, it'd be less a problem.  But in effect, I'm asking people who 
are giving me *free work* (presumably for fun or personal value) to then 
do *more* work that is *not* fun and which serves them *no* value.  It's 
just a drain on my contributor's time, and thus a drain on my contributions.

In my view, if the open-source community embraces dual licensing, I see 
no reason why it only does so by punishing contributors and managers 
with busywork.  It's hard enough to make an open source project succeed. 
  It's even harder making a business succeed.  Mandating unnecessary 
paperwork to stave off low probability, theoretical risks -- at the cost 
of aggravating high-probability, practical risks -- seems like bad policy.

-david