Restrictions in license

[Rick Moen]

Quoting Brian Behlendorf (brian at collab.net):

[Restriction on what source code may be distributed, on qmail page.]

> Hmm, I don't read it the way you do.

Noted.  What I read on that (upper) portion of the page was permission to
distribute particular files with particular md5sums, period, and I
interpreted that literally.  If, however, your reading is right, then
that portion of Dan's wording does indeed satisfy OSD #4.  But:

> >The "Exception" paragraph at the bottom relates to precompiled _binary_
> >packages with very narrowly constrained changes, not source code.
> 
> Right - fulfilling the requirement that "The license must explicitly 
> permit distribution of software built from modified source code."
> 
> So it still seems to me that it's OSD-compliant.

Um, not quite so fast.  Satisfying that clause in OSD#4 is _necessary_
(given Dan's restriction on distribution of modified source), but not,
of course, sufficient.  And:

> You can fork the code and compile binaries, but it must behave according 
> to his requirements.

And _those_ requirements contravene OSD #3, Derived Works.  Because:

> You can't fork the code and make any modifications you like - but then
> apparently other licenses restrict that.

I imagine OSI long ago decided -- on, we can hope, reasonable grounds --
that any such restrictions in _those_ licences on modifications are of
such nature that they do not substantively prevent exercise of the
rights enumerated in the various parts of the OSD and approximating
right to fork, right to use for any purpose (with footnote about
copyleft, blah, blah).

I doubt you're seriously maintaining that restricting code forking /
right of modification _generally_ is in harmony with the OSD.  
(I suspect you were aiming at reducio ad adsurdum?)

Granted that the OSD is an imperfect attempt to formalise the background 
notions it represents, but I think perhaps less so than you are
suggesting.

Getting back to Dan's restrictions on forking:  Saying "you may fork",
but that "fork" means must behave "the same way as normal
qmail+fastforward+dot-forward installations on all other systems" and
must install "exactly the same /var/qmail hierarchy as a user would
obtain by downloading, compiling, and installing qmail-1.03.tar.gz,
fastforward-0.51.tar.gz, and dot-forward-0.71.tar.gz" strikes me as a
value of the word "fork" that entirely omits the concept of forking.

When OSD #3 says "The license must allow modifications and derived works", 
I'm _very_ sure OSI doesn't contemplate limiting that concept solely to
derivative works that behave exactly the way the original did.  In fact,
quite the reverse.

> But at the end of the day, deciding upon arbitrary criteria is still
> just as arbitrary as deciding upon arbitrary licenses - especially
> since the desire appears to be to have fewer popular Open Source
> licenses than criteria in the OSD!

You say arbitrary; I say a not-half-bad procedural approximation of a
fairly clear underlying abstract idea.

> Suggestion: dump the current OSD, preserve and clarify the few criteria 
> that really matter (such as the right to fork) and recast them as 
> requirements but not by themselves sufficient to get the Open Source 
> trademark and seal-of-approval. 

Well, if you attempt to come up with a formalism that reasonably
approximates the right to fork, the right to use / develop by anyone for
any purpose (w/same footnote), then I suspect you'll find (1) it's more
difficult than you thought, and (2) it comes out looking a lot like the
OSD.

> Stop calling it a certification process. 

If you're going to have a service mark, then I'm not presently clear on
how you can avoid a certification process (whether it's called that or
not).  But I might be missing something.

-- 
Cheers,             
Rick Moen                 Support your local medical examiner:  Die strangely.
rick at linuxmafia.com