Am 2008-11-06 01:45:47, schrieb Faidon Liambotis:
> That's also false. You can easily jam cellphones using equipment bought
> from your local radio shop.
> There are even (perfectly legal) commercial products that do exactly that.
Maybe in the USNA, but not in Europe... (at least Germany and Franc
On Fri, Nov 7, 2008 at 9:47 PM, David Given <[EMAIL PROTECTED]> wrote:
> Luckily it's very unlikely that Debian will ever having anything to do
> with the labyrinthing maze of potential lawsuits that are involved in
> GSM protocol stacks... what *is* the Debian project's policy on using
> Debian w
Faidon Liambotis wrote:
[...]
> IMHO this is FUD well spread by companies that didn't want their IP
> "exposed". Atheros cards don't have any firmware; you can transmit in
> whatever frequency you want to with ath5k/ath9k -- ath9k is distributed
> by Atheros themselves while ath5k is nowdays endors
Manoj Srivastava wrote:
But there is less pressure on the author, since they are getting
paid, since people who want to run debian hassle free will by their
hardware anyway.
I think that the same argument would have helpd for including
netscape in main as Alex Yukhimets was ar
On Wed, 2008-11-05 at 18:06 +, David Given wrote:
> So having the source doesn't actually gain you anything --- you would
> neither be able nor allowed to do anything with it, apart from printing
> it on T-shirts.
You can learn about it. Remember the educational purpose of free
software?
Tho
On Tue, Nov 04, 2008, Gunnar Wolf wrote:
> It is better and more honest to our users to tell them, "that's not
> ours and we cannot fix it. We cannot pledge to support it. Here it is,
> it is a nice blob, but it is NOT ours, go bug your hardware
> manufacturer for support".
Ack.
> It is not that
On Wed, Nov 05, 2008, Robert Collins wrote:
> It may be that for that hardware Debian does not fit your desires. Can I
> remind you of this little statement
Please, don't quote the social contract on me.
And I already expressed that I understood my position implied changes
to foundation docume
David Given wrote:
> One potential reason is that in most jurisdictions you are legally *not
> allowed* to use custom wifi firmware. Consider that most wifi systems
> are software radios and that the software is entirely capable of
> exceeding all regulators' transmissions strength limits or subver
Robert Collins wrote:
[...]
> I wish I understood the reasoning here - putting aside the fact that
> most of the software in Debian is under a copyleft licence and so we
> *must* provide the source. Why is the source for the radio on my wifi
> card any *less* critical than the source for the driver
On Tue, 2008-11-04 at 15:11 +0100, Loïc Minier wrote:
> On Tue, Nov 04, 2008, Robert Collins wrote:
> > I wish I understood the reasoning here - putting aside the fact that
> > most of the software in Debian is under a copyleft licence and so we
> > *must* provide the source. Why is the source for
Loïc Minier <[EMAIL PROTECTED]> writes:
> On Tue, Nov 04, 2008, Robert Collins wrote:
> > I wish I understood the reasoning here - putting aside the fact
> > that most of the software in Debian is under a copyleft licence
> > and so we *must* provide the source. Why is the source for the
> > radio
On Tue, Nov 04 2008, Loïc Minier wrote:
> Because I can consider the wifi firmware a subsystem which doesn't
> contaminate my main OS; there's a clear interface between the two
> systems -- it's like talking to another computer, talking to your
> hard disk, talking to your keyboard: something
On Mon, Nov 03 2008, Brian May wrote:
> I don't think it does matter.
>
> On a related note though, compare to hardware vendors:
>
> A) provides all firmware, in binary only form, without source code, on
> board device ROM that cannot be changed.
>
> B) provides all firmware on disk, in binary on
Loïc Minier dijo [Tue, Nov 04, 2008 at 03:11:18PM +0100]:
> (...)
> And if we don't require the hardware to be freely modifiable, why
> require the firmware to be so?
So we can ship it coherently with our policies?
Because users have expectations we have a way to give support to what
we ship? I
On Tue, Nov 04, 2008, Robert Collins wrote:
> I wish I understood the reasoning here - putting aside the fact that
> most of the software in Debian is under a copyleft licence and so we
> *must* provide the source. Why is the source for the radio on my wifi
> card any *less* critical than the sourc
On Mon, 2008-11-03 at 21:20 +0100, Loïc Minier wrote:
...
> for which providing a source is not critical.
...
I wish I understood the reasoning here - putting aside the fact that
most of the software in Debian is under a copyleft licence and so we
*must* provide the source. Why is the source for
Loïc Minier <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 03, 2008, Josselin Mouette wrote:
>> Le lundi 03 novembre 2008 à 10:12 +0100, Aurelien Jarno a écrit :
>> > I haven't say that because they are not executed on by the CPU they are
>> > more free. What I mean is that we have those discussions bec
On Mon, Nov 03, 2008, Gunnar Wolf wrote:
> I agree with you. But we cannot see them as part of our system, which
> is mostly defined by its freedom. We can adjust our system to allow
> you to load the firmware (probably under the name "drivers", to which
> many people are more used) in a painless a
Loïc Minier dijo [Mon, Nov 03, 2008 at 10:58:16AM +0100]:
> > I don't think they are at all special. What interprets the software - be
> > it a 'cpu', a 'vm' or a co-processor like many video cards, or something
> > like an arduino doesn't alter the basic attributes - there is machine
> > code for
Le lundi 03 novembre 2008 à 13:33 +0100, Loïc Minier a écrit :
> On Mon, Nov 03, 2008, Josselin Mouette wrote:
> > Since SSL certificates are randomly generated data, they are not subject
> > to copyright law, so I don’t think they are in any grey area. We can
> > change them without any licensing
On Mon, Nov 03, 2008, Josselin Mouette wrote:
> Le lundi 03 novembre 2008 à 10:12 +0100, Aurelien Jarno a écrit :
> > I haven't say that because they are not executed on by the CPU they are
> > more free. What I mean is that we have those discussions because they
> > are not executed on the main CP
On Mon, Nov 03, 2008, Josselin Mouette wrote:
> > Consider SSL certificates for e.g. Verisign. It makes no sense to
> > change them and we don't have the ultimate source for them. These are
> > generated data files for which we have the tools to build them, but not
> > the ultimate source dat
Le lundi 03 novembre 2008 à 10:58 +0100, Loïc Minier a écrit :
> And I can think of other data bits in the grey area.
>
> Consider SSL certificates for e.g. Verisign. It makes no sense to
> change them and we don't have the ultimate source for them. These are
> generated data files for which
Le lundi 03 novembre 2008 à 10:12 +0100, Aurelien Jarno a écrit :
> I haven't say that because they are not executed on by the CPU they are
> more free. What I mean is that we have those discussions because they
> are not executed on the main CPU, which makes them different than other
> non-DFSG co
On Mon, Nov 03, 2008, Robert Collins wrote:
> I don't think they are at all special. What interprets the software - be
> it a 'cpu', a 'vm' or a co-processor like many video cards, or something
> like an arduino doesn't alter the basic attributes - there is machine
> code for one or more machines,
Manoj Srivastava wrote:
Can you explain to me why it matters which processing unit the
software runs on? Why does it matter whether the software being
executed on the central unit matters, and that on the peripheral
processing unit gets off scott free?
I don't think it does matte
On Mon, Nov 03, 2008 at 02:28:45AM -0600, Manoj Srivastava wrote:
> On Sun, Nov 02 2008, Aurelien Jarno wrote:
>
>
> > This look complicated. Everyone agrees that firmwares are a bit
> > special in the world of software due to the fact they don't run on the
> > host CPU.
>
> Can you expl
On Sun, Nov 02 2008, Aurelien Jarno wrote:
> This look complicated. Everyone agrees that firmwares are a bit
> special in the world of software due to the fact they don't run on the
> host CPU.
Can you explain to me why it matters which processing unit the
software runs on? Why does it
Michael Banck <[EMAIL PROTECTED]> writes:
> Hi Ben,
>
> On Mon, Nov 03, 2008 at 09:17:56AM +1100, Ben Finney wrote:
> > Anything which we propose to distribute as part of Debian must
> > follow the DFSG rules; otherwise, we violate our promises in the
> > Social Contract. There's nothing special
Aurelien Jarno <[EMAIL PROTECTED]> writes:
> On Mon, Nov 03, 2008 at 08:03:15AM +1100, Robert Collins wrote:
>> On Sun, 2008-11-02 at 14:51 +0100, Aurelien Jarno wrote:
>> > Everyone agrees that firmwares are a bit special
>> I don't think they are at all special.
> Bullshit.
--
Gruesse/greetings
Hi Ben,
On Mon, Nov 03, 2008 at 09:17:56AM +1100, Ben Finney wrote:
> Anything which we propose to distribute as part of Debian must follow
> the DFSG rules; otherwise, we violate our promises in the Social
> Contract. There's nothing special about the *vendor-intended use* of a
> collection of bi
Aurelien Jarno <[EMAIL PROTECTED]> writes:
> This look complicated. Everyone agrees that firmwares are a bit
> special in the world of software due to the fact they don't run on
> the host CPU.
I disagree.
That makes them special, but it doesn't at all affect the rules that
should be applied to
On Mon, Nov 03, 2008 at 08:03:15AM +1100, Robert Collins wrote:
> On Sun, 2008-11-02 at 14:51 +0100, Aurelien Jarno wrote:
> > Everyone agrees that firmwares are a bit special
> > in the world of software due to the fact they don't run on the host
> > CPU.
>
> I don't think they are at all special
On Sun, 2008-11-02 at 14:51 +0100, Aurelien Jarno wrote:
> Everyone agrees that firmwares are a bit special
> in the world of software due to the fact they don't run on the host
> CPU.
I don't think they are at all special. What interprets the software - be
it a 'cpu', a 'vm' or a co-processor lik
On Thu, Oct 30, 2008 at 10:34:47AM +, Robert Lemmen wrote:
> hi everyone,
>
> the current situation concerning firmware blobs and dfsg-freeness is a
> bit sad, among other things because there really isn't too much we can
> do about it in the short run. so how about some practical proposal tha
On Thu, Oct 30, 2008 at 09:01:18PM -0700, Thomas Bushnell BSG wrote:
> On Thu, 2008-10-30 at 16:33 -0400, Lennart Sorensen wrote:
> > So if any of the hardware that requires non-free firmware to operate and
> > currently works in etch was to not work with Lenny, then that's
> > completely unaccepta
On Thu, 2008-10-30 at 16:33 -0400, Lennart Sorensen wrote:
> So if any of the hardware that requires non-free firmware to operate and
> currently works in etch was to not work with Lenny, then that's
> completely unacceptable?
>
> If that's the case, then there is no way EVER to make Debian comply
On Thu, Oct 30, 2008 at 03:33:49PM +0100, Pierre Habouzit wrote:
> For the sake of 10 binary firmwares, you want to make whole Debian
> depend upon non-free ? Wow, what an achievement.
>
> No, please, we don't accept regressions as a solution.
So if any of the hardware that requires non-free firm
On Thu, Oct 30, 2008 at 03:47:56PM +, Robert Lemmen wrote:
> if i understand things correctly than option 2 is what we are trying to
> do with the kernel in the moment (correct me if i am wrong), and the
> only thing i am saying is that having a package A which will not work
> (in some cases) w
On Thu, Oct 30, 2008 at 03:47:56PM +, Robert Lemmen wrote:
> On Thu, Oct 30, 2008 at 03:33:49PM +0100, Pierre Habouzit wrote:
> > For the sake of 10 binary firmwares, you want to make whole Debian
> > depend upon non-free ? Wow, what an achievement.
>
> ok, i think i came across in a wrong way
In article <[EMAIL PROTECTED]> you wrote:
> doesn't that sound reasonable to you?
Yes maybe, but on the other hand, arent ppl used to the fact that the kernel
does not know about some available modules? Thats the whole idea of modules
(and plugins in other situations like media encoders).
Gruss
B
ok, i think i have just woken up and must have mixed up a few unrelated
things in my previous mail(s). please disregard everything i said...
thanks robert
--
Robert Lemmen http://www.semistable.com
signature.asc
Description: Digital signature
On Thu, Oct 30, 2008 at 03:33:49PM +0100, Pierre Habouzit wrote:
> For the sake of 10 binary firmwares, you want to make whole Debian
> depend upon non-free ? Wow, what an achievement.
ok, i think i came across in a wrong way, because that is certainly not
what i want!
but look at it this way: if
Le Thu, Oct 30, 2008 at 05:31:44AM -0500, William Pitcock a écrit :
>
> non-free is not enabled by default. Suggests/Recommends:
> would be technically feasible though.
… but Recommends would not be welcome, as "No unmet recommends" was a release
goal of Lenny.
http://release.debian.org/lenny/go
On Thu, Oct 30, 2008 at 10:34:47AM +, Robert Lemmen wrote:
> we relax the "main" requirements insofar that a package that depends
> on another package in non-free may stay in main (and doesn't have to
> go to contrib).
For the sake of 10 binary firmwares, you want to make whole Debian
depend u
Josselin Mouette <[EMAIL PROTECTED]> writes:
> Le jeudi 30 octobre 2008 à 12:07 +0100, Josselin Mouette a écrit :
> > Wrong. You can help Ben Finney testing his packages. That would be
> > much more useful than useless babbling on mailing lists.
>
> Of course that’s Ben Hutchings. Sorry for mista
On Thu, Oct 30, 2008 at 12:07:52PM +0100, Josselin Mouette wrote:
> Wrong. You can help Ben Finney testing his packages. That would be much
> more useful than useless babbling on mailing lists.
if you are talking about these [0], i certainly do not own any of these
pieces of hardware...
cu robe
Le jeudi 30 octobre 2008 à 12:07 +0100, Josselin Mouette a écrit :
> Wrong. You can help Ben Finney testing his packages. That would be much
> more useful than useless babbling on mailing lists.
Of course that’s Ben Hutchings. Sorry for mistaking you, Ben.
--
.''`.
: :' : We are debian.org
Le jeudi 30 octobre 2008 à 10:34 +, Robert Lemmen a écrit :
> the current situation concerning firmware blobs and dfsg-freeness is a
> bit sad, among other things because there really isn't too much we can
> do about it in the short run.
Wrong. You can help Ben Finney testing his packages. Tha
On Thu, Oct 30, 2008 at 05:31:44AM -0500, William Pitcock wrote:
> Not possible, non-free is not enabled by default. Suggests/Recommends:
> would be technically feasible though.
true, perhaps we even need a special dependency type. but these are
implementation issues. isn't the general route (put
On Thu, 2008-10-30 at 10:34 +, Robert Lemmen wrote:
> hi everyone,
>
> the current situation concerning firmware blobs and dfsg-freeness is a
> bit sad, among other things because there really isn't too much we can
> do about it in the short run. so how about some practical proposal that
> we
hi everyone,
the current situation concerning firmware blobs and dfsg-freeness is a
bit sad, among other things because there really isn't too much we can
do about it in the short run. so how about some practical proposal that
we can actually implement in a reasonable timeframe that gets us in a
b
52 matches
Mail list logo
