Re: {SPAM} Re: Anton's amendment
Hi,
I knew I should not speak out loud in this forum before formly
deciding what I believe in :)
On Thu, 02 Feb 2006 15:56:45 -0800, Russ Allbery <rra@debian.org> said:
> Manoj Srivastava <srivasta@debian.org> writes:
>> I have been thinking about this (originally brought up by Russ). I
>> have also been re-reading the SC/DFSG, and the time they were
>> written. I also started with the idea that the SC/DFSG are to be
>> considered to be consistent, unless strong evidence exists to the
>> contrary.
>> So, the DFSG are what they say they are -- guidelines. However,
>> some licenses were deemed by the project to be de-facto free, even
>> if they do contravene some of the guidelines, hence explicitly
>> naming the GPL and the bsd licenses. The naming them specifically
>> removes the requirement that they meet all the guidelines.
> Admittedly, I'm somewhat new to these parts, but I've been following
> this discussion for long enough that I'm pretty uncomfortable with
> this interpretation. It doesn't seem to match what other people
> have said about the beginnings of the DFSG and feels contrary to the
> language of the DFSG. The DFSG specifically calls those licenses
> *examples*, not exceptions, which isn't the language that I'd expect
> to be used if this was the case.
I am not sure. We offered them as examples of free licenses.
> I'd be a lot more comfortable with an interpretation that says that
> anything in the GPLv2 or four-clause BSD (the Artistic License has
> the problem of not being clearly written and is hard to use for
> comparison purposes) that appears to contradict the DFSG indicates
> that the DFSG aren't being applied in the manner that they were
> intended to be applied.
> Unfortunately, that does leave us with this vague notion of
> acceptable limitations on modification, which I'm not horribly
> comfortable with.
This feeling of discomfort is what started me down that path
speculating how I can make it all fit and be consistent.
> It's very open to interpretation and feels likely
> to be an endless source of argument. But I don't see a way out of
> that given what the DFSG says right now. Reading it to imply that
> the GPL is not otherwise free but is accepted as a special exception
> seems as tortured to me as reading it to say that a license is free
> provided that *some* modifications are permitted.
> I'd rather try to develop a better definition of what would be an
> acceptable restriction on modification. Since the GPL is our
> example, let's start there. The GPL interactive execution clause
> has the following properties:
> * The exact form of the notification is not specified by the
> license. The license allows one to translate it, rephrase it,
> move where it's displayed, make it a dialog box instead of
> standard output, etc.
> * The restriction is solely on the functionality of the code, not
> on the form of the code. In other words, every part of the
> implementation of the interactive notice may be freely modified
> provided that some notice is still displayed.
> * The restriction is specifically limited to a case where
> displaying such information does not cause harm. If the modified
> program does not read commands interactively when run, you're no
> longer required to print out the notice.
Actually, only if the original work printed out the copyright
notice are you required to do so.
> Note that invarient sections in the GFDL are more restrictive than
> clause 2c of the GPL in every respect I list above. The exact form
> of the text is fixed, the ability to modify the source that produces
> the invarient sections is unclear (to me at least) from the license,
> and the invarient sections must be retained no matter what the
> derivative work looks like, even if only a portion is being
> excerpted into a space-limited environment (the infamous coffee mug
> example).
> I think this is a stronger argument than deciding that the GPL isn't
> really DFSG-free but is just grandfathered in.
> To me, this whole discussion is over exactly what "allow" and
> "modifications" mean in:
> The license must allow modifications and derived works, and must
> allow them to be distributed under the same terms as the license
> of the original software.
> The example of the GPL argues that this means some requirements can
> be put on the form of those modifications, but those requirements
> should not be so strict as to enforce a particular implementation
> strategy, method of presentation, interface, or retention of code
> that is unsuitable for a new purpose. I think the GFDL is not
> DFSG-free because it goes far farther than the GPL in this area.
> However, at this point we're unfortunately way off into grey areas
> that, at least to me, are not explicit in the text of the DFSG.
> Allowing the GFDL in main seems like a huge stretch to me, and I'm
> not really arguing that it shouldn't require a 3:1 majority (it
> would certainly be a significant change to what I thought the DFSG
> was supposed to mean), but I can at least see the argument.
>> Besides, not removing a copyright notification already present is a
>> different kettle of fish from invariant sections.
> I'm not sure that I agree with this. So far as I know, there is no
> legal requirement that copyright and warranty disclaimers be
> presented in interactive programs. They must accompany the work in
> some legal jurisdictions, but the GPL goes much farther than that.
N, there is not. But I am far more comfortable with "retain
copyright notices" attached to the work (I do not considersuch
motices as part of the work) than I am with invariant sections that
are part of the work.
manoj
--
"Pascal is Pascal is Pascal is dog meat." Devine and P. Larson,
Computer Science 340
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: