On Fri, 30 Jan 2004, Anthony Towns wrote: > On Thu, Jan 29, 2004 at 09:58:34AM -0800, Don Armstrong wrote: > > Neither does including a small little non-free utility in main for > > which we don't have source. > > Sure it does: it means people who don't have non-free in their > sources.list can get at it, rather than only people who have main in > their sources.list. I'm lost here. Do you mean to say that it's perfectly ok for us to ignore the DFSG for small little non-free utilities in main? > By contrast, deciding whether to put a piece of text in > /usr/share/doc/*/copyright or > /usr/share/doc/*/free-patent-license.txt isn't really a big deal to > anyone. If it'd normally go in the latter location, but Debian > forbids it, then it's trivial to include some stupid little utility > that's covered under the license, then move it into the copyright > file instead, and reference it there. Sure, but the license has now been made relevant in the context of distributing the "stupid little utility" instead of just being a chunk of license like text. > > 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. > > Some people probably think it'd be useful if they could take the > Linux kernel in main, rip out a bunch of subsystems, then include it > in the next release of Windows. Unfortunately they can't, and we > certainly don't make any promises that they will be able to. I hope we'll agree that such a useful (heh) act isn't covered by the DFSG. > > Hopefully it's obvious that I am refering to a case where I am not > > the copyright holder. > > Then, again, that's not an issue: what is an issue is whether you > can take a valid license, modify it, and apply it to new works > legally. That's something that would be nice to have, and a necessary freedom for licenses that are included outside the context of enabling us to distribute a work of Free Software. > > 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. > > Well, no, it's not. They have to read the license that comes with > any package that they want to modify. Of course, they should do that > anyway, since we've made mistakes before, and probably will again, > and don't offer any indemneties to protect them from problems caused > by our mistakes. I agree that users should read the licenses to a work before they modify the work, but in cases where we know that a work is not licensed in a manner that is DFSG Free, failing to move the work out of main (or taking steps to have the work relicensed appropriately) is not acting in the best interest of our users. Moreover, I'm not only talking about DFSG #3 (modification), but the rest of the rights granted by the DFSG, most notably #5 and #6 (useage restrictions). > > 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] > would you like to rephrase your question so that it's obvious how my > answer didn't address whatever it is you're apparently actually > asking? Sure. If we decide that there is a class of works to which the DFSG does not apply, how do we tell the difference between them? For example, if we decide that documentation (or ...) does not have to follow the DFSG, we need to be able to tell the difference between documentation (or ...) and things that are not documentation (or not ...). Don Armstrong -- Never underestimate the power of human stupidity. -- Robert Heinlein http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu
Attachment:
signature.asc
Description: Digital signature