OVPL summary

[Ben Tilly]

On 9/15/05, Alex Bligh <alex at alex.org.uk> wrote:
> 
> 
> --On 15 September 2005 13:18 +0200 Chris Zumbrunn <chris at czv.com> wrote:
> 
> > But ten years down the road, the ID could again produce a proprietary
> > product from that fork, while the poor guy that maintained the fork for
> > all
> > these years can't.
> 
> Yes. But the likelihood is that the proprietary version will have additional
> features in (or anyone can produce such a version). The likelihood of being
> able to maintain those across a forked tree diminishes over time.

I think that the point was that a decade later the ID can decide, "You
know, that fork is better than my stuff, I'll just take it
proprietary!"  They then add a few features and do so.  Even worse,
the ID can go out of business, and whoever bought the residual
copyrights can look through the licenses, discover that they bought
this right, and create a new business.

At this point the ID (or descendent thereof) now has a proprietary
product that they did NOT do most of the work for, and that people who
did the work for cannot do likewise with.

Now before you dismiss this fear as ridiculous, I need to pass along a
comment that I first heard from Karsten Self.  Mr. Self pointed out to
me that when you read a software license, you discover what the author
of that license feared.  Licenses are all about being able to CYA in
likely and unlikely situations that someone doesn't want to see.

Therefore people's commentary on licenses is going to be driven by the
concerns that they are trying to address.  The repeated variations of
this complaint is merely a sign that lots of people have this
particular fear.

> You are correct of course that the ID has "an advantage" here. Remember
> though, in the case where the ID's code is originally a large closed-source
> project, the ID is, in return for that advantage, open-sourcing a lot
> of code to the communities advantage. We recognize that people may not say
> "that's a fair swap", in which case they need not contribute. Remember
> also that the ID will be putting into the community a whole lot of things
> that are *not* copyrightable (or, at least over here, patentable), and
> are currently only protected as trade secrets - there's nothing to stop
> community members who don't like the bargain going and generating a
> competing product based upon the same ideas.

Exactly true.  With the result being that many will not choose to
contribute, and the ID's project is likely to not get many
contributions.  Thereby rendering the previous situation unlikely. 
Unless, of course, the ID screws up and customers who are stuck on an
old version choose to maintain a fork of that which meets their needs.

Now we have the question of whether this should be considered open
source.  My opinion is that it depends on what you consider open
source to be about.  If what you value about open source is the
tendancy for people to find problems and send you patches, then it
falls short of the ideal by the fact that there is discouragement for
doing that in the license.  (Dual-licensed projects fall short of the
ideal for the same reason.)  On the other hand if what you value about
open source is that it is an insurance policy - you have viable
options if you wind up locked in to a product whose producer goes out
of business - then it definitely is open source.  You have source
code, you can pay someone to maintain it for your needs, and you can
do what you need with the result.

My personal opinion is that there is a lot more talk about people
fixing bugs than there is reality.  However I've seen a lot of cases
where people wind up in a bad spot because they relied on a vendor
whose interests changed, or who went out of business.  Therefore I
personally value the "insurance policy" aspect of open source more,
and thus I'd consider your license open source.  (Though I'd have a
preference for products with a more even license, like the GPL or
BSD.)

Cheers,
Ben