Are implicit dual-licensing agreements inherently anti-open?

[Michael Bernstein]

On Fri, 2005-07-22 at 13:27 -0700, David Barrett wrote:
> 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.

I don't think you understand what I wrote above. The ID not only gets to
be a freeloader, but he gets to sell that privilege (wholesale or
retail) to anyone else, in perpetuity, and the actual maintainers of the
forked project can't.

>   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.

Hmm. I think we've seen this particular argument before. "If I don't get
special privileges to take other people's code, I'm taking my ball and
going home".

Personally, I'm more scared of the possibility that such abuse under a
license approved by the OSI would be seen as sanctioned by the OSI than
I am that some particular piece of code never be labeled 'open source'.

> > 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.)

No, you didn't misunderstand me, but perhaps we are attaching different
meanings to the word 'low'. I think 1-in-20 is a fair estimate of the
likelihood of abuse by any individual vendor among the first batch of
vendors to adopt this license were it to be approved by the OSI.

>  >  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*.

Certainly they are insufficient for those vendors' purposes, but since
the sort of license that is typically proposed eliminates the "vendor
must play fair with contributors and users" provisions, I think it only
fair to give them the hairy eyeball and ask what those purposes are.

>   Personally, I see no conflict between open 
> source code and sound business sense.

Neither do I, and neither does anyone else who has created a thriving
business around open source software.

>   But it's striking how many do, 

Are you equating leaving the door open to screw over your contributors
with sound business sense?

> 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.

Hmm. Are we talking use-value or sale-value?

On the vendor's side, in many cases the risk in *not* releasing under an
open source license is that the vendor simply will not be able to enter
a market with entrenched players. If you can't sell it as proprietary
commercial software, the sale-value is negligible.

Also, you're ignoring the risks contributors take in investing time into
your particular software package, rather than a competing one. not to
mention the contributors code represents value as well.

So I don't see this as rebalancing the risks at all, I see this as the
ID wanting to have their cake and eat it too.

The current selection of licenses available are balanced, and for the
most part they require everyone to play by the same rules.

If your code is so valuable and unique, you will have no problem getting
contributors to sign an agreement for the privilege of having their
meager improvements included in the main project.

> >>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.

Hmm. Overhead, huh?

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

You're welcome.

> > 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.

Someone with actual legal credentials will surely correct me if I'm
wrong, but I think it's fairly well established that simple bugfixes and
the like can be treated as though the assignment is implied in any case.

>   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.

Well, assuming you use an SCM to maintain your code, a note in the
checkin message would probably suffice.

> 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.

The value proposition is: "please execute the assignment/contributor
agreement so I can add your code into the main project and it will be
included in the next release."

>   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.

Ahem. I don't think that the risks I described are 'low probability'. In
fact, I would expect a certain class of vendor to flock to a license
like the OVPL precisely because the loophole is there, eventually
dragging the OVPL and the OSI through the mud by association.

Ultimately, your argument seems to be that you need special privileges
for the ID that can be abused because without those privileges the
paperwork associated with explicit assignments is too much work.

Have I got that right?

While we're at it, let's get rid of the pesky paperwork involved in
filing their taxes. After all, we should trust that each citizen and
corporation will pay their fair share and not make them spend valuable
time with busywork. The risk that anyone would cheat is only
theoretical.

On the other hand, if you are truly only concerned about the extra
overhead, this might be a good opportunity for some sort of shared
infrastructure project to make gathering and storing copyright
assignments and contributor agreements much easier for a large number of
projects, and not have to resort to a new license for that purpose.

- Michael Bernstein