Re: DFSG violations: non-free but no contrib

[Manoj Srivastava]

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 matter whether the software being
 executed on the central unit matters, and that on the peripheral
 processing unit gets off scott free?

   Why should it matter that the software is executed on a
 processing unit that lives on a daughter board instead of the mother
 board?

Some people have said that most folks do not have the means of
 compiling the sources, even if they were available. But most people
 (like my mom) can't edit and compile code we run on the mother board
 either, but we do not say that people would not be able to use source
 code for the mother board, so we should not ship it.

I can also imagine a different hardware manufacturer, who does
 have the proprietary hardware and compilers _could_ use the  shipped
 source code, if for nothing else than for learning by example -- so
 that particular class of end users would be able to use and benefit
 from the source code for even the daughter boards.

Just because a subset of users can benefit from the sources for
 code executed in a processor does not mean freedom has become
 meaningless.

manoj
-- 
Reunite Gondwondaland!
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: [DRAFT] resolving DFSG violations

[Josselin Mouette]

Le jeudi 30 octobre 2008 à 16:03 -0400, Lennart Sorensen a écrit :
> > Again:  ARE you realy willing to pay at least
> > 10US$ or 8? more for the hardware?
> 
> Absolutely.  I know I may be a minority, but I do pay extra to buy high
> quality hardware rather than the cheapest crap I can find.  On the other
> hand I am much happier with my stuff because it works better, lasts
> longer, and doesn't waste my time dealing with @#$#$ firmware files.

Your assertion that it is better to put firmware in a flash ROM rather
than in the driver, including for software freedom, is utterly wrong.

All software has bugs and firmware is no exception. And when time comes
to update the firmware in a flash ROM, like in those crappy Smart Array
controllers, what will you do? Not only will the update not be available
with regular system upgrades, but you will have to install non-free
software provided by the manufacturer to update the ROM, and execute it
*on the host system*, with all the security implications.

Distributing the non-free firmware with regular package updates in
non-free ensures that you are able to update it for bug fixes with
system upgrades, and this is a definite improvement for users. And it
also ensures that the only thing that is done with this non-free
firmware is to upload it to the dedicated chip, which is an improvement
for both users and software freedom.

But the most important thing is that it gives leverage to convince
manufacturers to actually distribute the firmware with a free license.
We may have to put some firmware images in non-free, but we now have
also a lot of them in main with permission to modify them, and some of
them are even distributed with the source. 

The net result is that manufacturers are actually starting to open up
their hardware. If you want to avoid that and keep your hardware bugs,
go ahead and buy this hardware with flash ROMs.

