Should the three new criteria be in the OSD?
chuck at codefab.com
Sat Mar 5 03:11:57 UTC 2005
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?"
More information about the License-discuss