Re: [rms@gnu.org: Free Software Needs Free Documentation]
Hi,
>>"Marcus" == Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
Marcus> On Mon, Aug 10, 1998 at 12:13:01AM -0500, Manoj Srivastava wrote:
Marcus> On Sun, Aug 09, 1998 at 05:28:45PM -0500, Manoj Srivastava wrote:
Marcus> I can understand that people have that fear, but I think it
Marcus> is not substantiated (at least within the free osftware
Marcus> community), and therefore should not be taken into account in
Marcus> this discussion.
>>
>> Not so. Our fears of trojan horses have never been
>> instantiated. Our fears about people destroyin our CVS data have
>> never been instantiated. Does that mean we do not plan and take
>> precautions? This is a groundless argument.
Marcus> This is a groundless argument? Not quite so. The softwrae
Marcus> examples show thatq there are other ways to take
Marcus> precautions. The whole free software movement shows this. The
Marcus> precautions don't have to be set in the license.
Really? The way the whole free software community has reacted
is by supplying source code, so you may look at it before putting it
on your machine. Binary only software, and security related sources,
have had better, more stringent precautions. The free software
community has never been in favour of downloading binary only
software; that is deemed too dangerous.
Marcus> Trust is one thing, honesty another. Silly changes to
Marcus> standards will be followed by nobody, especially not by
Marcus> Debian.
You are being too naive about this, I think, if you think
people do not make changes to standards that appear silly (Java is
supposed to be protable, right? Is not building ActiveX and windows
support into the standard silly?)
Marcus> Taking precautions is one thing, making improvements
Marcus> impossible in the first place another.
Create your own standard, and improve it. One there is a
standard that one accepts, one should also accept that changes come
from upstream sources -- the authors. In this I think standards
differ from software -- wider acceptance and conformity is a goal for
standards, working well, though different from other implementations
is a goal for software.
Marcus> Some people are frightened about their software, too, and
Marcus> forbid disassembling etc. We don't allow this software in
Marcus> main.
>>
>> We have a reason. It has to do with sharing. It has to do with
>> being able to see what is going on, and not being locked in to a
>> vendor. Part of that does not apply to documents, and the sharing
>> aspect is actually enhanced if we can trust we all follow the same
>> standard, not w locally modified version of what used to be a common
>> but is not more standard.
Marcus> This is your opinion. My opinion is that the same reasons
Marcus> apply so that we are not being locked in by silly standards.
If the standard is silly, do not follow them. Noone has a gun
to your head. Create your own set of rules, if you wish.
Marcus> IMHO, locally modified versions of a standard are better than
Locally modified and standard in the same sentrence are
oxymorons. Standard means something that everyone follows. We modify
it locally, then only we are following it -- not a standard anymore.
Marcus> nobody following an insufficient standard at all and everyone
Marcus> making up his own "standard".
When you modify a standards document, you have indeed made up
your own strandard. At least we agree on this point -- evryone
modifying a standard to create their own strandard is a bad thing.
Marcus> Eventually someone will step up and merge all differences
Marcus> into a single standard again (as it happened with apache, for
Marcus> example. Sorry for the software analogy).
You are talking implementations which differe from a standard,
and a standards body looking at current art when updating a standard
-- that is the way to go. Creating non-conformant applications if the
standard is deficient.
I can't think of one case where there were a bunch of
divergent standards that were merged back in. All over, I see the
standards body looking at non-conformant implementations and updating
the standard; but I do not see the standard itself diverging and
converging. The distinction is important.
>> >> No, I'm not. What I am saying is that I can see authors not
>> >> wanting their baby to be modified and distorted, and releasing
>> >> standards under no-modification-or-translation terms, and I do not
>> >> see this as a threat to the community, indeed, it is not even
>> >> detrimental.
>>
Marcus> It is okay for authors to think and act this way, but I don't
Marcus> think we can distribute technical documents with this
Marcus> restrict copyright in main.
>>
>> Reasons, please.
Marcus> Read them up, I'll not repeat myself over and over again:
Marcus> http://master.debian.org/~brinkmd/free_doc/index.html
Marcus> and the various postings in this thread.
I read those. There are no reason there. You state whether the
DFSG is applicable or not, which is an opinion. stated there. Why is
the clause applicable? Why is it not applicable? You do not say.
Tehre are some reasons detailing the exceptions, which is
good. And I agree about most of that (see the benefit of providing
reasons and rationale?) except for that of standards.
The reason you can't just hack up a standard and pretend it is
OK is becuse no-one else would be following your local hacks, and the
reason for a standard would bve lost: that different entities can
depend on each other since they alkl follow the same rules.
If everyone modified the rules, then no one is following the
same standard, and there is, in fact no standard that is being
followed.
It is better, in fact, not to be fully compliant to a public
standard that to start a flood of different standards so that no one
can depend on what "following the standard" means.
Marcus> Example: Some people would not like to have bash scripts
Marcus> ported to csh, because they consider csh scripts as
Marcus> insecure. We don't allow authors to put restrictions like
Marcus> that.
>>
>> This is not the same case at all (please try not to mix
>> software examples into this, they just confuse the issue).
Marcus> This was an analogy, sorry for stretching your
Marcus> imagination. See below for the "translation" of the analogy
Marcus> into the topic.
Firstly, can we just discuss this things without calling ewach
other stupid and unimaginative? Huh? Seems to me you must be loosing
the argument, that you see the need to attack the people.
This is a very broken analogy. Software comes with baggage and
implications that are totally dofferent from thhose a standard come
with. Yuo are trying to compare apples to oranges.
Marcus> Another complication is indeed were documentation is mixed up
Marcus> with source code, I'mnot sure if I want to touch this topic
Marcus> for now.
Documentation of software is a totally different issue, and on
that one I agree with you.
>> This is borderline. However, the resistance to translation
>> could be that some things do not translate well (peotry is one). For
>> some works of art, translation is artistic butchery. I can see why
>> people may not want that to happen.
Marcus> Manoj, again you are confusing two issues:
Marcus> Poetry: You can't stop me translating it. Translations are
Marcus> considered a work by themselfes, where the copyright is
Marcus> holding the translator. I can take whatever art work and
Marcus> translate it, without considering copyright issues, and
Marcus> without considering the opinion of the original author.
BINGO!! It is a totally separate peice of work, and unrelated
to the original, and has different coprights. You said it. So the
original standard can be immutable, and you can still translate it?
Perfect. One more reason to allow immutable standards documents.
>> >> As long as one may create a standard that borroes from the
>> >> inital standard, but is distinct, and has a distinct name, I think it
>> >> is OK to allow the document into main.
>>
Marcus> This comes closer to our needs. But now you are fleeing in
Marcus> generalizations. What do you mean with "borrow"? We can't
Marcus> make policy with such vague terms, so we should keep on the
Marcus> safe side with terms we have experiences with.
Fleeing in generalizations? Yes, so we may find sme common
ground to work our way to specifics. Jumping to specifics without
thought does not help make policy either. We should find something we
can agree on, before we worry about language being fit for policy.
By borrow, I mean "derive a different work based on a prior
one". The new work is distinct from the original. The original work
is unchanged, you havge created a new work.
>> Like your example licence borrowed heavily from the GPL. The
>> GPL is not modifiable; but your license is likely to be allowed as
>> long as it does not pretend to be the GPL.
Marcus> Ok.
See? I had already explained it.
>> How about an original Graphic Novel? How about James Joyces
>> "Ullyses"? Do you approve af people punctuating Joyce's books?
Marcus> Shall I repeat myself? I already stated that I think art works and
Marcus> expression of personal opinions should be treated special.
Fine. I agree, so we do not have to discuss this further.
>> >> I am not really talking about ideal licencing here (marcus and
>> >> RMS and co are doing that). I am talking about wht I think is
>> >> detrimental to the community, and shold not be in main, and what I
>> >> think does not harm the community, and, IMHO, should be allowed into
>> >> Debian.
>>
Marcus> I'm also not discussing perfect world here. Reality requires
Marcus> clear terms. We have to decide if we want to allow
Marcus> non-dfsg-free data entities at all, and when, which under
Marcus> which additional restrictions.
>>
>> The discussion is a good start. But we have a long way to go
>> before we can come up with something.
Marcus> Fleeing in generalizations will not help us. Concrete points will.
Concrete ponts that are so far apart that we do not have
common ground lead to endless flamage. That helps even less. As it
stands, we totally oppse the specifics we have been coming up with. I
also think we are jumping the gun, going and specifying the details
before we have agreed to the big picture.
We are loosing ourselves looking at the trees, and we are
missing the forest.
Marcus> Please don't misunderstand me: I think we have seen many good
Marcus> and concrete points in the discussion so far. I just want
Marcus> that it stays so.
You want us to reach a conclusion, or not? I am willing to
keep looking at specifics and disagreeing until we are blue in the
face. Moving to a conclusion requires we actually cvome
closer. Starting with common ground and working our way to the
details is a way of resolving this.
manoj
--
When a man venerates those worthy of veneration, be they Buddhas or
their disciples, who have transcended all obstacles and passed beyond
sorrow and tears - venerating such as these, whose passions are
extinguished and for whom there is no further source for fear, no one
can calculate how great his merit is. 195, 196
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: