On Thu, 29 Jan 2004, Anthony Towns wrote: > On Wed, Jan 28, 2004 at 09:23:50PM -0800, Don Armstrong wrote: > > There is a large difference between a valid license and a chunk of > > text that happens to look like a license. > > Well, no, there's not: if it's the same text, it's the same > text. You know, by definition. The text might be the same, but one is a valid license, and the other is just text. Since it is possible to dicern between the two, we can choose to allow one while dissalowing the second. > Having a license in a file other than /usr/share/doc/*/copyright > doesn't change much. Having a license included in a package as an > example, rather than because it covers some trivial little program > doesn't change much either. Neither does including a small little non-free utility in main for which we don't have source. > Not everything that could be useful can reasonably be guaranteed by > the social contract. Probably, but when it is a usefull act upon a work in main covered by the DFSG, it seemingly is guaranteed by the Social Contract. > > but there is no way that I can modify the meaning of a valid > > license and have it remain valid. > > If you're the copyright holder, of course you can. Hopefully it's obvious that I am refering to a case where I am not the copyright holder. > And I don't see much point making the decision on whether we move > non-free documentation out of main (and keep it out) as part of the > social contract rather than doing it in the usual way: deciding we > want to do it, and having the appropriate delegates and maintainers > decide how to work towards that. I would imagine that making the decision as part of the SC would be equivalent to "deciding we want to do it". > What makes more sense? Keeping stuff our users rely on and expect > available, having productive relationships with upstream and helping > improve their software, or blindly adhering to an ideal, brooking no > exceptions and ignoring any negative consequences? There are negative consequences to both courses of action. Keeping non-free works in main means that individuals who are exercising rights apparently granted to them by the DFSG could suddenly fall afoul of the license terms of the work. Removing them would alleviate this issue. I would hope that most proponents of removing non DFSG free works from main are well aware of the consequences. I know that I personally am, having spent many hours of my own time working to keep works from becomming non free, or turning non-free works into free ones. > > While I personally disagree with this, could you (or someone else > > who holds this view) give an accounting of how we should discern > > between works to which we should apply the DSFG and works to which > > we should not? > > The current rules are that programs don't get into main unless they > appear to have DFSG-free licenses, and get removed from main if it > turns out that there are some non-DFSG-free terms in there, and > upstream isn't willing to change them. DFSG-free licenses are > preferred for documentation and other data in main, but as long as > its distributable, it's more or less up to the maintainer's > discretion. The problem with this tack is that it is very difficult for our end users to know what works in main they can exercise their rights preserved by the DFSG upon, and which works in main they cannot. Individuals holding this viewpoint apparently would accept works with restrictions on use as well. [Perhaps some would hold that only certain tenets of the DSFG are important for non "program" works in main, and the rest can be given lip service to.] That being said, I'm still interested in an answer to the original question: How do I dicern between works to which I apply the DFSG and works to which I do not?[1] Don Armstrong 1: For bonus points, propose a system to allow the user to know easily which works fail to fullfill the DFSG. -- If you have the slightest bit of intellectual integrity you cannot support the government. -- anonymous http://www.donarmstrong.com http://rzlab.ucr.edu
Attachment:
signature.asc
Description: Digital signature