Hi,
>>"Marcus" == Marcus Brinkmann <[EMAIL PROTECTED]> writes:
Marcus> Now you are confusing two issues. A book or a novel is quite
Marcus> different from a technical standard. Please let's talk about
Marcus> different things seperately.
Fine, as long as we remember that the final policy has to pay
attention to all these cases. I think we should really be paying
attention to the cases Raul has posted about.
Marcus> I recorded that you think that the "old criterion" does not
Marcus> fit for standards, me and other people don't feel so. I think
Marcus> there are reasons for both point of views, but you should be
Marcus> prepared to bring more reasons in the discussion than
Marcus> "standards mustn't be subverted".
Do I really noeed say more? Diluting standards by
proliferating zillions of slightly modified documents destroys the
validity and acceptance of the standard. I think such fears are
reasonable on the part of standards authors, and that they do not
harm the community. Why should they not be acceptable in main?
Marcus> In my opinion, the license is the wrong place to force the
Marcus> acceptance of a standard. A standard should be convincing by
Marcus> technical means.
A compelling standard, which everyone accepts and proceeds to
hack "just a little bit" produces a plethora of incompatible
documents, and no matter how compelling it may be technically, no one
would pay much atttention to it, because there is no one
standard. (Similar problems were the cause of the fall from grace for
UNIX).
>> I seem to see people having a knee jerk reaction about this --
>> we strongly advocate the DFSG for software, so it must be good for
>> everything else -- but I think if you examine *why* we advocate free
>> software, and what that says about community building, that the same
>> conditions do not apply here.
Marcus> I think I provided some reasons why they still apply in my
Marcus> original post, and other pointed out even more. Could you go
Marcus> back please and pick up specific points?
Refresh our minds. I fail to see any convincing reasons in the
postings that have not yet expired, apart from statements of genral
desirability.
Marcus> Remember that we promise our users that the Main distribution
Marcus> is free, completely. There are already subtle but valid
Marcus> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Marcus> exceptions (copyright licenses, emails). We have to make a
Marcus> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Marcus> decision where to draw the line.
>>
>> So, we are going to throw out the GPL and the artistic licence
>> from the distribution? I think that would be extremely silly.
Marcus> Yes, this is getting silly. Please READ what I wrote,
Marcus> otherwise I can't help you. (It is quoted above for your
Marcus> reference, I marked the relevant sentence).
In my opinioin, we should add standards documents to that
category. Unlike software, mutability of standards is a bad thing (if
everyone is fllowing a different document, then there _is_ no
standard)
Marcus> As you seem to agree that "orig source with patches", "name
Marcus> change" and "marking changes" is okay, and those are already
Marcus> granted by the dfsg, I don't know what you are argueing
Marcus> here. Should we also allow further restricitions than those
Marcus> already allowed by the dfsg? Please name them.
>>
>> I think we are not yet rready to name them. I have pointed out
>> a few cases where the DFSG may be too limited because it was designed
>> to cover software issues. If we are trying to define acceptable
>> document licences, I think we may have to rethink the issues
>> involved.
Marcus> This is not helping very much. Remember, being professional
Marcus> means staying close to the subject.
Jumping to conclusions withpout adequate thought is quite
unprofessional.
Marcus> The subject is to discuss what exceptions are to be allowed,
Marcus> and I posted a long mail (it is put on the web, too, under
Marcus> master.debian.org/~brinkmd/frre_doc/index.html), where I
Marcus> think I summarized most of the valid exceptions.
Add standards, fiction, graphic novels, etc to that, and you
shall be closer to the desired list of exceptions.
Marcus> If you think the DFSG is not acceptable for all *technical
Marcus> documents*, please specify which technical documentation
Marcus> should be subject to special considerations and why.
Documents that define the behaviour of software should be
licenced under the same terms as the software itself; so if the
software is DFSG free, so should the documents be.
Standards should not be, as well as the exceptions you have
noted (add fiction etc, to that list as well)
Every thing else I am willing to talk about ;-)
Marcus> Also, you never answered me my questions what documents you
Marcus> consider as "standards" (have we a good way to decide the
Marcus> question "Is this document a standard?").
Common sense? What has the document been written for? If it is
written to allow others (distinct from the creators) to write
software or otherwise collaborate; it it is a set of protocols or
interfaces, it is likely to be a standard. The third party clause is
essential; I can't create rules or policy that only I fllow and call
it a standard.
manoj
--
We give advice, but we cannot give the wisdom to profit by it. Duc de
La Rochefoucauld (A word to the wise is--unnecessary.)
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
