Amendment to GR on GFDL, and the changes to the Social Contract
Frank Küster
the text of the amendment says at its very end:
,----
| Since this amendment would require modification of a foundation
| document, namely, the Social Contract, it requires a 3:1 majority to
| pass.
`----
But AFAICS it does not propose a textual change to the SC, just a change
of its meaning, or interpretation or whatever. I have a couple of
questions about this:
- Has this been done previously? If yes, where can I find a collection
of all decisions that have thus "changed" the SC?
- Shouldn't we add a sentence to the SC, something like "In a couple of
cases, the interpretation of this Social Contract or how it should be
spelled out in technical details was controversial among the project,
and votes have been taken. The results of these votes are at
<hyperlink>"?
As for the intention of the amendment, it seems to me that it relies
heavily on the assumption that the excempted clauses are simply bugs of
the license text and not the actual intention. Given how bad
communication with the FSF was wrt to the GFDL, I doubt that we can sure
about this...
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Adeodato Simó
> Hi,
Hi. Just a clarification:
> the text of the amendment says at its very end:
^^^^^^^^^^^^^^^^^^^^^
> ,----
> | Since this amendment would require modification of a foundation
> | document, namely, the Social Contract, it requires a 3:1 majority to
> | pass.
> `----
As can be inferred by reading the original text amendment [1], the
sentence quoted above was added by the Secretary (it was his duty to
do so, if he understood that such majority requirement was applicable).
[1] http://lists.debian.org/debian-vote/2006/01/msg00060.html
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
As scarce as truth is, the supply has always been in excess of the demand.
-- Josh Billings
--
To UNSUBSCRIBE, email to debian-vo...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Adeodato Simó
> The fact that the license is buggy does not change the fact
> that works licensed under it would violate the DFSG. Given that, any
> resolution to allow these works to remain in Debian would require a
> rider to be added to the SC, something of the form:
> - Debian will remain 100% free
> + Debian will remain 100% free, apart from works licensed under the GFDL
> (the exact wording can be decided upon if the amendment passes).
> Since this requires a modification of a foundation document,
> the amendment requires a 3:1 majority.
I don't see why this _physical modification_ is necessary. I can admit
that the secretary says "this amendment overrules the social contract,
since it talks about putting non-free things in main, so it requires a
3:1 majority"; but if the amendment passes, and so the GR issues a
statement that some GFDL documents will remain in main, I don't think
explicit wording is needed _in_ the SC, at all.
Or so.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Arguing with an engineer is like wrestling with a pig in mud: after a
while, you realize the pig is enjoying it.
Debian Project Secretary
> Hi, the text of the amendment says at its very end:
> ,----
>> Since this amendment would require modification of a foundation
>> document, namely, the Social Contract, it requires a 3:1 majority
>> to pass.
> `----
> But AFAICS it does not propose a textual change to the SC, just a
> change of its meaning, or interpretation or whatever.
I am afraid I was responsible for that rider. I should
apologize for not sending a clarification earlier, but I was
inadvertently away from my keyboard since my laptop's graphics card
died just as I was going off on a business trip
> I have a couple of questions about this:
> - Has this been done previously? If yes, where can I find a
> collection of all decisions that have thus "changed" the SC?
Err, we have had two GR's that changed the SC -- the so called
"editorial changes" GR, and the GR that deferred the changes for
Sarge. But in each case we followed through and changed the text of
the SC.
> - Shouldn't we add a sentence to the SC, something like "In a couple
> of cases, the interpretation of this Social Contract or how it
> should be spelled out in technical details was controversial among
> the project, and votes have been taken. The results of these
> votes are at hyperlink> "?
> As for the intention of the amendment, it seems to me that it relies
> heavily on the assumption that the excempted clauses are simply bugs
> of the license text and not the actual intention. Given how bad
> communication with the FSF was wrt to the GFDL, I doubt that we can
> sure about this...
The fact that the license is buggy does not change the fact
that works licensed under it would violate the DFSG. Given that, any
resolution to allow these works to remain in Debian would require a
rider to be added to the SC, something of the form:
- Debian will remain 100% free
+ Debian will remain 100% free, apart from works licensed under the GFDL
(the exact wording can be decided upon if the amendment passes).
Since this requires a modification of a foundation document,
the amendment requires a 3:1 majority.
manoj
--
signal(i, SIG_DFL); /* crunch, crunch, crunch */ Larry Wall in doarg.c
From the perl source code
Debian Project Secretarty <secr...@debian.org> <http://vote.debian.org/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Frank Küster
> * Debian Project Secretary [Thu, 19 Jan 2006 10:12:50 -0600]:
>
>> Since this requires a modification of a foundation document,
>> the amendment requires a 3:1 majority.
>
> I don't see why this _physical modification_ is necessary. I can admit
> that the secretary says "this amendment overrules the social contract,
> since it talks about putting non-free things in main, so it requires a
> 3:1 majority"; but if the amendment passes, and so the GR issues a
> statement that some GFDL documents will remain in main, I don't think
> explicit wording is needed _in_ the SC, at all.
I disagree - either the interpretation of the SC allows GFDL'ed
documents without invariant (et al) sections, then we don't need a 3:1
majority, or it doesn't - then we have to change it if we want to keep
our promises.
Frank Küster
> The fact that the license is buggy does not change the fact
> that works licensed under it would violate the DFSG. Given that, any
> resolution to allow these works to remain in Debian would require a
> rider to be added to the SC, something of the form:
> - Debian will remain 100% free
> + Debian will remain 100% free, apart from works licensed under the GFDL
> (the exact wording can be decided upon if the amendment passes).
>
> Since this requires a modification of a foundation document,
> the amendment requires a 3:1 majority.
I think the text should rather be fixed before the vote.
Adeodato Simó
On second thoughts...
> The fact that the license is buggy does not change the fact
> that works licensed under it would violate the DFSG.
The amendment intentionally talks only about what Debian is going to
do ("allow invariant-less in main"), which is what most people from
outside are interested in hearing anyway, and does not talk about what
needs overruling to achieve that.
It seems, by my reading of the Constitution, that it's the task of the
Secretary to determine who is being overruled and thus what majority
is needed. And the Secretary's opinion is:
(a) this amendment overrules the Social Contract by putting non-free
bits in main, and thus needs 3:1
However, I'm pretty sure that more than one Developer thinks the
proper interpretation would be:
(b) this amendment overrules debian-legal's assessment that certain
two clauses of the GFDL are non-free, and thus needs 1:1
How this gets handled, that I don't know, but I can imagine.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Guy: My dad made my mom have a cesarean when she had my little brother.
He wanted to make sure he was born in the 1986 tax year so he could get
another tax credit.
-- http://www.overheardinnewyork.com/archives/002968.html
Christopher Martin
> However, I'm pretty sure that more than one Developer thinks the
> proper interpretation would be:
>
> (b) this amendment overrules debian-legal's assessment that certain
> two clauses of the GFDL are non-free, and thus needs 1:1
Right. To declare that the amendment would constitute a modification of a
foundation document is to presuppose the very issue that this amendment
seeks to clarify, namely, whether or not the GFDL-minus-invariant-sections
is indeed non-free. If the amendment passes, then
GFDL-minus-invariant-sections docs would not be considered non-free, and so
could be allowed in main without any special dispensation. The amendment is
not intended to declare that we should suspend the DFSG for the sake of
expediency; such a proposal would indeed require a 3:1 supermajority.
Rather, it simply promulgates the interpretation that the GFDL, minus
invariant sections, while not perfect, is still DFSG-free.
No GR has declared the GFDL-minus-invariant-sections to be non-free. The GRs
only decided to extend the DFSG to all of Debian, and then to postpone the
application of this rule until after Sarge. The GFDL (with or without
invariant sections) has been declared non-free with much controversy only
by a very small set of developers, largely active on debian-legal, a body
with no constitutional standing. While the Project finds it expedient to
respect the general debian-legal consensus on most issues to avoid endless
GRs on every subject, where there is a strong division of opinion within
the developer body, or the decision will have important consequences, a GR
to establish a license's status within the framework of the foundation
documents seems wholly appropriate.
The Project Secretary would be overstepping his or her authority to declare
the interpretation of the license being proposed to be fundamentally in
violation of the foundation documents _prior_ to any vote on the subject.
He or she may hold a strong personal view on the matter, but cannot impose
that view on the general shape of the vote.
If the Secretary views the amendment as insufficiently clear as to what it
is attempting to establish, then he or she can always request
clarification.
Cheers,
Christopher Martin
Josselin Mouette
> Rather, it simply promulgates the interpretation that the GFDL, minus
> invariant sections, while not perfect, is still DFSG-free.
But if this amendment passes, we would still have to modify the DFSG for
the sake of consistency.
--
.''`. Josselin Mouette /\./\
: :' : josselin...@ens-lyon.org
`. `' jo...@debian.org
`- Debian GNU/Linux -- The power of freedom
Christopher Martin
> Le jeudi 19 janvier 2006 à 18:05 -0500, Christopher Martin a écrit :
> > Rather, it simply promulgates the interpretation that the GFDL, minus
> > invariant sections, while not perfect, is still DFSG-free.
>
> But if this amendment passes, we would still have to modify the DFSG for
> the sake of consistency.
No, because as I wrote the whole point of the amendment is to make
officially acceptable the interpretation of the license which views the
license as flawed, but still DFSG-free. This amendment is in no way arguing
for any sort of exception or modification or suspension of the DFSG.
Therefore, no modification of the DFSG would be required after the passage
of the amendment, since it would have been decided by the developers that
there was no inconsistency.
If you personally disagree with this, and believe that the GFDL, even
without invariant sections, is inconsistent with the DFSG, then you may
vote against the amendment. My above post was not intended to persuade the
developers that they should vote for the amendment. Rather, it was
attempting the clarify the proper status of the amendment, and therefore to
correct the requirements for passage which the Secretary seems to have put
upon it.
Cheers,
Christopher Martin
Manoj Srivastava
> I think the text should rather be fixed before the vote.
I have no objection if people want to hammer out the wording a
priori.
manoj
--
Technology is dominated by those who manage what they do not
understand.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava
> * Debian Project Secretary [Thu, 19 Jan 2006 10:12:50 -0600]:
>> The fact that the license is buggy does not change the fact that
>> works licensed under it would violate the DFSG. Given that, any
>> resolution to allow these works to remain in Debian would require a
>> rider to be added to the SC, something of the form:
>> - Debian will remain 100% free
>> + Debian will remain 100% free, apart from works licensed under the
>> GFDL
>> (the exact wording can be decided upon if the amendment passes).
>> Since this requires a modification of a foundation document, the
>> amendment requires a 3:1 majority.
> I don't see why this _physical modification_ is necessary. I can
> admit that the secretary says "this amendment overrules the social
> contract, since it talks about putting non-free things in main, so
> it requires a 3:1 majority"; but if the amendment passes, and so
> the GR issues a statement that some GFDL documents will remain in
> main, I don't think explicit wording is needed _in_ the SC, at
> all.
Umm, no. The social contract and the DFSG have stated the
goals of the project, and have been given prominent status on the web
site, and in other pronouncements. We hould not add codicils and
riders that alter the meaning of the SC and not modify the SC
document itself to record these modifications.
manoj
--
Try to divide your time evenly to keep others happy.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava
> On Thursday 19 January 2006 12:09, Adeodato Simó wrote:
>> However, I'm pretty sure that more than one Developer thinks the
>> proper interpretation would be:
>>
>> (b) this amendment overrules debian-legal's assessment that certain
>> two clauses of the GFDL are non-free, and thus needs 1:1
> Right. To declare that the amendment would constitute a modification
> of a foundation document is to presuppose the very issue that this
> amendment seeks to clarify, namely, whether or not the
> GFDL-minus-invariant-sections is indeed non-free.
I'm sorry, whether or not something meets the requirements of
the DFSG is not entirely a matter of opinion. While I agree there are
grey areas where it can be hard to determine whether or not something
is non-free, it is not my belief that the GFDL falls in that
category, and hence my ruling that in order to ship GFDL licenced
works in main one needs to modify the SC itself.
> If the amendment passes, then GFDL-minus-invariant-sections docs
> would not be considered non-free, and so could be allowed in main
> without any special dispensation. The amendment is not intended to
> declare that we should suspend the DFSG for the sake of expediency;
> such a proposal would indeed require a 3:1 supermajority. Rather,
> it simply promulgates the interpretation that the GFDL, minus
> invariant sections, while not perfect, is still DFSG-free.
It is my opinion that this is trying to legislate a fallacy.
> No GR has declared the GFDL-minus-invariant-sections to be
> non-free. The GRs only decided to extend the DFSG to all of Debian,
> and then to postpone the application of this rule until after
> Sarge. The GFDL (with or without invariant sections) has been
> declared non-free with much controversy only by a very small set of
> developers, largely active on debian-legal, a body with no
> constitutional standing. While the Project finds it expedient to
> respect the general debian-legal consensus on most issues to avoid
> endless GRs on every subject, where there is a strong division of
> opinion within the developer body, or the decision will have
> important consequences, a GR to establish a license's status within
> the framework of the foundation documents seems wholly appropriate.
I would be willing to listen to arguments why GFDL licensed
works without invariant sections are not DFSG free with an open
mind. However, my current reading of the situation is that they
indeed do not meet DFSG requirements.
> The Project Secretary would be overstepping his or her authority to
> declare the interpretation of the license being proposed to be
> fundamentally in violation of the foundation documents _prior_ to
> any vote on the subject. He or she may hold a strong personal view
> on the matter, but cannot impose that view on the general shape of
> the vote.
I am, in my position as secretary, interpreting the
constitution, and the foundation documents, as well as the proposals
and vlaoots for the forthcoming GR.
> If the Secretary views the amendment as insufficiently clear as to
> what it is attempting to establish, then he or she can always
> request clarification.
I donot believe the proposal is unclear. I understand what the
intent of the proposal is, and I also believe that no matter how many
people state that something factual is incorrect, that does not make
it so.
manoj
--
Pascal is a language for children wanting to be naughty. Dr. Kasi
Ananthanarayanan
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Don Armstrong
> No, because as I wrote the whole point of the amendment is to make
> officially acceptable the interpretation of the license which views
> the license as flawed, but still DFSG-free. This amendment is in no
> way arguing for any sort of exception or modification or suspension
> of the DFSG.
The issue here devolves into a question of interpretation; if we can
decide to interpret the Foundation Documents in any way we want simply
by a majority vote, the requirement to have changes to them meet a 3:1
majority becomes rather pointless.
Don Armstrong
--
Filing a bug is probably not going to get it fixed any faster.
-- Anthony Towns
Christopher Martin
> I'm sorry, whether or not something meets the requirements of
> the DFSG is not entirely a matter of opinion. While I agree there are
> grey areas where it can be hard to determine whether or not something
> is non-free, it is not my belief that the GFDL falls in that
> category, and hence my ruling that in order to ship GFDL licenced
> works in main one needs to modify the SC itself.
You must separate your personal certainty in the GFDL's non-freeness from
your actions in the capacity of Project Secretary.
> It is my opinion that this is trying to legislate a fallacy.
It is not up to the Project Secretary to declare controversial licenses,
over which many developers disagree, DFSG-free or not, which is precisely
the power your decision arrogates. You may think the amendment
fundamentally fallacious, but that's not your decision to make. The
Secretary has some power to adjudicate issues of constitutional
interpretation, but the DFSG is not the constitution. The Secretary is not
charged with defending the purity of "main" with respect to the DFSG. A GR
is the appropriate place to decide this issue, yet you have prejudged it by
saddling the amendment with the supermajority requirement.
> I would be willing to listen to arguments why GFDL licensed
> works without invariant sections are not DFSG free with an open
> mind. However, my current reading of the situation is that they
> indeed do not meet DFSG requirements.
You are entitled to this reading, but as Project Secretary you are not
entitled to determine this for everyone else. As stated above, this is an
issue which a GR can and should settle, not the Project Secretary.
Again, please consider rescinding the supermajority requirement for the
amendment.
Thanks,
Christopher Martin
(I'm subscribed to d-vote now, so no CCs required; before I only read the
d-vote archive at regular intervals)
Christopher Martin
> On Thu, 19 Jan 2006, Christopher Martin wrote:
> > No, because as I wrote the whole point of the amendment is to make
> > officially acceptable the interpretation of the license which views
> > the license as flawed, but still DFSG-free. This amendment is in no
> > way arguing for any sort of exception or modification or suspension
> > of the DFSG.
>
> The issue here devolves into a question of interpretation; if we can
> decide to interpret the Foundation Documents in any way we want simply
> by a majority vote, the requirement to have changes to them meet a 3:1
> majority becomes rather pointless.
This is a real dilemma faced by all constitutions or similar charter
documents. Unfortunately, all constitutions can be undermined by the
reinterpretation of seemingly small details. But one person's "undermining"
is another person's "upholding".
The important question here is one of legitimacy. Who exactly has the
authority to determine these matters of interpretation? Specifically, who
decides what is in accordance with the DFSG? The developers do, through
GRs, if I understand correctly. Certainly nothing in my reading of the
Constitution suggests that the Secretary has this power.
The Secretary seems to be adopting the view that anyone who disagrees with
his interpretation of the GFDL is not holding a legitimate opinion. Given
the length of the GFDL debates, the acrimony, and the number of developers
who remain on both sides, this seems far, far too strong a stance for a
Project officer to adopt (even if Manoj holds that view personally). Hence
my complaint.
Cheers,
Christopher Martin
Don Armstrong
topic there.]
On Thu, 19 Jan 2006, Christopher Martin wrote:
> On Thursday 19 January 2006 20:39, Don Armstrong wrote:
> > On Thu, 19 Jan 2006, Christopher Martin wrote:
> > > No, because as I wrote the whole point of the amendment is to make
> > > officially acceptable the interpretation of the license which views
> > > the license as flawed, but still DFSG-free. This amendment is in no
> > > way arguing for any sort of exception or modification or suspension
> > > of the DFSG.
> >
> > The issue here devolves into a question of interpretation; if we
> > can decide to interpret the Foundation Documents in any way we
> > want simply by a majority vote, the requirement to have changes to
> > them meet a 3:1 majority becomes rather pointless.
>
> The important question here is one of legitimacy. Who exactly has
> the authority to determine these matters of interpretation?
The Secretary has the authority to adjudicate constitutional disputes
of interpretation under §7.1.2.[1] Since modifying the Foundation
Documents requires a modification to the constitution, it seems
reasonable that the secretary would adjudicate whether a particular GR
would require such a modification to remain consistent.
> Given the length of the GFDL debates, the acrimony, and the number
> of developers who remain on both sides, this seems far, far too
> strong a stance for a Project officer to adopt (even if Manoj holds
> that view personally). Hence my complaint.
A stance has to be made one way or the other; either way involves a
personal weighing of whether the acceptance of a particular license as
acceptable in main violates the DFSG itself; either decision will
cause some to be unhappy. Indeed, the very fact that we've had 2
previous GRs on this very issue which required a modification of the
DFSG to do so seems to indicate that the project has decided on
multiple occasions that 3:1 majorities were required to deal with the
current version of the GFDL.
Don Armstrong
1: Odly enough, it's not clear that the developers can override a
decision that the Secretary has made,[2] although I'd be surprised if
a Secretary would fail to heed a clear overriding vote.
2: Well, by some other manner than electing a DPL who will fail to
reappoint the secretary and then revisiting the decision...
--
You could say she lived on the edge... Well, maybe not exactly on the edge,
just close enough to watch other people fall off.
-- hugh macleod http://www.gapingvoid.com/batch8.htm
Manoj Srivastava
<chrs...@debian.org> said:
> The important question here is one of legitimacy. Who exactly has
> the authority to determine these matters of interpretation?
> Specifically, who decides what is in accordance with the DFSG? The
> developers do, through GRs, if I understand correctly. Certainly
> nothing in my reading of the Constitution suggests that the
> Secretary has this power.
The secretary decides on the procedure of voting on a GR, and
the final form the ballot may take. The secretary arrives at these
decisions based on their best interpretation of the situation at
hand.
> The Secretary seems to be adopting the view that anyone who
> disagrees with his interpretation of the GFDL is not holding a
> legitimate opinion. Given the length of the GFDL debates, the
> acrimony, and the number of developers who remain on both sides,
> this seems far, far too strong a stance for a Project officer to
> adopt (even if Manoj holds that view personally). Hence my
> complaint.
Then hold a separate GR on whether or not the GFDL meets the
DFSG -- aj's proposal, which states the GFDL licenced documents do
not meet the DFSG is not subject to the 3:1 majority requirements. By
moving to have GFDL licensed works included in main ahead of a
determination of whether or not GFDL licensed works are free or not
means that you have to accept the secretaries interpretation of
"reasonable" arguments.
Please note that I am not sure of the correctness of deciding
by popular acclaim whether or not a licensed work meets the
DFSG. But it is certainly one way of doing things.
manoj
--
Be careful when a loop exits to the same place from side and bottom.
Manoj Srivastava
> Manoj Srivastava wrote:
>> I'm sorry, whether or not something meets the requirements of the
>> DFSG is not entirely a matter of opinion. While I agree there are
>> grey areas where it can be hard to determine whether or not
>> something is non-free, it is not my belief that the GFDL falls in
>> that category, and hence my ruling that in order to ship GFDL
>> licenced works in main one needs to modify the SC itself.
> You must separate your personal certainty in the GFDL's non-freeness
> from your actions in the capacity of Project Secretary.
As project secretary, I have to determine the best form of the
ballot for this GR. My determination is that the amendment requires a
3:1 super majority, and is based on my best analysis of the situation
before us.
>> It is my opinion that this is trying to legislate a fallacy.
> It is not up to the Project Secretary to declare controversial
> licenses, over which many developers disagree, DFSG-free or not,
> which is precisely the power your decision arrogates. You may think
> the amendment fundamentally fallacious, but that's not your decision
> to make. The Secretary has some power to adjudicate issues of
> constitutional interpretation, but the DFSG is not the
> constitution. The Secretary is not charged with defending the purity
> of "main" with respect to the DFSG. A GR is the appropriate place to
> decide this issue, yet you have prejudged it by saddling the
> amendment with the supermajority requirement.
Obviously, your course is now clear: start a process for a GR
that states that the GFDL licensed works without invariant sections
do not fall afoul of the DFSG -- which is a rather different topic
than stating we may include GFDL licensed works without invariant
sections in main, before determination that such works are indeed
free.
Unless such a determination is made, clearly, by the
developers, and can override the determination made by the delegates
of the project, the release team/ ftp masters, you are subject to the
interpretations of the delegates.
>> I would be willing to listen to arguments why GFDL licensed works
>> without invariant sections are not DFSG free with an open
>> mind. However, my current reading of the situation is that they
>> indeed do not meet DFSG requirements.
> You are entitled to this reading, but as Project Secretary you are
> not entitled to determine this for everyone else. As stated above,
> this is an issue which a GR can and should settle, not the Project
> Secretary.
So start the GR. This is not it. This is a GR about a position
statement.
> Again, please consider rescinding the supermajority requirement for
> the amendment.
You know how to override the project secretary.
manoj
--
"It's a fine world, though rich in hardships at times." Augustus
McCrae
Christopher Martin
> The Secretary has the authority to adjudicate constitutional disputes
> of interpretation under §7.1.2.[1] Since modifying the Foundation
> Documents requires a modification to the constitution, it seems
> reasonable that the secretary would adjudicate whether a particular GR
> would require such a modification to remain consistent.
The authority to adjudicate constitutional disputes is not the same as the
power to interpret the DFSG, which while a foundation document, is NOT the
constitution. And therefore it is not the role of the Secretary to
determine whether a license complies with the GFDL, and it is therefore NOT
within his or her power to declare that a vote on such a question of
interpretation requires a supermajority (because this would necessarily
imply a prior judgment on the DFSG-freeness of the license in question).
> A stance has to be made one way or the other;
The correct stance for the Secretary to adopt would be not to exceed his or
her powers, and therefore let the vote occur without pre-judging it by
imposing a supermajority requirement, and then accept the outcome of the
vote regardless of personal opinion.
> either way involves a personal weighing of whether the acceptance of a
> particular license as acceptable in main violates the DFSG itself;
No, no such judgement is necessary. It is not the Secretary's role to make
such judgments.
> Indeed, the very fact that we've had 2 previous GRs on this very issue
> which required a modification of the DFSG to do so seems to indicate that
> the project has decided on multiple occasions that 3:1 majorities were
> required to deal with the current version of the GFDL.
We have not had any GRs on the GFDL. That the status of the GFDL was in
people's minds when debating recent GRs is immaterial. Nothing in the GRs
refers to the GFDL, or to any other specific license.
That the previous GRs required a supermajority is due to their clear
intention to modify or suspend foundation documents, not to establish an
interpretation one specific application of them.
> 1: Odly enough, it's not clear that the developers can override a
> decision that the Secretary has made,[2] although I'd be surprised if
> a Secretary would fail to heed a clear overriding vote.
I'm not trying to override the Secretary in any formal constitutional
manner. I'm simply trying to convince him not to overstep the bounds of his
powers by making a decision which he is not entitled to make.
Cheers,
Christopher Martin
Brian Nelson
I completely agree, and hereby question whether the secretary is capable
of being impartial in this case given his personal interests[1] in this
issue.
[1] http://people.debian.org/~srivasta/Position_Statement.xhtml
--
Captain Logic is not steering this tugboat.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
Christopher Martin
> Obviously, your course is now clear: start a process for a GR
> that states that the GFDL licensed works without invariant sections
> do not fall afoul of the DFSG -- which is a rather different topic
> than stating we may include GFDL licensed works without invariant
> sections in main, before determination that such works are indeed
> free.
It was my understanding that this is what the amendment was attempting to do
- to establish a position statement stating that
GFDL-minus-invariant-sections was problematic but still DFSG-free (and
therefore acceptable in main). Is your point that the amendment wasn't
sufficiently explicit?
Then perhaps we've found a way around this impasse. If someone were to
modify/restate the amendment to be more clear, would you then consider it
as not requiring supermajority?
"Formally, the Debian Project will include in the main section of its
distribution works licensed under the GNU Free Documentation License that
include no Invariant Sections, no Cover Texts, no Acknowledgements, and no
Dedications, unless permission to remove them is granted."
This could be extended to make it even more clear that we aren't engaging in
special pleading, but view the GFDL-minus-invariant-sections as DFSG-free.
> So start the GR. This is not it. This is a GR about a position statement.
Why can't the position statement say that the license is acceptable and
DFSG-free? Why not just accept an amended amendment, if you will, rather
than force an all new GR? Previous GRs have contained multiple options with
wildly varying intentions and viewpoints before.
Cheers,
Christopher Martin
Thomas Bushnell BSG
> I completely agree, and hereby question whether the secretary is capable
> of being impartial in this case given his personal interests[1] in this
> issue.
You may question it, but it doesn't affect the case.
Thomas Bushnell BSG
> It was my understanding that this is what the amendment was attempting to do
> - to establish a position statement stating that
> GFDL-minus-invariant-sections was problematic but still DFSG-free (and
> therefore acceptable in main). Is your point that the amendment wasn't
> sufficiently explicit?
No. I understood the amendment exactly as Manoj has characterized it:
it was an amendment to permit the GFDL in, whether or not it is
DFSG-free.
Brian Nelson
> Brian Nelson <py...@debian.org> writes:
>
>> I completely agree, and hereby question whether the secretary is capable
>> of being impartial in this case given his personal interests[1] in this
>> issue.
>
> You may question it, but it doesn't affect the case.
Weeee, look at me! I'm Thomas Bushnell and I reply to every single
message on every single Debian mailing list, regardless of whether I
have anything useful to say!
--
Captain Logic is not steering this tugboat.
Manoj Srivastava
> I completely agree, and hereby question whether the secretary is
> capable of being impartial in this case given his personal
> interests[1] in this issue.
> [1] http://people.debian.org/~srivasta/Position_Statement.xhtml
And of whom are you asking this question? In every vote so
far I have had strong opinions, often sponsoring or seconding some
optoins, and have strong views on DPL candidates as well. If you
think that a secretary may not have personal views, you are naive. If
you think that it is impossible for a secretary to act impartially
given personal opinions, heck , you have just invalidated that part
of the constitutional mechanism.
manoj
--
"There is no statement so absurd that no philosopher will make it." -
Cicero, Marcus Tullius
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava
> On Thursday 19 January 2006 21:27, Don Armstrong wrote:
>> The Secretary has the authority to adjudicate constitutional
>> disputes of interpretation under §7.1.2.[1] Since modifying the
>> Foundation Documents requires a modification to the constitution,
>> it seems reasonable that the secretary would adjudicate whether a
>> particular GR would require such a modification to remain
>> consistent.
> The authority to adjudicate constitutional disputes is not the same
> as the power to interpret the DFSG, which while a foundation
> document, is NOT the constitution. And therefore it is not the role
> of the Secretary to determine whether a license complies with the
> GFDL, and it is therefore NOT within his or her power to declare
> that a vote on such a question of interpretation requires a
> supermajority (because this would necessarily imply a prior judgment
> on the DFSG-freeness of the license in question).
Since the ballot for this GR requires one to make a judgement
call on the license, I would be remiss in my duties if I did not make
a proper determination for the majority requirements for the
amendment. As I see my duties, I _have_ to determine the proper
procedure and ballot for this vote.
>> A stance has to be made one way or the other;
> The correct stance for the Secretary to adopt would be not to exceed
> his or her powers, and therefore let the vote occur without
> pre-judging it by imposing a supermajority requirement, and then
> accept the outcome of the vote regardless of personal opinion.
It is my judgement that I am indeed not exceeding my powers.
> We have not had any GRs on the GFDL. That the status of the GFDL was
> in people's minds when debating recent GRs is immaterial. Nothing in
> the GRs refers to the GFDL, or to any other specific license.
Quite true. Nothing is preventing that question from being
posed to the developers as a GR. I note, however, the release team,
as delegates, have already determined that GFDL licensed works are
not free, and thus must be removed from Etch.
The developers may chose to override their decision, as
provided for in the constitution.
>> 1: Odly enough, it's not clear that the developers can override a
>> decision that the Secretary has made,[2] although I'd be surprised
>> if a Secretary would fail to heed a clear overriding vote.
> I'm not trying to override the Secretary in any formal
> constitutional manner. I'm simply trying to convince him not to
> overstep the bounds of his powers by making a decision which he is
> not entitled to make.
If it is not already clear, you have failed to convince me
that I am indeed overstepping my bounds.
manoj
--
Though many hands make light work, too many cooks spoil the broth.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-vo...@lists.debian.org
Manoj Srivastava
> On Thursday 19 January 2006 21:38, Manoj Srivastava wrote:
>> Obviously, your course is now clear: start a process for a GR that
>> states that the GFDL licensed works without invariant sections do
>> not fall afoul of the DFSG -- which is a rather different topic
>> than stating we may include GFDL licensed works without invariant
>> sections in main, before determination that such works are indeed
>> free.
> It was my understanding that this is what the amendment was
> attempting to do
> - to establish a position statement stating that
> GFDL-minus-invariant-sections was problematic but still DFSG-free
> (and therefore acceptable in main). Is your point that the amendment
> wasn't sufficiently explicit?
My point is that it is about including works licensed under
the GFDL, with no invariant sections, into main -- which is a
different stastement than averring that such works are free, and meet
DFSG requirements.
> Then perhaps we've found a way around this impasse. If someone were
> to modify/restate the amendment to be more clear, would you then
> consider it as not requiring supermajority?
No necessarily. I would probably consider it a separate issue
from issuing a position statement explaining the projects decision to
drop GFDL licensed works, and I would consider it a move to override
the release team statement about removing GFDL licensed works for the
Etch release.
> "Formally, the Debian Project will include in the main section of
> its distribution works licensed under the GNU Free Documentation
> License that include no Invariant Sections, no Cover Texts, no
> Acknowledgements, and no Dedications, unless permission to remove
> them is granted."
This does not mean that such works are free, just that we
shall include them in main, will-ye, nil-ye.
> This could be extended to make it even more clear that we aren't
> engaging in special pleading, but view the
> GFDL-minus-invariant-sections as DFSG-free.
I do not think that statement parses the way you think it
does.
>> So start the GR. This is not it. This is a GR about a position
>> statement.
> Why can't the position statement say that the license is acceptable
> and DFSG-free? Why not just accept an amended amendment, if you
> will, rather than force an all new GR? Previous GRs have contained
> multiple options with wildly varying intentions and viewpoints
> before.
The original GR is explaining why the project considers the
licenses non-free, since the delegates have already so decided
(having GFDL licensed works is now deemed non-free).
Overriding that decision is a different kettle of fish.
manoj
--
"Being against torture ought to be sort of a bipartisan thing." Karl
Lehenbauer
Thomas Bushnell BSG
> Thomas Bushnell BSG <t...@becket.net> writes:
>
>> Brian Nelson <py...@debian.org> writes:
>>
>>> I completely agree, and hereby question whether the secretary is capable
>>> of being impartial in this case given his personal interests[1] in this
>>> issue.
>>
>> You may question it, but it doesn't affect the case.
>
> Weeee, look at me! I'm Thomas Bushnell and I reply to every single
> message on every single Debian mailing list, regardless of whether I
> have anything useful to say!
Huh? You seemed to be saying (using quite formal language like
"hereby") that your questioning should have some effect.
My point is that it does not, and need not. It has only whatever
effect Manoj chooses to give it.
Christopher Martin
> My point is that it is about including works licensed under
> the GFDL, with no invariant sections, into main -- which is a
> different stastement than averring that such works are free, and meet
> DFSG requirements.
So indeed there was a misunderstanding from the outset.
> > Then perhaps we've found a way around this impasse. If someone were
> > to modify/restate the amendment to be more clear, would you then
> > consider it as not requiring supermajority?
>
> No necessarily. I would probably consider it a separate issue
> from issuing a position statement explaining the projects decision to
> drop GFDL licensed works, and I would consider it a move to override
> the release team statement about removing GFDL licensed works for the
> Etch release.
>
> > "Formally, the Debian Project will include in the main section of
> > its distribution works licensed under the GNU Free Documentation
> > License that include no Invariant Sections, no Cover Texts, no
> > Acknowledgements, and no Dedications, unless permission to remove
> > them is granted."
>
> This does not mean that such works are free, just that we
> shall include them in main, will-ye, nil-ye.
>
> > This could be extended to make it even more clear that we aren't
> > engaging in special pleading, but view the
> > GFDL-minus-invariant-sections as DFSG-free.
>
> I do not think that statement parses the way you think it
> does.
The block I quoted was from the original amendment. I wasn't implying that
it stated that the GFDL would be considered DFSG-free, merely that
something would need to be added to it, or it would need to be changed, in
order to make clear the original intention of the amendment.
> >> So start the GR. This is not it. This is a GR about a position
> >> statement.
> >
> > Why can't the position statement say that the license is acceptable
> > and DFSG-free? Why not just accept an amended amendment, if you
> > will, rather than force an all new GR? Previous GRs have contained
> > multiple options with wildly varying intentions and viewpoints
> > before.
>
> The original GR is explaining why the project considers the
> licenses non-free, since the delegates have already so decided
> (having GFDL licensed works is now deemed non-free).
Plenty of GRs have contained diametrically opposed options in the past. The
last one contained a virtual smorgasbord of options, from temporarily
suspending the preceding GR, to not suspending it, to adding a new
foundation document, etc. An earlier GR on non-free had multiple options,
some for it, others stating the opposite. So I don't see why we would need
to have two GRs on the same basic issue, namely, the position of Debian on
the freeness of the GFDL. That would be needlessly distracting and
time-consuming.
So let's start again. Let's say that someone tried put forward a new
amendment in place of the old. This amendment makes clear its intention to
assert the position of the Debian Project as viewing the GFDL, minus
invariant sections, to be sufficiently free to meet the DFSG and be
included in main. Would you accept the amendment? Given all my arguments in
previous posts, would you require a supermajority for the amendment to
pass?
Cheers,
Christopher Martin
Daniel Ruoso
> Christopher Martin <chrs...@debian.org> writes:
> > It was my understanding that this is what the amendment was attempting to do
> > - to establish a position statement stating that
> > GFDL-minus-invariant-sections was problematic but still DFSG-free (and
> > therefore acceptable in main). Is your point that the amendment wasn't
> > sufficiently explicit?
> No. I understood the amendment exactly as Manoj has characterized it:
> it was an amendment to permit the GFDL in, whether or not it is
> DFSG-free.
Just to make it clear:
"We consider that the GNU Free Documentation License version 1.2
conflicts with traditional requirements for free software in a variety
of ways, explained in detail in the Problems of the GFDL section below."
And later, on "Problems of the GFDL"
"The DRM Restriction [...] Transparent And Opaque Copies [...] Invariant
Sections"
So, the amendment do recognize the other problems, but still...
"We believe that works licensed under the GFDL that include no such
unmodifiable sections do fully meet the spirit of the Debian Free
Software Guidelines, and have a place in our distribution despite the
other problems (minor, in comparison) that the GFDL has."
It's something like, "Hey GFDL has problems, but it has the *spirit*, so
the other problems doesn't matter"... Unfortunally, spirit doesn't
changes the license...
And also:
"Despite the compromise above, GFDL'd documentation is still not free of
trouble: as an example, it is incompatible with the major free software
licenses, which means that GFDL'd text can't be incorporated into free
programs."
So... If the intention was to refute the interpretation of the GFDL
license that thinks the other problems do exist? Shouldn't it be forced
to say that the problems doesn't exist? If the amendment recognizes that
the other problems exists but still wants to includes it in main, so it
changes the DFSG.
daniel
Anthony DeRobertis
> Therefore, no modification of the DFSG would be required after the passage
> of the amendment, since it would have been decided by the developers that
> there was no inconsistency.
If a simple majority can yell, "there is no inconsistency" then the 3:1
requirement has little meaning. I think it'd be reasonable to request
that people who believe [0] is wrong should produce reasoned arguments
against it; to the best of my knowledge (and memory, of course), no one
has done so.
Without a reasoned argument for why the GFDL w/o Invariant Sections is
free, I don't see how the Secretary can consider the amendment anything
else than an attempt to change a foundation document, and either rule it
out of order or require the supermajority.
[0] http://people.debian.org/~srivasta/Position_Statement.xhtml
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
Manoj Srivastava
<chrs...@debian.org> said:
> So let's start again. Let's say that someone tried put forward a new
> amendment in place of the old. This amendment makes clear its
> intention to assert the position of the Debian Project as viewing
> the GFDL, minus invariant sections, to be sufficiently free to meet
> the DFSG and be included in main. Would you accept the amendment?
> Given all my arguments in previous posts, would you require a
> supermajority for the amendment to pass?
If you want to override the delegates decision that works
licensed under the GFDL are incontrovertibly non-free, that is a
separate GR. We'll even fast track it to appear before this
one. (This falls under determining which issues are the same and fall
on the same ballot).
manoj
--
I love dogs, but I hate Chihuahuas. A Chihuahua isn't a dog. It's a
rat with a thyroid problem.
Peter Samuelson
[Anthony DeRobertis]
> If a simple majority can yell, "there is no inconsistency" then the
> 3:1 requirement has little meaning. I think it'd be reasonable to
> request that people who believe [0] is wrong should produce reasoned
> arguments against it; to the best of my knowledge (and memory, of
> course), no one has done so.
I just reread the position statement looking for the DFSG violations.
I was surprised to see that beyond the extensive commentary on
invariant-this-and-that, the only actual DFSG violation mentioned is a
small point about anonymous modification (the problem with changelogs
and Chinese dissidents).
And it's not entirely clear to me whether the "onerous changelog
requirement" (§4B,H) has any teeth if the original copyright holder
specifies that there be no immutable bits.
Did I miss other DFSG problems mentioned in the position statement? It
seemed to me that the rest was about "mere" annoyances, like forcing CD
vendors to ship source CDs whether or not customers order them, and
forbidding the use of rsync-over-ssh for CD images.
Anthony Towns
> On Fri, 20 Jan 2006 11:45:26 -0500, Christopher Martin
> <chrs...@debian.org> said:
>
> > So let's start again. Let's say that someone tried put forward a new
> > amendment in place of the old. This amendment makes clear its
> > intention to assert the position of the Debian Project as viewing
> > the GFDL, minus invariant sections, to be sufficiently free to meet
> > the DFSG and be included in main. Would you accept the amendment?
> > Given all my arguments in previous posts, would you require a
> > supermajority for the amendment to pass?
> If you want to override the delegates decision that works
> licensed under the GFDL are incontrovertibly non-free, that is a
> separate GR.
Why should it be a separate GR? That's seems both unnecessary and a bad
idea; what's the point in overriding decisions about the GFDL, if it is
then declared non-free anyway?
Cheers,
aj
Thijs Kinkhorst
> So, can the developers dispute this? Obviously, the developer
> body can dispute any delegated action. But a GR can't overturn something
> seen as fact (so no GR stating PI=exacly 3.14 or 22/7).
Could you please explain how you arrive at the conclusion that an
interpretation of guidelines can be seen as a fact? This is not exact
science, even though you link it to the value of pi. In judicial systems
one can dispute an interpretation of the law at a court, because the law
is seen as something that is subject to interpretation.
This goes even further here, because the DFSG is not even a strict set of
rules but are guidelines. As we all know, guidelines are subject to
interpretation on a case-by-case basis, that's what distinguishes them
from rules. Therefore, I think a specific application of guidelines can
not be seen as a fact.
Thijs
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
Martijn van Oosterhout
> This goes even further here, because the DFSG is not even a strict set of
> rules but are guidelines. As we all know, guidelines are subject to
> interpretation on a case-by-case basis, that's what distinguishes them
> from rules. Therefore, I think a specific application of guidelines can
> not be seen as a fact.
As someone who can't vote and thus whose opinion doesn't matter, it
seems to me that the issue is that people may actually want to vote
multiple ways:
1. debian-legal is wrong, the GFDL is compatable with the DFSG and
thus should be included in main.
2. I know the GFDL isn't compatable with the DFSG but I think it
should be allowed in main anyway.
3. I know the GFDL isn't compatable with the DFSG but the DFSG is only
for software not documentation, so it's allowed in main for
documentation only. :)
It seems that some people see the vote as meaning 1 and others want
meaning 2. The latter would seems to require changing the SC, the
former wouldn't.
--
Martijn van Oosterhout <kle...@gmail.com> http://svana.org/kleptog/
Margarita Manterola
>
> So, I am seeking arguments and guidance from the developer
> body whether issue 1 can, and should, be decidable by a general
> resolution, or whether the freeness of the GFDL licensed works
> without invariant clauses is incontrovertibly non-free, as the
> license is currently written.
Although I haven't yet made up my mind about the issue itself (i.e if
the GFDL without invariant sections is free or not), I consider that
it is a matter of interpretation, and not a matter of fact, and
therefore it can be decided by a GR.
--
Besos,
Marga
Manoj Srivastava
> On Sat, January 21, 2006 21:52, Manoj Srivastava wrote:
>> So, can the developers dispute this? Obviously, the developer body
>> can dispute any delegated action. But a GR can't overturn something
>> seen as fact (so no GR stating PI=exacly 3.14 or 22/7).
> Could you please explain how you arrive at the conclusion that an
> interpretation of guidelines can be seen as a fact?
If you do not see closed source software as incontrovertibly
non-free, I have no desire to discuss this issue with you.
> This is not exact science, even though you link it to the value of
> pi. In judicial systems one can dispute an interpretation of the law
> at a court, because the law is seen as something that is subject to
> interpretation.
Even inexact sciences have things accepted
axiomatically. Under some (extreme) viewpoints, there are no facts
(you, sir, are a figment of my imagination, as is the universe).
> This goes even further here, because the DFSG is not even a strict
> set of rules but are guidelines. As we all know, guidelines are
> subject to interpretation on a case-by-case basis, that's what
> distinguishes them from rules. Therefore, I think a specific
> application of guidelines can not be seen as a fact.
This is not a metaphysical or existential debate. If you are
of the opinion that everything about licensing is a matter of
opinion, and every opinion counts, I must beg to differ. If opinions
are scattered on an issue like a bell curve, I am not interested in
the long tails --- and I am trying to determine how far off the mean
ad along the tail my own opinion lies.
manoj
--
Good night, Mrs. Calabash, wherever you are.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Wesley J. Landaker
> So, I am seeking arguments and guidance from the developer
> body whether issue 1 can, and should, be decidable by a general
> resolution, or whether the freeness of the GFDL licensed works
> without invariant clauses is incontrovertibly non-free, as the
> license is currently written.
I believe this issue is a matter of interpretation, especially given that
the DFSG is specifically and explicitly intended to be a set of guidelines.
My reading of all the options of this GR so far have the effect of stating
how the Debian project is interpreting the DFSG with respect to the GFDL.
--
Wesley J. Landaker <w...@icecavern.net> <xmpp:w...@icecavern.net>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2
Manoj Srivastava
The issue remains happily moot unless that GR is actually
proposed, though.
manoj
--
I hope if dogs ever take over the world and they choose a king, they
don't just go by size, because I bet there are some Chihuahuas with
some good ideas.
Manoj Srivastava
<kle...@gmail.com> said:
> 1. debian-legal is wrong, the GFDL is compatable with the DFSG and
> thus should be included in main.
Looking over the arguments for and against it in -legal, I am
trying to ascertain if this stance has a leg to stand on.
> 2. I know the GFDL isn't compatable with the DFSG but I think it
> should be allowed in main anyway.
Which is where we are.
> 3. I know the GFDL isn't compatable with the DFSG but the DFSG is
> only for software not documentation, so it's allowed in main for
> documentation only. :)
We have already decided this is incorrect via GR's
> It seems that some people see the vote as meaning 1 and others want
> meaning 2. The latter would seems to require changing the SC, the
> former wouldn't.
Quite. I think that people who want to establish one should
do it separately from this current GR that is trying to explain why
we think it is non-free.
manoj
--
BEWARE! People acting under the influence of human nature.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
David N. Welton
> On Sun, 22 Jan 2006 13:59:15 +0100, Martijn van Oosterhout
> <kle...@gmail.com> said:
>
>
>>1. debian-legal is wrong, the GFDL is compatable with the DFSG and
>> thus should be included in main.
>
>
> Looking over the arguments for and against it in -legal, I am
> trying to ascertain if this stance has a leg to stand on.
... and ?
I am still trying to ascertain whether debian-legal has a leg to stand on.
--
David N. Welton
- http://www.dedasys.com/davidw/
Linux, Open Source Consulting
- http://www.dedasys.com/
--
To UNSUBSCRIBE, email to debian-vo...@lists.debian.org
Manoj Srivastava
> Manoj Srivastava wrote:
>> On Sun, 22 Jan 2006 13:59:15 +0100, Martijn van Oosterhout
>> <kle...@gmail.com> said:
>>
>>
>>> 1. debian-legal is wrong, the GFDL is compatable with the DFSG and
>>> thus should be included in main.
>>
>>
>> Looking over the arguments for and against it in -legal, I am
>> trying to ascertain if this stance has a leg to stand on.
> ... and ?
And what? If someone tries to bring through a GR stating that
MS office warez can be distributed in main since it meets the DFSG,
one might rule that as frivolous and a waste of time.
> I am still trying to ascertain whether debian-legal has a leg to
> stand on.
Only insofar in how they convince people -- like delegates,
for example. I am, for one, convinced that the GFDL does not meet the
standards of freedom the project espouses.
manoj
--
It is impossible to make anything foolproof because fools are so
ingenious.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava
> On Saturday 21 January 2006 13:52, Manoj Srivastava wrote:
>> So, I am seeking arguments and guidance from the developer body
>> whether issue 1 can, and should, be decidable by a general
>> resolution, or whether the freeness of the GFDL licensed works
>> without invariant clauses is incontrovertibly non-free, as the
>> license is currently written.
> I believe this issue is a matter of interpretation, especially given
> that the DFSG is specifically and explicitly intended to be a set of
> guidelines.
Noted.
> My reading of all the options of this GR so far have the effect of
> stating how the Debian project is interpreting the DFSG with respect
> to the GFDL.
I beg to differ. The original proposal was to explain the
stance Debian has already taken, as evidenced by the BTS usertags
gfdl and nonfree-doc, and the release team statement -- and how the
license may be fixed.
If you someone wants to change how Debian interprets the GFDL,
it should be a separate issue -- and quite likely should be done
before. Why is it that no one cared to override the delegates
decision until a statement explaining the decision is being issued?
manoj
--
Dying is one of the few things that can be done as easily lying
down. Woody Allen
Wesley J. Landaker
> On Sun, 22 Jan 2006 10:21:13 -0700, Wesley J Landaker <w...@icecavern.net>
said:
> > On Saturday 21 January 2006 13:52, Manoj Srivastava wrote:
> >> So, I am seeking arguments and guidance from the developer body
> >> whether issue 1 can, and should, be decidable by a general
> >> resolution, or whether the freeness of the GFDL licensed works
> >> without invariant clauses is incontrovertibly non-free, as the
> >> license is currently written.
> > My reading of all the options of this GR so far have the effect of
> > stating how the Debian project is interpreting the DFSG with respect
> > to the GFDL.
> I beg to differ. The original proposal was to explain the
> stance Debian has already taken, as evidenced by the BTS usertags
> gfdl and nonfree-doc, and the release team statement -- and how the
> license may be fixed.
Well, I believe that the original proposal was to *determine* the stance
Debian should take. Anyway, you asked, as Project Secretary, for arguments
and guidance from developers, so I provied my input.
> If you someone wants to change how Debian interprets the GFDL,
> it should be a separate issue -- and quite likely should be done
> before. Why is it that no one cared to override the delegates
> decision until a statement explaining the decision is being issued?
Well, this last paragraph makes it sound to me like you've already made up
your mind. If you are actually interested in why I personally didn't
publicly make a big deal about the delegates decision, I'd be happy to
discuss it some other time, but I don't think my action or inaction
actually relevent to this GR.
Bill Allombert
>
> I am, at this point, unclear whether I hold GFDL licensed
> works without invariant texts non-free as a matter of opinion, or of
> fact.
Fact 1: The GFDL include this:
"You may not use technical measures to obstruct or control the
reading or further copying of the copies you make or distribute."
Fact 2: The DFSG include this:
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in
a specific field of endeavor. For example, it may not restrict the
program from being used in a business, or from being used for genetic
research.
Fact 3:
There exist fields of endeavours that require mandatory encryption.
For example, if you work in security-sensitive field, you can be
required to use a hard-drive with built-in encryption. This technology
certainly control who can read the disk. In that case, you cannot copy a
GFDL licensed document to your computer for reading it.
Fact 4: the GFDL is incompatible with DFSG 6.
Cheers,
--
Bill. <ball...@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
Peter Samuelson
[Bill Allombert]
> Fact 1: The GFDL include this:
>
> "You may not use technical measures to obstruct or control the
> reading or further copying of the copies you make or distribute."
>
> Fact 2: The DFSG include this:
>
> 6. No Discrimination Against Fields of Endeavor
>
> The license must not restrict anyone from making use of the
> program in a specific field of endeavor. For example, it may not
> restrict the program from being used in a business, or from
> being used for genetic research.
Yes....
> Fact 3:
>
> There exist fields of endeavours that require mandatory encryption.
> For example, if you work in security-sensitive field, you can be
> required to use a hard-drive with built-in encryption. This
> technology certainly control who can read the disk. In that case,
> you cannot copy a GFDL licensed document to your computer for reading
> it.
That's not at all what DFSG 6 means. That's equivalent to interpreting
DFSG 6 to ban the GPL on the grounds that it discriminates against
proprietary software companies.
DFSG 6 does not say "anything a company might plausibly want to do, our
software must allow them to do". It merely says that every field of
endeavor must be given the same rights. Never mind whether that set of
rights is enough to satisfy any given party.
Peter
Thijs Kinkhorst
> If you do not see closed source software as incontrovertibly
> non-free, I have no desire to discuss this issue with you.
You are exaggerating my point into ridicule.
> Under some (extreme) viewpoints, there are no facts
> (you, sir, are a figment of my imagination, as is the universe).
You are exaggerating my point into ridicule.
> If you are of the opinion that everything about licensing is a
> matter of opinion,
You are exaggerating my point into ridicule.
I don't think it's useful to take this discussion any further if this is
the way it's done. I am willing to learn from a discussion, to accept
that I perhaps misunderstood things or that simply opinons differ. I'm
also willing to accept that someone doesn't want to discuss something at
all. This kind of response does nothing except demotivating me to even
care about this issue. Thanks.
Thijs
Steve Langasek
> On Sun, 22 Jan 2006 19:25:58 +0100, David N Welton <dav...@dedasys.com> said:
> > Manoj Srivastava wrote:
> >> On Sun, 22 Jan 2006 13:59:15 +0100, Martijn van Oosterhout
> >> <kle...@gmail.com> said:
> >>> 1. debian-legal is wrong, the GFDL is compatable with the DFSG and
> >>> thus should be included in main.
> >> Looking over the arguments for and against it in -legal, I am
> >> trying to ascertain if this stance has a leg to stand on.
> > ... and ?
> And what? If someone tries to bring through a GR stating that
> MS office warez can be distributed in main since it meets the DFSG,
> one might rule that as frivolous and a waste of time.
I'm not convinced the constitution gives the secretary the power to make
such a ruling. There are no provisions in the constitution for the Project
Secretary to dismiss a GR -- *even* a GR stating that the Debian Project
holds the value of pi to be 3 -- so long as the GR has the requisite number
of seconds.
In the present case, I understand that the proposed ballot option is
ambiguous wrt whether it constitutes an implicit amendment to the foundation
docs, and that in the absence of clarification (in the form of a re-worded
proposal) on the part of the proposer, it is the project secretary's
prerogative to specify a supermajority requirement. But I don't think that
extends to dismissing a GR that you happen to believe is inconsistent with
reality.
FWIW, aside from not being covered as a constitutional power of the
secretary, I think trying to stop a GR this way would be pretty darn futile.
If half of the project wants to vote in favor of saying pi=3, we're pretty
well screwed whether or not the vote actually happens.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vor...@debian.org http://www.debian.org/
Anthony Towns
> MS office warez can be distributed in main since it meets the DFSG,
> one might rule that as frivolous and a waste of time.
One answer to this would be to let them have that as a vote, and trust
the developers to vote that it's a daft resolution for the project to
make. I don't think the secretary needs to stand against that sort of
idiocy, in place of the project as a whole.
Cheers,
aj
Frank Küster
> Q1.1) Are GFDL licensed works without invariant texts non-free?
>
> Well, according to the RM team, and some developers (full
> disclosure: myself included), yes, they are, even if there is no
> explicit infraction of specific portions of our guidelines.
>
> The release team, a delegated body, has unequivocally stated that
> the GFDL licensed works are non-free, with no codicils and riders
> about absence of invariant clauses.
>
> Absent any other action, I am, by my own analysis, and the actions
> of the RM team, going to treat these works as non-free -- and this
> impacts issue 2.
>
> So, can the developers dispute this? Obviously, the developer
> body can dispute any delegated action.
And the consititution does not specifiy a supermajority requirement for
this case, while it specifically does so if the TC is overruled.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Bill Allombert
>
> [Bill Allombert]
> > Fact 1: The GFDL include this:
> >
> > "You may not use technical measures to obstruct or control the
> > reading or further copying of the copies you make or distribute."
> >
> > Fact 2: The DFSG include this:
> >
> > 6. No Discrimination Against Fields of Endeavor
> >
> > The license must not restrict anyone from making use of the
> > program in a specific field of endeavor. For example, it may not
> > restrict the program from being used in a business, or from
> > being used for genetic research.
>
> Yes....
>
> > Fact 3:
> >
> > There exist fields of endeavours that require mandatory encryption.
> > For example, if you work in security-sensitive field, you can be
> > required to use a hard-drive with built-in encryption. This
> > technology certainly control who can read the disk. In that case,
> > you cannot copy a GFDL licensed document to your computer for reading
> > it.
>
> That's not at all what DFSG 6 means. That's equivalent to interpreting
> DFSG 6 to ban the GPL on the grounds that it discriminates against
> proprietary software companies.
No, the GPL does not ban proprietary software companies from using the
software.
> DFSG 6 does not say "anything a company might plausibly want to do, our
> software must allow them to do". It merely says that every field of
> endeavor must be given the same rights. Never mind whether that set of
> rights is enough to satisfy any given party.
No it does not either. It says "The license must not restrict anyone from
making use of the program in a specific field of endeavor". No mention
of "giving the same right".
Cheers,
Bill.
--
To UNSUBSCRIBE, email to debian-vo...@lists.debian.org
Pierre Habouzit
> > >
> > > There exist fields of endeavours that require mandatory
> > > encryption. For example, if you work in security-sensitive field,
> > > you can be required to use a hard-drive with built-in encryption.
> > > This technology certainly control who can read the disk. In
> > > that case, you cannot copy a GFDL licensed document to your
> > > computer for reading it.
> >
> > That's not at all what DFSG 6 means. That's equivalent to
> > interpreting DFSG 6 to ban the GPL on the grounds that it
> > discriminates against proprietary software companies.
>
> No, the GPL does not ban proprietary software companies from using
> the software.
Not *yet*. GPLv3 does (with the Patent related clauses) ;p
does it makes GPLv3 non free ?
--
·O· Pierre Habouzit
··O madc...@debian.org
OOO http://www.madism.org
Laurent Fousse
> > No, the GPL does not ban proprietary software companies from using
> > the software.
>
> Not *yet*. GPLv3 does (with the Patent related clauses) ;p
I really don't think the current draft "ban proprietary software
companies from using the software".
Anthony DeRobertis
> > And what? If someone tries to bring through a GR stating that
> > MS office warez can be distributed in main since it meets the DFSG,
> > one might rule that as frivolous and a waste of time.
>
> I'm not convinced the constitution gives the secretary the power to make
> such a ruling. There are no provisions in the constitution for the Project
> Secretary to dismiss a GR -- *even* a GR stating that the Debian Project
> holds the value of pi to be 3 -- so long as the GR has the requisite number
> of seconds.
I suspect the Secretary could effectively do so by declining to take the
vote under Section 2.1.1 ("[n]othing in this constitution imposes an
obligation on anyone to do work for the Project.") It seems then that
the secretary has no obligation to actually perform 4.2.3 or 7.1.1.
>
> In the present case, I understand that the proposed ballot option is
> ambiguous wrt whether it constitutes an implicit amendment to the foundation
> docs, and that in the absence of clarification (in the form of a re-worded
> proposal) on the part of the proposer, it is the project secretary's
> prerogative to specify a supermajority requirement.
I think that under 7.1.3, it'd be the Secretary's job/power to determine
supermajority requirement regardless of what the proposed ballot option
says.
If 6 developers (K=5 currently, I think) can decide that the
supermajority requirements to not apply to a ballot option, then the
supermajority requirements are rather worthless.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
Don Armstrong
> > No, the GPL does not ban proprietary software companies from using
> > the software.
>
> Not *yet*. GPLv3 does (with the Patent related clauses) ;p does it
> makes GPLv3 non free ?
No, it imposes duties on entites who control patents (or have patents
licenced to them) and distribute software as well as restricting
certain actions which are outside of the scope of running software.
Now, if you feel the above is non-free, please, please make a comment
on gplv3.fsf.org cogently and precisely laying out your theory for why
it isn't free so it can actually be addressed. (The same goes for
anyone else who has a problem, suggest, or anything else for part of
the GPLv3.)
Don Armstrong
--
"There's no problem so large it can't be solved by killing the user
off, deleting their files, closing their account and reporting their
REAL earnings to the IRS."
-- The B.O.F.H..
Peter Samuelson
[Bill Allombert]
> > > There exist fields of endeavours that require mandatory
> > > encryption. For example, if you work in security-sensitive
> > > field, you can be required to use a hard-drive with built-in
> > > encryption. This technology certainly control who can read the
> > > disk. In that case, you cannot copy a GFDL licensed document to
> > > your computer for reading it.
> > That's not at all what DFSG 6 means. That's equivalent to
> > interpreting DFSG 6 to ban the GPL on the grounds that it
> > discriminates against proprietary software companies.
> No, the GPL does not ban proprietary software companies from using
> the software.
Exactly. And neither does the GFDL ban people from using the
documentation if they work in a security field.
It's an equivalent case. The DFSG does not say that any particular
requirements related to a field of endeavor must be honored. This is
true whether that requirement is "in order to use this software, we
really need to be able to make proprietary derivatives" or "in order to
use this documentation, we really need to store it on encrypted media".
> > DFSG 6 does not say "anything a company might plausibly want to do,
> > our software must allow them to do". It merely says that every
> > field of endeavor must be given the same rights. Never mind
> > whether that set of rights is enough to satisfy any given party.
>
> No it does not either. It says "The license must not restrict anyone
> from making use of the program in a specific field of endeavor". No
> mention of "giving the same right".
The whole point of the DFSG is to guarantee the giving of rights.
Perhaps a better wording would be "giving the rights outlined in the
rest of the DFSG" rather than "giving the same rights". Either
interpretation does not change the effectiveness of your original
argument, though, so I have to wonder why you bring it up. Unless you
have missed the connection between "not discriminating" and "giving
rights to people in every field", when the issue is about giving
rights. I don't know how to explain that one better than I already
have.
Bill Allombert
>
> [Bill Allombert]
> > > > There exist fields of endeavours that require mandatory
> > > > encryption. For example, if you work in security-sensitive
> > > > field, you can be required to use a hard-drive with built-in
> > > > encryption. This technology certainly control who can read the
> > > > disk. In that case, you cannot copy a GFDL licensed document to
> > > > your computer for reading it.
>
> > > That's not at all what DFSG 6 means. That's equivalent to
> > > interpreting DFSG 6 to ban the GPL on the grounds that it
> > > discriminates against proprietary software companies.
>
> > No, the GPL does not ban proprietary software companies from using
> > the software.
>
> Exactly. And neither does the GFDL ban people from using the
> documentation if they work in a security field.
The GFDL does ban them: they are not allowed to copy the document on
their computer so they cannot read it.
> It's an equivalent case. The DFSG does not say that any particular
> requirements related to a field of endeavor must be honored. This is
> true whether that requirement is "in order to use this software, we
> really need to be able to make proprietary derivatives" or "in order to
> use this documentation, we really need to store it on encrypted media".
The GPL allows you to make proprietary derivatives as long as you do not
distribute them.
This section is about usage not distribution. It says "making use of
the program" not "redistribute the program".
> > > DFSG 6 does not say "anything a company might plausibly want to do,
> > > our software must allow them to do". It merely says that every
> > > field of endeavor must be given the same rights. Never mind
> > > whether that set of rights is enough to satisfy any given party.
> >
> > No it does not either. It says "The license must not restrict anyone
> > from making use of the program in a specific field of endeavor". No
> > mention of "giving the same right".
>
> The whole point of the DFSG is to guarantee the giving of rights.
> Perhaps a better wording would be "giving the rights outlined in the
> rest of the DFSG" rather than "giving the same rights". Either
But it still does not say "giving the rights outlined in the rest of the DFSG",
it says "The license must not restrict anyone from making use of the
program in a specific field of endeavor".
Cheers,
--
Bill. <ball...@debian.org>
Imagine a large red swirl here.
Graham Wilson
> Q1.1) Are GFDL licensed works without invariant texts non-free?
>
> Well, according to the RM team, and some developers (full
> disclosure: myself included), yes, they are, even if there is no
> explicit infraction of specific portions of our guidelines.
>
> The release team, a delegated body, has unequivocally stated that
> the GFDL licensed works are non-free, with no codicils and riders
> about absence of invariant clauses.
>
> Absent any other action, I am, by my own analysis, and the actions
> of the RM team, going to treat these works as non-free -- and this
> impacts issue 2.
What sections of the DFSG do you think GFDL documents without invariant
sections fail?
--
gram
Steve Langasek
> On Sun, Jan 22, 2006 at 03:42:39PM -0800, Steve Langasek wrote:
> > > And what? If someone tries to bring through a GR stating that
> > > MS office warez can be distributed in main since it meets the DFSG,
> > > one might rule that as frivolous and a waste of time.
> > I'm not convinced the constitution gives the secretary the power to make
> > such a ruling. There are no provisions in the constitution for the Project
> > Secretary to dismiss a GR -- *even* a GR stating that the Debian Project
> > holds the value of pi to be 3 -- so long as the GR has the requisite number
> > of seconds.
> I suspect the Secretary could effectively do so by declining to take the
> vote under Section 2.1.1 ("[n]othing in this constitution imposes an
> obligation on anyone to do work for the Project.") It seems then that
> the secretary has no obligation to actually perform 4.2.3 or 7.1.1.
Which would be grounds for removing the secretary from office, if necessary
by appealing to the SPI board under 7.2. of the constitution.
> > In the present case, I understand that the proposed ballot option is
> > ambiguous wrt whether it constitutes an implicit amendment to the foundation
> > docs, and that in the absence of clarification (in the form of a re-worded
> > proposal) on the part of the proposer, it is the project secretary's
> > prerogative to specify a supermajority requirement.
> I think that under 7.1.3, it'd be the Secretary's job/power to determine
> supermajority requirement regardless of what the proposed ballot option
> says.
Correct, it is the secretary's job to determine supermajority requirement in
all cases. It would also be an abuse of power to establish a supermajority
requirement other than that specified by the constitution.
Russ Allbery
> What sections of the DFSG do you think GFDL documents without invariant
> sections fail?
I've been thinking a lot about this issue, and I think it basically
revolves around one's interpretation of the first two points of the DFSG:
| Free Redistribution
|
| The license of a Debian component may not restrict any party from
| selling or giving away the software as a component of an aggregate
| software distribution containing programs from several different
| sources. The license may not require a royalty or other fee for such
| sale.
|
| Source Code
|
| The program must include source code, and must allow distribution in
| source code as well as compiled form.
The question is, basically, what do "allow distribution" and "may not
restrict" mean? To take a more obvious example, consider a software
package released under a license that says:
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that distribution of the software is only done on Mondays and
the software is not redistributed on any other day of the week.
Obviously, the Debian project could not redistribute such software for
purely practical reasons, but is that license DFSG-free?
I don't buy the arguments from "No Discrimination Against Fields of
Endeavor." I think the logical argument required to conclude that this
provision would fail that test based on fields of endeavor that require
working on other days of the week is too convoluted to hold up.
My feeling is that the first two points of the DFSG imply some sort of
unstated "reasonableness" standard on the restrictions on distribution.
We allow the GPL, so obviously we allow *some* restrictions, such as the
GPL requirements about accompanying source code. Equally obviously, in my
opinion, we don't allow *any* restriction that's compatible with the rest
of the DFSG; I think my Monday-only license is compatible with the rest of
the DFSG (and even if not, I think it's obvious that you could fiddle with
such an idea to come up with one that is), but I still think that it fails
the DFSG as a whole.
Assuming you buy this argument, the next obvious question is then whether
the restrictions on redistribution in the GFDL fail that fuzzy
"reasonableness" test.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Peter Samuelson
[Bill Allombert]
> > > No, the GPL does not ban proprietary software companies from
> > > using the software.
> >
> > Exactly. And neither does the GFDL ban people from using the
> > documentation if they work in a security field.
>
> The GFDL does ban them: they are not allowed to copy the document on
> their computer so they cannot read it.
Don't be ridiculous. Nowhere in the GFDL does it say "people working
in security-related fields cannot use this work". It doesn't even say
"people working in security-related fields cannot copy this work to
their hard drives". Nobody is forcing you to encrypt your filesystems.
Let me try another analogy, since you seem to be having a lot of
trouble with this point. There may be some fields of endeavor which
require the use of Windows 2000, because most of the software they need
only runs on Windows 2000. This does not imply that all our software
must build and run correctly on Windows 2000 in order to comply with
DFSG 6. And it doesn't mean that Debian as a whole violates DFSG 6 by
not running that company's Windows applications.
It is your choice to encrypt your hard disk, or to run Windows 2000.
Or your company's choice. But it has nothing to do with
"discrimination against fields of endeavor".
> But it still does not say "giving the rights outlined in the rest of
> the DFSG", it says "The license must not restrict anyone from making
> use of the program in a specific field of endeavor".
When you're trying to break down the GFDL, please pick something other
than DFSG 6. It doesn't mean what you think it means. And I can't
believe I'm still having this conversation.
Walter Landry
> So, I am seeking arguments and guidance from the developer
> body whether issue 1 can, and should, be decidable by a general
> resolution, or whether the freeness of the GFDL licensed works
> without invariant clauses is incontrovertibly non-free, as the
> license is currently written.
Whether the GFDL conflicts with the DFSG is not a matter of opinion.
It either conflicts or it doesn't. The question is really who decides
whether it conflicts. I would say that it depends on what is being
asked. If the question is whether something can be uploaded to main,
then it is the ftp-masters decision. If it is the question of what
the release criteria are for the next release, then it is the RM's
decision. Similarly, if it is the question of whether a GR requires a
supermajority, then it is up to the secretary [1].
They have to make a decision, so they do not have the luxury of
waiting until something is completely clear in one direction or
another. So what standard should they use? I would argue that there
is always a more restrained option A (reject the package, require a
supermajority) and a less restrained option B. Given that the actions
of the delegates should be more restrained (so they may inherently
favor option A), there are two standards that come to mind for B to
prevail
1) Preponderance of evidence: Option B more likely true than option
A other, but neither need be clear cut. Options A and B are
symmetric.
2) Beyond a reasonable doubt: No reasonable person who has studied
the issue would say that A is true.
Which standard to use is not specified in the constitution.
Cheers,
Walter Landry
wla...@ucsd.edu
[1] Appendix A3.3.4 of the constitution says
In cases of doubt the Project Secretary shall decide on matters of
procedure.
Henning Makholm
> Whether the GFDL conflicts with the DFSG is not a matter of opinion.
> It either conflicts or it doesn't. The question is really who decides
> whether it conflicts.
It now becomes time for the obligatory reminder that
The G in DFSG stands for "guidelines".
Because they are only guidelines, I think we as a project are free to
deviate (in either direction) from a literal reading of the guidelines
when we decide whether a particular piece of software should be
considered free, if we have a good enough reason. Which is good
because sometimes the guidelines *do not have* an unambiguous literal
reading, and the most literal readings often lead to completely
spurious results which we have a sound tradition for correcting
unceremoniously. The guidelines were never meant to be anything *but*
guidelines, and so they are not phrased carefully enough to work
reliably as a bright-line test.
The decision whether or not to consider some software free *is*
eventually a matter of opinion, even though that opinion should be
guided by the DFSG. As such, it can be settled by GR.
--
Henning Makholm "En tapper tinsoldat. En dame i
spagat. Du er en lykkelig mand ..."
Hamish Moffatt
> Christopher Martin wrote:
>
> > Therefore, no modification of the DFSG would be required after the passage
> > of the amendment, since it would have been decided by the developers that
> > there was no inconsistency.
>
> If a simple majority can yell, "there is no inconsistency" then the 3:1
> requirement has little meaning. I think it'd be reasonable to request
> that people who believe [0] is wrong should produce reasoned arguments
> against it; to the best of my knowledge (and memory, of course), no one
> has done so.
Perhaps I'm missing something, but
> [0] http://people.debian.org/~srivasta/Position_Statement.xhtml
does not seem to specifically address why the DRM and transparent copies
requirements violate the DFSG. I would like to know what the argument
is, since it appears to be ok by the letter. Of course the spirit is
also important but open to interpretation.
Hamish
--
Hamish Moffatt VK3SB <ham...@debian.org> <ham...@cloud.net.au>
Hubert Chan
> Scripsit Walter Landry <wla...@ucsd.edu>
>> Whether the GFDL conflicts with the DFSG is not a matter of opinion.
>> It either conflicts or it doesn't. The question is really who
>> decides whether it conflicts.
> It now becomes time for the obligatory reminder that
> The G in DFSG stands for "guidelines".
From the Debian Social *Contract*, point 1:
We provide the guidelines that we use to determine if a work is
"free" in the document entitled "The Debian Free Software
Guidelines". *We promise that the Debian system and all its
components will be free according to these guidelines.*
(Emphasis mine.)
In order to deviate from the DFSG, you would need to modify the SC.
--
Hubert Chan <hub...@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
Bill Allombert
>
> [Bill Allombert]
> > > > No, the GPL does not ban proprietary software companies from
> > > > using the software.
> > >
> > > Exactly. And neither does the GFDL ban people from using the
> > > documentation if they work in a security field.
> >
> > The GFDL does ban them: they are not allowed to copy the document on
> > their computer so they cannot read it.
>
> Don't be ridiculous.
Don't be rude, that weaken your point.
> Let me try another analogy, since you seem to be having a lot of
> trouble with this point. There may be some fields of endeavor which
> require the use of Windows 2000, because most of the software they need
> only runs on Windows 2000. This does not imply that all our software
> must build and run correctly on Windows 2000 in order to comply with
> DFSG 6. And it doesn't mean that Debian as a whole violates DFSG 6 by
> not running that company's Windows applications.
The DFSG says 'the license must not restrict ...', it does not say 'the
program must not restrict ...'.
The GNU GPL e.g. does not forbid to run the software on Windows 2000.
Not running on Windows 2000 is due to a software limitation, not to a
license restriction.
On the other hand the aforementioned GFDL clause is clearly a license
restriction.
Cheers,
Bill.
Peter Samuelson
[Bill Allombert]
> The DFSG says 'the license must not restrict ...', it does not say
> 'the program must not restrict ...'.
That's a fair point. I chose a bad example indeed.
You still haven't given a reasonable answer to the real point, though,
that being: "field of endeavor" does not mean "a field where some
people in the field may want to do specific things, which other people
outside the field may or may not want to do as well". There is nothing
field-specific about "needing" to encrypt your hard drive. Some
security professionals may want to do this, some may not want to. Some
people who are not security professionals may want to do this, others
may not want to. Nobody can say "the only way a security firm can
possibly use Debian is to encrypt every hard drive of every computer in
the whole company".
To be fair, you are not the first person to misunderstand DFSG #5 and
DFSG #6 this way, and try to apply them to things they do not apply to.
It was a favorite tactic on the debian-legal list, last I checked ---
which was some time ago.
Compare the following two statements:
- If you are XXX [DFSG #5] or your business is involved in YYY [#6],
then you cannot use this software, or you cannot use it the same
way other people can use it.
- You cannot do ZZZ, no matter who you are, no matter what your
business is about.
Can you see the difference? The first is what DFSG #5 and #6 attempt
to prevent. The second is not, although many people think it is.
The problem is, if DFSG #5 and #6 mean what you think they mean, they
effectively prevent _all_ license restrictions whatsoever. Because if
you are creative enough, for any restriction ZZZ, you can find _some_
group of people _somewhere_, or _some_ field of endeavor, which you can
tenuously link to _some_ reason ZZZ is a problem for them. Though the
chain of logic can get quite convoluted, as we see in the present case.
Bill Allombert
> The problem is, if DFSG #5 and #6 mean what you think they mean, they
> effectively prevent _all_ license restrictions whatsoever. Because if
DFSG 6 is only about license restrictions on usage. It does not cover
restriction on distributions, modification, etc which are covered
in other sections. It says "from making use of the program".
> you are creative enough, for any restriction ZZZ, you can find _some_
> group of people _somewhere_, or _some_ field of endeavor, which you can
> tenuously link to _some_ reason ZZZ is a problem for them. Though the
> chain of logic can get quite convoluted, as we see in the present case.
It seems you attempted a 'reductio at absurdum' but failed to state the
contradiction. You reached the conclusion that DFSG 5/6 prevent all
restrictions on usage. Why this conclusion leads to a contradiction ?
Nick Phillips
> The important question here is one of legitimacy. Who exactly has the
> authority to determine these matters of interpretation? Specifically, who
> decides what is in accordance with the DFSG? The developers do, through
> GRs, if I understand correctly. Certainly nothing in my reading of the
> Constitution suggests that the Secretary has this power.
>
> The Secretary seems to be adopting the view that anyone who disagrees with
> his interpretation of the GFDL is not holding a legitimate opinion. Given
> the length of the GFDL debates, the acrimony, and the number of developers
> who remain on both sides, this seems far, far too strong a stance for a
> Project officer to adopt (even if Manoj holds that view personally). Hence
> my complaint.
I agree completely.
The GR as amended might appear to contradict the Social Contract, or the
DFSG, but it certainly *does not* modify them, and hence cannot be said to
require a supermajority.
In fact, Adeodato's amendment is clear in its explanation that "we
believe that the GFDL does meet the spirit of the DFSG (so long as you
have no invariant sections)". If, therefore, that particular amended
version of the GR were to pass, it would be clear that a majority of
developers *did not* believe that it required or constituted a
modification to either the Social Contract or the DFSG.
Even if for some reason that I am unable to fathom you do fervently
believe that I am wrong in the above paragraph, then there is *still
nothing* to say that we can't happily pass GRs that contradict each
other. It would be foolish, sure, and perhaps reflect poorly on our
ability to work through these things, but democracies pass laws like
that the whole time and the courts seem to manage to resolve the
contradictions.
Note that the alternative to this process is for someone (usually a
General, it seems) to stand up and tell the parliament not to be so
damn silly, and to follow his interpretation of the constitution, or
else. This usually ends badly for all concerned.
So, I'm strongly opposed to Manoj attempting to require a
supermajority requirement when it is not clearly and unambiguously
required. I believe that were the outcome of the vote to be a simple
majority for the amendment, that the consequences for the project
could be pretty dire.
Now, the amendment (Adeodato's) itself. I've just noticed that it's a
complete waste of space as presented at
http://www.debian.org/vote/2006/vote_001 -- the second paragraph of
point 2) of the first (un-headed) section reads as follows:
Formally, the Debian Project will include in the main section of its
distribution works licensed under the GNU Free Documentation License
that include no Invariant Sections, no Cover Texts, no
Acknowledgements, and no Dedications, unless permission to remove
them is granted.
Can you read that carefully and tell me (with a straight face) that it
says what its author intended it to say? I don't think you can -- and
that single error (if it is indeed presented as proposed) in what is a
critical part of the document renders that entire amendment
ridiculous.
What it says, for those who can't (or can't be bothered) to read it is
essentially this:
We will include GFDL'd works that have no bad bits unless we have
permission to remove them.
Or rewritten slightly more clearly (by "bad bits" I obviously mean
invariant sections, cover texts etc.):
We will not include GFDL'd works that have no bad bits if we have
permission to remove them.
What is that "them" -- it can't be the "bad bits" because we're
talking about works that don't have any. So it must be the works
themselves. This implies that what this paragraph actually says is
that we won't include any GFDL'd works that have no bad bits. Maybe
we'll include ones that do?...
Yuck. Voting for that would make us look even sillier than voting for
something that really did contradict the Social Contract or DFSG.
Cheers,
Nick
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
Raul Miller
> The GR as amended might appear to contradict the Social Contract, or the
> DFSG, but it certainly *does not* modify them, and hence cannot be said to
> require a supermajority.
This comment seems insincere.
If the GR is adopted by Debian, there is no significant difference
between "contradicts the foundation documents" and "modifies
the foundation documents".
--
Raul
Wouter Verhelst
> What it says, for those who can't (or can't be bothered) to read it is
> essentially this:
>
> We will include GFDL'd works that have no bad bits unless we have
> permission to remove them.
>
> Or rewritten slightly more clearly (by "bad bits" I obviously mean
> invariant sections, cover texts etc.):
>
> We will not include GFDL'd works that have no bad bits if we have
> permission to remove them.
Sorry, but the above two sentences mean something *completely*
different. Either you had a brain fart here, or your knowledge of the
English language is... strange.
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Nick Phillips
> On Wed, Feb 08, 2006 at 09:21:36PM +1300, Nick Phillips wrote:
> > What it says, for those who can't (or can't be bothered) to read it is
> > essentially this:
> >
> > We will include GFDL'd works that have no bad bits unless we have
> > permission to remove them.
> >
> > Or rewritten slightly more clearly (by "bad bits" I obviously mean
> > invariant sections, cover texts etc.):
> >
> > We will not include GFDL'd works that have no bad bits if we have
> > permission to remove them.
>
> Sorry, but the above two sentences mean something *completely*
> different. Either you had a brain fart here, or your knowledge of the
> English language is... strange.
Bah, brain fart indeed. Negated the wrong bit. Not entirely surprising
given that the original didn't make sense anyway. Fixed, it translates
to:
"We will include GFDL'd works that have no bad bits if we do not have
permission to remove them."
"Them" cannot apply to non-existent bad bits, so can only apply to
the works. So, who has to give us permission to remove things?
This does *not* make sense...
Cheers,
Nick
Nick Phillips
> On 2/8/06, Nick Phillips <n...@nz.lemon-computing.com> wrote:
> > The GR as amended might appear to contradict the Social Contract, or the
> > DFSG, but it certainly *does not* modify them, and hence cannot be said to
> > require a supermajority.
>
> This comment seems insincere.
Down that road lies tit-for-tat ad-hominem.
> If the GR is adopted by Debian, there is no significant difference
> between "contradicts the foundation documents" and "modifies
> the foundation documents".
First of all, you're assuming that it does contradict the foundation
documents. It clearly asserts otherwise, and one might assume that
developers voting for it would agree with that. If it won a majority,
it would therefore seem to be the case that the majority of developers
agreed with it. In which case those asserting that it needed
supermajority wouldn't have a leg to stand on. So we'd be in a right
mess.
Second, you're completely wrong. Of course there is a difference
between modifying the foundation documents and appearing to contradict
them. One modifies them and the other, well, doesn't.
Thomas Bushnell BSG
> documents. It clearly asserts otherwise, and one might assume that
> developers voting for it would agree with that. If it won a majority,
> it would therefore seem to be the case that the majority of developers
> agreed with it. In which case those asserting that it needed
> supermajority wouldn't have a leg to stand on. So we'd be in a right
> mess.
Clearly if the 3:1 supermajority requirement means anything, it cannot
be obviated merely by a simple majority declaring "there is no
contradiction".
Thomas
Anthony Towns
> Nick Phillips <n...@nz.lemon-computing.com> writes:
> > documents. It clearly asserts otherwise, and one might assume that
> > developers voting for it would agree with that. If it won a majority,
> > it would therefore seem to be the case that the majority of developers
> > agreed with it. In which case those asserting that it needed
> > supermajority wouldn't have a leg to stand on. So we'd be in a right
> > mess.
> Clearly if the 3:1 supermajority requirement means anything, it cannot
> be obviated merely by a simple majority declaring "there is no
> contradiction".
Way back in highschool, I was told that you shouldn't use the word
"clearly" because it's a sure sign that you aren't actually able to
backup the assertion you're about to make.
In any event, there is in fact a meaning in that case: the 3:1
suerpmajority would still apply to issues where the majority of developers
felt that the proposed resolution did contradict the social contract or
DFSG -- and that the social contract/DFSG happened to be wrong.
Personally, I hope and trust that the developer body are honourable
enough to note vote for a proposal they think contradicts the social
contract or DFSG; and I don't see much point to all the implications
that we're not that honourable and need to have the secretary's adult
supervision. I don't see much point to all the grumbling about the
secretary's supervision either though -- if we're acting like adult's
anyway, that's hardly a problem, is it?
Cheers,
aj
Thomas Bushnell BSG
> In any event, there is in fact a meaning in that case: the 3:1
> suerpmajority would still apply to issues where the majority of developers
> felt that the proposed resolution did contradict the social contract or
> DFSG -- and that the social contract/DFSG happened to be wrong.
> Personally, I hope and trust that the developer body are honourable
> enough to note vote for a proposal they think contradicts the social
> contract or DFSG.
It's not about honor; it's about decision-making.
If a majority sincerely believe that their proposal does not run afoul
of the 3:1 requirement, does that mean that it therefore does not?
I think that it is possible for people to disagree about such a
question, and it seems crazy to me to say that anytime they disagree,
it can be settled by majority vote.
Moreover, while I think a majority of the developers are surely
honorable, this is not true of everyone. Now that this is the *third*
time we are being asked to vote on essentially the same question, I
suspect that many of the proponents of the measure are simply
unwilling to let it drop, and will continue to pester the rest of the
project forever. This is not honorable behavior.
Thomas
--
To UNSUBSCRIBE, email to debian-vo...@lists.debian.org
Anthony Towns
> Anthony Towns <a...@azure.humbug.org.au> writes:
> > In any event, there is in fact a meaning in that case: the 3:1
> > suerpmajority would still apply to issues where the majority of developers
> > felt that the proposed resolution did contradict the social contract or
> > DFSG -- and that the social contract/DFSG happened to be wrong.
> > Personally, I hope and trust that the developer body are honourable
> > enough to note vote for a proposal they think contradicts the social
> > contract or DFSG.
> It's not about honor; it's about decision-making.
When you raise the implication that your fellow developers can't be
trusted, you make it about honour; when you think it's important to
move a decision from one set of hands to another in order to ensure the
"right" decision is made, that's a pretty direct implication that you
don't trust the first group.
> If a majority sincerely believe that their proposal does not run afoul
> of the 3:1 requirement, does that mean that it therefore does not?
If the secretary sincerely believes the proposal has a 3:1 requirement,
does that mean it does? I think you're better off looking at the
constitution, personally. As it happens, it says nothing about implicit
changes to foundation documents, or even about having to act in accord
with them.
> Moreover, while I think a majority of the developers are surely
> honorable, this is not true of everyone. Now that this is the *third*
> time we are being asked to vote on essentially the same question, I
> suspect that many of the proponents of the measure are simply
> unwilling to let it drop, and will continue to pester the rest of the
> project forever. This is not honorable behavior.
So much for not being about honour. In any event, each of the questions have
been different, and it's quite plausible for someone to take any of the
eight possible combinations of:
Docs and firmware in Debian should be DFSG-free [yes/no]
If the above happens it should be post-sarge [yes/no]
Common GFDL docs are free anyway [yes/no]
As it happens, those eight combinations are only some of the nuances
we've had in the votes to date.
I hope you're tolerant enough to be able to cope with the variety of
opinions on those questions present in Debian, and you're willing to
retract the fairly insulting remarks above. There's absolutely no need
to turn this discussion into an attack on those who disagree with you.
Cheers,
aj
Nathanael Nerode
> Now, the amendment (Adeodato's) itself. I've just noticed that it's a
> complete waste of space as presented at
> http://www.debian.org/vote/2006/vote_001 -- the second paragraph of
> point 2) of the first (un-headed) section reads as follows:
>
> Formally, the Debian Project will include in the main section of its
> distribution works licensed under the GNU Free Documentation License
> that include no Invariant Sections, no Cover Texts, no
> Acknowledgements, and no Dedications, unless permission to remove
> them is granted.
>
> Can you read that carefully and tell me (with a straight face) that it
> says what its author intended it to say? I don't think you can -- and
> that single error (if it is indeed presented as proposed) in what is a
> critical part of the document renders that entire amendment
> ridiculous.
You're right, this is misdrafted in such a way that the "unless permission to
remove them" clause can't be correctly parsed to mean anything.
But what do you expect from people who are essentially requesting that we pay
attention only to the spirit of licenses, and ignore the letter? This
strikes me as exactly what you should expect; they're being true to their
belief that the actual wording doesn't matter.
It should say:
> Formally, the Debian Project will include in the main section of its
> distribution works licensed under the GNU Free Documentation License
> that include no Invariant Sections, no Cover Texts, no
> Acknowledgements, and no Dedications; and works licensed under the GNU Free
> Documentation License where permission is granted to remove any Invariant
> Sections, Cover Texts, Acknowledgements, or Dedications.
That's clearly what the author meant, and that's clearly not what the GR says.
Note how similar this situation is to the GFDL's DRM clause and
opaque/transparent clauses, which clearly do not say what the author meant.
Those exact clauses where this GR is proposing to allow works under them into
Debian. Interesting, eh?
--
Nathanael Nerode <ner...@twcny.rr.com>
"It's just a goddamned piece of paper."
-- President Bush, referring to the US Constitution
http://www.capitolhillblue.com/artman/publish/article_7779.shtml
Nathanael Nerode
> The GR as amended might appear to contradict the Social Contract, or the
> DFSG, but it certainly *does not* modify them, and hence cannot be said to
> require a supermajority.
Well, um. That depends if you want the GR-as-amended to actually *do*
anything other than spark a giant flamewar, doesn't it? See below: There's a
good argument that a GR which contradicted the Social Contract without the
supermajority authority would be null and void.
> In fact, Adeodato's amendment is clear in its explanation that "we
> believe that the GFDL does meet the spirit of the DFSG (so long as you
> have no invariant sections)". If, therefore, that particular amended
> version of the GR were to pass, it would be clear that a majority of
> developers *did not* believe that it required or constituted a
> modification to either the Social Contract or the DFSG.
This argument-to-the-spirit is interesting: it is the claim that Debian should
accept works where we believe that the intention of the license is
satisfactory, even if the actual letter of the license is not and we have no
clarification from the copyright holder. This is a very unwise thing to do
in my opinion; I don't think it serves Debian's users to accept such software
when the licensor could easily decide to enforce the license as written. But
it is a tenable position, I suppose: a "don't be legalistic or excessively
careful, even in matters of the law -- just accept anything that looks OK at
first glance" position. If it is the consensus view of Debian Developers
(and I'm pretty sure it isn't), then I will go along with it. Just as long
as it's made clear to the users (preferably with a note attached to the
Social Contract or something).
If it does pass, I will likely request that bsdgames-nonfree and xsnow be
included in 'main' because it looks like the intention of these licenses is
as free as the GFDL, although the letter of the licenses isn't and we have no
clarification from the copyright holder. Again if it does pass, I will
*definitely* request the same for povray, as we know for sure that the
intention of the license is free (thanks to the current relicensing effort),
although the letter of the license isn't and we have no clarification from
many of the copyright holders. These actions would be in keeping with the
new interpretation of the Social Contract, which I would be honor-bound to
support.
Perhaps this viewpoint would be better for Debian all around. I don't think
so, but I would bow to the will of the developers and see how it works out.
> Even if for some reason that I am unable to fathom you do fervently
> believe that I am wrong in the above paragraph, then there is *still
> nothing* to say that we can't happily pass GRs that contradict each
> other. It would be foolish, sure, and perhaps reflect poorly on our
> ability to work through these things, but democracies pass laws like
> that the whole time and the courts seem to manage to resolve the
> contradictions.
Debian doesn't have courts. The closest we've got is debian-legal, and
there's a group of people who deny the legitimacy of debian-legal. (They are
usually the same people trying to put or keep random unmodifiable junk in
main.)
If Debian passed a GR which contradicted the Social Contract -- without being
an "implicit amendment" -- I would assume that the Social Contract would win
and the GR would be void. That's normally how analagous situations are dealt
with in real courts. That seems particularly undesirable.
> Note that the alternative to this process is for someone (usually a
> General, it seems) to stand up and tell the parliament not to be so
> damn silly, and to follow his interpretation of the constitution, or
> else. This usually ends badly for all concerned.
So with no courts, that's the only alternative, then? :-(
--
Nathanael Nerode <ner...@twcny.rr.com>
[Insert famous quote here]
Anthony Towns
> Nick Phillips <n...@nz.lemon-computing.com> wrote:
> > In fact, Adeodato's amendment is clear in its explanation that "we
> > believe that the GFDL does meet the spirit of the DFSG (so long as you
> This argument-to-the-spirit is interesting: it is the claim that Debian should
> accept works where we believe that the intention of the license is
> satisfactory, even if the actual letter of the license is not and we have no
> clarification from the copyright holder.
Actually it's the opposite claim -- it's not about the spirit of the license
that Nick's talking about, it's the spirit of the DFSG.
Cheers,
aj
Marco d'Itri
> Moreover, while I think a majority of the developers are surely
> honorable, this is not true of everyone. Now that this is the *third*
> time we are being asked to vote on essentially the same question, I
> suspect that many of the proponents of the measure are simply
> unwilling to let it drop, and will continue to pester the rest of the
> project forever. This is not honorable behavior.
Well, maybe the people who mislabeled the "everything is software" vote
as an "editorial change" and deceived many other developers should have
tought about this.
--
ciao,
Marco
Xavier Roche
> Well, maybe the people who mislabeled the "everything is software" vote
> as an "editorial change" and deceived many other developers should have
> tought about this.
Maybe we could suggest another "editorial change" and revert to the
previous wording (not everything is software)
Uh ?
Kalle Kivimaa
> Debian doesn't have courts. The closest we've got is debian-legal,
The closest thing to courts we have are DPL, TC, DAM, FTP masters and
the Project Secretary. They have a final decision making power that
effectively resolves any disputes among the developers. debian-legal
is just an advisory board for them.
--
* Sufficiently advanced magic is indistinguishable from technology (T.P) *
* PGP public key available @ http://www.iki.fi/killer *
Jérôme Marant
> Well, maybe the people who mislabeled the "everything is software" vote
> as an "editorial change" and deceived many other developers should have
> tought about this.
The only people it made happy are extremists. See #207932. This is a
very good example of the silliness it leads to. You won't be surprised
to see the same fundamentalists as involved in debian-legal crusades.
I'd propose to revert this and clearly define what software is.
--
Jérôme Marant
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
Xavier Roche
> I'd propose to revert this and clearly define what software is.
I fully agree. The "Holier than Stallman" stuff is really getting
ridiculous. After the firmware madeness, now the documentation madeness.
And after that, the font madeness maybe ? (after all, fonts ARE also
software, and they shall be distributed with their original sources)
Marco d'Itri
> I fully agree. The "Holier than Stallman" stuff is really getting
> ridiculous. After the firmware madeness, now the documentation madeness.
> And after that, the font madeness maybe ? (after all, fonts ARE also
> software, and they shall be distributed with their original sources)
The usual suspects from time to time have already been trying to start
an images madness on debian-legal@.
If you care about Debian, please contribute sane ideas to debian-legal@.
--
ciao,
Marco
Josselin Mouette
> Maybe we could suggest another "editorial change" and revert to the
> previous wording (not everything is software)
This has already been voted. And the answer was "no".
--
.''`. Josselin Mouette /\./\
: :' : josselin...@ens-lyon.org
`. `' jo...@debian.org
`- Debian GNU/Linux -- The power of freedom
Josselin Mouette
> Well, maybe the people who mislabeled the "everything is software" vote
> as an "editorial change" and deceived many other developers should have
> tought about this.
Hey ! Look ! We've just found a second person to think the change wasn't
editorial !
Simon Richter
Xavier Roche wrote:
> I fully agree. The "Holier than Stallman" stuff is really getting
> ridiculous. After the firmware madeness, now the documentation madeness.
> And after that, the font madeness maybe ? (after all, fonts ARE also
> software, and they shall be distributed with their original sources)
It's not about us being holier than Stallman. It's about Stallman not
caring that his new license is creating real world problems for everyone
but the FSF because only the FSF has permission to relicense their stuff.
The binutils package generates part of its documentation from header
files in order to get the structures and constants right. The headers
are GPLed, the compiled documentation is under the GFDL. For this
relicensing to happen, one must be the copyright holder, or have an
appropriate license, which after a quick glance does not seem to be
there. Thus, only the FSF may build the binutils package. I'd be very
surprised if that were to meet your definition of free software.
Simon
Marco d'Itri
> The binutils package generates part of its documentation from header
> files in order to get the structures and constants right. The headers
> are GPLed, the compiled documentation is under the GFDL. For this
> relicensing to happen, one must be the copyright holder, or have an
> appropriate license, which after a quick glance does not seem to be
> there. Thus, only the FSF may build the binutils package. I'd be very
> surprised if that were to meet your definition of free software.
Did you ask FSF what they think about this situation?
--
ciao,
Marco
Martijn van Oosterhout
You make good arguments and I agree with many points. But the following:
2006/2/8, Nick Phillips <n...@nz.lemon-computing.com>:
> Even if for some reason that I am unable to fathom you do fervently
> believe that I am wrong in the above paragraph, then there is *still
> nothing* to say that we can't happily pass GRs that contradict each
> other. It would be foolish, sure, and perhaps reflect poorly on our
> ability to work through these things, but democracies pass laws like
> that the whole time and the courts seem to manage to resolve the
> contradictions.
Debian has no courts to resolve contradictions. No-one has the
authority to rule one way or the other. So we have to decide now,
before the vote, if there is a contradiction or not. Since there is
disagreement here already, we have a difficulty.
There are democracies that work this way. In some countries, courts
cannot rule a law unconstitutional because that is the role of
parliament. If the legislature says it's constitutional, it is.
Contradictions are solved by the legislature. The point being that
courts apply the law, but do not create it.
Back to the issue at hand. Given the only source of authority
considered by debian is the developers themselves, what we need to do
is draft a GR as follows (I think Manoj suggested something like
this):
----
If there is a belief that a GR contradicts the foundations documents,
this contradiction can be resolved by:
1. The project secretary
2. A majority vote
3. A 3:1 supermajority vote
4. The project leader.
5. The technical committee
6. Debian-legal
----
The only other possibility is to add a second option to every possible
vote asking developers to say whether they think this requires a
supermajority or not. Or commually binding arbitration system to sort
this out.
I hope this doesn't go that far.
> Note that the alternative to this process is for someone (usually a
> General, it seems) to stand up and tell the parliament not to be so
> damn silly, and to follow his interpretation of the constitution, or
> else. This usually ends badly for all concerned.
We have no courts, so what's the alternative? If we get a
super-majority of developers to say a majority is enough, we're home.
If a majority of developers say a majority is enough, what does that
mean?
Have a nice day,
--
Martijn van Oosterhout <kle...@gmail.com> http://svana.org/kleptog/
Xavier Roche
> Le jeudi 09 février 2006 à 11:12 +0100, Xavier Roche a écrit :
> > Maybe we could suggest another "editorial change" and revert to the
> > previous wording (not everything is software)
> This has already been voted. And the answer was "no".
Well, maybe the wording was not deceptive enough ?
Henrique de Moraes Holschuh
Maybe people should get re-acquinted with GR 2004-04 and its results before
they bring up GR 2004-03, even for jokes.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Henrique de Moraes Holschuh
> Quoting Marco d'Itri <m...@Linux.IT>:
> > Well, maybe the people who mislabeled the "everything is software" vote
> > as an "editorial change" and deceived many other developers should have
> > tought about this.
>
> The only people it made happy are extremists. See #207932. This is a
A 3:1 majority win in 2004-04 makes your claim rather tenuous, unless you
are arguing that such a large part of Debian is composed of extremists,
only.
> I'd propose to revert this and clearly define what software is.
Then do so.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Xavier Roche
> > Well, maybe the wording was not deceptive enough ?
> Maybe people should get re-acquinted with GR 2004-04 and its results before
> they bring up GR 2004-03, even for jokes.
No, no. The funny joke is to modify the constitution with a deceptive
wording, with 214 votes out of 911 developpers.
Henrique de Moraes Holschuh
> Le jeudi 09 février 2006 à 09:59 +0100, Marco d'Itri a écrit :
> > Well, maybe the people who mislabeled the "everything is software" vote
> > as an "editorial change" and deceived many other developers should have
> > tought about this.
>
> Hey ! Look ! We've just found a second person to think the change wasn't
> editorial !
A lot of us thought it was far and beyond "editorial", which is why GR
2004-04 was held with options to *entirely revoke* GR 2004-03 (the
"editorial" one).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
MJ Ray
> On Thu, 9 Feb 2006, J=E9r=F4me Marant wrote:
> > I'd propose to revert this and clearly define what software is.
>
> I fully agree. The "Holier than Stallman" stuff is really getting
> ridiculous. After the firmware madeness, now the documentation madeness.
Stallman is amazingly arbitrary and illogical about manuals and
invariant sections, ignoring Moglen's advice that we can't rely on
distinguishing bitstreams for deciding what freedoms are important.
I welcome debian's consistent approach: if it's in main, it should
follow the DFSG (at least in spirit as far as possible), no matter
what sort of software it is (programs, manuals, and so on).
Stallman tries to redefine software=programs and many follow.
It's not about "holier than Stallman" but about what we understand
as software. Just programs for PCs, programs for everything (inc.
firmware), or computerised creative work in general?
Software is a wider group than programs: if you know esperanto,
software is programaroj rather than programoj. Unfortunately,
similar arguments seem to happen for many languages, including
French: do programme and logiciel differ for computers?
The FSF promotion of the FDL looks like a fairly obvious example of
working against FSF's aim, but I don't know their precise objective.
FDL looks like a fairly cynical attempt to create an adware licence
acceptable to legacy dead-tree publishers and few of them seem to use
it. Someone mentioned the "encyclopedia problem" where including an
invariant section on a topic prevents text being reused in a manual
about that topic: that's just one of the more obvious problems.
I believe the debates about program copyrights, computer-stored music,
video and so on are essentially the same. The same freedoms fit.
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Lars Wirzenius
> On Thu, 9 Feb 2006, Henrique de Moraes Holschuh wrote:
> > > Well, maybe the wording was not deceptive enough ?
> > Maybe people should get re-acquinted with GR 2004-04 and its results before
> > they bring up GR 2004-03, even for jokes.
>
> No, no. The funny joke is to modify the constitution with a deceptive
> wording, with 214 votes out of 911 developpers.
Please stop abusing that horse. We're running out of glue.
--
Fundamental truth #2: Attitude is usually more important than skills.
--
To UNSUBSCRIBE, email to debian-vo...@lists.debian.org