OVPL summary

[Alex Bligh]

Ben,

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

Hang on, they can't *take* it proprietary, because it will ALWAYS (without
the new features anyway) be available under the OVPL, because the license
is not revocable (if you're arguing the license is revocable, that's a
different can of worms that would apply equally to - say - the MPL). Sure,
they can produce a proprietary version, and cease helping with the
non-proprietary version - I'm assuming that's what you mean.

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

They cannot create a proprietary version, no.

> Now before you dismiss this fear as ridiculous, I need to pass along a
> comment that I first heard from Karsten Self.

Your fear (at least modified as above for non-revocability above) is
far from ridiculous. It's what I'd be looking at. One should always
look at the worst case.

And the worst case is this:
* The ID open-sources a closed-source work under the OVPL
* Others contribute
* The ID (or a successor in title) says "thanks very much for all your
  hard work guys, all future work I do on this will be proprietary and
  I'm having all your modifications - good bye". Let's call the state of
  the code at this stage X.

What's happened here? IE who has gained and who has lost (in what's
basically the disaster scenario). The ID has gained a pile of code for
their proprietary product. The opensource community now have a product
under a reciprocal license they can carry on using and modifying (in state
X) but know that there's a risk the ID can "freeload" off any further
modifications. You'll notice that compare to the start case (where the
community had nothing) they've won something (a large code base), and lost
something (some time working). The ID's won something (some time working),
and lost something (the trade secrets, and the threat of competition from
the non-proprietary version in state X). It's a trade-off. Enter into this
only with your eyes open!

But pretending other open-source projects are not a trade-off for
contributors would be naive. When you write BSD code, you know someone
(anyone) can take it proprietary. When you modify GPL code, you know you
can't use your work in a proprietary version. In either event, there is the
risk *someone* will freeload (remember two word responses saying "Send
Code"?). In practice with any license where the ID is a large powerful
organization with budget, they often will have more influence over where
code goes than the guy on the street (dollars still talk). OF COURSE it's a
different trade-off with each license, but it's still a trade-off.

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

I agree with them! We made it clear in our FAQ (I hope - if not I'll
modify it). However, our view is this is something for contributors
(and of course ID's thinking of licensing code bases) at contribution
time. Not a reason not to approve the license.

However, (and hence my earlier replies), when you're assessing that
fear, just like when you assess any other "risks" with open-source
licensing, there are things to bear in mind, and often you want to
assume that it is at least likely that the ID will operate logically
and according to its own self-interest.

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

I will happily accept "get fewer contributions". People have worked
on stuff with all sorts of licenses - look at the QPL which is far
more draconian.

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

Yep.

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

All I'm arguing here is it meets the OSD :-) I can happily give
you an argument it meets the FSF's "free software" guidelines if
you like.

>  If what you value about open source is the
> tendency 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.)

I agree, but then again I don't think anyone would argue dual-licensed
products with (say) GPL and A N Other license are not open-source.

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

That's another factor.

The truth is there are lots of factors. And if you go back to the
OSD (and the DFSG before it) you'll find these have most of them
listed ( :-) ).

The OSI (obviously, being an approval body) takes a binary view.
It has to meet each requirement.

Talking more loosely, some licenses are more "open" than others.
(Cue argument about GPL vs BSD, and sound the retreat). I'm perfectly
happy to state publicly the OVPL is less open than either. However,
I think it still meets the OSD, and...

> I'd consider your license open source.

... so it seems do you.

> Though I'd have a
> preference for products with a more even license, like the GPL or
> BSD.)

We make this very point ourselves. The OVPL is not suitable for
new projects. It should be a transition license from closed source
to open-source. Note the fact that an OVPL ID can effectively relicense
(technically sublicense) the entire project under a more "open" license
such as the GPL using clause 3.3 is entirely deliberate.

Alex