Cheers,
-- 
 .''`.
: :' :  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

are webapps allowed to have a default user with a default password?

[Evgeni Golov]

Hi *,

while working on a fix for opendb's RC/Security bug #504173, I noticed
that opendb creates a default admin user "test" with "test" as password.
This is IMHO a security hole, but I would like to hear your opinion -
is this okay or not?

Regards
Evgeni


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

Re: DFSG violations: non-free but no contrib

[Aurelien Jarno]

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 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?
> 
>Why should it matter that the software is executed on a
>  processing unit that lives on a daughter board instead of the mother
>  board?

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 compliant software. Then some people consider that acceptable,
some other not.

At least having a separate section kills the argument that moving all
firmwares to non-free means that a lot of people will then use non-free
and install non-free stuff by mistake.

It also allows more easily to put all firmwares on a separate media for
use by debian installer (AFAIK there is no other reason to use non-free
in d-i).

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: are webapps allowed to have a default user with a default password?

[Paul Wise]

On Mon, Nov 3, 2008 at 5:40 PM, Evgeni Golov <[EMAIL PROTECTED]> wrote:

> while working on a fix for opendb's RC/Security bug #504173, I noticed
> that opendb creates a default admin user "test" with "test" as password.
> This is IMHO a security hole, but I would like to hear your opinion -
> is this okay or not?

Sounds like a security issue to me, severity would depend on what
admins can do and apache configuration though. IMO the sysadmin should
be responsible for setting the initial password, or it might be
reasonable to generate a random password.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: are webapps allowed to have a default user with a default password?

[Evgeni Golov]

On Mon, 3 Nov 2008 18:18:38 +0900 Paul Wise wrote:

> On Mon, Nov 3, 2008 at 5:40 PM, Evgeni Golov <[EMAIL PROTECTED]> wrote:
> 
> > while working on a fix for opendb's RC/Security bug #504173, I noticed
> > that opendb creates a default admin user "test" with "test" as password.
> > This is IMHO a security hole, but I would like to hear your opinion -
> > is this okay or not?
> 
> Sounds like a security issue to me, severity would depend on what
> admins can do and apache configuration though.

Apache config is autoadjusted (but you can disable this though) via the
maintainer scripts.
An admin can use the app, delete stuff, possibly exploit
CVE-2008-4796 :) - doesnt sound too good

Based on KiBi's words on IRC, opendb's popcon (22) and the count of
problems (CVE-2008-4796/#504173, this issue, 1 lintian error and 18
warnings[1]), why not just remove the package and let someone who is
interested upload a new upstream (upstream is at 1.5 now) after Lenny?

Regards

[1]
http://lintian.debian.org/reports/maintainer/[EMAIL PROTECTED]


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

Re: Bug Sprint results (draft)

[Ben Finney]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> I’d like to thank all players for their contributions. The game was
> not really fair since some issues were much easier to deal with than
> others, but it was very nice to see people all over the world fix RC
> bugs for fun and cookies.

Thanks very much, Josselin, for creating and driving an international
Debian bug sprint for fun and cookies. What a great and positive way
to encourage both competition and collaboration. I hope to see more of
these!

-- 
 \   “Anyone who puts a small gloss on [a] fundamental technology, |
  `\  calls it proprietary, and then tries to keep others from |
_o__)   building on it, is a thief.” —Tim O'Reilly, 2000-01-25 |
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

[Josselin Mouette]

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 compliant software. Then some people consider that acceptable,
> some other not.

This case is very similar to non-free documentation, which is not
executed on any CPU at all. It sounds bogus to split firmware in a
specific archive and to not do it for documentation, data, etc.

If you want to make a specific distinction for software for which we
don’t have a source and which is executed on the host CPU, I’d prefer to
see the non-free rules updated to ban such software from our archive,
and to add restrictions to it such as:
  * availability of source code (for binaries meant for the host
CPU);
  * legal possibility to autobuild the package (for arch-any ones);
  * legal possibility to add patches for security updates.

This way we could add the non-free archive to sources.list without
wondering whether installing stuff from it will introduce an unfixable
root security hole. If more and more systems need non-free because of
firmware, this is a move that I’d like to see.

