debian-devel :Consulta

[Isabel Sanchez]

Estimados señores:
 
estamos realizando la presentacion de un servicio de locuciones, para 
reemplazar la musica de espera de la central telefonica por un mensaje con 
informacion de la empresa de ustedes.

(Tambien realizamos grabaciones de mensajes de bienvenidas, preantededores 
o contestadores telefonicos)
 
Deseariamos que la proxima semana,  puedan escuchar un demo sin cargo de 
nuestro servicio que le sera enviado directamente a su mail..
 
Solo necesitariamos saber, si tienen pagina web o bien que nos digan que 
actividad principal tiene la empresa, para poder realizarles la grabacion..
 
Desde ya, agradeceri una respuesta y les pido disculpas si los he molestado 
con este mail.
 
 
Atte.
 
M. Isabel Sanchez
Asesora Comercial
 
 
GRABA-TEL SA
TEL: 54-11-4141-
 
 
 
 
 
 
 
 
Este correo electronico no se considera spam ya que cumple con las leyes 
sobre comercio electronico por contener instrucciones y una forma de 
solicitar la cancelacion de su envio. Si no le interesa recibir novedades, 
por favor escriba a [EMAIL PROTECTED]  con la palabra REMOVER en la 
linea de asunto. Disculpe las molestias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DFSG violations: non-free but no contrib

[Loïc Minier]

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 source for the driver for my wifi
> card?

 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 proprietary or free might
 well be inside, I don't care as long as I can run a free OS on the main
 CPU.  I'd *prefer* if it was free, but I can start another project to
 fulfill this goal.  I don't want the freedom requirements for the main
 OS to require using free hardware, just like I want the freedom
 requirements to require talking to computers running free software.

 Now if Debian can distribute a blob which allows my hardware to run as
 indicated by a clear interface with my free OS, that's good enough for
 me.  If something breaks, I can look at the interface and fix the OS or
 blame the hardware (+ firmware).  I don't personally feel like I need
 the freedom to fix the firmware more than the hardware.
   (However, I acknowledge that we must make it clear that particular
 files are only distributed as enablement tools, and don't come with
 ultimate source, tools, and doc.)

 And if we don't require the hardware to be freely modifiable, why
 require the firmware to be so?

> And if the answer reduces down to 'firmware is made by proprietary
> vendors and does something many people need and we don't have a
> replacement yet' - well thats fine, but at various points we didn't have
> a free kernel, or a free libc, or a free graphic desktop environment.

 And we didn't have Debian or OpenMoko; and the glibc, linux, and
 Xorg/GNOME/KDE/Xfce are huge separate projects and we could start new
 projects to free more things up.

 Google.com is run with software I don't have access to, but I use it
 daily, as well as my microwave, or my wifi card.

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Leverage in licensing discussions (was: [DRAFT] resolving DFSG violations)

[Josselin Mouette]

Le mardi 04 novembre 2008 à 10:23 +1100, Ben Finney a écrit :
> How does this follow? Surely if the firmware is already being
> distributed by the project, that's a *smaller* incentive to the vendor
> to change the license.
> 
> The position “Your license isn't acceptable to us; please change the
> license so that we can begin distributing to our users” is surely
> stronger than “We're distributing your firmware and all our users can
> get it, but please change the license so that it's slightly easier to
> get”. In the latter case, the vendor stands to gain less from making
> the license free, so that's less leverage.

Past experience shows that manufacturers aren’t really listening to
arguments such as “we won’t distribute your drivers unless you do that”.
See nVidia if you want a good example.

On the contrary, by distributing firmware images in a way that makes
them already technically modifiable and subject to reverse-engineering,
it becomes clear that they have nothing to lose by distributing the
sources, and much to win as it allows the community to help them in
maintenance tasks.

In other words, I think the carrot has better leverage on them than the
stick. Of course it all depends on who we’re talking, as the stick will
work just fine on an obscure Chinese manufacturer but not on a
world-leading company that sells high-grade hardware at 10 times the
price.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: DFSG violations: non-free but no contrib

[Gunnar Wolf]

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? If it is a program, we can fix bugs. If it is documentation,
we can fix typos. If it is an image, we can deuglify it. If it is a
sound, we can make it sound... hmm... better? If it is
firmware... Well, we cannot do a thing to it. 

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".

