Should the three new criteria be in the OSD?

[Chuck Swiger]

Fink, Martin R wrote:
> Well, I'm the OSDL dude that's largely responsible for "piling on the
> pressure".  For the record, I have NEVER created a new license, so I
> feel uniquely positioned to pile on that pressure.

Fair enough.  Even someone who has created a new software license might still 
be concerned about license proliferation, but I take your point.

> I approve about 3 OSS projects/activities a week at HP and have NEVER had
> to create a license, so I can't figure out why anybody else needs to.  

Oh, a few people create new licenses out of a genuine need, but most of the 
time, people create a new license simply because they choose to do so.

Perhaps they don't know about an existing license which would suit their 
perceived requirements, or perhaps they wish to have their name or their 
organization's name listed with a standards body like the OSI out of vanity or 
for advertising reasons.

There appears to be a common consensus that the OSI should do what it can to 
encourage license reuse where possible, but even so, more new licenses are 
going to be created in the future, regardless of what you, HP, the OSDL, OSI, 
or anyone else may do.  (Aside from the authors of the software who decide to 
create a new license, that is.)

> The question shouldn't be if OSDL members will stop using Open Source
> software (or any other of your questions), the question is if over the
> long haul the OSI will have delivered useful value to the industry (and
> the community) when we get to license #500 and no one can figure out
> what works with what?  So, I really don't care about politics or
> philosophy, I just want to make sure that 10 years from now the OSS
> model actually still works.  That's all - plain and simple.

OK, this seems to be a perfectly reasonable expectation.

The BSD license was created circa 1977 and is still a popular choice nearly 
thirty years later.  If the OSI added 500 variants of a simple permissive 
license like the BSD or MIT license over the next decade, would this cause a 
significant problem to you and yours?

I am pretty sure that the answer is no, since if you actually look through the 
source code for FreeBSD, OpenBSD, NetBSD, and so forth, you'll find that 
dozens of close variants of the BSD license already exist.  All of these 
variants are compatible with each other, and with pretty much every other 
license out there.

Once we move to more complex licenses involving copyleft or patent defense 
provisions, starting with the Bison license in 1987 which evolved to become 
the GPL in 1989, and continuing through today to the CDDL, well, things become 
a lot more challenging.

Clauses like GPL #4 & #7 prohibit sublicensing of software under the terms of 
another license by design, although presumably those of you in the OSDL who 
work with GPL'ed software have chosen to accept these consequences in return 
for access to the large amount of high-quality GPL software available today.

(Much of which was written by members of the FSF in the days where vendors 
like HP and Sun were shipping proprietary royalty-bearing SysV derivatives 
like HP/UX and Solaris, and having end-users resort to installing GNU versions 
of stuff found in /usr/bin because the GNU version was fixable and ended up 
with fewer bugs and fewer arbitrarily limits on line-length and the like.  :-)

Given the above, could Martin's concern about license proliferation be more 
accurately described as a problem of proliferating *reciprocal* licenses?

This connects with another thread going on right now:

John Cowan wrote:
> Jason White scripsit:
>> The OSL is similar [to the GPL] in that it requires derivative works which you
>> distribute to be made available in turn under the OSL.
[ ...stuff about reciprocal licenses... ]
> I claim that appropriate refactoring can always eliminate this problem.

Perhaps.  Even if you are right, it sure is a lot of work to refactor two 
software projects just in order to make their licenses play nice with each 
other.  And if you can't manage to make the licenses play nice, well, isn't 
this situation exactly what Martin describes: "...no one can figure out what 
works with what?"

-- 
-Chuck