-- 
 .''`.
: :' :  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

[Loïc Minier]

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, which is usually derived from some more
> editable source (more can be quite a range though) though compilation.

 It's hard to define how they are special, but I think they are.

 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 we have the tools to build them, but not
 the ultimate source data (private key).  And if we had the private key,
 they would be worthless.  These are effectively static data enabling
 SSL communications with sites using these SSL certs providers.
   I could make another argument about RFCs, it's even easier to change
 them.

 Firmwares can be considered somewhat the same: static data enabling the
 use of your hardware.  You can perhaps change them.  Perhaps we have
 the tools to change them.  Perhaps we can change them usefully.  But
 they are useful as such and we don't need to fight for their freedom as
 we fight for the freedom of the main OS.

 With requiring the freedom of firmwares, we're putting our finger in a
 completely new problem: the one of free hardware.  To build an useful
 firmware, we will need information about registers, the operation of
 the hardware, it's hardware architecture, limits, caracteristics, test
 results.

 Perhaps someday we will port Debian to our graphics cards, just like
 it's ported to wifi aps.  This would be a new port, we don't need to
 require Debian to be running on your ap to use it so why not enable the
 distribution of useful data which doesn't taint the main OS if we have
 the permissions to do so and it benefits our users?

 I don't see Debian as a free harware and computers project.  We need to
 leave some hard problems to others to solve!

-- 
Loïc Minier


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

Re: DFSG violations: non-free but no contrib

[Brian May]

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


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

Is this really a win? Have we gained anything for freedom? I suspect 
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.


The only benefit I see is a technical one - it is easy to draw the line 
and say Debian must exclude all binary blobs that don't comply with the 
DFSG. I can't see it helping in any practical manner achieve the goal of 
the DFSG by increasing the freedoms we get with Debian. Users will still 
have the same restrictions and not be able to make modifications. Not 
until we can get open source hardware will this change.


I haven't heard a good answer to the problem that some types of firmware 
can only be legally endorsed if the manufacturer ensures users can't 
change it - e.g. firmware for wireless interfaces.


Brian May


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

Bug#504398: ITP: l7-protocols -- protocol definitions for the Linux layer 7 packet classifier

[Piotr Lewandowski]

Package: wnpp
Severity: wishlist
Owner: Piotr Lewandowski <[EMAIL PROTECTED]>


* Package name: l7-protocols
  Version : 20081014
  Upstream Author : Matthew Strait <[EMAIL PROTECTED]>
* URL : http://l7-filter.sourceforge.net/
* License : GPL
  Programming Lang: N/A
  Description : protocol definitions for the Linux layer 7 packet classifier

Patterns (protocol definitions) for the Linux layer 7 packet
classifier (l7-filter).  To use them, you need the kernel and iptables
patches or l7-filter userspace version.

--
Piotr Lewandowski



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

[Stefano Zacchiroli]

On Mon, Nov 03, 2008 at 08:51:55PM +0900, Tatsuya Kinoshita wrote:
> 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 still object the ITP. If you firmly believe that it can not
(easily) be integrated into Emacs main tree, at least put it into
emacs-goodies-el: alpaca is still *a single file*, we don't want
1-filer packages in the archive. Really.

You did mail the maintainer in this thread, but no reply was
received. Turn it into a feature request against emacs-goodies-el,
provide patch, ..., at worst upload a patched package to DELAYED/1000
(which seems a bit premature right now).

Cc-ing emacs-goodies-el maintainers.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
[EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right
uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach


signature.asc
Description: Digital signature

Bug#504411: ITP: latexdiff -- Determine and mark up significant differences between LaTeX files

[Pietro Abate]

Package: wnpp
Severity: wishlist
Owner: Pietro Abate <[EMAIL PROTECTED]>


* Package name: latexdiff
  Version : 0.5
  Upstream Author : Frederik Tilmann <[EMAIL PROTECTED]>
* URL : http://bullard.esc.cam.ac.uk/~tilmann/soft.html
* License : GPL
  Programming Lang: Perl
  Description : Determine and mark up significant differences between LaTeX 
files

 latexdiff is a Perl script, which compares two LaTeX files and marks up
 significant differences between them (i.e. a diff for LaTeX files). Various
 options are available for visual markup using standard LaTeX packages such as
 'color.sty'. Changes not directly affecting visible text, for example in
 formatting commands, are still marked in the LaTeX source.
 .
 A rudimentary revision facilility is provided by another Perl script,
 'latexrevise', which accepts or rejects all changes. Manual editing of the
 difference file can be used to override this default behaviour and accept or
 reject selected changes only.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)



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

Re: DFSG violations: non-free but no contrib

[Josselin Mouette]

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 we have the tools to build them, but not
>  the ultimate source data (private key).  And if we had the private key,
>  they would be worthless.  These are effectively static data enabling
>  SSL communications with sites using these SSL certs providers.

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 issue, it’s just that they won’t
fulfill their job if we do.

>  Firmwares can be considered somewhat the same: static data enabling the
>  use of your hardware.  You can perhaps change them.  Perhaps we have
>  the tools to change them.  Perhaps we can change them usefully.  But
>  they are useful as such and we don't need to fight for their freedom as
>  we fight for the freedom of the main OS.

Firmware images are very different. They are binary code, only code not
meant for execution on the host CPU. They are similar to non-free data
for games: stuff that we cannot modify and with which we can live
without modifying, but it would be useful to be able to, and it is
impossible to distribute it in main.

Cheers,
-- 
 .''`.
