OSD #6 (fields of endeavor) and research vs commercial rights

[Chris F Clark]

Bob Scheifler asked:
> So the word "restrict" in OSD#6 (and the word "prevent" in the rationale)
> should be interpreted narrowly to mean "completely preclude"? Meaning,
> there's no obligation for all fields of endeavor to be on equal footing;

I think completely preclude would be *too* narrow.  My sense is that
you can impose restrictions that require end users to make available
(e.g. publish or return copies to the author) and to attribute or not
attribute authorship (e.g. you must keep copyright notices marking
some work as having come from some source, but you may not use the
name of that source otherwise), but not much more.  Those restrictions
don't have to be levelled equally.  

However, other types of restrictions are going to be more problematic,
e.g. fees to any one group (or even equally levelled) will definitely
not fly.  Other restrictions that I don't think could be made to fly
are restrictions that the software must be (or may not be) used in
conjunction with other software.

My rule of thumb is that restrictions that preserve "authorship" are
likely to pass, but restrictions that preserve "ownership" are not.
That is, you can place restrictions that protect your rights as an
author of the software, but not restrictions that protect your rights
as an owner.  However, that is just a personal rule of thumb, based
upon my model of what rights are related to authorship and what ones
come from ownership--a strict legal interpretation of those words
would invalidate the rule of thumb entirely, as copyright law reserves
some rights to an author that would not likely be acceptible in an
open source license.

One area where I think things are gray is in whether restrictions on
how derivative works can be made are acceptible.  For example,
licenses have passed that require special handling of changes to the
code (e.g. segregation into patches and keeping the original work
intact).  However, licesnes that prohibit making derivative works have
not (and will not).

> Not knowing how this list works, are there people who speak
> authoritatively on interpretations of the OSD?

There are definitely those who speak more authoritatively than others
as they are members of the OSI board, me *not* being among them. No
one speaks with absolute authority though, as it is a committee that
does the approval and this list is simply advisory, trying to raise
issues in specific licenses so that the board can make a more informed
decision.  There is certainly no requirement that the board listen to
the discussion on the list or abide by any of the results of the
discussions.

-Chris

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3