It is not that I want Debian to ship a system with no hardware support
- But that I'd prefer it to be kept visibly separate. We might have a
nonfree-firmware file that can be just copied over at install time (as
Lenny's d-i already allows for) if your devices are needed for
installation. It is not -in my POV- antiethical to have non-free
hardware (i.e. hardware requiring non-free software), but shipping its
supporting firmware it does not allow us to keep our promises.

> > And if the answer reduces down to 'firmware is made by proprietary
> > vendors and does something many people need and we don't have a
> > replacement yet' - well thats fine, but at various points we didn't have
> > a free kernel, or a free libc, or a free graphic desktop environment.
> 
>  And we didn't have Debian or OpenMoko; and the glibc, linux, and
>  Xorg/GNOME/KDE/Xfce are huge separate projects and we could start new
>  projects to free more things up.
> 
>  Google.com is run with software I don't have access to, but I use it
>  daily, as well as my microwave, or my wifi card.

Nothing to argue there. I use Google every day, and I provide the
infrastructure for my users to run their non-free programs on every
day. Still, I do not advocate distributing them as part of Debian.

And not because they are inherently evil or anything, but because
Debian is not the right place to distribute them from. See what I
wrote regarding the RFCs - I agree with the IETF, the RFCs server much
better their purpose being non-free than if they were DFSG-free. But
that's not a reason to bend Debian's principles and ship IETF RFCs in
main. 

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug sprint: cookies assignments

[José Luis Tallón]

Josselin Mouette wrote:
> Many thanks to José Luis Tallón for proposing to bake cookies, but there
> are already enough cookers in Spain. 
Thank you for organizing this all along, and thanks to *all*
contributors, whether they fixed their bugs or not, for helping make a
better free OS for everyone.


Cheers,

J.L.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DFSG violations: non-free but no contrib

[Manoj Srivastava]

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 only form, without source
> code, in form that must be downloaded to device after every boot.
>
  C) Provides the source of the binary blob, which may, given the tool
 chain (hardware/software) can be used by people who own such a tool
 chain to modify and recreate the blob.  Or to create a different
 hardware by studying the original, Or  just print it on a
 shirt. What people do with the freedom is not something I would
 like to label and narrow down.

> A hardware is usable with Debian main. B is not.

C is usable as well.

> Is this really a win? Have we gained anything for freedom? I suspect

We can't convince all non-free creators to come over rfom the
 dark side to the source.  Buty that is not an agument to embrace the
 sith either.

> not. In both cases the firmware cannot be modified. At least for B
> there is some hope because the open source code to perform the
> downloading of the firmware has been written, where as doing that for
> A that might be harder.

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 arguing back in '97. There might
 be short term gain in popularity by letting the line shift on freedom
 (heck, windows still is the dominant OS for a reason).

manoj

-- 
Blow it out your ear.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DFSG violations: non-free but no contrib

[Manoj Srivastava]

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 proprietary or free
>  might well be inside, I don't care as long as I can run a free OS on
>  the main CPU.  I'd *prefer* if it was free, but I can start another
>  project to fulfill this goal.  I don't want the freedom requirements
>  for the main OS to require using free hardware, just like I want the
>  freedom requirements to require talking to computers running free
>  software.

So you only care for one of the two freedoms. Which is
 fair. Some of our users care about fewer freedoms -- they would be
 happy if we distributed nvidia binary drivers in main. None of this,
 however, is relevant to the central issue.

>  Now if Debian can distribute a blob which allows my hardware to run as
>  indicated by a clear interface with my free OS, that's good enough for
>  me.  If something breaks, I can look at the interface and fix the OS or
>  blame the hardware (+ firmware).  I don't personally feel like I need
>  the freedom to fix the firmware more than the hardware.
>(However, I acknowledge that we must make it clear that particular
>  files are only distributed as enablement tools, and don't come with
>  ultimate source, tools, and doc.)

As I said, this is expressing your personal preference for the
 kinds of freedom you care about.

>  And if we don't require the hardware to be freely modifiable, why
>  require the firmware to be so?

The issue is not really about whether the user can achieve
 perfect freedom -- we do not restrict user actions. They may dual boot
 Vista if they wish.

 The issue is whether Debian distributes things that restrict
 user freedoms.  Last I looked, we did not distribute the hardware.


>> And if the answer reduces down to 'firmware is made by proprietary
>> vendors and does something many people need and we don't have a
>> replacement yet' - well thats fine, but at various points we didn't have
>> a free kernel, or a free libc, or a free graphic desktop environment.

>  Google.com is run with software I don't have access to, but I use it
>  daily, as well as my microwave, or my wifi card.

Sure. but Debian does not distribute them.

manoj
-- 
Is knowledge knowable?  If not, how do we know that?
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Direction on foo2zjs and web fetching scripts

[Luca Capello]

Hi Michael!