: :' :  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

[Loïc Minier]

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 CPU, which makes them different than other
> > non-DFSG compliant software. Then some people consider that acceptable,
> > some other not.
> This case is very similar to non-free documentation, which is not
> executed on any CPU at all. It sounds bogus to split firmware in a
> specific archive and to not do it for documentation, data, etc.

 Which non-free documentation specifically?  The GFDL has this invariant
 sections concept which prevents us from modifying the doc, so you can
 not e.g. fork a software and rename/update doc in the invariant
 sections.  However I wouldn't mind having modifiable documentation in a
 format which isn't the ultimate source but is maintainable, e.g. html
 format if that's maintainable over time, even if originally it was
 built from docbook and we don't have the docbook source.

 IOW, I don't mind with picking up autogenerated contents to include in
 Debian if we can maintain it in this form.

-- 
Loïc Minier


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

[Tatsuya Kinoshita]

On October 26, 2008 at 9:12PM +0900,
tats (at debian.org) wrote:

> On October 26, 2008 at 11:11AM +0100,
> zack (at debian.org) wrote:
> 
> > Indeed, the fact that EasyPG is now integrated in development version
> > of Emacs is my main reason for objecting this ITP.
> [...]
> > 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.

If not, I'll make and upload the package soon.

Thanks,
-- 
Tatsuya Kinoshita


pgpGK51nhEj6m.pgp
Description: PGP signature

Re: DFSG violations: non-free but no contrib

[Loïc Minier]

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 data (private key).  And if we had the private key,
> >  they would be worthless.  These are effectively static data enabling
> >  SSL communications with sites using these SSL certs providers.
> 
> 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 issue, it’s just that they won’t
> fulfill their job if we do.

 I'm not arguing about their copyright(-ability): just that we can't
 usefully modify them; and still, the private key is the source to
 create the certificate (even if it's random data), and we don't have it
 in main.  The same goes with firmware: we might have the right to
 distribute modified binary firmwares, and they are sufficiently useful
 as they are, even without accompanying ultimate source.  Their form is
 sufficient for a free OS, not for free hardware though; just like
 certificates are sufficient for a free OS, not for an open
 certification chain.

> >  Firmwares can be considered somewhat the same: static data enabling the
> >  use of your hardware.  You can perhaps change them.  Perhaps we have
> >  the tools to change them.  Perhaps we can change them usefully.  But
> >  they are useful as such and we don't need to fight for their freedom as
> >  we fight for the freedom of the main OS.
> 
> Firmware images are very different. They are binary code, only code not
> meant for execution on the host CPU. They are similar to non-free data
> for games: stuff that we cannot modify and with which we can live
> without modifying, but it would be useful to be able to, and it is
> impossible to distribute it in main.

 The non-free games data I know of is non-free because we may not modify
 it because the license doesn't explicitely allow it; what specific
 example did you have in mind?  This is IMO different from firmware
 binaries which we may well be allowed to change, but don't have the
 tools/doc to do so.

-- 
Loïc Minier


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

Re: DFSG violations / buyers guide.

[Frank Lin PIAT]

On Mon, 2008-11-03 at 08:42 +0100, Rémi Vanicat wrote:
> Frank Lin PIAT <[EMAIL PROTECTED]> writes:
> 
> > On Thu, 2008-10-30 at 11:29 +, Robert Lemmen wrote:
> >> 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... 
> >
> > I would be very pleased to have a "Buyers guide" on the wiki (i.e list
> > devices that are current, supported and dfsg-free).
> 
> the problem with those list is that they often become outdated and
> incomplete

Such buyer guide could list the supported-and-free chipsets (not laptop
model or device name).
Also, it should be limited to DebianLenny devices... Such page would
quiet "stable".

Depending on the device type, it could be either be a white-list or a
black list :
- All LAN adapter, except X,Y
- Only the X and Y Wifi adapter.

Franklin


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

Re: [DRAFT] resolving DFSG violations

[Gunnar Wolf]

Michelle Konzack dijo [Thu, Oct 30, 2008 at 12:10:48AM +0100]:
> Curently I am building a hardware where the parts cost arround 40US$ per
> device (@10.000) and using the same microcontroller with a  "big"  FLASH
> memory would mke this Hardware arround 5 US$ in  final  production  more
> expensive.
> 
> So for the end-users arreound 10 US$ or 8 Euro
> 
> Are you willing to pay arround 15-18% more for such hardware?

So probably the end result won't be shipping raw Debian in your
product - As you are not willing to release the firmware, Debian
cannot inlcude it. Yes, even if it is worthless without a $8000
compiler. Who knows? If the device is interesting enough and becomes
highly successful, somebody (i.e. the Debian project?) can decide to
pay $8000 for the compiler license and be able to fix bugs or enhance
your firmware? 

> Again:  ARE you realy willing to pay at least
> 10US$ or 8€ more for the hardware?

If sharing the source for the firmware is not an option to you, and
raising the price so the device can be self-sufficient without the
computer uploading a firmware to it, then... Well, your device won't
be natively supported by Debian. And that's not necesarily a curse! Of
course I'd like every device on Earth to be Debian-based, but
sometimes reality does not agree with my wishes.

> I mean, the I am trying currently servera hardware models since  I  need
> highly optimized one (for solar-Energie Systems) and there is nothing in
> production yet.  I am 100% free what to do and how I do it...
> 
> Since all of my software must run under GNU/Linux and is licensed  under
> GNU GPL version 3 I like to see, that my hardware/Software fit the  DFSG
> which mean, must run with "main".

Oh, here we have a problem. You are 100% free and want to use GPL3 -
So you are required to distribute the sources, the preferred form of
modification. If not even the input you give to the mighty $8000
compiler qualifies as source, then maybe the schematics you have on
the whiteboard do? You just cannot say "there is no source". That
would imply the firmware is a result of your computer's creativity -
and I'd seriously doubt it.

-- 
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]

