Yes, by all means we should ignore the fake personas, Mr. Natural Linux,
whoever you are.
On Sun, Mar 2, 2014 at 7:25 PM, Natural Linux naturalli...@dcemail.comwrote:
Matthias Urlichs, Why should we believe you or the bullshit excuses given
in the article?
The fact is, last year none of
On Mon, 2010-02-08 at 00:35 +0900, Charles Plessy wrote:
3) Is there a benefit of allowing non-free files to be distributed together
with the source of the Debian system ?
Have you considered the harm? It means that users can no longer assume
that whatever is in the source packages can be
On Wed, 2009-05-13 at 10:53 +0200, Giacomo A. Catenazzi wrote:
DFSG is a guideline and a target: we must no go far as the nearest point
we reached, but it still a guideline.
Consider:
- we never had a full DFSG Debian (also when DFSG was written)
- we have RC also on stable releases. What
On Tue, 2009-05-12 at 17:06 +0200, Wouter Verhelst wrote:
I think this is the core of the disagreement. I do not call it a
temporary override of a foundation document; I call it a temporary
practical consensus between the needs of our users and the needs of
the free software community.
I
On Fri, 2009-05-01 at 13:58 +0200, Stefano Zacchiroli wrote:
On Fri, May 01, 2009 at 11:48:58AM +0200, Luk Claes wrote:
What do people think of a new vote regarding the status of firmware?
One of the options can probably be Peter Palfrader's proposal [1].
I'm very much in favor of having
On Sun, 2009-01-11 at 10:32 +0100, Joerg Jaspert wrote:
So, I think you made a mistake, a very serious one, and when asked about it,
your explanation is completely unsatisfactory. How do we solve this?
Currently, the only solution I see is that we ask the developers what they
think, and
On Sun, 2009-01-11 at 11:35 +0100, Joerg Jaspert wrote:
Do you have any other idea in mind?
Btw, Joerg, that goes for you too. If you have something constructive to
say,
this would be a good time.
How about you going elsewhere until Lenny is released, then coming back
as soon as
On Sun, 2009-01-11 at 10:44 -0700, Bdale Garbee wrote:
That's why I think the main outcome of this ballot was an assertion of
desire by the voters that we release Lenny.
Actually, I ranked #1 first, and yet, I have a desire that we release
Lenny. However, I don't want a bad release, I want a
On Sun, 2009-01-11 at 21:07 +0100, Frank Küster wrote:
Robert Millan r...@aybabtu.com wrote:
4- Bugs which are trivial to fix, such as #459705 (just remove a text
file),
#483217 (only affects optional functionality that could be removed
according to the maintainer)
Of
On Fri, 2009-01-02 at 16:59 -0800, Steve Langasek wrote:
When you say he was asserting a power that was not his, what exactly are
you saying? I'm having trouble understanding. It is unquestionably the
Secretary's job to prepare the ballot and announce the results; this
requires the
On Wed, 2008-12-31 at 12:01 -0800, Steve Langasek wrote:
While I understand the desire to add additional checks and balances in
response to figures exercising power in ways we don't approve of, I think
the fundamental problem with this latest vote was that the Secretary was
asserting a power
On Mon, 2008-12-29 at 23:27 +1000, Anthony Towns wrote:
Whatever his motives, I think Ted's demonstrably done more to further the
cause of free software than most developers, both by making Linux more
and more usable for over 15 years now, and for helping other developers
work together better,
On Sun, 2008-12-28 at 09:05 +0100, Andreas Barth wrote:
What this voting seems to show is that clearly a majority doesn't want to
stop the release of Lenny. What it also shows however is that the mixing up
of the other options on this ballot and the way the supermajority
requirements were set
On Mon, 2008-12-29 at 11:54 +1100, Ben Finney wrote:
Some members do not agree that the supermajority-required ballot
options actually required changes to the foundation documents, which
is not a comment on how those people think supermajority requirements
should be assigned.
I can only
On Sun, 2008-12-28 at 20:45 -0500, Theodore Tso wrote:
On Mon, Dec 29, 2008 at 12:48:24AM +, Simon Huggins wrote:
I wonder how many DDs were ashamed to vote the titled Reaffirm the
social contract lower than the choices that chose to release.
I'm not ashamed at all; I joined
On Mon, 2008-12-29 at 15:02 +1000, Anthony Towns wrote:
For example, having non-free in the archive and the BTS (and potentially
buildds and elsewhere) is implied by point (3) (ie, supporting Debian
users who choose to use non-free software to the best of our ability),
and potentially using
On Thu, 2008-10-23 at 18:13 +0100, Neil McGovern wrote:
Perhaps I'm mis-reading the above. Which bit of the foundation documents
do you think would need overriding for the tech-ctte to rule on which
fix to take?
One might think that this is the situation: two alternative fixes for
the DFSG
On Tue, 2008-10-21 at 15:22 +, Anthony Towns wrote:
Thomas: your continued inaction and unwillingness to code an acceptable
solution to this issue, in spite of being aware of the problem since
at least 2004 -- over four years ago! -- means we will continue to do
releases with non-free
On Tue, 2008-10-21 at 20:24 +0200, Pierre Habouzit wrote:
On Tue, Oct 21, 2008 at 05:52:28PM +, Manoj Srivastava wrote:
This is the part I am not comfortable with. I do not think the
delegates have the powers to decide when enough progress has been made
to violate a foundation
On Tue, 2008-10-21 at 21:21 +0200, Frans Pop wrote:
Thomas Bushnell BSG wrote:
I am *happy* to code an acceptable solution, but I regard not support
the hardware for installation as acceptable.
I'm very glad that history has shown most developers disagree with you.
So I can upload
On Tue, 2008-10-21 at 14:59 -0500, William Pitcock wrote:
If we waited for a release to be 100% perfect, it will likely take
several more years. The good news is that the amount of inline firmware
in the kernel is decreasing. So, eventually, all non-DFSG
redistributable firmware can belong in
On Tue, 2008-10-21 at 22:47 +0200, Frans Pop wrote:
On Tuesday 21 October 2008, Thomas Bushnell BSG wrote:
I see. So the previous statement that nobody is standing in the way
of a fix is simply not so. People certainly are standing in the way.
That's nonsense. Uncoordinated NMUs
On Tue, 2008-10-21 at 16:00 -0500, William Pitcock wrote:
Unfortunately, those who contribute to Debian must be dedicated to
ensuring future releases of Debian support the latest available hardware
at time of release.
No matter what our principles are? Wow. Why are we not equally
committed
On Tue, 2008-10-21 at 23:28 +0300, Kalle Kivimaa wrote:
Would it be a good compromise between SCs #1, #3 and #4 if we made an
exhaustive list of non-free bits in main, and make it our goal that the
list gets smaller between each release and not to add anything to
that list?
I would be
On Tue, 2008-10-21 at 22:31 +0200, Aurelien Jarno wrote:
I knew I haven't quote enough parts of DFSG:
5. Works that do not meet our free software standards
We acknowledge that some of our users require the use of works that do
not conform to the Debian Free Software Guidelines. We have
On Tue, 2008-10-21 at 23:23 +0200, Frans Pop wrote:
On Tuesday 21 October 2008, you wrote:
But, in fact, fixes are not welcome from the team. They have raised a
major roadblock, allowing only one kind of fix which requires a lot of
work, and rejecting anything simpler.
Ever hear of the
On Tue, 2008-10-21 at 16:27 -0500, William Pitcock wrote:
On Tue, 2008-10-21 at 14:20 -0700, Thomas Bushnell BSG wrote:
On Tue, 2008-10-21 at 23:28 +0300, Kalle Kivimaa wrote:
Would it be a good compromise between SCs #1, #3 and #4 if we made an
exhaustive list of non-free bits in main
On Tue, 2008-10-21 at 17:06 -0500, William Pitcock wrote:
I worded that rather badly. You should imply within acceptable terms of
the DFSG here... in this case, putting stuff in the nonfree firmware
package in non-free is an acceptable solution.
Of course; that's an excellent solution. Right
On Tue, 2008-10-21 at 18:45 -0500, Ean Schuessler wrote:
I guess the question is, staying in the arena of 100% Free, what if
DRM technologies become pervasive in the United States and Europe and
it literally becomes illegal to have a computer without some
proprietary software in it? What if it
On Mon, 2008-10-20 at 11:43 -0500, Manoj Srivastava wrote:
Actually, I think we need a GR on the lines of
,
| http://www.debian.org/vote/2006/vote_007
| General Resolution: Handling source-less firmware in the Linux kernel
`
To get a special dispensation for
On Mon, 2008-10-20 at 19:11 +0100, Mark Brown wrote:
On Mon, Oct 20, 2008 at 10:55:00AM -0700, Thomas Bushnell BSG wrote:
I object to a second round of this. I was ok with it once, as a
compromise, but the understanding I had then was that it was a one-time
thing, to give time
On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote:
No, really. The kernel team are volunteers. Ordering them to do things
doesn't help at all; one could equally well send the same message to
everyone working on Debian (or, indeed, the wider community) since they
could also step up to the
On Sun, 2008-03-16 at 04:29 -0500, Manoj Srivastava wrote:
All this replacement in favour of a better person sounds very
nasty, mean, and likely to be highly subjective to me, and most
organizations do not often throw people out while they are still
performing their duties.
Of
On Mon, 2008-03-17 at 00:13 +0100, Andreas Barth wrote:
* Thomas Bushnell BSG ([EMAIL PROTECTED]) [080316 21:01]:
On Sun, 2008-03-16 at 04:29 -0500, Manoj Srivastava wrote:
The creiteria can be more than just voting on issues -- look for
number of emails on threads on a issue
On Mon, 2008-03-17 at 00:33 +0100, Andreas Barth wrote:
I see; so there are no members of the technical committee who have
failed twice to vote?
I'm not sure how not voting twice in a row makes someone a less
important contributor by definition.
I see; so what number do you think would
On Mon, 2008-03-17 at 00:33 +0100, Andreas Barth wrote:
But I would really prefer if you would fix your own packages instead of
relaying on our BSPers.
Actually, I'm very good about uploading fixes for RC bugs promptly. The
bugs I think you are referring to were marked severity important.
On Mon, 2008-03-17 at 02:46 +0100, Cyril Brulebois wrote:
On 17/03/2008, Thomas Bushnell BSG wrote:
Actually, I'm very good about uploading fixes for RC bugs promptly.
The bugs I think you are referring to were marked severity
important. Perhaps the bugs were tagged incorrectly
On Mon, 2008-03-17 at 03:12 +0100, Cyril Brulebois wrote:
On 17/03/2008, Thomas Bushnell BSG wrote:
I thought all RC bugs were supposed to have severity serious or
higher. Has that been changed?
RC != RG.
Ah, well then there is no need to berate me for failing to fix the bug
immediately
On Mon, 2008-03-17 at 03:12 +0100, Cyril Brulebois wrote:
And what exactly does this have to do with the technical committee?
No idea. It looks like it all started with
[EMAIL PROTECTED], and since you're still
wondering about RC/RG bugs, I'm answering these questions.
It would be a shame
On Sat, 2008-03-15 at 00:41 -0700, Steve Langasek wrote:
Oh, and we need a way to deal with the structural problem of questions
which get posed to tech-ctte and simply never answered at all. Suppose
the tech-ctte fails to answer a question in, oh, three months, the
entire membership is
On Thu, 2008-03-13 at 23:46 -0700, Russ Allbery wrote:
Anthony Towns [EMAIL PROTECTED] writes:
Neither is the argument I'm making. The argument I'm making is that
because it's likely there are better ways of doing things than the way
we're doing things now (ie, though foo is the way
On Fri, 2008-03-14 at 11:40 -0500, Manoj Srivastava wrote:
I do not presume to be omniscient. But I believe lack of time,
which is reflected in lack of contribution to the debate on a topic,
and, even worse, lack of participation in the voting effort, is
definitely a root cause,
On Mon, 2007-06-25 at 12:53 +0200, Benjamin BAYART wrote:
Le Sun, Jun 24, 2007 at 09:50:37PM -0700, Thomas Bushnell BSG:
Yes. So, the right solution if I want to help is:
- first I spend a lot of time proving that I'm skilled enough to read
crazy licenses in a language
Yes. So, the right solution if I want to help is:
- first I spend a lot of time proving that I'm skilled enough to read
crazy licenses in a language that is not mine
No, you only have to do this if you want to package software and upload
it into the archive without review.
- then I spend
On Thu, 2007-05-10 at 15:47 +0100, MJ Ray wrote:
Sven Luther [EMAIL PROTECTED] wrote:
The DAMs, who did not follow their own procedure [...]
I contacted Sven Luther directly with an offer to start a GR to rescind
the decision and optionally do some other stuff. I've seen no reply.
The
Matthias Urlichs [EMAIL PROTECTED] writes:
On Sat, 07 Oct 2006 23:53:35 +, Debian Project Secretary wrote:
[ ] Choice 1: Re-affirm DPL, wish success to unofficial Dunc Tank
[ ] Choice 2: Re-affirm DPL, do not endorse nor support his other projects
and
[ ] Choice 1: Recall the
Anthony Towns aj@azure.humbug.org.au writes:
I believe that distributing firmware written in chunks of hex is in
compliance with the GPL, and repetition of your arguments isn't going
to change that belief.
Do you really think that the GPL contains an exception for firmware
blobs? Or that the
MJ Ray [EMAIL PROTECTED] writes:
How is the DPL empowered to take that decision when it is so obviously
against some developers' opinions?
Are you seriously saying that a minority of developers have a vote
power over the actions of the DPL?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
Manoj Srivastava [EMAIL PROTECTED] writes:
I don't care about just the proposers opinion, I want to
ensure that what the proposer is telling me is what the people and
the sponsors also agreed to. I suppose we could have a lengthy email
exchange, and assume that the sponsors are
Manoj Srivastava [EMAIL PROTECTED] writes:
Seems like I'm damned if I do, and damned if I don't.
It seems to me as if what happened was:
You thought the preamble was rationale and not part of the
resolution proper; but the proposer said no, that was an important
part of the resolution
Manoj Srivastava [EMAIL PROTECTED] writes:
What is an issue is that a sloppy proposal mail may have
mislead the sponsors to believe that a preamble was an introductory
section, or vice versa. Hard to know unless the proposors and ponsors
are clear about their intent.
Right, so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I second this proposal.
Don Armstrong [EMAIL PROTECTED] writes:
Because there appears to be some residual confusion[1][2][3] about
what I actually proposed and its content, here is the proposal as it
currently stands. The proposal is only the
I want to issue a somewhat blanket apology; I'm trying to get better,
but I do so only in fits and starts.
In my posts about the controversial etch/drivers/freeness issue, I
crossed the line more than once into unhelpful and unreflective
posts. I am sorry, and if you were hurt or offended by
Steve Langasek [EMAIL PROTECTED] writes:
On Fri, Sep 08, 2006 at 12:01:37AM -0700, Thomas Bushnell BSG wrote:
One of the people hinting at this has been Steve, who basically said
to me recently that for some packages, they would get booted from the
release for violating the DFSG
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Sep 07, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
The widely accepted custom was to interpret the DFSG this way, yes.
This is what matters.
What is your evidence of this?
My experience of 9 years in Debian, which can be verified by browsing
Anthony Towns [EMAIL PROTECTED] writes:
On Wed, Sep 06, 2006 at 10:21:18AM -0700, Thomas Bushnell BSG wrote:
We could have met those expectations of the d-i and kernel teams had
taken the issue seriously before now. Their failure to do so does not
translate to an emergency on my or Debian's
Josselin Mouette [EMAIL PROTECTED] writes:
Le mardi 05 septembre 2006 à 19:07 -0700, Thomas Bushnell BSG a écrit :
For me the key question is whether the d-i team is actually doing the
work or not. Are they? If the answer is yes, then I might vote for
a delay. If the answer is no, then I
Marco d'Itri [EMAIL PROTECTED] writes:
As usual you forget that we also have that other commitment to our
users, and that we used to pride ourselves in providing the best free OS.
There is an absolute ranking in Debian, that *first* we must provide
100% free software, and *second* we do
Anthony Towns aj@azure.humbug.org.au writes:
As best I can see, our users expect us to release etch soon rather than
either of the approaches to fixing that that have been mooted so far
(drop drivers or delay etch), and I don't believe we can fairly say
we're putting the needs of our users
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Sep 06, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
No, it's a contentious issue because some people are trying hard to
change the values of Debian replacing what was a compromise widely
accepted by everybody in Debian and most people outside
[EMAIL PROTECTED] (Marco d'Itri) writes:
The widely accepted custom was to interpret the DFSG this way, yes.
This is what matters.
What is your evidence of this?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Russ Allbery [EMAIL PROTECTED] writes:
Not for some reason, for some very obvious reasons. They're not adequate
as an immediate solution to this problem because separating the firmware
from the packages that currently contain it is hard and needs development
and because d-i currently can't
Marco d'Itri [EMAIL PROTECTED] writes:
No, it's a contentious issue because some people are trying hard to
change the values of Debian replacing what was a compromise widely
accepted by everybody in Debian and most people outside Debian with
mindlessly following their idea of the DFSG.
I'm
Anthony Towns aj@azure.humbug.org.au writes:
We'll fail to meet it for firmware and logos in etch, including our own
logo, and to the best of my knowledge, we're yet to consider addressing
the license of documents like the Debian Manifesto, or the Debian
Constitution.
What? Are you
Josselin Mouette [EMAIL PROTECTED] writes:
Following the social contract change, we have been able to remove most
of non-free stuff from the distribution, especially documentation. It
wasn't easy and we couldn't make it in time for sarge, but we can make
it in time for etch. For etch, we have
Anthony Towns aj@azure.humbug.org.au writes:
No. Ceasing to make commitments we can't keep doesn't mean we should
stop meeting the commitments we can. Which is why the bullet points you
didn't quote were in the proposal.
What do you mean that we can't keep the commitment to make the
kernel
Russ Allbery [EMAIL PROTECTED] writes:
Point 2.1.1 of the Debian Constitution is relevant here. Under the Debian
Constitution, you have no grounds for expecting the d-i team to work on
this on your preferred time scale. If you want to get work done that
other people have not completed as
Sven Luther [EMAIL PROTECTED] writes:
It seems to me that this GR is unacceptable in this form because it
does not give an adequate definition of firmware, and people seem to
mean many different things by it.
Well, in this case, firmware is clearly the firmware blobs actually into the
Raphael Hertzog [EMAIL PROTECTED] writes:
So I don't think it's a 3:1 issue. We're not changing our goals, only
clarifying the timeline and acknowledging that the etch timeframe is too
short for us to reach this goal.
I don't believe it. We already clarified the timeline, and created a
Sven Luther [EMAIL PROTECTED] writes:
So how do I know whether something is firmware instead of just
ordinary sourceless code?
Ah, well, i would say that the definition you search here are :
hexdump sourceless blobs which are uploaded to a peripheral device.
So you would say that it is
Sven Luther [EMAIL PROTECTED] writes:
No. The sourceless firmware blobs mentioned in this GR, are identified as
those programs or register dumps or fpga config files, which are uploaded to a
peripheral processor, and are part of a linux kernel driver in some way,
usually an array of chars or
Sven Luther [EMAIL PROTECTED] writes:
Nope, i am not sure we have such microcode in the kernel tree. It certainly
fits the same category as the rest of the stuff, and i think the above
identifies perfectly which firmware blobs we are speakign about.
Huh? Microcode for the main processor
Jacob Hallen [EMAIL PROTECTED] writes:
My personal experience is that the larger the company, the smaller the
interest in change will be and they will only change when outside pressure
forces them to. This leads me to believe that the quickest way to a future
where we can distribute free
Sven Luther [EMAIL PROTECTED] writes:
Microcode for the main processor does not match (2) or (3). So no,
there is no obvious likeness between microcode for the main processor
and the rest of the stuff.
Microcode does run in a lower level of the cpu than the main code, as thus you
could see
Frederik Schueler [EMAIL PROTECTED] writes:
1. We affirm that our Priorities are our users and the free software
community (Social Contract #4);
2. We acknowledge that there is a lot of progress in the kernel firmware
issue; however, it is not yet finally sorted out;
3. We give priority to
David Nusinow [EMAIL PROTECTED] writes:
On Wed, Aug 30, 2006 at 10:41:00PM -0700, Thomas Bushnell BSG wrote:
David Nusinow [EMAIL PROTECTED] writes:
Would you, or someone else, mind pointing out some examples of firmware
with source? Preferrably with some of the breadth you refer to above
Steve Langasek [EMAIL PROTECTED] writes:
If it's the latter, I maintain that this is precisely the subject matter of
the proposed GR; we obviously *don't* have agreement in Debian over what
should or should not be considered a program, so I think that's begging
the question.
However, your
I think it is ludicrous to pretend that firmware is not a program.
Suppose we had in our possession the source code and an assembler for
it. Surely then it would be obviously a program.
thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
Steve Langasek [EMAIL PROTECTED] writes:
4. determines that for the purposes of DFSG #2, device firmware
shall also not be considered a program.
I am bothered that there is never a definition of firmware here. It
seems to me that if you gave one, it would be something like:
firmware
Steve Langasek [EMAIL PROTECTED] writes:
As you and I discussed previously on IRC, I don't agree with this amendment.
The premise of my proposal is that we are *not* granting an exception nor
redefining any terms, we are merely recognizing a latent definition of
programs that has guided
Sven Luther [EMAIL PROTECTED] writes:
Notice that the bios or other firmware used on most machines today is also
refered as firmware. The original definition is, i believe, any kind of code
provided by the vendor of said device, and on which he has full control, so
firmware was non-free by
Sven Luther [EMAIL PROTECTED] writes:
In cases like hte NLSU thingy, the firmware goes to include the whole linux +
userland stack on top of whatever they use for booting, since it is held in
the flash of the board.
Wow. I thought that doesn't run on the main CPU was entirely
indefensible.
Sven Luther [EMAIL PROTECTED] writes:
The idea is that the firmware is all the software and other softwarish
information which the vendor provides to make use of the board he sells you.
I see. If I buy a standard-issue Dell computer, then Windows is
firmware, right? (Dell does provide it,
Josselin Mouette [EMAIL PROTECTED] writes:
At the end of DFSG #2, the following text should be added:
The license may restrict distribution to some kinds of media if
it is still possible to distribute the source code and compiled
code together on at least one
Josselin Mouette [EMAIL PROTECTED] writes:
Le jeudi 06 avril 2006 à 09:50 -0700, Thomas Bushnell BSG a écrit :
Josselin Mouette [EMAIL PROTECTED] writes:
At the end of DFSG #2, the following text should be added:
The license may restrict distribution to some kinds of media
Jeroen van Wolffelaar [EMAIL PROTECTED] writes:
On Sat, Mar 11, 2006 at 01:20:19PM +, Neil McGovern wrote:
If you were elected tomorrow as DPL, and could only pick one thing about
Debian to change, what would it be?
Make our mailinglists an enjoyable place for technical discussions.
James Troup [EMAIL PROTECTED] writes:
But I never personally replied to Joey's mail about the next point
release explicitly saying that fixing sudo was a pre-depends, and I
apologise for that.
You're not a DPL candidate, and if this question is relevant at all,
it's relevant to DPL
Ted Walther [EMAIL PROTECTED] writes:
I think the other DPL candidates, especially Steve McIntyre who has been
pussy-footing around this issue, should stand forward and say clearly
where they stand on the issue of expelling developers; what is a just
case for expulsion? Be really clear and
Anthony Towns aj@azure.humbug.org.au writes:
If I could pick /anything/, it'd be to make Debian suddenly 100% fun
for everyone involved.
Yeah, I'm with you!
Can you outline perhaps some of the things you think that keep it from
being 100% fun, and what the DPL can do to help them?
I'm
Anthony Towns aj@azure.humbug.org.au writes:
If I can only pick the things that're directly achievable, I'll just
go with getting the momentum back -- ie, doing cool things quickly and
regularly, no matter what they are.
What are some of the organizational or institutional factors which you
Craig Sanders [EMAIL PROTECTED] writes:
the GPL says you must include the full machine-readable/editable source
code, so if you can't do that in a given medium (say, a chip with 1KB
capacity) then GPL software is not free in any medium.
Of course, but that isn't an imposition on changes.
If
Craig Sanders [EMAIL PROTECTED] writes:
why are you obsessing with a convenience issue and pretending that it
has ANY BEARING AT ALL on freedom issues? it doesn't.
I think if you'll look at the header you'll see that this is about a
new practical problem. If you aren't interested in the
Craig Sanders [EMAIL PROTECTED] writes:
bullshit. freedom, as used by Debian, is explicitly defined in the
DFSG. the DFSG has a number of clauses detailing what we consider
free and what we don't consider free. convenience is NOT one of those
clauses, and never was. in fact, convenience is
Craig Sanders [EMAIL PROTECTED] writes:
On Mon, Feb 13, 2006 at 01:42:44PM -0700, Hubert Chan wrote:
3a only says that a binary has to be *accompanied* with the source code.
Hence it can be on a separate medium. So you can distribute your 1KB
chip, stapled to a CD-ROM that contains the
Craig Sanders [EMAIL PROTECTED] writes:
once again: you *can* modify an invariant section by patching it. the
GFDL does not say you can not modify at all, it says you can not
delete or change these small secondary sections, but you can add your
own comments to them.
A patched version of the
Craig Sanders [EMAIL PROTECTED] writes:
don't be an idiot. you only have to keep the invariant sections if you
are DISTRIBUTING a copy. you can do whatever you want with your own
copy.
Right, so you can't *distribute* a copy on an ASCII-only medium, even
of the English translation of a
Craig Sanders [EMAIL PROTECTED] writes:
there's nothing in the GFDL that prevents you from doing that. the
capabilities of your medium are beyond the ability of the GFDL (or any
license) to control.
This is hardly true. The GFDL says you must transmit the original
Japanese text in the case
Nick Phillips [EMAIL PROTECTED] writes:
Certainly looks like you think that there is some absolute way to
determine that the license is not DFSG-compliant to me. If there
isn't, then the if in the first part of your sentence is never
satisfied, and the rest is completely hypothetical.
Wrong.
Anton Zinoviev [EMAIL PROTECTED] writes:
On Fri, Feb 10, 2006 at 02:30:43PM -0800, Thomas Bushnell BSG wrote:
Anton Zinoviev [EMAIL PROTECTED] writes:
On Fri, Feb 10, 2006 at 11:55:11AM -0800, Thomas Bushnell BSG wrote:
But that isn't my point. My point is that you can't include
Anton Zinoviev [EMAIL PROTECTED] writes:
If you want your binary to use pieces from the manual for help
strings, then your binary has to read these pieces from auxiliary file
which would be (speaking in the terms of GFDL) an opaque copy and
would be covered under GFDL.
Likely not. In all
1 - 100 of 793 matches
Mail list logo