On Tue, 04 Nov 2008 07:28:00 +0100, Neil McGovern wrote:
> On Mon, Nov 03, 2008 at 11:40:22PM -0500, Michael Gilbert wrote:
>> Where do I go from here to make sure the issue gets the appropriate
>> level of thought and consideration that it deserves (after lenny gets
>> released of course)?
>
> Dropping lots of CCs.

Re-adding the foo2zjs-maintainer mailing list, please discuss this issue
there (I set R-T and M-F-T accordingly).

> I'd suggest asking on debian-devel and other stakeholders (security
> teams and security audit teams for example) what their views are, and
> trying to build a consensus.

I planned to work on this issue, at least checking every files the
getweb script downloads, as I already did for the only foo2zjs printer I
have (the HP Color LaserJet 1500L [1]).  IMHO this will surely help to
understand where these files originally come from and which license they
are distributed under.

If someone owns any other foo2zjs printer and can perform some basic
quality tests, please reply on the list or privately to me.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503814#188


pgpQj7mvHLAKb.pgp
Description: PGP signature

Re: DFSG violations: non-free but no contrib

[Ben Finney]

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 my wifi card any *less* critical than the source for the
> > driver for my wifi card?
> 
>  Because I can consider the wifi firmware a subsystem which doesn't
>  contaminate my main OS

It seems to me that you can only honestly consider it so if it
*actually does not* contaminate the main OS. The situation we're faced
with is that non-free works *do* contaminate the main OS; that's the
reason we're having these discussions about DFSG violation at all.

>  Now if Debian can distribute a blob which allows my hardware to run
>  as indicated by a clear interface with my free OS, that's good
>  enough for me.

The result can't be called free, though. So long as Debian is promised
to be free, I expect that promise to be met. It seems, from what you
say here, that you do not expect that promise to be met.

>  And if we don't require the hardware to be freely modifiable, why
>  require the firmware to be so?

Because it's distributed in an operating system — Debian — that its
distributor — the Debian project — promises is freely modifiable
(among other freedoms).

When someone distributes hardware to me and promises it is freely
modifiable, I require *that* promise to be upheld also.

-- 
 \  “I don't like country music, but I don't mean to denigrate |
  `\  those who do. And for the people who like country music, |
_o__)denigrate means ‘put down’.” —Bob Newhart |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Leverage in licensing discussions

[Ben Finney]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Le mardi 04 novembre 2008 à 10:23 +1100, Ben Finney a écrit :
> > How does this follow? Surely if the firmware is already being
> > distributed by the project, that's a *smaller* incentive to the
> > vendor to change the license.
> 
> Past experience shows that manufacturers aren’t really listening to
> arguments such as “we won’t distribute your drivers unless you do
> that”. See nVidia if you want a good example.

My understanding was that nVidia *do* listen, and have engaged the
discussion numerous times; they just openly disagree. That's fine,
they're free to do that, and I'll continue to recommend against their
hardware for that reason.

> On the contrary, by distributing firmware images in a way that makes
> them already technically modifiable and subject to
> reverse-engineering, it becomes clear that they have nothing to lose
> by distributing the sources, and much to win as it allows the
> community to help them in maintenance tasks.

I find this interesting; if so, it would appear to be a different
tactic from what we find effective in host-CPU-targeted works. Do you
have a reference for an occurrence of this tactic succeeding?

> In other words, I think the carrot has better leverage on [some
> vendors] than the stick.

Doubtless that's true in some cases.

-- 
 \  “I hope if dogs ever take over the world, and they chose a |
  `\king, they don't just go by size, because I bet there are some |
_o__)   Chihuahuas with some good ideas.” —Jack Handey |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DFSG violations: non-free but no contrib

[Robert Collins]

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 the radio on my wifi
> > card any *less* critical than the source for the driver for my wifi
> > card?
> 
>  Because I can consider the wifi firmware a subsystem which doesn't
>  contaminate my main OS;

If it wasn't fixed and never got altered I would subscribe to this
argument.

>  there's a clear interface between the two
>  systems -- it's like talking to another computer

Not at all, I don't own that other computer, and if it doesn't work
correctly I have to talk to it's owner to get it fixed.

> , talking to your hard
>  disk