Bug sprint: cookies assignments

[Josselin Mouette]

Following the previous announcement and corrections I received, I
dispatched cookie assignments using the best available technology [0].

Cookies sent to indisputable winners:
  * Yves-Alexis Perez will receive cookies from Frank Lin Piat
  * Stefano Zacchiroli will receive cookies from myself
  * Riku Voipio will receive cookies from Frank Lienhard
  * Clint Adams will receive cookies from David Moreno Garza
  * Sean Finney will receive cookies from Jeremiah Foster
  * Emmanuel Bouthenot will receive cookies from Charles Plessy (who
volunteered to send them overseas)
  * Paul Wise will receive cookies from Tim Richardson

As for those who failed to fix their bugs but for whom it would have
really been a hard time, they are free to apply the following sentences:
  * Bruno Beaufils, you can send cookies to Raphaël Hertzog
  * Julien Danjou, you can send some to Thijs Kinkhorst
  * Ghe Rivero, you can send them to Adeodato Simó
  * Christoph Berg, you can send tasty cookies to Marc Brockschmidt
  * Dominic Hargreaves, feel free to send them to Luk Claes
  * Tim Retout, it would be nice to bake something for Philipp Kern
  * Moritz Muehlenhoff, you can send them to Thomas Viehmann, who is
basically the only remaining competitor of the BSP marathon

Many thanks to José Luis Tallón for proposing to bake cookies, but there
are already enough cookers in Spain. Thanks to Y Giridhar Appaji Nag and
Nicolas Valcarcel for participating, but we’re not going to ask you to
send cookies overseas, unless you know how to make solid and
long-lasting ones! Feel free to send cookies to any Debian
developer/contributor in your area to encourage them.

