Re: What RMS says about standards
Hi,
>>"Joseph" == Joseph Carter <knghtbrd@earthlink.net> writes:
Joseph> No, we can all agree that Free Software is important. It
Joseph> seems like a very good split as to whether or not every
Joseph> collection of words included on the CD (licenses, standards
Joseph> documents, lg) or else they can't be accepted into main.
There were sme fairly strong objections to putting them in
main. And I don't think that contrib or non-free are justified
either.
Joseph> Saying that these things should instead go into a "verbatim"
Joseph> section is going to complicate things greatly. Arguably
Joseph> there is not enough content that would belong in this section
Joseph> to warrant dists/slink/verbatim/binary-all (it would have to
Joseph> be binary-all considering..)
Umm. I think there have been enough examples already to
populate the dists/slink/verbatim/binary-all, to an extent. Since Apt
can already take multiple archives, I don't see size as a big issue
-- if it needs be done, it needs be done.
Are we now using convenience to militate against doing the
right thing? If we decide that verbatim is the right thing to do, we
should not let (minor) inconvenience stand in our way.
Joseph> ISSUE: What should be done with packages which happen to
Joseph> include some content which is software and some content which
Joseph> is documentation. The software is free because it's software
Joseph> and the documentation is "submit any changes you'd like
Joseph> upstream but don't distrubute modded versions" to protect the
Joseph> integrity of the document. Then what? Are you going to tear
Joseph> apart a package in main that shouldn't be torn apart just to
Joseph> put the document portion in a verbatim dist? Tearing apart
Joseph> such a package might not be technically sound and would be
Joseph> giving others free ammunition to use against Debian and free
Joseph> software in general.
We have already agred that documentation of the software
should be considered a part of the software and have the same
license. Whether or not one tears apart packages has yet to be
decided; I think no one actually proposed tearing them up. Some
wiggle room remains in our stance.
Joseph> Does policy even allow recommends on packages in main to
Joseph> packages outside main? I would argue that in my above
Joseph> example suggests may not be suitable.
Policy is not a moribund document set in stone. And this is
not a reason not to do verbatim; if we create a verbatim
distribution, policy can be changed to say that the packages in
Debian (main,verbatim) should not depend on packages not in Debian
(main,verbatim).
This is not a big deal.
Joseph> ISSUE: People talking about putting licenses in this verbatim
Joseph> dist should Stop Right Now.
;-). This is really convincing.
Joseph> We can't legally do that in many cases and we should not be
Joseph> doing it at all!
The latter is still moot.
Joseph> Besides, I have already pointed out that because of what a
Joseph> license is, it CAN be modified with or without permission and
Joseph> applied to another product.
Really? One can take a copyrighted docuemnt, and modify and
distribute it at will? I, and the laws of the united states, beg to
differ.
Joseph> Take the BSD license, we have seen 2, 3, and 4 clause
Joseph> versions. The 4 clause version is of course the actual BSD
Joseph> license, but the 2 and 3 clause versions are used because
Joseph> people don't like that 4th clause and don't want it to apply
Joseph> to their software. The BSD license grants no permission to
Joseph> do this. If it were copyright violation to change this
Joseph> license, then ANY package under a "BSD style" license which
Joseph> isn't the full advertising clause version of the BSD license
Joseph> would not be able to be part of Debian. Think about that and
Joseph> how much software you would be removing. How does that
Joseph> affect PR?
I think that you have indeed pointed out illegal
modifications. How many packages arte guilty of this? Breaking the
law is not great PR either. And we did the right thing, and did not
bow to PR, over the pine issue. Why start now?
>> And while I do agree that PR is important; I would not let PR
>> dictate the policy rhtather than technical merit; and what we feel is
>> right.
Joseph> See above. There are at least two very good reasons why this
Joseph> is a bad idea. Technical,
I think I disagree that this is technically a bad idea. As I
said, policvy can be changed if we so decide.Adding a verbatim along
with main is fairly trivial; especially with Apt.
Joseph> legal,
I think you are misinformed, or being parochial. Licenses
can't be modified at will in the united states (where our main
distribution resides); there is no requirement that is not satisfied
by having the licenses on a) every debian box; b) every CD, and c) on
every archive of Debian. What other legal objections do you see?
Joseph> and political.
This is the worst of the lot. You are arguing that we should
not do what is right, merely on the basis of politics. What's next,
bring pine back in because of politics? Start introducing packages
back in main because of politics?
Joseph> Not to mention the common sense argument that creating
Joseph> slink/verbatim for just the tiniest handful of packages and
Joseph> saying from then on that we will happily allow and distribute
Joseph> non-free docs if they're in that section is probably a bad
Joseph> idea.
You really have not being paying attention. No one ever said
that non-free or non-mutable documentation goes in verbatim. Please
read what the proposal is before objecting to things.
Again, this tiniest handful argument is really not relevant,
if it is the right thing to do.
Joseph> And creating a main/verbatim section would leave them
Joseph> in main anyway, resulting in absolutely no change other than
Joseph> making a big deal over something we cannot realistically
Joseph> affect at this time.
That is a good argument against a main/verbatim section.
manoj
--
Why is it called a funny bone when it hurts so much?
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: