[EMAIL PROTECTED] wrote:
i have read that graphviz is licensed under the Common Public License
Version 1.0 [1]. The FSF consider this license as free and also in the
debian-legal mailing-list archive i couldn't find a statement that debian
have a different view.
So why this package is in
[EMAIL PROTECTED] wrote:
Personally, I think all licenses that impose restrictions like those in the
APSL are non-free.
I think that these are all desireable restrictions in many classes of
free licenses.
OTOH, what we'd like to see or not in a license does not have an obvious
on its freeness.
[EMAIL PROTECTED] wrote:
Do you really want to argue that software under licences which try to
affect other pieces of unrelated software meets the DFSG?
Yes, because I do not believe that it is a restriction on other
software.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
[EMAIL PROTECTED] wrote:
Since the license is somewhat restricted I am considering putting the
package in contrib or non-free sections.
What section would you suggest?
After last year's general resolution, the firmware cannot be distributed
in main or contrib because it lacks source code.
--
[EMAIL PROTECTED] wrote:
Do we have to split the alsa-tools source into two packages, one free
and one non-free/contrib? It will make it a bit harder.
No.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
This is an interesting opinion, but I can't see which part of the DFSG
supports it.
The DFSG also doesn't tell us that we should not distribute too buggy
software - but we still try to avoid release such packages.
But still this does not make buggy packages not
[EMAIL PROTECTED] wrote:
People like Marco keep saying the DFSG doesn't say it explicitly,
therefore it should be allowed, which is irresponsible, favoring
getting their warez in main (despite the latest ugly restrictions)
over keeping Debian Free. Instead, he and others should be arguing
While
[EMAIL PROTECTED] wrote:
You are missing the obvious point that the debian-legal consensus is not
the definition of freedom for Debian. So yes, I think that this
consensus has a limited value.
But there's a difference between holding something in little value and
attempting to reduce it's
[EMAIL PROTECTED] wrote:
You treat the DFSG as a set of pesky rules to be weaseled around and
dictionary-lawyered, instead of a set of guidelines to be followed.
No, I don't.
(Nice arguments these...)
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
[EMAIL PROTECTED] wrote:
First, thank you all very much for your time and
valuable insight. I foresaw the issue would be
controversical, but if debian-legal is not *the* place
where it should be debated, where else could it be ?
Ask the debian listmasters to create [EMAIL PROTECTED] There is
[EMAIL PROTECTED] wrote:
By throwing hardware support out the window? Good plan!
We already did this with the firmwares decision.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
My understanding of this is that neither the firmware constitute a derived
work from the flasher, nor the flasher constitute a derived work of the
firmware. The fact that they are individually packaged in the same elf binary
does not constitute a linking act, nor a
[EMAIL PROTECTED] wrote:
To the user, this doesn't appear as two separate works. He/she/it will
So what? This still does not make them derived.
see one program with pre-loaded data. If you are using already
existing, copyrighted data (the firmware), this means you are building
your work on top
[EMAIL PROTECTED] wrote:
It is not necessarily so clear. The FSF argues that a program's use
of an API, at least when there is only one implementation, makes it a
derived work of the program that implements the API. This is broadly
No, the FSF position is more complex than this, and is
[EMAIL PROTECTED] wrote:
It is not necessarily so clear. The FSF argues that a program's use
of an API, at least when there is only one implementation, makes it a
derived work of the program that implements the API. This is broadly
No, the FSF position is more complex than this, and is
[EMAIL PROTECTED] wrote:
In general we should distinguish the types of problems we have with
the license and separate them into a few categories:
Good work. Thank you for trying to add some sanity.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
[EMAIL PROTECTED] wrote:
Can Creative Commons
fix the confusing parts of the license?
No, because no matter how much some people pretend to be confused, the
trademark stuff is still *not part of the license*!
Now, a more useful question would be can creative commons fix the
license web page?, and
[EMAIL PROTECTED] wrote:
No, but if it's included in the licence by a licensor who considers it
part of the licence, clearly your we all know is false.
Then this licensor is using a different license which is not a CC
license. It's not that hard.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to
[EMAIL PROTECTED] wrote:
Then we should still ask CC to make reasonable adjustments to
stop encouraging them, or to actually enforce the trademark and
stop people describing these licences as CC-by (or whatever)
instead of leaving it to us to mop up. It's not that hard to
Sure, I see nothing
[EMAIL PROTECTED] wrote:
I'm following this thread -and some other- but is not so easy to
understand it completely - right now I am studying the desert island
test...;-)
There are better ways to spend you time, these tests are not based on
the DFSG and so are not much relevant.
I don't know if
[EMAIL PROTECTED] wrote:
I suppose you are reading Barak Pearlmutter's DFSG FAQ
(http://people.debian.org/~bap/dfsg-faq.html), right?
yes, it is a faq in debian.org, although in a personal page.
Should I not consider that faq?
You should consider it as the opinion of a debian-legal contributor,
On Apr 04, Greg KH [EMAIL PROTECTED] wrote:
What if we don't want to do so? I know I personally posted a solution
Then probably the extremists in Debian will manage to kill your driver,
like they did with tg3 and others.
This sucks, yes.
--
ciao,
Marco (@debian.org)
signature.asc
On Apr 04, Sven Luther [EMAIL PROTECTED] wrote:
What if we don't want to do so? I know I personally posted a solution
Then probably the extremists in Debian will manage to kill your driver,
like they did with tg3 and others.
Nope, they were simply moved to non-free, as it should. I
[EMAIL PROTECTED] wrote:
It's an example of how no consistent distinction between documentation and
programs can be drawn: the source *is* the documentation. I think it's a
Wrong. When using doxygen and similar programs, source and documentation
are in the same file but they are not the same
[EMAIL PROTECTED] wrote:
Legally, I can't modify a glibc API and then paste my revisions into
the glibc documentation, because my changes truly are a work derived
from GPL material and can't be amalgamated with GFDL material. I
You are totally missing the point. Even if an API were copyrightable
[EMAIL PROTECTED] wrote:
technology. Unfortunately, the company's trademark guide makes the
following restrictions on the use of the trademark:
(1) the product (i.e. the Linux kernel) must display the trademark on
the splash screen (or in the About... box);
(2) the trademark must appear in all
In linux.debian.legal Frank Lichtenheld [EMAIL PROTECTED] wrote:
Since this hasn't really worked out I propose to delete this stuff again
until someone comes up with a better idea how to better present the
work of debian-legal.
Seconded.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL
[EMAIL PROTECTED] wrote:
Wait, the QPL (with no additional permission and a choice of venue)
is *not* DFSG-free (many long discussions were hold on debian-legal last
summer, IIRC).
This is just bullshit. A few people thinking it's not free does not make
it non-free.
--
ciao,
Marco
--
To
[EMAIL PROTECTED] wrote:
The choice-of-venue makes it *non-free*.
There is no consensus about this, many people have no complaints about
choice of venue.
UNFREE: fails Desert Island test.
This is not relevant, because this test is not based on the DFSG so it
cannot make a license to be non-free.
[EMAIL PROTECTED] wrote:
It blatently fails DFSG 5, because the person modifying the software may not
have internet access for emailing the changes. (Think perhaps a developing
nation.)
I still do not believe that this is discrimination against persons or
groups. This is an unreasonable
[EMAIL PROTECTED] wrote:
Nope, I can only give you a link but as I understand it the tests are
commonly used.
http://people.debian.org/~bap/dfsg-faq.html
You do not understand correctly. This FAQ is merely the opinion of a few
debian-legal contributors, is not widely accepted and is by no
[EMAIL PROTECTED] wrote:
In both cases, the Courts have said yes, it is text book descrimination. A
group of people is being treated differently than others. However, the Court
says that while it is descrimination, it is not prohibited descrimination.
The law itself is facially neutral and
[EMAIL PROTECTED] wrote:
The Social Contract needs to be changed then, if it leads to such
a silliness.
Yes. This is why we had months-long flames and we will continue to have
them in the future.
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
[Please Cc me, I'm not subscribed.]
This is the new Postfix license. Is it GPL-compatible?
--
ciao,
Marco
---BeginMessage---
And here it is. Reactions are welcome, before we apply this license
to Postfix/Secure Mailer.
Wietse
On Mar 29, Thomas Bushnell, BSG [EMAIL PROTECTED] wrote:
It seems pretty clear to me that it is not DFSG-free. A DFSG program
needs to be usable on any operating system without discrimination, and
this license says you can use it on Linux without worrying, but if you
merely bundle it with,
[EMAIL PROTECTED] wrote:
Ah. It would be nice to have a mail archive that doesn't chop threads
into calendar-month blocks.
We do: search in linux.debian.legal on google groups.
--
ciao,
Marco
On Nov 19, Oliver Kurth [EMAIL PROTECTED] wrote:
The firmware is needed. Without it, the device is completely dumb.
But there are some devices which can store the fw permanently. Also,
the fw is distributed on their (windows) installation CDs.
Make an unofficial package which will contain just
[EMAIL PROTECTED] wrote:
I have just packaged a driver for wifi cards. The driver is licensed
under GPL, but the cards needs a non-free firmware to be uploaded in
order to work.
I will quote from policy 2.2.2:
Examples of packages which would be included in _contrib_ or
[EMAIL PROTECTED] wrote:
Probably the right question to ask is: is there any chance to use the
driver without touching the non-free firmware (nor any other non-free
stuff, for that matters)?
Can you quote which part of the policy describes this criteria?
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
If the driver does not provide any significant functionality without the
firmware, it belongs in contrib.
The driver provides all of its functionality without the firmware, the
firmware never becomes part of the driver. The hardware device may or
may not provide useful
[EMAIL PROTECTED] wrote:
I think it's a question of what dependence means for contrib. If the
driver absolutely _depends_ on using the non-free firmware, it should be
in contrib. If the non-free firmware is optional, it should go into
main.
Again, please explain which part of the policy defines
[EMAIL PROTECTED] wrote:
On the other side, if it is possible to distribute the firmware in the
non-free section (I have to ask that to Texas Instrument), the package
of the driver will have a Depends: or at least a Recommends: on the
firmware package. In that case it seems that the driver has
[EMAIL PROTECTED] wrote:
This package should be removed from Debian before Debian gets sued for
copyright infringement.
Can you cut this bullshit please? You know well that Debian is not going
to get sued.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
Of course, there's shades of gray, here. If all the driver does is emit
a message CAN'T FIND NON-FREE FIRMWARE, ABORTING without the firmware,
it's hard to say that it doesn't depend on the firmware. But if the
This applies to almost every driver in the Linux kernel.
[EMAIL PROTECTED] wrote:
Right, the package in main should not depend on an hypothetical package
from non-free.
So rather than ship the driver in contrib and the firmware in
non-free, you're suggesting that the driver go in main and the
firmware not be shipped at all, even though that reduces
On Oct 11, Evan Prodromou [EMAIL PROTECTED] wrote:
I think it's a question of what dependence means for contrib. If the
driver absolutely _depends_ on using the non-free firmware, it should be
in contrib. If the non-free firmware is optional, it should go into
main.
Again, please
[EMAIL PROTECTED] wrote:
It's a perfectly reasonable means to discriminate. One is *in the
hardware*. If I buy a widget, I don't care whether it uses firmware
in an eeprom or a well-trained gerbil. It's a box. Software on my
CPU is different.
Firmwares do not run on your CPU. Your poing
[EMAIL PROTECTED] wrote:
Why should debian adopt a different policy if the vendor provides this
firmware on a CD instead of on a flash EEPROM chip?
Because of the reasonable expectation that the user already has the
EEPROM chip, and it's part of the hardware. It's not something Debian
could
[EMAIL PROTECTED] wrote:
Anyways, here's the relevant quote:
Examples of packages which would be included in contrib or
non-US/contrib are: [...] free packages which require contrib,
non-free packages or packages which are not in our archive at
all for
[EMAIL PROTECTED] wrote:
Marco, it seems to me that there's a parallel case to non-free
firmware: dongleware. Perhaps you could explain how this philosophy
applies to that. If a piece of software is distributed under the GPL,
can I add functionality by putting it into firmware on a dongle and
[EMAIL PROTECTED] wrote:
I think that requiring a hardware upgrade to support behavior is
irrelevant to free software. Firmware that's part of the hardware is
part of the hardware. Firmware that looks like software is software.
If Debian *could* ship it, it's software.
This distinction is not
[EMAIL PROTECTED] wrote:
In both cases, the quantity of non-free software used has remained the
same. The purpose of contrib is to discourage free software with
non-free dependencies. Deciding whether software falls into it or not
purely based on another vendor's choice of media seems mad. Either
[EMAIL PROTECTED] wrote:
I find the criteria extremely clear and consistent: if it depends on
stuff that is either non-free, or that is too non-free to even ship, it
goes to contrib. If a user can install and run it (and be able to
But, as I already explained, the driver does not depend on the
[EMAIL PROTECTED] wrote:
That would probably depend on the license on the non-free drivers.
We are not discussing non-free drivers, but 100% free (usually GPL'ed)
drivers.
One problem with non-free drivers in downloaded firmware is that they
can be licensed such that not everyone who owns the
[EMAIL PROTECTED] wrote:
Marco d'Itri wrote:
So you understand that we will remove from the kernel e.g. ide-cd and
the ACPI subsystem? This does not appears to be correct to me.
Is it completely impossible to have an IDE CD drive or an ACPI hardware
system without keeping part of it under
[EMAIL PROTECTED] wrote:
If Debian *could* ship it, it's software.
This distinction is not clear at all to me. What if I take a dump of the
flash EPROM chip? Does this magically makes the firmware a software?
There's no magic about it. If I build a simulator for some hardware,
then my
[EMAIL PROTECTED] wrote:
Your driver can be compiled and successfully executed without the
firmware,
But does it do anything useful when executed?...
I don't know how you define useful. All its functionality is already
there, but probably the controlled device will only respond to a subset
of
In article [EMAIL PROTECTED] you wrote:
Loïc, I suggest you read the whole debian-legal thread named non-free
firmware: driver in main or contrib?, because it answers many of the
points you raised.
I will summarize the points relevant to the eagle-usb-* packages:
- distribution of firmwares with
[EMAIL PROTECTED] wrote:
Given that the entire purpose of the driver is to actually *drive a
device*, and that it can't do that at all without the firmware, then the
No, apparently you do not understand how the driver, hardware and
firmware interact. The driver is fully functional as is: the
[EMAIL PROTECTED] wrote:
Firmwares do not run on the host CPU (they are /data/ for the host
system)
Ah. You seem to be labouring under the misconception that non-program
data files aren't subject to the same rules for inclusion in main as
executable programs. That's an incorrect assumption.
No,
[EMAIL PROTECTED] wrote:
Drivers do not require firmwares, hardware devices require firmwares.
Well, actually, there are cases where the communication between firmware
and driver is tight and both need each other, i.e driver won't work with
another firmware and vice versa.
This is applicable to
[EMAIL PROTECTED] wrote:
A broken law in Germany prohibiting the utterance of a pair of words
does not make something non-free. If that line of logic held--if
Agreed. This is so obvious that I can't see why this should be on topic
here.
The only problem I can see is that some mirror operators
[EMAIL PROTECTED] wrote:
The point is, some drivers DO require firmwares. I'd rather say: Some
But, as I explained, this is not correct: hardware devices require
firmwares, not drivers.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
Atari game, and he said its OK. Of course I tried to contact
der Mouse, but without luck. And since Mouse is widely used
in computing, Google didn't return something usefull.
You need to know what to look for... der Mouse is well known in some
circles. :-) mailto:[EMAIL
[EMAIL PROTECTED] wrote:
Huh? If a driver requires a firmware blob be copied from a driver CD,
Please repeat after me: drivers do not require firmwares, hardware
devices require firmwares.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
The total amount of non-free software on a user's system is different if the
firmware comes pre-loaded on the device than if we have to load it from the
OS, isn't it?
No.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
Huh? If a driver requires a firmware blob be copied from a driver CD,
Please repeat after me: drivers do not require firmwares, hardware
devices require firmwares.
And the driver requires a functioning hardware device. Thus, the
This is not an use of the verb require
[EMAIL PROTECTED] wrote:
On the other hand, if it's clearly software when it's on CD then it's
clearly software when it's on eeprom.
False. That's why we call it firmware, not just software living on a device.
Get real. Software does not change its nature depending on the media
it's stored on.
[EMAIL PROTECTED] wrote:
Oh, wait, maybe you're suggesting that they had some OTHER reason for
putting those bits in rom? If that's the case, your claim that it
doesn't help our users is a bit specious.
It's not obvious that this would be an improvement which benefits users.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
Huh? If a driver requires a firmware blob be copied from a driver CD,
Please repeat after me: drivers do not require firmwares, hardware
devices require firmwares.
Then, how do you explain the ipw2200 case where driver version 0.5 and
less will only work with a
On Oct 25, Brian Thomas Sniffen [EMAIL PROTECTED] wrote:
Marco d'Itri [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Huh? If a driver requires a firmware blob be copied from a driver CD,
Please repeat after me: drivers do not require firmwares, hardware
devices require firmwares
[EMAIL PROTECTED] wrote:
be provided while keeping the packages in contrib), but I didn't see
anything where you argued that a package in main that requires software
not in our archive was not a violation of Policy and the Social Contract
(other than many unsupported assertions that only the
[EMAIL PROTECTED] wrote:
So if you don't have the firmware installed (into
/usr/lib/hotplug/firmware/something_or_other), the driver will only
print an error message and return an error code. If that is your
definition of fully functional, then perhaps we should include all the
programs in
[EMAIL PROTECTED] wrote:
Heck, for all I know there's a device out there where the firmware on
disk is verilog code, and it's compiled by the driver and loaded to
an FPGA on the device.
Surely that's software.
I'm not so sure that an FPGA design is software (for sane definitions of
software).
[EMAIL PROTECTED] wrote:
While this is true, it is incomplete: the driver Depends, in the
policy sense, on the device, and the device Depends on the firmware.
I do not think policy can justify this.
Obviously any kind of device driver has limited practical use[1] if
you do not own the hardware
[EMAIL PROTECTED] wrote:
On Mon, Oct 25, 2004 at 04:43:50PM +0200, Marco d'Itri wrote:
Please repeat after me: drivers do not require firmwares, hardware
devices require firmwares.
Then, how do you explain the ipw2200 case where driver version 0.5 and
less will only work with a certain
[EMAIL PROTECTED] wrote:
On Mon, Oct 25, 2004 at 11:44:37AM +0200, Marco d'Itri wrote:
Huh? If a driver requires a firmware blob be copied from a driver CD,
Please repeat after me: drivers do not require firmwares, hardware
devices require firmwares.
The driver is opening a block of data
[EMAIL PROTECTED] wrote:
In cases where firmware is basically indistinguishable from hardware,
we treat it as hardware, and not as software.
Really? Which part of policy states this?
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
Then there's no point continuing this conversation. An FPGA design,
living as a file on disk and possibly even shipped by Debian is
clearly software under Debian's definitions. Runtime-loaded firmware
I was not discussing Debian's definitions now.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
In cases where firmware is basically indistinguishable from hardware,
we treat it as hardware, and not as software.
Really? Which part of policy states this?
Historical practice.
OK, thank you for confirming that this has no foundation in the policy.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
I'm telling you some drivers *do depend* on a certain firmware. You're
still repeating the opposite. Now explain me how in ipw2200 case the
driver doesn't *depend* on the firmware, since you seem to know the
truth.
You are using a different meaning of depend than the
[EMAIL PROTECTED] wrote:
Yes, Marco. We all understand the model you propose, based around the
idea all firmware is essentially hardware, even if it's clearly a
file that has to be there on disk for a driver to function. An
Now it's quite clear that you did not understand at all what I have
[EMAIL PROTECTED] wrote:
These two cases are well different: the first driver already contains
all code needed to manage the hardware device (even if it chooses to not
send some commends to the device until it will be ready to process them),
in the second case the program is not complete and
[EMAIL PROTECTED] wrote:
No, this is again wrong: a program and the libraries it use are a single
entity (why do you think it's called linking?) while drivers and devices
are different entities.
They interact the same way IM clients and servers interact.
From the point of view of userspace, a
[EMAIL PROTECTED] wrote:
On Tue, Oct 26, 2004 at 12:27:09PM +0200, Marco d'Itri wrote:
In cases where firmware is basically indistinguishable from hardware,
we treat it as hardware, and not as software.
Really? Which part of policy states this?
It's very interesting how quickly people who fail
[EMAIL PROTECTED] wrote:
On Wed, Oct 27, 2004 at 10:56:58AM +0200, Marco d'Itri wrote:
I explained my principles at the beginning of the discussion, and I do
not feel the need to state them again because they are not relevant here:
How about something that is relevant, then?
If that's
[EMAIL PROTECTED] wrote:
In the goal of seeking consistency, I think this requires mass bug
filing against packages with unmet dependencies, including:
If dependencies really have to be followed outside the borders of
software manages by the OS then I agree that this is the only logical
[EMAIL PROTECTED] wrote:
Does anyone know if it is possible to obtain an IDE disc drive that
contains no non-free software,
I do not believe that this is possible.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
On Thu, Oct 28, 2004 at 10:05:05PM -0400, Michael Poole wrote:
BIOSes are in the EPROM case that I've described--part of the hardware,
already present--and go in main.
How does this exception follow from either the SC, DFSG or Policy?
Hardware is not part of Debian,
[EMAIL PROTECTED] wrote:
On Thu, Oct 28, 2004 at 10:10:47PM -0400, Michael Poole wrote:
Conflict in what way? It says contrib and non-free are for works
that do not conform to the DFSG. Packages in contrib conform to the
DFSG but depend on software that does not. If I interpret the SC's
[EMAIL PROTECTED] wrote:
Then let's forget for a minute boot loaders. What about all drivers
which interact with non-free software stored in computers and their
peripherals?
I think you're forgetting about more than boot loaders, since this has
been explained more than once. However, I'll
[EMAIL PROTECTED] wrote:
On Fri, Oct 29, 2004 at 11:07:14AM +0200, Marco d'Itri wrote:
Hardware is not part of Debian, and the fact that Debian depends on
non-free pieces of hardware has never been considered to violate any of
the above. (And, as I've said a few times, stuff tucked away
[EMAIL PROTECTED] wrote:
On Fri, Oct 29, 2004 at 05:50:29PM +0200, Marco d'Itri wrote:
So, following from this why you think that the motherboard firmware
(the BIOS, which can be reflashed by users) or the CD reader firmware
(which can be reflashed as well, with the right tools) and e.g
On Jan 24, Russ Allbery [EMAIL PROTECTED] wrote:
[mrouted]
If anyone actually cares, I may be able to get this relicensed and am
willing to at least try. I'm mildly surprised that anyone is still using
this.
Two weeks ago I opened #227146 but the maintainer did not reply:
The OpenBSD
Let's consider a program, released under a MIT/X11 license and linked
with OpenSSL. Some GPL'ed plugins (which are dlopen'ed at run time) are
distributed with the program.
Is distribution of this package a GPL violation?
The plugins are actually a modified version of standalone applications,
so
[EMAIL PROTECTED] wrote:
Debian's committment to Free Software does not stop at the DFSG. The G
in Debian Free Software Guidelines means Guidelines.
Obviously, this is your personal view of the issue, not shared among all
developers.
--
ciao,
Marco
at 01:51:56AM +0100, Marco d'Itri wrote:
So you say that non-free software is OK with you as long as you can
pretend it's not there? Which part of the policy or SC justifies this
theory?
So you say that I was talking about pretending? Which part of what I
wrote justifies this interpretation
[EMAIL PROTECTED] wrote:
Yes, sure! If some stream of bits is considered software when stored in
RAM then I can't see why it should not be software anymore when stored
in some other media. I have not seen any convincing argument about why
software should lose its nature if stored in ROM.
If
[EMAIL PROTECTED] wrote:
On Mon, Nov 01, 2004 at 01:51:56AM +0100, Marco d'Itri wrote:
So you say that non-free software is OK with you as long as you can
pretend it's not there? Which part of the policy or SC justifies this
theory?
If I ignore something as a part of a system when
[EMAIL PROTECTED] wrote:
On Thu, Nov 04, 2004 at 04:42:00PM +0100, Marco d'Itri wrote:
So you say that non-free software is OK with you as long as you can
ignore it's running on your system? Which part of the policy or SC
justifies this theory?
No, I've been saying that non-free software can
1 - 100 of 288 matches
Mail list logo