[0] http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Pastiches/Pifom%C3%A8tre
-- 
 .''`.
: :' :  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

[Josselin Mouette]

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 issue, it’s just that they won’t
> > fulfill their job if we do.
> 
>  I'm not arguing about their copyright(-ability): just that we can't
>  usefully modify them; and still, the private key is the source to
>  create the certificate (even if it's random data), and we don't have it
>  in main.  The same goes with firmware: we might have the right to
>  distribute modified binary firmwares, and they are sufficiently useful
>  as they are, even without accompanying ultimate source.

Ah, firmwares without source but with a free (e.g. MIT) license are
another story. This is definitely a grey area, since I guess many
upstreams are working on the binary directly, but there are also some
who compile it from C sources or assembly. For some of them the tools
are available, for some of them they are in-house, for some of them the
tool is a hex editor. And I don’t think we can easily distinguish
between them.

Firmwares without a free license should go to non-free, regardless of
their format.

> > Firmware images are very different. They are binary code, only code not
> > meant for execution on the host CPU. They are similar to non-free data
> > for games: stuff that we cannot modify and with which we can live
> > without modifying, but it would be useful to be able to, and it is
> > impossible to distribute it in main.
> 
>  The non-free games data I know of is non-free because we may not modify
>  it because the license doesn't explicitely allow it; what specific
>  example did you have in mind?  This is IMO different from firmware
>  binaries which we may well be allowed to change, but don't have the
>  tools/doc to do so.

Yes, I didn’t understand you were talking about “free” firmware without
sources.

-- 
 .''`.
: :' :  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 [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 one or more machines, which is usually derived from some more
> > editable source (more can be quite a range though) though compilation.
> 
>  It's hard to define how they are special, but I think they are.
> 
>  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 we have the tools to build them, but not
>  the ultimate source data (private key).  And if we had the private key,
>  they would be worthless.  These are effectively static data enabling
>  SSL communications with sites using these SSL certs providers.

The thing is, some things are simply not OK for us to distribute as
part of our project, because they don't meet our requirements. That
does not mean "don't use that device" - It means only that "if you are
going to use that device, you should get the firmware". And probably
that statement will be followed by "You can get the firmware in a
nice, packaged way at http://nonfree-firmware.debian.net/yourfunnycard
or by adding non-free to your APT sources list, and installing
yourfunnycard-firmware". 