Not at all the same; probably because they are part of the standard boot
sequence I have yet to see a hard disk needing firmware (for SCSI/ATA
disks, I can't comment on more esoteric interfaces).

> , talking to your keyboard

Some keyboards we can't use properly because there is proprietary
features activated by USB command sequences that are not documented and
open. Those keyboards get less functionality on Linux until someone
reverse engineers them. Wouldn't it be great if that wasn't the case?

> : something proprietary or free might
>  well be inside, I don't care as long as I can run a free OS on the main
>  CPU. 

I care that I can use the full capabilities of e.g. that extended
keyboard, that all the media keys, LCD displays and so on work.

>  I'd *prefer* if it was free, but I can start another project to
>  fulfill this goal.  I don't want the freedom requirements for the main
>  OS to require using free hardware, just like I want the freedom
>  requirements to require talking to computers running free software.

It may be that for that hardware Debian does not fit your desires. Can I
remind you of this little statement:

"Social Contract" with the Free Software Community:
1. Debian will remain 100% free 

We provide the guidelines that we use to determine if a work is free in
the document entitled The Debian Free Software Guidelines. We promise
that the Debian system and all its components will be free according to
these guidelines. We will support people who create or use both free and
non-free works on Debian. We will never make the system require the use
of a non-free component. 

>  Now if Debian can distribute a blob which allows my hardware to run as
>  indicated by a clear interface with my free OS, that's good enough for
>  me.

Why draw the line there? why not be happy if Debian can ship a blob that
uses the kernel's binary interfaces?  There's no moral or technical
difference.

>  And if we don't require the hardware to be freely modifiable, why
>  require the firmware to be so?

Because the firmware isn't the hardware. It is software.

> > And if the answer reduces down to 'firmware is made by proprietary
> > vendors and does something many people need and we don't have a
> > replacement yet' - well thats fine, but at various points we didn't have
> > a free kernel, or a free libc, or a free graphic desktop environment.
> 
>  And we didn't have Debian or OpenMoko; and the glibc, linux, and
>  Xorg/GNOME/KDE/Xfce are huge separate projects and we could start new
>  projects to free more things up.

Debian started in 1993; Linux was first released in 1991, glibc had its
core functional in 1988
( http://en.wikipedia.org/wiki/GNU_C_Library#cite_note-1). KDE was
started in 1996, and GNOME in 1997. XFree86 forked around 1992, IIRC.

We *had* Debian long before we had a free graphical desktop environment
[that really meets the term - a window many isn't enough :)]

>  Google.com is run with software I don't have access to

google doesn't affect the functionality of hardware you own.

> , but I use it
>  daily, as well as my microwave

ECOMPLETELYUNRELATED

> , or my wifi card.

Which is the point under contention.

-Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part

Processed: Re: Bug#504516: libc6 package allows for a potential root compromise to users in 'staff' group

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 504516 general
Bug#504516: libc6 package allows for a potential root compromise to users in 
'staff' group
Bug reassigned from package `libc6' to `general'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#503096: ITP: alpaca -- GnuPG file handling for Emacs

[Joerg Jaspert]

>> > Hence the question goes as: considering that the next release of
>> > Debian is most likely going to be released with Emacs (>= 23.1), which
>> > is integrated properly with EasyPG, do we need alpaca in Debian? I
>> > believe the answer is «no».
>> I think that the alpaca package isn't meaningless even if less
>> people use alpaca than EasyPG.
>> `alpaca' uses symmetric encryption with "--cipher-algo AES" for a
>> new *.gpg file by default, while I haven't found an easy way to
>> customizet EasyPG.
>> To avoid the complexity of handling *.gpg files, I won't enable the
>> alpaca feature if EasyPG is installed, and I'll suggest EasyPG and
>> add more information in the alpaca package document.
> I don't intend to push alpaca into the Emacs main tree.  Please
> allow making just an optional Debian package.

> Does anyone still strongly have objection to this ITP?  If so,
> please tell me against the above comments.

Yes I have, this package for *one single file* won't make it into
Debian, sorry. Please have it included in emacs-goodies-el, it seems to
fit very well there.

-- 
bye, Joerg
[Talking about Social Contract]:
We will not discriminate noone[...]
[So we discriminate anyone?]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: reassign 504516 to tech-ctte ..., merging 504516 484841

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # Automatically generated email from bts, devscripts version 2.10.35
> reassign 504516 tech-ctte
Bug#504516: libc6 package allows for a potential root compromise to users in 
'staff' group
Bug reassigned from package `general' to `tech-ctte'.

> retitle 504516 /usr/local/lib is writable by group staff and in default 
> search path
Bug#504516: libc6 package allows for a potential root compromise to users in 
'staff' group
Changed Bug title to `/usr/local/lib is writable by group staff and in default 
search path' from `libc6 package allows for a potential root compromise to 
users in 'staff' group'.

> merge 504516 484841
Bug#484841: Should /usr/local be writable by group staff?
Bug#504516: /usr/local/lib is writable by group staff and in default search path
Merged 484841 504516.

>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]