compatibility and the OSD

[Chris F Clark]

I wrote:
> Not allowing a particular
> form of a derived work to be shipped (provided that the preferred form
> is also shipped) would seem to be non-OSD compliant.

Bob replied:
> Can you explain what term(s) in the OSD you think it violates?

IANAL...

I'm sorry, but not interested in the exact terms of the OSD, so don't
keep myself intimately familiar with them, so as to point out exactly
where something runs afoul.

I'm much more comfortable with the concept behind the OSD (e.g the
spirit rather than the letter of the law).  A restriction on
redistibuting binaries would seem to be a "use" restriction.  I cannot
use the sources to create an incompatible derivative work that I can
"use" (where use requires redistribution).  

As I see it, OSD compliant licenses have to allow creation (and
distribution) of forked (incompatible) derivatives, and the types and
kinds of restrictions that the original author can place on those
derivatives are severly limited.  (As I understand it, the
restrictions on the allowable restrictions are even more severe for
"free" software.)  The author of an open source licensed work can put
restrictions (via the license) that preserve the integrity of the work
in source form and can require that other users also distribute their
modifications in source form and also require that source copies are
made available to any users.  Beyond that, there are few restrictions
an OSD compliant license can put on subsequent distibutions.

The exact set of allowable restrictions make sense if you view the
purpose of the OSD to be the creation of a large body of works
available in source form (and possibly other additional forms), which
can be adapted by later authors to new purposes not embodied in the
original works.

Thus, licenses which require sources of modifications to be made
available increase that body.  Licenses the require "original" sources
to be made available to users of deriviative works increase the
availability of that body of work.  License that protect certain
"artistic" freedoms (attribution, advertising, etc.) can encourage
certain authors to contribute additional works to the pool.

However, licenses that make redistributing derivative works more
difficult and that don't fit into one of the above categories of
"aloowable" restrictions are "contrary to the spirit of the OSD".

And, now i must admit that i misread your original sketch, because I
interpreted source distribution to be requiring source code to be
included in the distribution not as outlawing other forms of copies as
being included.  I think that derived binary files could be considered
an integral part of a work as a whole, and thus prohibiting the
distribution of binaries made from an non-conforming derivative work,
would be non-compliant to the spirit of the OSD.

An OSD compliant license can require sources be shipped with
derivative works (and force the inclusion of all relevant sources) and
can place restrictions on the sources themselves, but it cannot
restrict non-source parts of a distribution (other than requiring the
presence of (some or all) sources).

In that way, the OSD is like the Constitution of the Unitd States.
Yes, its composed of words, but the real importance is how the
relevant parties interpret those words.  In the Constitution's case,
it is how the various branches of government interpret the words.  In
the OSD's case, it is how the board interprets those words.  How you
and I read the words of the OSD can make interesting discussions, but
in the end it is how the board decides to certify licenses as OSD
compliant that counts.  The OSD is just a hint to the prospective
license writer as to how the board is likely to react....
 
-Chris