What's the distinction regarding SSL certificates? Well, the
certificates are not the result of the creative process of a person
(unless you consider "creating just the right entropy for your
computer" as a creative process.

>I could make another argument about RFCs, it's even easier to change
>  them.

RFCs are, indeed, a very interesting case. I understand the motivation
of the IETF on requesting them to be distributed verbatim and
disallowing distribution of modified formats - Well then, even if it
is nice to have everything in your system and packaged for Debian, I
agree that the ultimate reference point for RFCs is ietf.org - so if I
need to study a given protocol, I'll go to their website and grab the
needed bytes.

>  Firmwares can be considered somewhat the same: static data enabling the
>  use of your hardware.  You can perhaps change them.  Perhaps we have
>  the tools to change them.  Perhaps we can change them usefully.  But
>  they are useful as such and we don't need to fight for their freedom as
>  we fight for the freedom of the main OS.

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 and intuitive fashion. But I
have yet to see a real reason (besides the work that must go into
sweeping them out of the current and future kernel tree - Thanks to
everybody involved into that!) for Debian to make the needed
exceptions to distribute them as part of main.

Greetings,

-- 
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: DFSG violations: non-free but no contrib

[Loïc Minier]

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 and intuitive fashion. But I
> have yet to see a real reason (besides the work that must go into
> sweeping them out of the current and future kernel tree - Thanks to
> everybody involved into that!) for Debian to make the needed
> exceptions to distribute them as part of main.

 Your post made me see the issue under a different light: I must agree
 that this can't be considered on par with the rest of Debian so I wish
 we would distribute it while making clear that these particular files
 are not with accompanying source.


 Why not come up with a new system which would be more convenient than
 sections (or separate archives as you suggest)?


 e.g. trivial but not very flexible: /lib/no-source-code/firmwares/blah
 and a symlink /lib/firmware/foo -> /lib/no-source-code/firmwares/blah.

 Or a list of "not fully-free" files, provided by the packages
 themselves, e.g. /usr/share/doc/$pkg/btw-these-files-are-firmwares.

 Or complex, but might be cleaner: a new type of dpkg meta-information,
 just like we have conffiles, shlibs, we'd have "licensing" and would be
 able to express that /lib/firmware/foo is free to distribute but
 doesn't come with source code, and you probably don't care.


 I'm not happy that people would enable non-free on most systems just
 for the convenience of getting some files which most people will need
 and for which providing a source is not critical.  Fetching them
 dynamically from $site isn't ok for live CDs, or when you actually try
 to provide the firmware to get network to work.   :-/

-- 
Loïc Minier


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

Re: DFSG violations: non-free but no contrib

[Frank Küster]

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 because they
>> > are not executed on the main CPU, which makes them different than other
>> > non-DFSG compliant software. Then some people consider that acceptable,
>> > some other not.
>> This case is very similar to non-free documentation, which is not
>> executed on any CPU at all. It sounds bogus to split firmware in a
>> specific archive and to not do it for documentation, data, etc.
>
>  Which non-free documentation specifically?  

e.g. PDF files with a DFSG-free license to them, the document source
available as a LaTeX file, but LaTeX will typeset the document using a
non-free font. 

Here, you can even modify the content as you like, you just can't
reproduce the original PDF, and it would maybe be hard to make sure that
the typesetting still looks nice and readable with a free replacement
font with different metrics.

Regards, Frank

-- 
Frank Küster
Debian Developer (TeXLive)
ADFC Miltenberg
B90/Grüne KV Miltenberg


--
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 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 the radio on my wifi
card any *less* critical than the source for the driver for my wifi
card?

And please, no handwaving about 'different' or 'its hardware
enablement'.

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.

-Rob


-- 
GPG key available at: .


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

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

[Ben Finney]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Distributing the non-free firmware with regular package updates in
> non-free [has a particular effect]
> 
> But the most important thing is that it gives leverage to convince
> manufacturers to actually distribute the firmware with a free
> license.

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.

Yet that seems at odds with what you're saying. What's missing?

-- 
 \“Always code as if the guy who ends up maintaining your code |
  `\ will be a violent psychopath who knows where you live.” —John |
_o__) F. Woods |
Ben Finney


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

Re: How to stop building libv4l on non-Linux architectures

[Ben Hutchings]

On Sun, 2008-11-02 at 14:16 +0100, Gregor Jasny wrote:
> Hi,
> 
> I'm the maintainer of libv4l which passed the new queue yesterday.
> Obviously the package build failed on non-Linux architectures [1]. How 
> do I handle this situation? Should I list all supported architectures in 
> the control file,

Either that or it can be added to wanna-build's packages-arch-specific
list.  Mail Lamont Jones <[EMAIL PROTECTED]> if you want that change
made.

> or will the Hurd and BSD porter teams add libv4l to 
> the NOT-FOR-US list?

I believe not-for-us is intended for temporary use where a build attempt
can break the buildd.

Ben.



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

Direction on foo2zjs and web fetching scripts

[Michael Gilbert]

Dear release team,

Thank you for making a decision on the direction for bug #449497 in
foo2zjs [1].  I believe that this is a reasonable choice for now due
to the impending release.  However, I would really like to see an
honest and consructive conversation on the issue.  I believe that
there are some major security and functionality problems with fetching
scripts, and there should be clear direction from the members of the
debian project on the matter.  I would like to be able to completely
trust main, so it is my hope that developers would do everything in
their power to keep main as clean and safe as possible.  I am just a
user, so I feel powerless to do anything, and my experience dealing
with the foo2zjs maintainers was not exactly constructive [2],[3],[4]
(primarily because of apathy, over-reactiveness, and hyper sensitivity
on their part and perhaps a lack of appreciation for the bug severity
command and control authority [5] on my part).  Where do we 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)?

Best wishes,
Michael Gilbert

[1] http://lists.debian.org/debian-release/2008/11/msg00106.html
[2] http://bugs.debian.org/449497
[3] http://bugs.debian.org/503813
[4] http://bugs.debian.org/503814
[5]


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

Direction on foo2zjs and web fetching scripts

[Michael Gilbert]

Dear release team,

Thank you for making a decision on the direction for bug #449497 in
foo2zjs [1].  I believe that this is a reasonable choice for now due
to the impending release.  However, I would really like to see an
honest and consructive conversation on the issue.  I believe that
there are some major security and functionality problems with fetching
scripts, and there should be clear direction from the members of the
debian project on the matter.  I would like to be able to completely
trust main, so it is my hope that developers would do everything in
their power to keep main as clean and safe as possible.  I am just a
user, so I feel powerless to do anything, and my experience dealing
with this issue through the foo2zjs maintainers was not exactly
constructive [2],[3],[4] (primarily because of over-reactiveness and
hyper sensitivity on their part and perhaps a lack of appreciation for
debian's bug command and control authority [5] on my part -- and of
course some good old misunderstanding and misinterpretation).  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)?

Best wishes,
Michael Gilbert

[1] http://lists.debian.org/debian-release/2008/11/msg00106.html
[2] http://bugs.debian.org/449497
[3] http://bugs.debian.org/503813
[4] http://bugs.debian.org/503814
[5] http://lists.debian.org/debian-ctte/2008/10/msg6.html

P.S. Please CC me on any responses since I am not subscribed to these lists.


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

Re: Direction on foo2zjs and web fetching scripts

[Michael Gilbert]

I appologize for the double post.  Please disregard the first message,
which was send mid-thought due to an errant click.


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

Re: [Foo2zjs-maintainer] Bug#449497: Direction on foo2zjs and web fetching scripts

[Steffen Joeris]

On Tue, 4 Nov 2008 03:40:22 pm Michael Gilbert wrote:
> Dear release team,
>
> Thank you for making a decision on the direction for bug #449497 in
> foo2zjs [1].  I believe that this is a reasonable choice for now due
> to the impending release.  However, I would really like to see an
> honest and consructive conversation on the issue.  I believe that
> there are some major security and functionality problems with fetching
> scripts, and there should be clear direction from the members of the
> debian project on the matter.  I would like to be able to completely
> trust main, so it is my hope that developers would do everything in
> their power to keep main as clean and safe as possible.  I am just a
> user, so I feel powerless to do anything, and my experience dealing
> with this issue through the foo2zjs maintainers was not exactly
> constructive [2],[3],[4] (primarily because of over-reactiveness and
> hyper sensitivity on their part and perhaps a lack of appreciation for
> debian's bug command and control authority [5] on my part -- and of
> course some good old misunderstanding and misinterpretation).  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)?
>
> Best wishes,
> Michael Gilbert
>
> [1] http://lists.debian.org/debian-release/2008/11/msg00106.html
> [2] http://bugs.debian.org/449497
> [3] http://bugs.debian.org/503813
> [4] http://bugs.debian.org/503814
> [5] http://lists.debian.org/debian-ctte/2008/10/msg6.html
Please let me just say two things. First we are not over-sensitive or 
anything, but we took your ideas into consideration and even asked for 
advice. I think we were pretty sensible in that manner, so please stop 
stating otherwise.
Furthermore, the script is not automatically called and users know what they 
are doing (or at least they should), when they call it. Maybe we could even 
add an additional warning, which I would definitely be open to.
Now to your "security concerns". Since this script explicitely downloads stuff 
from an author's webpage (and it is stated like that), the user knows the 
risk. Are you proposing to call this a security issue? Then packages like 
iceweasel are also affected and many others ...
We can talk about putting the script somwhere else or do $whatever with it 
after the release, but not for lenny. So please stop the noise and get back 
to us about it after the release. I promise that I'll do my best to find a 
solution that suits everyone. But right now you create more work for other 
people, including me, which I could spend on security related work.
Thanks in advance.

Cheers
Steffen


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

Re: Direction on foo2zjs and web fetching scripts

[Neil McGovern]

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.

Hi Michael,

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.

However, I'd ask for you to wait until after we've released. There's
been quite a lot of discussion on other policy matters recently, and
it's not helping the release at all.

Thanks,
Neil
-- 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?
gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li B345BDD3


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