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