[H-GEN] re: OpenSolaris

[Benjamin Carlyle]

On Sat, 2005-02-12 at 14:17 +1000, Adrian Sutton wrote:
> I would argue that that's not a viable option for Sun.  They clearly
> wanted a license that provided similar rights as the MPL, ie: not
> viral but changes have to be made public.  They also had to pick a
> license that provided patent grants otherwise they would have been
> slammed (rightfully) for with holding their patents over the code
> (which they pretty much copped - wrongfully - anyway).  This point is
> actually covered in the FAQ:
>         We reviewed a number of existing open source licenses, but
>         were unable to find one that that was appropriate for the
>         OpenSolaris source code. Therefore, we reluctantly drafted a
>         new license...

What's not so clear from the FAQ is whether they approach
representatives of mozilla.org, pointed out their problems with the MPL,
and asked whether they could come to a consensus on what had to change.
I would have much preferred to see a MPLv2 or seen CDDL adopted by
mozilla.org rather than be bombarded with yet another license. I don't
see that it distinguishes itself clearly enough from the parent
licence's intent to be usefully different, however its existence as an
extra license definitely has disadvantages.

> Each project has different requirements and the variety of licenses
> reflect that.  If you don't like being confused by licenses, advocate
> the public domain which removes all confusion - you can just do what
> you want.

I don't advocate public domain, although it appears to work well enough
for sqlite. What I would hope is that with so many people saying that
the GPL is wrong, and that the LGPL is equally-unacceptable that it
should be easy to characterise what is wrong with the two licenses and
come up with a small number of reasonable alternatives to address these
problems that most people outside the GPL camp can agree on. Maybe with
a clear alternative consensus the GPL camp would have something to
consider also. The current situation of having 58 OSI-approved licenses
that new players still can't accept the terms of for their own software
is flawed and counter-productive. We need fewer good licenses rather
than more "better" licenses. It feels far too much like Microsoft's
Embrace and Extend strategy for my liking.

Users should understand their rights and responsibilities when they're
given open source software. At the moment it seems too hard to do that.

> Then again, I'm involved with the Apache Software Foundation and the
> ASF was the last target of the GPL fanatic hit-squad for not being GPL
> compatible (I'm not sure anyone's really sorted out if the ASL 2.0 is
> GPL compatible or not).  Perhaps I'm just still grumpy.

I'm still agnostic about whether the GPL's restriction to use with open
source software is a good thing, but I'm supportive of those who use it
and I'm happy that the LGPL exists as an alternative. To me those
licenses and the community knowledge surrounding them give a fairly
clear definition of what a user needs to know:

1) You can do what you want with it,
2) So long as what you do with it stays under the original license,
3) but if it's GPL and you combine it with other software, that software
must be open source[1]

I think (1) and (2) are pretty widely accepted. Whether (3) is good
depends on your perspective.

Surely if we agree with these basic principles but consider these
licenses flawed we should be able to come to a consensus on how they are
flawed. Surely we can come to a consensus as to what a fixed version of
each license would look like, rather than having everyone go off into
their own little corner of nowhere to write their own. We should be able
to characterise what makes every existing open source license's intent
unique. If there is nothing to make a particular license's intent unique
then pick one from the non-unique set and recommend it for all future
work that matches the non-unique intent. Don't leave licenses hanging
around that have the same intent but different wordings or subtly
different unintended implications. The MPL and CDDL should not both be
in active use. One should supersede the other.

In the end, I think we should be working towards a model like that of
creative commons where the various intended consequences of a single
license can be decided based on a particular project's needs but all
come from the same licence "code-base". We should think about licenses
like we think about software. Forks and branches for a little while, but
work towards a common base once we understand the problem domain.

Hi, I'm your license for Solaris. I,
(grants)
[x] Do permit combination with open source software (clase 18)
[x] Do permit combination with non-open-source software (clause 19)
[x] Allow you to modify my code (clause 32),
[x] Allow you to redistribute modified code as patches (clause 34),
[x] Allow you to redistribute modified code as a whole (clause 35),
[x] I grant you patent rights unless (clause 50),
(terminations)
I,
[x] reserve the right to terminate if you sue (clause 73)
(Only crossed boxes apply)

Now, that's the starting point of a license I can trust. Extensible,
reusable, and clear in its intent. The detail remains in the clauses,
but a consensus has been achieved that these clauses implement their
intent properly. Ideally, when you combine sources from variants of this
license you can work out the terms of distributing your own program by
performing a bitwise "and" between all of the grants sections and a
bitwise "or" of the termination sections from each part of your program.

-- 
Benjamin Carlyle <benjamincarlyle at optusnet.com.au>
[1] For values of "open source" approximating GPL | LGPL.