Your message dated Thu, 23 Mar 2023 13:03:32 +0100
with message-id
and subject line Re: Bug#1033227: unblock: live-tasks-non-free-firmware/12.0.1
has caused the Debian Bug report #1033227,
regarding unblock: live-tasks-non-free-firmware/12.0.1
to be marked as done.
This means that you claim
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: live-tasks-non-free-firmw...@packages.debian.org
Control: affects -1 + src:live-tasks-non-free-firmware
Please unblock package live-tasks-non-free-firmware
This is provides
Processing control commands:
> affects -1 + src:live-tasks-non-free-firmware
Bug #1033227 [release.debian.org] unblock: live-tasks-non-free-firmware/12.0.1
Added indication that 1033227 affects src:live-tasks-non-free-firmware
--
1033227: https://bugs.debian.org/cgi-bin/bugreport.cgi?
Control: tags -1 confirmed
On 13-02-2023 20:45, Andreas Beckmann wrote:
src:nvidia-graphics-drivers recently moved from non-free to
non-free-firmware since the firmware-nvidia-gsp binary package was moved
to that section, too.
Ack.
Tracker reports
autopkgtest for nvidia-graphics-drivers/n
Hi Michael!
Adding the d-release mailing list to cc:.
On Fri, 31 Oct 2008 13:41:25 +0100, Michael Gilbert wrote:
i'll go ahead and start the discussion since no one else is running
with it. this matter is rather urgent since the problem is now being
considered release-critical for lenny.
be less than important [2],
it's *anyway* not more than that.
On Sun, 26 Oct 2008 11:40:34 pm Joost Yervante Damad wrote:
Hi Luca,
[3] not that I checked with such printers, I'm only in touch with one
that needs a non-free firmware
http://bugs.debian.org/cgi-bin/bugreport.cgi
severity 449497 serious
thank you
i don't see how this bug can be considered anything less than serious.
as i explained in my last message, there are two potential grave
problems: security and breakage. and even if neither of these
problems exist now, they certainly could arise during the
of the non-free firmware or
your image or sound, is that it is transported in the same binary, and used
as
data offloaded to the peripheral device.
Assume the image/sound was rendered/generated from some source format
not included in the source. E.g. povray input.
So ? What has
Sven Luther [EMAIL PROTECTED] writes:
So, now that we agreed that those modules need to go into non-free, but that
provided their licence is clear enough, like in the tg3 case, they are indeed
distriutable in non-free, let's go back to the initial point.
This is upstream work, and work which
Daniel Dickinson [EMAIL PROTECTED] writes:
On Sun, 06 Aug 2006 23:52:01 +0200
Goswin von Brederlow [EMAIL PROTECTED] wrote:
They have always been a problem and have always violated the license
of the rest of the kernel. It is just that nobody noticed or cared
before but now the cat is out
in the same deb.
Well, the FSF argues that it is not important where the file is, as long as
there is a logical link, in order to have the GPL cross the dynamic linking
barrier. In the same way, the only relationship of the non-free firmware or
your image or sound, is that it is transported
On Sat, Aug 12, 2006 at 12:46:18AM +0200, Goswin von Brederlow wrote:
Sven Luther [EMAIL PROTECTED] writes:
On Thu, Aug 10, 2006 at 06:14:08PM +0200, Goswin von Brederlow wrote:
Sven Luther [EMAIL PROTECTED] writes:
Where people buy their hardware or how free their hardware is has
Goswin von Brederlow [EMAIL PROTECTED] writes:
Is it an aggregation with the image linked into the binary?
It doesn't matter for Debian's purposes.
While the GPL permits shipping a GPL'd program merely aggregated
alongside a non-free program, we don't ship the nonfree part no matter
what, so
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Aug 07, Goswin von Brederlow [EMAIL PROTECTED] wrote:
No, because those are not linked together with the GPLed code, but are a
mere
aggregation of works inside the same media, i.e. the binary file. Those
non-free firmware will never run
the same media, i.e. the binary file. Those
non-free firmware will never run inside the same memory space as the
kernel,
and are offloaded to a peripheral processor, and the communication media
between the kernel and this peripheral processor running said firmware is
clearly defined
Sven Luther [EMAIL PROTECTED] writes:
On Thu, Aug 10, 2006 at 06:14:08PM +0200, Goswin von Brederlow wrote:
Sven Luther [EMAIL PROTECTED] writes:
Where people buy their hardware or how free their hardware is has
little to do with Debian main. It is a problem for the linux upostream
, there is no way i see that we can deal with this in a timely fashion
without delaying etch by a year or so. Remember that d-i and kernel freeze
date was planned last week.
Furthermore, there is no evidence that future upstream version of the kernel
will not add more such non-free firmware, so
Nathanael Nerode wrote:
[snip]
http://wiki.debian.org/KernelFirmwareLicensing is grossly out-of-date, but I
will integrate the relevant information from that in the process.
KernelFirmwareLicensing is supposed to track information about
mis-licensed firmware. IIRC you mentioned to have found at
Sven Luther [EMAIL PROTECTED] writes:
On Mon, Aug 07, 2006 at 02:48:08PM +0200, Goswin von Brederlow wrote:
Sven Luther [EMAIL PROTECTED] writes:
And even for an aggregation of works the DFSG holds and you are still
in trouble.
Sure, the DFSG says that we need the source code for those, and
On Thu, Aug 10, 2006 at 04:32:52PM +0200, Goswin von Brederlow wrote:
Sven Luther [EMAIL PROTECTED] writes:
On Mon, Aug 07, 2006 at 02:48:08PM +0200, Goswin von Brederlow wrote:
Sven Luther [EMAIL PROTECTED] writes:
And even for an aggregation of works the DFSG holds and you are still
Sven Luther [EMAIL PROTECTED] writes:
On Thu, Aug 10, 2006 at 04:32:52PM +0200, Goswin von Brederlow wrote:
Sven Luther [EMAIL PROTECTED] writes:
I am not familiar enough with how library are run, but there is some very
different way in which libraries called by programs work, and the way
On Thu, Aug 10, 2006 at 06:14:08PM +0200, Goswin von Brederlow wrote:
Sven Luther [EMAIL PROTECTED] writes:
Where people buy their hardware or how free their hardware is has
little to do with Debian main. It is a problem for the linux upostream
authors to support the hardware with free
Russ Allbery [EMAIL PROTECTED] writes:
Please don't lose track of the fact that there's nothing inherently wrong
with a sourceless binary if that's all the source anyone *has*.
I think in most of the cases under consideration, we have firmware
which a hardware manufacturer wrote and then
On Tue, Aug 08, 2006 at 04:49:33PM -0700, Thomas Bushnell BSG wrote:
Sven Luther [EMAIL PROTECTED] writes:
Well, it reads to me that we won't screw our users without second
thought like some here are proposing.
In my opinion, we have been screwing our users for years by lying to
them
Sven Luther [EMAIL PROTECTED] writes:
2) either move the individual affected drivers or just their firmware if
possible to non-free, and keep the cripled kernel in main.
This is certainly the last resort, in my opinion, but it isn't
crippled. Merely not supporting particular pieces of
Sven Luther [EMAIL PROTECTED] writes:
4) pass a GR explaining the issue as is, and admitting our
incapacity to fix it with 2 or 3 due to lack of ressources.
We do not need a GR to simply follow our existing procedures.
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
On Wed, Aug 09, 2006 at 12:57:36AM -0700, Thomas Bushnell BSG wrote:
Sven Luther [EMAIL PROTECTED] writes:
2) either move the individual affected drivers or just their firmware if
possible to non-free, and keep the cripled kernel in main.
This is certainly the last resort, in my
On Wed, Aug 09, 2006 at 12:58:33AM -0700, Thomas Bushnell BSG wrote:
Sven Luther [EMAIL PROTECTED] writes:
4) pass a GR explaining the issue as is, and admitting our
incapacity to fix it with 2 or 3 due to lack of ressources.
We do not need a GR to simply follow our existing
Sven Luther [EMAIL PROTECTED] writes:
On Wed, Aug 09, 2006 at 12:58:33AM -0700, Thomas Bushnell BSG wrote:
Sven Luther [EMAIL PROTECTED] writes:
4) pass a GR explaining the issue as is, and admitting our
incapacity to fix it with 2 or 3 due to lack of ressources.
We do not need a
that there was non-free
firmware in the kernel, and we decided to ignore it for the sarge
release. We explicitly did *not* decide to ignore it forever.
Maybe, but the kernel team was really operational, and not saddled with broken
legacy packaging only after the sarge release.
So, basically, you
Scores in that thread:
who how many
--
A. Spragg 1
A. Thornton1
B. Gerardo 1
D. Dickinson 1
F. Schueler1
G. Danchev 1
G. von Brederlow 4
J.
Hallo,
On Wed, Aug 09, 2006 at 02:02:42AM -0700, Thomas Bushnell BSG wrote:
We can simply take our time to do (2). It is the job of a package
maintainer to check the licenses of their software; if the kernel team
cannot do so by December, even with help, I don't mind waiting.
then, please,
On 08/02/06 22:17, Nathanael Nerode wrote:
Start with drivers/char/drm/mga_ucode.h. This is distributable, because it's
under
a BSD license, but it's not free software, because there's no source code.
There is no source code, because there never was any source code.
What do you think
are
distributability issues, while some are clearly distributable and simply
non-free. Some may be fixed by a new upstream version. Some may be fixed
by implementing firmware loading and a non-free firmware package; some may
be fixed by moving the driver to an out-of-tree kernel module; others may
be fixed
On Tue, Aug 08, 2006 at 07:39:21AM +0200, Mike Hommey wrote:
On Tue, Aug 08, 2006 at 06:49:32AM +0200, Sven Luther [EMAIL PROTECTED]
wrote:
On Mon, Aug 07, 2006 at 04:46:09PM -0700, Thomas Bushnell BSG wrote:
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Aug 08, Thomas Bushnell BSG
On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
Yes. There is the option of simply not supporting installation on
the devices in question.
i.e. screwing our users.
Why do you think people use debian? It's not the most up to date
distro or the most stable (damn close though).
my
appliance work, that's a very nice feature.
My position on non-free firmware is that distributing it certainly
seems, to my untrained eye, to violate the Social Contract, and this
needs to be addressed somehow, whether by dropping support for those
devices, amending the Contract
Adam Thornton [EMAIL PROTECTED] writes:
My position on non-free firmware is that distributing it certainly
seems, to my untrained eye, to violate the Social Contract, and this
needs to be addressed somehow, whether by dropping support for those
devices, amending the Contract, or seeking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 06 Aug 2006 23:52:01 +0200
Goswin von Brederlow [EMAIL PROTECTED] wrote:
They have always been a problem and have always violated the license
of the rest of the kernel. It is just that nobody noticed or cared
before but now the cat is out
Sven Luther [EMAIL PROTECTED] writes:
# Our priorities are our users and free software
We will be guided by the needs of our users and the free software community.
We will place their interests first in our priorities. We will support the
needs of our users for operation in many
Sven Luther [EMAIL PROTECTED] writes:
Well, it reads to me that we won't screw our users without second
thought like some here are proposing.
In my opinion, we have been screwing our users for years by lying to
them about whether their software was free. We would even say things
like hardware
Daniel Dickinson [EMAIL PROTECTED] writes:
If permission is given to distribute the blobs unmodified (i.e. read
from disk, upload to device), then the question is about the social
contract. Personally I think firmware blobs shouln't be covered,
because the reasons free software is important
May I remind you all that debian-release is NOT a discussion list?
I think the respective positions are clear. Now can the release team
please step in and say what their view on the matter is, which AFAICS is
the only reason why this thread should belong to this list?
Gerardo
On Sun, Aug 06, 2006 at 04:50:54PM -0700, Thomas Bushnell BSG wrote:
Sven Luther [EMAIL PROTECTED] writes:
So, i don't believe there is much choice left to the kernel team in
this issue but to ask for a waiver of the DFSG compliance for the
kernel for etch, and hope the d-i folk take
On Mon, Aug 07, 2006 at 10:23:31AM +0200, Frederik Schueler wrote:
Hello,
On Mon, Aug 07, 2006 at 09:32:11AM +0200, Sven Luther wrote:
These are fine words, but how do you think they can translate into reality ?
We don't currently have the ressources to do it the way it should be done,
notice
break the GPL.
No, because those are not linked together with the GPLed code, but are a mere
aggregation of works inside the same media, i.e. the binary file. Those
non-free firmware will never run inside the same memory space as the kernel,
and are offloaded to a peripheral processor
again. There can be no doubt
that binaries without source or even a DO NOT DISTRIBUTE notice
break the GPL.
No, because those are not linked together with the GPLed code, but are a
mere
aggregation of works inside the same media, i.e. the binary file. Those
non-free firmware
file. Those
non-free firmware will never run inside the same memory space as the
kernel,
and are offloaded to a peripheral processor, and the communication media
between the kernel and this peripheral processor running said firmware
is
clearly defined, there is no doubt
Sven Luther [EMAIL PROTECTED] writes:
untruth in what i said above, or in the other mail ?
Yes. There is the option of simply not supporting installation on the
devices in question.
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
Yes. There is the option of simply not supporting installation on the
devices in question.
i.e. screwing our users.
--
ciao,
Marco
signature.asc
Description: Digital signature
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
We Do Not Distribute Non-Free Software No Matter How Much It Helps Our
Users.
Now think about why we do not do it.
It does not matter. Different members of Debian have different
reasons. We
On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
Now think about why we do not do it.
It does not matter. Different members of Debian have different
reasons. We have all agreed to work together on the basis of the
Social Contract, which says that We Do Not Distribute Non-Free
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
Now think about why we do not do it.
It does not matter. Different members of Debian have different
reasons. We have all agreed to work together on the basis of the
Social Contract, which
On Mon, Aug 07, 2006 at 04:26:45PM -0700, Thomas Bushnell BSG wrote:
Sven Luther [EMAIL PROTECTED] writes:
untruth in what i said above, or in the other mail ?
Yes. There is the option of simply not supporting installation on the
devices in question.
Yeah, well, sure there is, but
On Mon, Aug 07, 2006 at 04:46:09PM -0700, Thomas Bushnell BSG wrote:
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
We Do Not Distribute Non-Free Software No Matter How Much It Helps Our
Users.
Now think about why we do not do it.
On Tue, Aug 08, 2006 at 06:49:32AM +0200, Sven Luther [EMAIL PROTECTED] wrote:
On Mon, Aug 07, 2006 at 04:46:09PM -0700, Thomas Bushnell BSG wrote:
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Aug 08, Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
We Do Not Distribute Non-Free Software
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Aug 04, Goswin von Brederlow [EMAIL PROTECTED] wrote:
think not? Prove it by proposing a GR. More importantly, the release team
I had such a plan, but no time to implement it currently.
How do you handle the fact that it is a license violation
On Saturday 05 August 2006 17:30, Marco d'Itri wrote:
In linux.debian.kernel Ron Johnson [EMAIL PROTECTED] wrote:
I see that the lawyers of SuSE and Red Hat do not believe this to be
true or at least do not consider it a problem, and this is enough for
me to ignore the opinion of the
are not linked together with the GPLed code, but are a mere
aggregation of works inside the same media, i.e. the binary file. Those
non-free firmware will never run inside the same memory space as the kernel,
and are offloaded to a peripheral processor, and the communication media
between the kernel
Marco d'Itri [EMAIL PROTECTED] writes:
In linux.debian.kernel Sven Luther [EMAIL PROTECTED] wrote:
The real issue here is one of freedom and DFSG and not one of legality anyway.
Those firmware are not DFSG-free and have nothing to do in main, and this is
the real problem.
They were not a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
George Danchev wrote:
On Saturday 05 August 2006 17:30, Marco d'Itri wrote:
In linux.debian.kernel Ron Johnson [EMAIL PROTECTED] wrote:
I see that the lawyers of SuSE and Red Hat do not believe this to be
true or at least do not consider it a
Sven Luther [EMAIL PROTECTED] writes:
So, i don't believe there is much choice left to the kernel team in
this issue but to ask for a waiver of the DFSG compliance for the
kernel for etch, and hope the d-i folk take their responsabilities a
bit more seriously for the etch+1 release.
Or, the
[EMAIL PROTECTED] (Marco d'Itri) writes:
I see that the lawyers of SuSE and Red Hat do not believe this to be
true or at least do not consider it a problem, and this is enough for
me to ignore the opinion of the debian-legal@ armchair lawyers.
We already know that the lawyers of SuSE and Red
Marco d'Itri [EMAIL PROTECTED] writes:
I became a developer long before the NM process was created, and I
agreed to follow the unclarified social contract.
Are you unwilling to follow the current Social Contract? If so, you
should resign, and yesterday.
Thomas
--
To UNSUBSCRIBE, email to
In linux.debian.kernel Nathanael Nerode [EMAIL PROTECTED] wrote:
What can be done about this?
Accept that most people do not consider this a problem?
First of all, this is false. Most Debian developers agree with me. You
This is unproven.
think not? Prove it by proposing a GR. More
Marco d'Itri [EMAIL PROTECTED] writes:
In linux.debian.kernel Nathanael Nerode [EMAIL PROTECTED] wrote:
What can be done about this?
Accept that most people do not consider this a problem?
First of all, this is false. Most Debian developers agree with me. You
This is unproven.
It is also
In linux.debian.kernel Nathanael Nerode [EMAIL PROTECTED] wrote:
What can be done about this?
Accept that most people do not consider this a problem?
--
ciao,
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
In linux.debian.kernel Nathanael Nerode [EMAIL PROTECTED] wrote:
What can be done about this?
Accept that most people do not consider this a problem?
First of all, this is false. Most Debian developers agree with me. You
think not? Prove it by proposing a GR. More importantly, the release
* Sven Luther ([EMAIL PROTECTED]) [060110 21:16]:
On Tue, Jan 10, 2006 at 05:19:47PM +0100, Andreas Barth wrote:
difference to this. It might however make an difference to
GPL-compatibility, unless the license is GPL-compatible anyways.
Nope, please read my posts on debian-legal about this
On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote:
how can you consider it as non-program. It is indeed composed of machine code
destined to run on the controller of the device the driver is written for.
This is incorrect. I know firmware[tm] blobs which only includes data.
You can't
On Wed, Jan 11, 2006 at 12:56:44PM +0100, Bastian Blank wrote:
On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote:
how can you consider it as non-program. It is indeed composed of machine
code
destined to run on the controller of the device the driver is written for.
This is
* Bastian Blank ([EMAIL PROTECTED]) [060111 12:57]:
On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote:
how can you consider it as non-program. It is indeed composed of machine
code
destined to run on the controller of the device the driver is written for.
This is incorrect. I
Bastian Blank wrote:
On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote:
how can you consider it as non-program. It is indeed composed of machine
code destined to run on the controller of the device the driver is
written for.
This is incorrect. I know firmware[tm] blobs which only
Andreas Barth wrote:
* Bastian Blank ([EMAIL PROTECTED]) [060111 12:57]:
On Tue, Jan 10, 2006 at 09:13:27PM +0100, Sven Luther wrote:
how can you consider it as non-program. It is indeed composed of
machine code destined to run on the controller of the device the driver
is written for.
On Wed, Jan 11, 2006 at 12:14:10PM -0500, Nathanael Nerode wrote:
Sven Luther wrote:
2) there are now drivers which contains non-free firmware blobs, with
explicit licence, and these are thus distributable. A quick search for
fw_ revealed 159 such files in 2.6.15.
I would like
Kyle McMartin wrote:
The question is: when you remove the firmware from the driver, and all
it is, is a file sitting in /lib/firmware/; and it's contents are just
non-executable hex,
Sorry, it is executable. For instance, the tg3 code is simply MIPS binary
which can be disassembled with
[EMAIL PROTECTED] wrote:
licenced modules. If we don't want to do that, the most honest way to
handle it is to get another GR out the door,explaining that this is not
easily possible or convenient at this time, and asking for an explicit
exception for kernel firmware. I would second such a GR.
I
Nathanael Nerode wrote:
Second, the issues with the installer
--
Your analysis of the modules that would be needed by the installer does
not take all possible installation methods and hardware combinations
into account, notably missing a) network cards b)
On Mon, Jan 09, 2006 at 08:13:18PM +0100, Sven Luther wrote:
current fact is that the qlaxxx firmware is gpl,
so on has all it's right in main.
It is GPL, except for the binary blob of firmware, as the two constitute
separate work, this is not a violation of the GPL. The exact licence, that
On Mon, Jan 09, 2006 at 11:03:13PM +0100, Sven Luther wrote:
In 2004, there was a GR that decided to put everything in main under the
DFSG. We had some discussions, but in the end, the result was that all
the non-free firmware bits have to be removed from main before we can
release etch
significant problems unless we are able to
provide better infrastructure for such modules in the installer.
c) we move the firmware in non-free, and actively use the request_firmware
mechanism.
Seems like a pretty good division, but if there are users who *need* the
non-free firmware, we still
3) an effort seems to be happening inside the upstream kernel to use the
request_firmware infrastructure which allows to load firmware code from
userland through an hotplug mechanism. There seem to be more and more
drivers going this way, since there aare more in current git than
* Kyle McMartin ([EMAIL PROTECTED]) [060110 16:20]:
I would argue it's the former. I can see the argument when it's a part of
the source code, but not when it's a completely seperate entity.
Sorry, but there is no difference regarding DFSG: If the binary blob is
actually seperated from the
On Tue, Jan 10, 2006 at 01:45:11AM -0800, Steve Langasek wrote:
You may redistribute the hardware specific firmware binary file
under the following terms:
1. Redistribution of source code (only if applicable),
must retain the above copyright notice, this list of
On Tue, Jan 10, 2006 at 11:38:21AM -0600, Bill Allombert wrote:
On Tue, Jan 10, 2006 at 01:45:11AM -0800, Steve Langasek wrote:
You may redistribute the hardware specific firmware binary file
under the following terms:
1. Redistribution of source code (only if applicable),
On Tue, Jan 10, 2006 at 10:00:53AM -0500, Kyle McMartin wrote:
3) an effort seems to be happening inside the upstream kernel to use the
request_firmware infrastructure which allows to load firmware code from
userland through an hotplug mechanism. There seem to be more and more
On Tue, Jan 10, 2006 at 05:19:47PM +0100, Andreas Barth wrote:
* Kyle McMartin ([EMAIL PROTECTED]) [060110 16:20]:
I would argue it's the former. I can see the argument when it's a part of
the source code, but not when it's a completely seperate entity.
Sorry, but there is no difference
licenses
and needs to be put in non-free.
the problem is that there are two issues :
1) non-distributable modules, because the licence was messy.
2) distributable modules with non-free firmware.
tg3 and qla2xxx used to be in the first class, and due to relicencing
, like the acenic one, partly because of the
demise of the company producing them and various acquisitions which left the
IP in an unknown state nobody seems to bother with.
2) there are now drivers which contains non-free firmware blobs, with
explicit licence, and these are thus distributable
On Mon, Jan 09, 2006 at 11:03:13PM +0100, Sven Luther wrote:
I think everyone agrees that a) is not a possibility. Both b) and c) require a
non-negligible amount of work, altough b) is less work than c), but c) is the
better solution, and also to the best of my knowledge the one which upstream
90 matches
Mail list logo
