Are implicit dual-licensing agreements inherently anti-open?
Michael Bernstein
webmaven at cox.net
Fri Jul 22 16:29:10 UTC 2005
On Fri, 2005-07-22 at 01:49 -0700, David Barrett wrote:
> Michael Bernstein wrote:
> > The ID is set up perpetually as the sole proprietary free
> > rider. In the worst-case scenario, the ID (and no one else) can continue
> > to use the forked code as the basis for their proprietary product, even
> > though they are now expending no effort to maintain it.
>
> Ok, so the worst possible outcome is that the initial developer
> freeloads on a successful open source project? And... that's it?
>
> Both the severity and probability of this outcome is certainly a value
> judgment. I wager you believe the severity is high, and the probability
> is likely -- and I won't try to convince you otherwise. But I
> personally believe developers aren't so easily manipulated, nor are
> initial developers so Machiavellian.
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.
Probability: Likely low for any particular project, but near certainty
overall if the license is at all widely adopted, 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.
> >>Furthermore, you seem to be discounting that there's any possible way
> >>that such an arrangement could go "right". I mean, do you disagree that
> >>it's possible an ID could be smart, could treat his community of
> >>contributors fairly, and could actually release code in an open way --
> >>code that probably wouldn't have been released at all otherwise -- such
> >>that he and everyone benefits?
> >
> > Ah, but in the positive scenarios, the normal dynamics of open-source
> > licensing with a dual-licensing business model would suffice, and the
> > additional safeguards (in the form of perpetual special privileges) in
> > the OVPL for the ID are unnecessary.
>
> "Would suffice" is another judgment call.
I was simply responding to the question you posed. The circumstances you
stated under which the OVPL arrangement would "go right" are the same
under which a more usual dual-licensing situation would "go right".
> In your case, I recognize you
> see the hassle of gathering contributor agreements to be negligible.
> That's fair; I recommend you do so. But in my case, I'm a nomad. I
> literally have no physical address that lives longer than a month. It's
> not possible (or, at least, convenient) for me to harvest physical
> contributor agreements because of the simple matter -- to where would
> they send them? Likewise, I live out of a tiny backpack. I don't have
> a file cabinet. Even if I received all this paperwork, where would I
> keep it? 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.
> I'm not trying to convince you that you should use the OVPL. I'm not
> trying to convince you you should contribute to the OVPL. I'm just
> asking that you accept that there are others who need, would use, and
> would contribute under the OVPL.
I am not yet ready to accept the need, and you should be trying to to
convince me of that.
And I am sure there are those who would use and contribute, so what?
That has no impact on the desirability of OSI adding it's imprimatur on
the license.
> I enjoy and appreciate your personal opinions on the matter. But what I
> really want is precise feedback on where the OVPL violates OSI
> principles, or where it includes language that is unenforceable under
> certain jurisdictions. And if you don't see any such conflicts, I'd
> like you to state that, too.
I am simply not qualified to find such conflicts.
> > I do realize that these are not *necessarily* arguments against OSD
> > compliance (I'll leave that determination to others).
> >
> > I would however argue that the OVPL does not represent a useful (from
> > the OSI's point of view) innovation in software licensing, and I
> > strongly urge you to reconsider whether you truly need the special
> > privileges the OVPL grants to the ID.
>
> That's fair and useful feedback -- thank you. But I respectfully
> disagree. I believe the inclusion of an implied contributor agreement
> does in fact serve as a useful innovation, does not conflict with OSI
> principles, and is necessary for certain people and situations.
>
> Such as me, and mine.
Perhaps. I'd like you to demonstrate that need a bit more clearly,
though.
- Michael Bernstein
More information about the License-discuss
mailing list