date:20060606

On Sun, Jun 04, 2006 at 03:59:03PM +0200, Dalibor Topic wrote:
 On Sun, 2006-06-04 at 09:57 +1000, Anthony Towns wrote:
  I would furthermore strongly encourage people to work *with* Sun towards
  improving the current license
 There have been numerous issues with the current text pointed out here
 already, I guess people are currently just waiting for the fixes from
 Sun's legal.

Mmm. The impression I got was that people were waiting for the packages
to be removed from Debian and no one was really all that interested in
responses from Sun, cf:

   http://lists.debian.org/debian-legal/2006/06/msg00025.html
   http://lists.debian.org/debian-legal/2006/06/msg00031.html
   http://lists.debian.org/debian-legal/2006/06/msg00051.html
   http://lists.debian.org/debian-legal/2006/06/msg00058.html
   http://lists.debian.org/debian-legal/2006/06/msg00098.html

And people are welcome to hold that opinion and speak about it all they
like, but the way Debian makes the actual call on whether a license
is suitable for distribution in non-free isn't based on who shouts the
loudest on a mailing list, it's on the views of the archive maintainers.

But that isn't the only issue at stake here, and it's not even the most
important one; the other is communicating with Sun and other upstream
authors the values that Debian thinks are important, and working with
them to find common ground so that the licenses they choose reflect some
of the goals and insights we've developed.

Sun have made it very clear that they're trying to work with us on this
for something that benefits our users, so that just leaves it to us
to decide what's more important: taking a principled stand that we'll
read every license literally and pedantically; or take advantage of
other means by which we can be confident in distributing the software,
and in so doing build a relationship with Sun that can be used later,
and improve the experience of using Debian for people who need Sun Java?

Certainly there are benefits to having a license that can be read
literally and pedantically without causing problems -- and they're not
small or neglible benefits either, as has been shown by pine, Qt, or ncftp
in the past. But when standing up for that principle doesn't actually
protect our users, and taking a flexible approach to it helps them, well,
we have a social contract to make sure we do bend at this sort of time.

 Some kind of more structured process would be nice, the DPL
 could play a useful role there.

The process for improving a license is pretty easy: someone suggests
improvements to the author, they consider them and ask around for advice,
there's some more discussion to make sure the suggestion is a good idea,
and eventually a new license is issued. In this case, Sun have already
gone to the effort of looking through Debian's procedures and started
participating on the -legal list; -legal meanwhile have been obstructive
in trying to tell Sun what their license means, even when that contradicts
what Sun understands their license to mean as documented in their FAQ,
and verified by their lawyers.

  and developing sufficient confidence in
  the Debian and free software community to release Java under an entirely
  free license.
 In my opinion, that's conflating two separate issues. 
 Afaict, noone working on the DLJ (from Sun's or Debian's side) knew
 anything about Sun's recently voiced intention to 'release Java under an
 entirely free license'.

I think interpreting that as an intention would be overstating it. Open
sourcing Java has been on the cards for quite a while, and equally there
have been objections to doing so for quite a while. One of the simplest
objections is that the free software community just aren't an interesting
market for Java people -- we don't want Java, so why spend effort giving
it to us? We have an opportunity, if we choose to take advantage of it,
get rid of that objection right now -- by putting in the effort to get
Java packaged up in non-free and made useful for our users, both we and
Sun can demonstrate that Java on Linux is actually a good idea. Or we
could reinforce that objection, by making sure that no step Sun might
take will achieve anything, and saying things like We've got Perl and
Python and Ruby, why would we want Java?

Personally, I'm not a Java programmer anymore than I'm a C++ or a
Fortran programmer. But I know Java's a language, and I know Sun have
written some runtime software for it, so I think that should first of
all be cleanly packaged for Debian, and second of all be free software,
and I just don't need a third thought on the issue.

 Sun already *is* part of the free software community, and has been for
 years. 

Sun is a big company; some parts are comfortable working with free
software, others aren't. Historically, the Java section hasn't been -- and
that's continues to be reflected in how well Java works on Linux. That's
something we should change.

 Debian ships lots of free software with Sun's

Re: Non-DD's in debian-legal

2006-06-06 Thread MJ Ray

Andreas Barth [EMAIL PROTECTED]
 It has happened in the past that the DPL asked a DD and a NM to make
 together a team to deal with a problematic license and to give together
 official Debian statements. [...]

Whatever happened to that?  July's coming, bringing a new FDL draft,
if the news reports (and my memory) are accurate.

There is also the delegation to a DD who assembled a team of DDs to
work on another group of problematic licences.  Sadly, one of those
DDs resigned from the project during the delegation.  I doubt that the
constant abuse directed at DDs who help answer debian-legal helped,
but I don't claim any insight into his resignation.

It would be nice if all contributors actually tried to stick to our
lists code of conduct and the constitution and those documents were
actually supported in a transparent consistent manner, but most DDs seem
happy to wallow in the brown stuff and sling it around liberally,
including the recent unnecessary URNADD posting rash.
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Bug#370695: ITP: libsub-exporter-perl -- A sophisticated exporter for custom-built routines

2006-06-06 Thread Krzysztof Krzyzaniak (eloy)

Package: wnpp
Severity: wishlist
Owner: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED]

* Package name: libsub-exporter-perl
  Version : http://search.cpan.org/~rjbs/Sub-Exporter-0.952/
  Upstream Author : Ricardo SIGNES, [EMAIL PROTECTED]
* URL : http://www.example.org/
* License : Perl: GPL/Artistic
  Programming Lang: Perl
  Description : A sophisticated exporter for custom-built routines

 Sub::Exporter provides a sophisticated alternative to Exporter.pm.  It allows
 for renaming, currying/sub-generation etc.
 .
 Sub::Exporter builds a custom exporter which can then be installed into your 
 perl module. It builds this method based on configuration passed to its 
 setup_exporter method.
  

NOTE: this package is needed to upload new version of libmoose-perl

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-686
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)


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

Re: Non-DD's in debian-legal

2006-06-06 Thread Jeremy Hankins

Wouter Verhelst [EMAIL PROTECTED] writes:

 Well, no, that's not actually true. Debian developers get a say in
 whatever they're responsible for. Whether that whatever is a bunch of
 packages on which they're listed as Maintainer, or a port they've been
 maintaining for a few years, or a programming language for which they
 maintain an extraordinary amount of packages and have been helping out
 in shaping a policy for, or some appointed position (as in this case)
 really isn't all that important.

That is a crucial difference between d-l and many other responsibilities
in Debian: ultimately, d-l is only advisory.

 If somebody not involved with the m68k port comes and tells me that
 some decision I made for m68k is all wrong and that I should've done
 this or that instead, I'll have a good laugh. And go on with doing
 whatever I was doing.

 Which, I think, is what the ftp-masters should do to this thread.

That's probably good advice for those of us who contribute to d-l, too.
Except for one thing: if there's significant distrust or antipathy
directed toward d-l it interferes with our ability to give advice on
software freedom issues because people don't listen to us.  That,
ultimately, is why I posted my original message.

-- 
Jeremy Hankins [EMAIL PROTECTED]
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03


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

Re: Hidden files

2006-06-06 Thread Mike Hommey

On Tue, Jun 06, 2006 at 11:47:10AM +0200, Klaus Ethgen [EMAIL PROTECTED] 
wrote:
 Hello,
 
 more and more packages use hidden files in /usr. I see this as an error.
 But before making a bug report for such packages I wish to ask if this
 is intended or really a bug? Some of the files are in the package some
 are created in postinst and not registered to any package. I see ANY
 hidden file in /usr as a bug which should be fixed!
 
 Packages are:
 - firefox
 - libnss3-0d or libxul0d (/usr/lib/xulrunner/.autoreg)

I can speak for these two. This is not a bug but an intended feature. It
helps component registration on upgrade. The file could be renamed, but
that means modifying mozilla's code. Not that we don't already modify
it, but if we can avoid to make too many changes, it's still better.

Could you tell us what kind of harm can do a hidden empty file in /usr ?

Mike


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

Bug#370696: ITP: libibatis-java -- iBATIS Data Mapper framework

2006-06-06 Thread Tim Peeler

Package: wnpp
Severity: wishlist
Owner: Tim Peeler [EMAIL PROTECTED]


* Package name: libibatis-java
  Version : 2.1.7.597
  Upstream Author : Clinton Begin, Gilles Bayon, Ted Husted, et al.
* URL : http://ibatis.apache.org/
* License : Apache
  Description : iBATIS Data Mapper framework

The  iBATIS Data Mapper framework makes it easier to use a database with
Java and .NET applications. iBATIS couples objects with stored procedures
or SQL statements using a XML descriptor. Simplicity is the biggest
advantage of the iBATIS Data Mapper over object relational mapping tools.

To use the iBATIS Data Mapper, you rely on your own objects, XML,
and SQL.  There is little to learn that you don't already know. With
the iBATIS Data Mapper, you have the full power of both SQL and stored
procedures at your fingertips.


-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.8-11-amd64-k8
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Re: Hidden files

2006-06-06 Thread Linas Žvirblis

Mike Hommey wrote:

 Could you tell us what kind of harm can do a hidden empty file in /usr ?

First of all, false positives in rootkit and security scanners. And too
many false positives lead to false negatives sooner or later.


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

Re: Hidden files

2006-06-06 Thread Olaf van der Spek


On 6/6/06, Mike Hommey [EMAIL PROTECTED] wrote:

On Tue, Jun 06, 2006 at 11:47:10AM +0200, Klaus Ethgen [EMAIL PROTECTED] 
wrote:
 Hello,

 more and more packages use hidden files in /usr. I see this as an error.
 But before making a bug report for such packages I wish to ask if this
 is intended or really a bug? Some of the files are in the package some
 are created in postinst and not registered to any package. I see ANY
 hidden file in /usr as a bug which should be fixed!

 Packages are:
 - firefox
 - libnss3-0d or libxul0d (/usr/lib/xulrunner/.autoreg)

I can speak for these two. This is not a bug but an intended feature. It
helps component registration on upgrade. The file could be renamed, but
that means modifying mozilla's code. Not that we don't already modify


What about an upstream 'feature' request?


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

Re: Hidden files

2006-06-06 Thread Henrique de Moraes Holschuh

On Tue, 06 Jun 2006, Mike Hommey wrote:
 Could you tell us what kind of harm can do a hidden empty file in /usr ?

It flags alarms, it is obscure, and generally it is bad form to have hidden
files anywhere but under user homes anyway.  There certainly is no excuse to
have anything hidden inside the system hierarchies, you WANT to easily know
what is there.

Please consider this email as a second request that those files be renamed
to something without a leading dot.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: rcpar, parallel boot written in C

2006-06-06 Thread Petter Reinholdtsen

[Maximiliano Curia]
After Marga's talk in Debconf6, I've been working in a program that
starts the initscripts in parallel [1]. It's similar in some aspects
to startpar (part of sysvinit package) but with two main goals: it
must work, it must be as little intrusive as possible (in respect to
the scripts behavior).

What is the speed impact compared to the non-parallel boot and a boot
with startpar and shell parallelization?

The idea is to have a working parallel boot system, which could be
accompanied by something similar to insserv[2], to have the smallest
possible boot time.

The current version is almost a proof of concept, but works quite
well with non-interactive initscripts. It still does not handle the
input for scripts like checkroot.sh, scripts that prompt for a
passphrase, or similar. Anyway, I'll be working in the support of
interactive scripts for the next few days.

It's not ready to be released, nor to be included in Debian, but I
would really like to have some eyes over it, some comments and
suggestions.

I might make a package for this soon, but I still have to figure out how to
modify /etc/init.d/rc from outside the sysvinit package.

[1] The darcs repository is available in http://maxy.com.ar/~maxy/darcs/rcpar
[2] insserv uses the new lsb initscripts tags to reorder them, but it's too
SUSE based

As Martin comments, the initscripts-ng project is a better place for
this topic. CC to it, and lets continue the discussion there.

A similar system to yours was proposed by Olivier Sessink. Check out
The thread starting at
URL:http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/2005-November/000225.html

Friendly,
--
Petter Reinholdtsen

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

Bug#370707: ITP: libdata-optlist-perl -- Parse and validate simple name/value option pairs

2006-06-06 Thread Krzysztof Krzyzaniak (eloy)

Package: wnpp
Severity: wishlist
Owner: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED]

* Package name: libdata-optlist-perl
  Version : 0.100
  Upstream Author : Ricardo SIGNES, [EMAIL PROTECTED]
* URL : 
http://mirrors.kernel.org/cpan/modules/by-module/Data/Data-OptList-0.100.tar.gz
* License : Perl: GPL/Artistic
  Programming Lang: Perl
  Description : Parse and validate simple name/value option pairs

 Hashes are great for storing named data, but if you want more than one entry
 for a name, you have to use a list of pairs.
 .
 Data::OptList make it easy by assuming that any defined scalar is a name and 
 any reference following a name is its value.
 
NOTE: this package is needed to upload new version of libmoose-perl

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-686
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)


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

Re: Sun Java available from non-free

2006-06-06 Thread Mike Bird

On Tuesday 06 June 2006 04:43, Anthony Towns wrote:
 Sun have made it very clear that they're trying to work with us on this
 for something that benefits our users, so that just leaves it to us
 to decide what's more important: taking a principled stand that we'll
 read every license literally and pedantically; or take advantage of
 other means by which we can be confident in distributing the software,
 and in so doing build a relationship with Sun that can be used later,
 and improve the experience of using Debian for people who need Sun Java?

Reading a proposed contract or license in any way other than
literally and pedantically is dumb.  Some actions are so
dumb that no nicer adjective is correct.  Judges are like
compilers.  Modulo judge bugs (which can usually be fixed on
appeal) judges process legal source files literally and
pedantically.

Debian has gcj etc without Debian indemnifying Sun.  Users
can install Sun's Java without Debian indemnifying Sun.
Being able to install Sun's Java with apt-get after editing
sources.list is a minor step forward, which would be welcome
if there were no significant downside.

Why is building a relationship with Sun so important to
Debian that it's worth the risk to Debian of indemnifying
Sun, Sun's licensors, and all their successors in interest?

--Mike Bird


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

Re: Sun Java available from non-free

2006-06-06 Thread Thijs Kinkhorst

Hello Mike,

On Tue, 2006-06-06 at 07:41 -0700, Mike Bird wrote:
 Reading a proposed contract or license in any way other than
 literally and pedantically is dumb.  Some actions are so
 dumb that no nicer adjective is correct.  Judges are like
 compilers.  Modulo judge bugs (which can usually be fixed on
 appeal) judges process legal source files literally and
 pedantically.

I believe you are quite incorrect - judges are far from automatic. They
interpret each and every individual case on its own merit, circumstances
and context, on the intention of the law, and take the personal
situation of the involved parties in consideration. The keyword is
reason: a judge will try to decide in a way that he/she considers to
be the most reasonable, not the most literal.

More importantly, proclaiming the dumbness of people does not help
anyone on this list, including yourself.


Thijs


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

Bug#370722: ITP: libnet-httpserver-perl -- An extensible HTTP server framework for perl

2006-06-06 Thread Steve Kemp

Package: wnpp
Severity: wishlist
Owner: Steve Kemp [EMAIL PROTECTED]


* Package name: libnet-httpserver-perl
  Version : 1.1.1.
  Upstream Author : Ryan Eatmon [EMAIL PROTECTED]
* URL : http://search.cpan.org/~reatmon/Net-HTTPServer/
* License : LGPL
  Description : An extensible HTTP server framework for perl

  Net::HTTPServer provides a lite HTTP server. It can serve files, or
  can be configured to call Perl functions when a URL is accessed.
  .
  Net::HTTPServer basically turns a CGI script into a stand alone
  server. Useful for temporary services, mobile/local servers, or
  embedding an HTTP server into another program.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.12.6-xen
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: Hidden files

2006-06-06 Thread Joey Hess

Henrique de Moraes Holschuh wrote:
 It flags alarms, it is obscure, and generally it is bad form to have hidden
 files anywhere but under user homes anyway.  There certainly is no excuse to
 have anything hidden inside the system hierarchies, you WANT to easily know
 what is there.

Sure there is. For example, mooix uses .mooix as a flag file in
directories that are mooix objects, and uses other dotfiles inside
objects for fields that are only accessible by methods of that object
and are hidden from casual interspection (as opposed to public fields).
Some mooix objects live under /usr, some under /var, and some in user
home directories, it wouldn't make sense to rename all the fields in the
objects that are installed under /usr.

If you want to know what's really there, use ls -a ..

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Sun Java available from non-free

On Tue, Jun 06, 2006 at 09:43:02PM +1000, Anthony Towns wrote:
 Mmm. The impression I got was that people were waiting for the packages
 to be removed from Debian and no one was really all that interested in
 responses from Sun, cf:
 
http://lists.debian.org/debian-legal/2006/06/msg00025.html
http://lists.debian.org/debian-legal/2006/06/msg00031.html
http://lists.debian.org/debian-legal/2006/06/msg00051.html

Well, that is not accurate.  Sun's responses are indeed quite
interesting to Debian.  However, if their response is in the form of a
FAQ that explicitly has no legal bearing on the matter, or in the
form of mailing list posts that have no legal bearing on the matter,
they have not yet resolved the problem.

If Debian agrees to do X, and commits itself legally to doing X, which
is what Sun's license is asking, why should our standards for Sun be any
different than for someone else?

If Sun and Debian agree to certain terms in a contract, and then one
party posts a FAQ, or a mailing list post, or whatever, that explicitly
has no legal influence, how does that resolve concerns?

To me, you are confusing two entirely different problems.

1) The FAQ explicitly has no legal bearing on things and, as such,
   can't be used to consider whether Debian can distribute something.

2) The FAQ can be a useful place to begin a discussion with Sun on
   fixing the license and perhaps putting some of the material in the
   FAQ into it, and this has been suggested to them.


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

Who can make binding legal agreements

On Tue, Jun 06, 2006 at 09:43:02PM +1000, Anthony Towns wrote:
 On Sun, Jun 04, 2006 at 03:59:03PM +0200, Dalibor Topic wrote:
 
 Mmm. The impression I got was that people were waiting for the packages
 to be removed from Debian and no one was really all that interested in
 responses from Sun, cf:
 
http://lists.debian.org/debian-legal/2006/06/msg00025.html
http://lists.debian.org/debian-legal/2006/06/msg00031.html
http://lists.debian.org/debian-legal/2006/06/msg00051.html

That msg00051 was my message raising the concern about SPI's role in
this.  A message that had nothing to do with Sun, everything to do with
our legal right to do what you have done, and which received no reply
whatsoever.

[ snip ]

 And people are welcome to hold that opinion and speak about it all they
 like, but the way Debian makes the actual call on whether a license
 is suitable for distribution in non-free isn't based on who shouts the
 loudest on a mailing list, it's on the views of the archive maintainers.

I am becoming increasingly concerned at the unilateral method in which
you and/or the archive maintainers have taken this decision.

The ability to enter into a legal contract to indemnify a third party
should be, and arguably IS, reserved solely for the SPI Board of
Directors.  I don't recall even a heads-up to the SPI board.  Nor do I
recall any SPI resolution, past or present, delegating the ability to
enter into such an agreement to any Debian developer, archive maintainer
or otherwise.

By taking this action, you have committed SPI to expend resources in the
event of legal action.  Worse, SPI wasn't even *aware* of this.

A case could be made that since you did not have authorization to enter
into this agreement with Sun that the agreement to indemnify is void,
but then we (both SPI and Debian) are in even worse shape as the
permission to distribute Java also may be void in that case.

 to decide what's more important: taking a principled stand that we'll
 read every license literally and pedantically; or take advantage of
 other means by which we can be confident in distributing the software,
 and in so doing build a relationship with Sun that can be used later,
 and improve the experience of using Debian for people who need Sun Java?

You didn't even give SPI the chance to run it by our attorney before
posting the software, and now you present it as a fait accompli.  Why
would it have been so hard to learn, from a legal expert, whether this
really does pose a problem to Debian or SPI -- in advance?

Why did you not consult people about this?

It doesn't improve the experience of Debian for people, regardless of
whether they need Sun Java, if Debian and SPI are run into the ground
because of a lawsuit.

 Certainly there are benefits to having a license that can be read
 literally and pedantically without causing problems -- and they're not

If Debian agress to do X, and commits to doing X via a legal contract, I
fail to see what real difference a pragmatic vs. a flexible reading
would provide.  Either we agree to do X or we don't.

 in the past. But when standing up for that principle doesn't actually
 protect our users, and taking a flexible approach to it helps them, well,
 we have a social contract to make sure we do bend at this sort of time.

The social contract should not be used as an excuse to take unwise legal
risks.  Nor should it be used as an excuse to bypass proper channels for
approving legal contracts.

 participating on the -legal list; -legal meanwhile have been obstructive
 in trying to tell Sun what their license means, even when that contradicts
 what Sun understands their license to mean as documented in their FAQ,
 and verified by their lawyers.

If Sun would commit to putting that interpretation in their license,
that would be one thing.  But as an aside as it is, with no legal
standing, who is to say that other lawyers or a judge wouldn't decide it
means something entirely different?

This is an important check that SPI's attorney could have helped with.

SPI projects shouldn't be taking advice from Sun's attorneys.  We should
be taking advice from SPI's attorneys.

I am greatly troubled by the lack of foresight and communication with
which this situation has been handled.  It feels very much that the
interests of Sun have been placed ahead of those of Debian (and, by
extension, SPI).

I am also troubled about the potentially murky legal water in which we
are now, with a potentially unauthorized agreement with Sun and thus
potentially unauthorized downloads in non-free.

And I know you would like me to just go away and shut up about this, but
this project is too important, and this action has too many unknowns at
this stage, to just put blind faith in Sun's lawyers doing the right
thing by Debian.

-- John


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

Re: Hidden files

2006-06-06 Thread Klaus Ethgen

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Di den  6. Jun 2006 um 18:12 schrieb Joey Hess:
 If you want to know what's really there, use ls -a ..

This is not the point. I think no of us do not know how to show that
files.

There are two reasons not to use hidden files in /usr, /var, /dev and
other:
1. It generates false positives (as mention before). And to many false
   positives only ends in overlook the real bad files and directories.

2. There is absolutely no reason to hide think in this directories. If a
   programming method use dot files to make there classes and methods
   private -- no problem. But is it necessary to put them in common
   paths? I think this is more a misuse. Finished programs should be
   compiled in some way.

Regards
   Klaus Ethgen
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen [EMAIL PROTECTED]
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iQEVAwUBRIWyaZ+OKpjRpO3lAQJLcwf9Hddd96EmUISBjK8NlXh027JAHcy4duXy
NOkJlXQTTT8IqwTRLWXK4CYOCVemWQHgrfy9dWkkXcKuGeRvAQ8v/RlpdySkwCSR
RNJYvZ63GGaqbkNydlvyU+3R4mYaTWotXwF4u5KiKcJlLXWVT4vkTb9iS7k4yFf9
9UdDnq+8BAkTLRYaw0XmlGMVL05jb5k3VeYPw6hTfrtRhhabnV0ArLl0aFtWKRXi
exgrTgMXA3GbsxIkZyzaikciKrCfRIsHqlpeo2kmndvKLj8XdePw8XrwXYMfuAFc
FzuNE1uCIi883aUdWzoCBXuhD+swGqqFJR8+e8cSiFvrKuJXRM5CtA==
=wGqe
-END PGP SIGNATURE-


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

Re: Summary of Debconf i18n/l10n activities


On 6/6/06, Christian Perrier [EMAIL PROTECTED] wrote:

(this report is a little bit late as it took time to finalize
it...sorry for the inconvenience)

The work on internationalisation (i18n) and localisation (l10n) at
Debconf6 has been particularly interesting and productive.

(...)


You wrote a good overview about the possible workflow, but i still miss exactly
how we (or the coordinators) will merge from third parties (eg:
Rosetta) and most
important, how we will push our translations back to the upstream (eg: GNOME).

I think there's a lot of translations being done for different apps in
Rosetta, but it's
not pushed back to their upstream, so we need to keep in mind that we will do a
lot of bridge (Rosetta-Pootle-Projects) work to start, just in
this scenario.


Future plans for Debian l10n contributors
-

  Reviving the DDTP - translated package descriptions as a release goal
  -
(...)
Having working translated package descriptions as an etch pet release
goal for the Debian i18n team seems possible.


Agreed. Btw, it would be better keep Etch package descriptions updated
during its support cycle, but i think it's impossible with the
infrascture we've, right ?


(...)


Thanks,
-- stratus


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

Re: Hidden files

2006-06-06 Thread Joey Hess

Klaus Ethgen wrote:
 1. It generates false positives (as mention before). And to many false
positives only ends in overlook the real bad files and directories.

Scanning for dotfiles is not an effective way to find files left behind
by exploits. People writing exploits are aware of programs that warn
about dotfiles, and it's easy to find other places to hide troublesome
files. I'd probably use /var/lib/dpkg/info/ on Debian systems if I were
writing an exploit; the high churn rate of new files in that directory
coupled with the absurd number of files in it make it an excellent hiding
place.

 2. There is absolutely no reason to hide think in this directories. If a
programming method use dot files to make there classes and methods
private -- no problem. But is it necessary to put them in common
paths? I think this is more a misuse. Finished programs should be
compiled in some way.

The example I saw was of a dotfile in /usr/lib/something/ not /usr/bin.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Summary of Debconf i18n/l10n activities


On 6/6/06, Otavio Salvador [EMAIL PROTECTED] wrote:

Gustavo Franco [EMAIL PROTECTED] writes:

 Agreed. Btw, it would be better keep Etch package descriptions updated
 during its support cycle, but i think it's impossible with the
 infrascture we've, right ?

No. We already have the previous working structure all up and
running. What we want to do is improve it.


Does it mean that we've infrastructure to keep updating Etch package
descriptions during it support cycle? Is it the plan?

Thanks,
-- stratus


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

Re: Hidden files

2006-06-06 Thread Roger Leigh

Joey Hess [EMAIL PROTECTED] writes:

 Henrique de Moraes Holschuh wrote:
 It flags alarms, it is obscure, and generally it is bad form to have hidden
 files anywhere but under user homes anyway.  There certainly is no excuse to
 have anything hidden inside the system hierarchies, you WANT to easily know
 what is there.

 Sure there is. For example, mooix uses .mooix as a flag file in
 directories that are mooix objects, and uses other dotfiles inside
 objects for fields that are only accessible by methods of that object
 and are hidden from casual interspection (as opposed to public
 fields).

It is always bad practice to hide things from the user or system
administrator, particularly outside their $HOME.  If you need to store
additional metadata about files or directories, you really should be
using POSIX 1003.1e extended attributes.  It's supported by glibc.


Regards,
Roger

-- 
Roger Leigh
Printing on GNU/Linux?  http://gutenprint.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


pgpDdFCMmwvkg.pgp
Description: PGP signature

Re: Hidden files

2006-06-06 Thread Uwe Hermann

Hi,

On Tue, Jun 06, 2006 at 11:05:31AM -0300, Henrique de Moraes Holschuh wrote:
 It flags alarms, it is obscure, and generally it is bad form to have hidden
 files anywhere but under user homes anyway.  There certainly is no excuse to
 have anything hidden inside the system hierarchies, you WANT to easily know
 what is there.
 
 Please consider this email as a second request that those files be renamed
 to something without a leading dot.

Make that three requests.


Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org


signature.asc
Description: Digital signature

Re: Summary of Debconf i18n/l10n activities

2006-06-06 Thread Felipe Augusto van de Wiel (faw)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[ Adding -i18n ]

On 06/06/2006 02:04 PM, Gustavo Franco wrote:
 On 6/6/06, Christian Perrier [EMAIL PROTECTED] wrote:
 (this report is a little bit late as it took time to finalize
 it...sorry for the inconvenience)

 The work on internationalisation (i18n) and localisation (l10n) at
 Debconf6 has been particularly interesting and productive.

 (...)
 
 You wrote a good overview about the possible workflow, but i still 
 miss exactly how we (or the coordinators) will merge from third
 parties (eg: Rosetta) and most important, how we will push our
 translations back to the upstream (eg: GNOME).

As I understood during DebConf, we would have to coordinate
efforts between different projects and upstream and one of the main
goals to our infrastructure is to be modular, so we can add a module
to import/export data from one system to another.


 I think there's a lot of translations being done for different apps in
 Rosetta, but it's not pushed back to their upstream, so we need to 
 keep in mind that we will do a lot of bridge
 (Rosetta-Pootle-Projects) work to start, just in this scenario.

Rosetta has problems with legal aspects of the translations and
also problems of translation QA. We still have to figure out how good
will be for us to push these translations back. (Maybe translate it
again is more worthwhile than review it).

Actually, we still lack some recommendations on how to deal
with big projects i18n/l10n (GNOME, KDE and so on), specially with
regards to translation license (Nicolas recently brought this subject
to the spotlight) and also the alignment of terms being used.


 Future plans for Debian l10n contributors
 -

   Reviving the DDTP - translated package descriptions as a release goal
   -
 (...)
 Having working translated package descriptions as an etch pet release
 goal for the Debian i18n team seems possible.
 
 Agreed. Btw, it would be better keep Etch package descriptions updated
 during its support cycle, but i think it's impossible with the
 infrascture we've, right ?

Hmmm, it depends on how the ftp-master team will deal with that.
There is a working version of DDTP at ddtp.debian.net and the
Translation-* files can be updated, we still need to check impact in
SecureAPT and related mirror/archive issues. Anyway, it should be
possible to keep it up-to-date during the support cycle.

Kind regards,

- --
Felipe Augusto van de Wiel (faw)
Debian. Freedom to code. Code to freedom!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFEhcksCjAO0JDlykYRAsy4AJ9iMO1r6i2gBRcHrzIPsg4d0DexKgCfa8qH
GxK3hGM2Ok+rJXmfbKikhjo=
=aopQ
-END PGP SIGNATURE-


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

Re: Summary of Debconf i18n/l10n activities


On 6/6/06, Otavio Salvador [EMAIL PROTECTED] wrote:

Gustavo Franco [EMAIL PROTECTED] writes:

 On 6/6/06, Otavio Salvador [EMAIL PROTECTED] wrote:
 Gustavo Franco [EMAIL PROTECTED] writes:

  Agreed. Btw, it would be better keep Etch package descriptions updated
  during its support cycle, but i think it's impossible with the
  infrascture we've, right ?

 No. We already have the previous working structure all up and
 running. What we want to do is improve it.

 Does it mean that we've infrastructure to keep updating Etch package
 descriptions during it support cycle? Is it the plan?

People is testing it and then will announce it probably. We intent to
try to make as fast as possible.



Nice, thanks. While we're at this subject, what's your view on the
Ubuntu language packs? Are we going to extract the translations from
the packages creating language packs? It has pros and cons, and
the best thing i see is the possibility to keep translating stuff after
release. Thoughts?

regards,
-- stratus


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

Re: Summary of Debconf i18n/l10n activities


On 6/6/06, Felipe Augusto van de Wiel (faw) [EMAIL PROTECTED] wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[ Adding -i18n ]

On 06/06/2006 02:04 PM, Gustavo Franco wrote:
 On 6/6/06, Christian Perrier [EMAIL PROTECTED] wrote:
 (this report is a little bit late as it took time to finalize
 it...sorry for the inconvenience)

 The work on internationalisation (i18n) and localisation (l10n) at
 Debconf6 has been particularly interesting and productive.

 (...)

 You wrote a good overview about the possible workflow, but i still
 miss exactly how we (or the coordinators) will merge from third
 parties (eg: Rosetta) and most important, how we will push our
 translations back to the upstream (eg: GNOME).

As I understood during DebConf, we would have to coordinate
efforts between different projects and upstream and one of the main
goals to our infrastructure is to be modular, so we can add a module
to import/export data from one system to another.


Sounds good. Keep in mind, that we will need to be ready to support not
structured projects so it should be easy for us track if a translation revision
(annotate) came from Rosetta, GNOME or it was made using our Pootle
setup.


 I think there's a lot of translations being done for different apps in
 Rosetta, but it's not pushed back to their upstream, so we need to
 keep in mind that we will do a lot of bridge
 (Rosetta-Pootle-Projects) work to start, just in this scenario.

Rosetta has problems with legal aspects of the translations and
also problems of translation QA. We still have to figure out how good
will be for us to push these translations back. (Maybe translate it
again is more worthwhile than review it).


The legal aspects should be sorted out before importing anything,
right. I think push the translations would be good if we've the track feature
i pointed out above and if it was merged as 'pending' or 'suggestion' for
a reviewer. It should be done for any third party project, we should just
trust our translation once we merge with upstream (GNOME, KDE, ...), IMHO.


(...)
 Future plans for Debian l10n contributors
 -

   Reviving the DDTP - translated package descriptions as a release goal
   -
 (...)
 Having working translated package descriptions as an etch pet release
 goal for the Debian i18n team seems possible.

 Agreed. Btw, it would be better keep Etch package descriptions updated
 during its support cycle, but i think it's impossible with the
 infrascture we've, right ?

Hmmm, it depends on how the ftp-master team will deal with that.
There is a working version of DDTP at ddtp.debian.net and the
Translation-* files can be updated, we still need to check impact in
SecureAPT and related mirror/archive issues. Anyway, it should be
possible to keep it up-to-date during the support cycle.


Sounds interesting. I hope to see it translatable through the UI for
apps translation
too.

regards,
-- stratus


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

Re: Hidden files

2006-06-06 Thread Thijs Kinkhorst

On Tue, 2006-06-06 at 18:54 +0100, Roger Leigh wrote:
 It is always bad practice to hide things from the user or system
 administrator, particularly outside their $HOME.   

Indeed, I'd call that ``the principle of least surprise''.


Thijs


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

Re: Hidden files

2006-06-06 Thread Mike Hommey

On Tue, Jun 06, 2006 at 08:32:34PM +0200, Uwe Hermann [EMAIL PROTECTED] wrote:
 Hi,
 
 On Tue, Jun 06, 2006 at 11:05:31AM -0300, Henrique de Moraes Holschuh wrote:
  It flags alarms, it is obscure, and generally it is bad form to have hidden
  files anywhere but under user homes anyway.  There certainly is no excuse to
  have anything hidden inside the system hierarchies, you WANT to easily know
  what is there.
  
  Please consider this email as a second request that those files be renamed
  to something without a leading dot.
 
 Make that three requests.

It'd be easier to take your claim into account if you actually brought
better facts than I don't like it or stupid tools give false positives

Mike


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

Re: Summary of Debconf i18n/l10n activities

2006-06-06 Thread Felipe Augusto van de Wiel (faw)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/06/2006 04:02 PM, Gustavo Franco wrote:
 On 6/6/06, Felipe Augusto van de Wiel (faw) [EMAIL PROTECTED]
 wrote:
 On 06/06/2006 02:04 PM, Gustavo Franco wrote:
  On 6/6/06, Christian Perrier [EMAIL PROTECTED] wrote:

[...]

  I think there's a lot of translations being done for different apps in
  Rosetta, but it's not pushed back to their upstream, so we need to
  keep in mind that we will do a lot of bridge
  (Rosetta-Pootle-Projects) work to start, just in this scenario.

 Rosetta has problems with legal aspects of the translations and
 also problems of translation QA. We still have to figure out how good
 will be for us to push these translations back. (Maybe translate it
 again is more worthwhile than review it).
 
 The legal aspects should be sorted out before importing anything,
 right. 

People involved with Rosetta should work on that. :-)


 I think push the translations would be good if we've the track
 feature
 i pointed out above and if it was merged as 'pending' or 'suggestion' for
 a reviewer. It should be done for any third party project, we should just
 trust our translation once we merge with upstream (GNOME, KDE, ...), IMHO.

The real problem, is that we have reports of people overwritten
translation using Rosetta, and usually, with bad translations, which
means that we can trust *our* translation, but we still need to check
if it is worthwhile to review translation from others or just translate
it again in the Right Way (tm) (and there is still the license problem,
how to push something without being allowed to).

[...]

Kind regards,

- --
Felipe Augusto van de Wiel (faw)
Debian. Freedom to code. Code to freedom!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFEhdlcCjAO0JDlykYRAm7jAJ95gssT2Wzm6LoO8SG7oKWOVGs+cgCgvKmW
BQg2Hxol20//THvkARgrMXI=
=AxWu
-END PGP SIGNATURE-


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

Re: Summary of Debconf i18n/l10n activities


On 6/6/06, Felipe Augusto van de Wiel (faw) [EMAIL PROTECTED] wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/06/2006 04:02 PM, Gustavo Franco wrote:
 On 6/6/06, Felipe Augusto van de Wiel (faw) [EMAIL PROTECTED]
 wrote:
 On 06/06/2006 02:04 PM, Gustavo Franco wrote:
  On 6/6/06, Christian Perrier [EMAIL PROTECTED] wrote:

[...]

  I think there's a lot of translations being done for different apps in
  Rosetta, but it's not pushed back to their upstream, so we need to
  keep in mind that we will do a lot of bridge
  (Rosetta-Pootle-Projects) work to start, just in this scenario.

 Rosetta has problems with legal aspects of the translations and
 also problems of translation QA. We still have to figure out how good
 will be for us to push these translations back. (Maybe translate it
 again is more worthwhile than review it).

 The legal aspects should be sorted out before importing anything,
 right.

People involved with Rosetta should work on that. :-)


They did with the wiki content, probably they will do the same thing
or something similar with Rosetta translations. The question is if it
will be free.


 I think push the translations would be good if we've the track
 feature
 i pointed out above and if it was merged as 'pending' or 'suggestion' for
 a reviewer. It should be done for any third party project, we should just
 trust our translation once we merge with upstream (GNOME, KDE, ...), IMHO.

The real problem, is that we have reports of people overwritten
translation using Rosetta, and usually, with bad translations, which
means that we can trust *our* translation, but we still need to check
if it is worthwhile to review translation from others or just translate
it again in the Right Way (tm) (and there is still the license problem,
how to push something without being allowed to).


If the content we're merging is free, there's no problem show this to the
reviewer and let him accept or refuse the translation. It's way simpler to do
than rewrite everything again. If the translation was overwritten in a
'source' (eg:
Rosetta), we should show the translation we've and the alternative
translations as suggestions.

regards,
-- stratus


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

Re: Hidden files

2006-06-06 Thread Linas Žvirblis

Mike Hommey wrote:

 It'd be easier to take your claim into account if you actually brought
 better facts than I don't like it or stupid tools give false positives

Let us imagine someone decides to introduce package X that contains a
lot of files (let us say 50) in /usr/lib and half of them are dot
files. And what about shipping hidden directories? Would such packages
be accepted into Debian?


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

Re: Hidden files

2006-06-06 Thread Mike Hommey

On Tue, Jun 06, 2006 at 10:51:02PM +0300, Linas Žvirblis [EMAIL PROTECTED] 
wrote:
 Mike Hommey wrote:
 
  It'd be easier to take your claim into account if you actually brought
  better facts than I don't like it or stupid tools give false positives
 
 Let us imagine someone decides to introduce package X that contains a
 lot of files (let us say 50) in /usr/lib and half of them are dot
 files. And what about shipping hidden directories? Would such packages
 be accepted into Debian?

Here, we are talking about the empty file /usr/lib/xulrunner/.autoreg...

Mike


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

Re: Summary of Debconf i18n/l10n activities

2006-06-06 Thread Denis Barbier

On Tue, Jun 06, 2006 at 02:04:09PM -0300, Gustavo Franco wrote:
 You wrote a good overview about the possible workflow, but i still
 miss exactly how we (or the coordinators) will merge from third
 parties (eg: Rosetta) and most important, how we will push our
 translations back to the upstream (eg: GNOME).

I do not know what has been discussed at DebConf, but I hope that
Debian translators will only translate Debian material and not
interfere with other translation teams.

 I think there's a lot of translations being done for different apps in
 Rosetta, but it's not pushed back to their upstream, so we need to
 keep in mind that we will do a lot of bridge
 (Rosetta-Pootle-Projects) work to start, just in this scenario.

Err, no, we have to not repeat the same mistakes.

Denis


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

Re: Hidden files

2006-06-06 Thread Linas Žvirblis

Mike Hommey wrote:

 Here, we are talking about the empty file /usr/lib/xulrunner/.autoreg...

Are you saying it is fine for empty files? So what about
/usr/lib/kaffe/.system (a symlink to directory) or
/usr/lib/jvm/.java-gcj.jinfo (non-empty file)?


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

Re: Hidden files

2006-06-06 Thread Joey Hess

Linas Žvirblis wrote:
 Let us imagine someone decides to introduce package X that contains a
 lot of files (let us say 50) in /usr/lib and half of them are dot
 files. And what about shipping hidden directories? Would such packages
 be accepted into Debian?

I've had packages in Debian with more dotfiles than that in /usr/lib
(although only perhaps 5% of the total file count).

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Summary of Debconf i18n/l10n activities


On 6/6/06, Denis Barbier [EMAIL PROTECTED] wrote:

On Tue, Jun 06, 2006 at 02:04:09PM -0300, Gustavo Franco wrote:
 You wrote a good overview about the possible workflow, but i still
 miss exactly how we (or the coordinators) will merge from third
 parties (eg: Rosetta) and most important, how we will push our
 translations back to the upstream (eg: GNOME).

I do not know what has been discussed at DebConf, but I hope that
Debian translators will only translate Debian material and not
interfere with other translation teams.


I hope we keep translating Debian material with an eye on what others
are doing. Why not? The licensing issue needs to be sorted out in
some (Rosetta?) cases, but we won't start burning upstream potfiles (eg:
GNOME) for nothing so we can coordinate the work from the start.


 I think there's a lot of translations being done for different apps in
 Rosetta, but it's not pushed back to their upstream, so we need to
 keep in mind that we will do a lot of bridge
 (Rosetta-Pootle-Projects) work to start, just in this scenario.

Err, no, we have to not repeat the same mistakes.


Hopefully you misunderstood my sentence. It isn't a mistake give the
translations back to the upstream.  Probably you considered that i was
asking for merge Rosetta stuff on our Pootle and then forward it to the
upstream directly. No, that's why i wrote about suggestions to reviewers
and all the other points i raised there.

regards,
-- stratus


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

Re: Sun Java available from non-free

2006-06-06 Thread MJ Ray

Anthony Towns aj@azure.humbug.org.au [...]
 And people are welcome to hold that opinion and speak about it all they
 like, but the way Debian makes the actual call on whether a license
 is suitable for distribution in non-free isn't based on who shouts the
 loudest on a mailing list, it's on the views of the archive maintainers.

The package maintainer did not ask debian-legal (serious bug) and I'm
really surprised that the archive maintainers felt no need to consult
developers about this licence, in public or private, or SPI, before
agreeing to indemnify Sun so broadly.

I've not actively worked on this so far because:
1. I'm not up-to-date with the situation;
2. I've seen mention that others here are filing bug reports;
3. I don't use non-free anyway;
4. there's already working java in main; and
5. I think those responsible are personally at risk, not debian's property.

This seems another topic that the DPL is inflaming unnecessarily. It's
a shame voters didn't believe those who pointed out that #debian-tech
rules are a conflict-creation system, not a conflict-resolution one.

[...]
 Sun have made it very clear that they're trying to work with us on this
 for something that benefits our users, so that just leaves it to us
 to decide what's more important: taking a principled stand that we'll
 read every license literally and pedantically; or take advantage of
 other means by which we can be confident in distributing the software,
 and in so doing build a relationship with Sun that can be used later,
 and improve the experience of using Debian for people who need Sun Java?

I know that you are confident in distributing the software under those
terms, but it looks to me like most of -legal would have picked a third
way: keep negotiating and wait for terms in which they are confident.
I'd call that prudence and good practice, not pedantry or obstruction.

 [...] In this case, Sun have already
 gone to the effort of looking through Debian's procedures and started
 participating on the -legal list; -legal meanwhile have been obstructive
 in trying to tell Sun what their license means, even when that contradicts
 what Sun understands their license to mean as documented in their FAQ,
 and verified by their lawyers.

-legal seems to have believed what Sun says their license means, namely
   It supersedes all prior or contemporaneous
oral or written communications, proposals, representations and
warranties and prevails over any conflicting or additional terms
of any quote, order, acknowledgment, or other communication
between the parties relating to its subject matter during the term
of this Agreement.
So, I don't think any reasonable person would prefer Sun's FAQ or emails
when they aren't clearly explaining particular terms in an obvious way.
If someone seems to say both X is entirely black and X is entirely
white then one has to look for some way to decide, such as the above.

Is there even any dispute that the DLJ indemnity seeks to overturn all
the no warranty statements in debian and leave the licensee liable
for the effects of everything in our operating system?

 [...] One of the simplest
 objections is that the free software community just aren't an interesting
 market for Java people -- we don't want Java, so why spend effort giving
 it to us? [...]

That is a strawman AICM5P.  There's been java in main for some time now
and the packages show up quite well in popcon, so there seems to be some
java people interested in us and it seems to be wanted.

Hope that helps,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: Hidden files

2006-06-06 Thread Ron Johnson

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joey Hess wrote:
 Linas ?virblis wrote:
 Let us imagine someone decides to introduce package X that contains a
 lot of files (let us say 50) in /usr/lib and half of them are dot
 files. And what about shipping hidden directories? Would such packages
 be accepted into Debian?
 
 I've had packages in Debian with more dotfiles than that in /usr/lib
 (although only perhaps 5% of the total file count).

Just my humble opinion, but hidden system files just smacks of the
Sony DRM rootkit debacle.

Just as /etc/bashrc is not hidden, whereas ~/.bashrc is, *why*
should any *system* files be hidden?

Nevertheless, IMO these changes and arguments should be made upstream.

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is common sense really valid?
For example, it is common sense to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that common sense is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEhgOjS9HxQb37XmcRAtHKAKClkbZqmJtuVoCGatf6GVEyAYmvIgCfcZaQ
n9GUEECNl3fPr+YzF60mcfY=
=aqY5
-END PGP SIGNATURE-


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

Re: Sun Java available from non-free

2006-06-06 Thread Ron Johnson

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

MJ Ray wrote:
 Anthony Towns aj@azure.humbug.org.au [...]
[snip]
 4. there's already working java in main; and

Partly/somewhat/mostly working.

- --
Ron Johnson, Jr.
Jefferson LA  USA

Is common sense really valid?
For example, it is common sense to white-power racists that
whites are superior to blacks, and that those with brown skins
are mud people.
However, that common sense is obviously wrong.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEhgQZS9HxQb37XmcRAvFaAKDC2niBaDpsJbiwvX0QA9utJhcQSACfe28j
cMK8+C6xO+LJMurbMbuiUDE=
=xO9I
-END PGP SIGNATURE-


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

Re: Hidden files

2006-06-06 Thread Roger Leigh

Ron Johnson [EMAIL PROTECTED] writes:

 Joey Hess wrote:
 Linas ?virblis wrote:
 Let us imagine someone decides to introduce package X that contains a
 lot of files (let us say 50) in /usr/lib and half of them are dot
 files. And what about shipping hidden directories? Would such packages
 be accepted into Debian?
 
 I've had packages in Debian with more dotfiles than that in /usr/lib
 (although only perhaps 5% of the total file count).

 Just my humble opinion, but hidden system files just smacks of the
 Sony DRM rootkit debacle.

 Just as /etc/bashrc is not hidden, whereas ~/.bashrc is, *why*
 should any *system* files be hidden?

IMO dotfiles are a historical artifact which we are stuck with.  If we
were just starting today, I'm sure we would be using ~/etc/bashrc
rather than ~/.bashrc so the user's files match the standard
locations.  It's logical, simple, and would make many things easier.

While historical reasons are acceptable for users' dotfiles, I remain
to be convinced that there is a logical rationale for them in any
system location, or even anywhere under $HOME except the root.


Regards,
Roger

-- 
Roger Leigh
Printing on GNU/Linux?  http://gutenprint.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


pgpYuET3esKLa.pgp
Description: PGP signature

Re: Hidden files

2006-06-06 Thread Tyler MacDonald

Roger Leigh [EMAIL PROTECTED] wrote:
 IMO dotfiles are a historical artifact which we are stuck with.  If we
 were just starting today, I'm sure we would be using ~/etc/bashrc
 rather than ~/.bashrc so the user's files match the standard
 locations.  It's logical, simple, and would make many things easier.
 
 While historical reasons are acceptable for users' dotfiles, I remain
 to be convinced that there is a logical rationale for them in any
 system location, or even anywhere under $HOME except the root.

For most cases I agree, there's little point to it, but I don't
think they pose a real security risk either. I mean, find will reveal them
by default, and for the really security-concious, it's easy to alias ls to
ls -a. And I can see a use for them in global directories, for files that
you should not modify unless you
*really* know what you are doing.

- Tyler





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

Re: Sun Java available from non-free

2006-06-06 Thread Marco d'Itri

In linux.debian.legal MJ Ray [EMAIL PROTECTED] wrote:

The package maintainer did not ask debian-legal (serious bug) and I'm
They do not need to.

really surprised that the archive maintainers felt no need to consult
developers about this licence, in public or private, or SPI, before
agreeing to indemnify Sun so broadly.
They do not need too.

I've not actively worked on this so far because:
I fear thinking about what you could have done if you had chosen to be
more active...

4. there's already working java in main; and
I wish. (Well, actually I don't. I despise java and I am happy if it
will continue to be hard to use, but pretending that the free java
implementations are a replacement for the Sun implementation is bullshit.)

-legal seems to have believed what Sun says their license means, namely
debian-legal is just a mailing list and does not hold beliefs.

-- 
ciao,
Marco


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

Re: Sun Java available from non-free

2006-06-06 Thread Dalibor Topic

On Tue, Jun 06, 2006 at 05:39:21PM -0500, Ron Johnson wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 MJ Ray wrote:
  Anthony Towns aj@azure.humbug.org.au [...]
 [snip]
  4. there's already working java in main; and
 
 Partly/somewhat/mostly working.

That's correct: Unfortunately, we've not completely finished liberating
all free software written in Java from the proprietary runtime dependency 
[1] yet. The work is progressing steadily, as can be seen from
the API coverage list at
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html for 1.4
and http://www.object-refinery.com/classpath/statcvs/ LOC charts. We
need more Java developers to help us create the best Java runtimes 
and class library implementation as free software.

The Debian Java packagers and the respective upstreams would likely
appreciate contributions to improve the state of support for free
software written in the Java programming language on free runtimes,
such that it can be moved into the main archive.

See http://www.classpath.org for helping out with the class library, 
and see, for example, FSF's gcj at http://gcc.gnu.org/java for the
leading (35%, says popcon) free runtime. Debian also packages JamVM 
and Cacao, among other traditional free runtimes, as well as IKVM. 
Please report bugs in the class library to GNU Classpath's bug tracker, 
so that they can be fixed. If you have a chance, please consider 
contributing a patch to help make the Java application you care about
work (better).

See http://jroller.com/page/dgilbert?entry=sven_de_genius ,
http://kennke.org/blog/?p=5 and http://kennke.org/blog/?p=7 for a few
applications that are currently being liberated from dependencies on 
proprietary Java implementations.

cheers,
dalibor topic

[1] http://www.gnu.org/philosophy/java-trap.html

 
 - --
 Ron Johnson, Jr.
 Jefferson LA  USA
 
 Is common sense really valid?
 For example, it is common sense to white-power racists that
 whites are superior to blacks, and that those with brown skins
 are mud people.
 However, that common sense is obviously wrong.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.3 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iD8DBQFEhgQZS9HxQb37XmcRAvFaAKDC2niBaDpsJbiwvX0QA9utJhcQSACfe28j
 cMK8+C6xO+LJMurbMbuiUDE=
 =xO9I
 -END PGP SIGNATURE-
 
 
 -- 
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
 


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

Re: Debian Light Desktop - meta package

2006-06-06 Thread Axel Beckert

Hi!

 I'm creating a meta package for install a lite desktop for old
 machines with poor hardware.

Hey, that's a really cool idea! Debian is one of the last modern (and
not specialised) Linux distribution feasible for old and slow
hardware, especially old PCs. But Sarge already made a big step away
from old PCs (e.g. by dropping XFree86 3.3 and requiring 32 Megs of
RAM for installation -- Woody needed only 12 Megs) so I'm really happy
to see that others try to take the cudgels for Debian on old hardware
too.

I used the Slackware and kernel 2.2 based Desktop Light (DeLi) Linux
(http://www.delilinux.de/) distribution for a while on old boxes (e.g.
i486 laptops), but its package variety just sucks (the full ISO is 90
MB) and so I had to compile a lot on the boxes itself locally. (Any
Gentoo advocates here? ;-) But the package list of DeLi Linux partly
was quite well chosen (Siag Office as office tools, Dillo and Links as
browsers, etc.) and DeLi can surely give an idea of what is good for
old, low resource hardware and what isn't. (Ok, I strongly disagree in
putting PHP5 on such boxes, even only for developing purposes. ;-)

Since one of the points, why I like Debian, is its huge package
variety (so there's nearly always also a low end software for the
desired purpose) and since Woody runs fine on most of those boxes, I
was perfectly fine with that. Now since Woody runs out of security
support, I installed Sarge on a Pentium 90 with 76 MB of RAM and a 1,5
GB big but bad performing HD. I general it runs fine, but X took a
while (the graphics card is no more supported in XFree 4.x and there
no more supported in Sarge) to get it running.

That is also one of the reasons I stay with Woody as long as I can.
Another reason is GNOME 2.x. It is neither as performant as GNOME 1.x
nor is it (IMHO) as user-friendly as GNOME 1.x was. (Ok, we'll drop
the user-friendly discussion here, it just doesn't matter here. ;-)

 I would like to receive opinions about my packages list:

 - x-window-system-core
 - xfce4 (beautiful!)

That's really fine IMHO. XFCE is not as resource-hungry as GNOME or
KDE are and is easy to use. But if you just want an easy to use WM
instead of a desktop environment, I suggest the FLTK based FLWM or one
of the *box famliy window managers (and ion3 or ratpoison for the
mouse-haters).

 - gdm

Why gdm and not wdm? gdm depends on a horribly large bunch of
libraries including GNOME. wdm depends on way less libraries, looks
not as bare as xdm by default does and still is fast and easy to use.
(We use it on all our Debian workstations at the Department of Physics
at ETH Zurich.)

 - mozilla-firefox
 - mozilla-thunderbird

Those are resource-whores, too: They render their whole GUI with Gecko
instead of a widget toolkit and cost a lot of performance and memory.
You just don't want them on old hardware, it's really no fun to use
them there.

If you want a slim Gecko based web browser use Galeon, Epiphany (both
GNOME, but still faster than Firefox or Mozilla itself) or the
currently GTK based (and AFAIH planned to be FLTK based) Kazehakase --
a web browser useable for both beginners and power users (the UI and
the configuration dialog has a user level switch). Only drawback:
Kazehakase isn't really stable in Sarge. But it is in Sid (or at least
was the last time I played with it).

And then there are the real low end browsers like Dillo and the Links
family (links, links2, elinks, etc.) as well the pure text browsers as
lynx and w3m. But there you have to lower your sights regarding the
rendering quality respective rendering features (no CSS there, etc.).

 - eog

Isn't xzgv much leaner?

 - abiword
 - gnumeric

Here I would like to see Siag Office, the free low end office package
instead. But unfortunately it fell out of Debian with Sarge. It run
acceptable even on a i486 with 16 Megs of RAM.

In general I would try to not use any GNOME or KDE depended package
(and I don't say that because I like parts of Linus' statement in the
Desktop Environment War a few months ago ;-), GNOME and KDE are both
just a lot of bloat which badly slows down old boxes.

In the future, I see thre main problems for Debian on old PCs and other
old non-x86 hardware:

+ Memory requirements for installation (32 MB RAM AFAIK). The
  requirements for finally running a Sarge box are lower AFAIH.

+ The dropping of XFree86 3.3 as far as Xorg doesn't step in. XFree86
  4.x probably never will.

+ The dropping of the 2.4 kernel line: This will drop AFAIK support
  for e.g. active ISDN cards. On the other hand the new schedulers
  seem to bring better (feelable) performance, if an old box is used
  as desktop.

I'm not sure, if it really is a possibility to still support older
hardware in Debian, but if the Linux kernel 2.6 makes hassles, perhaps
Debian GNU/kFreeBSD can help. I at least plan to give it a try on some
Pentium 1 box.

In general, I think it could help to create some kind of forward
ports (e.g. packages from Woody ported to

Re: Hidden files

Roger Leigh [EMAIL PROTECTED] writes:

 While historical reasons are acceptable for users' dotfiles, I remain to
 be convinced that there is a logical rationale for them in any system
 location, or even anywhere under $HOME except the root.

It's way too much of a pain to modify upstream code that uses files
beginning with '.' for reasons that are essentially cosmetic.

Passing along the request to upstream makes perfect sense.  I would
recommend using _ instead of . if they want to put the file into a clearly
separate namespace.  But if upstream doesn't bite, I'd say that this is
the sort of divergence and maintenance burden that Debian really doesn't
need.  The advantages are not compelling enough, IMO.

-- 
Russ Allbery ([EMAIL PROTECTED])   http://www.eyrie.org/~eagle/


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

Re: Sun Java available from non-free

On Tue, Jun 06, 2006 at 11:34:10PM +0100, MJ Ray wrote:
 Anthony Towns aj@azure.humbug.org.au [...]
  And people are welcome to hold that opinion and speak about it all they
  like, but the way Debian makes the actual call on whether a license
  is suitable for distribution in non-free isn't based on who shouts the
  loudest on a mailing list, it's on the views of the archive maintainers.
 The package maintainer did not ask debian-legal (serious bug) 

That's mistaken. debian-legal is a useful source of advice, not a
decision making body. That's precisely as it should be, since there
is absolutely no accountability for anyone on debian-legal -- anyone,
developer or not, who agrees with the social contract or not, can reply
to queries raised on this list with their own opinion. If people have
weighed the costs and benefits of contacting -legal and decided not to,
that's entirely their choice.

 and I'm
 really surprised that the archive maintainers felt no need to consult
 developers about this licence, in public or private, or SPI, before
 agreeing to indemnify Sun so broadly.

We do not indemnify Sun for any actions Sun takes.

 I know that you are confident in distributing the software under those
 terms, but it looks to me like most of -legal would have picked a third
 way: keep negotiating and wait for terms in which they are confident.

As far as I've seen most of -legal would have taken the same attitude
you have -- there's already working java in main, I don't use non-free
anyway, found a few token problems and stopped helping Sun at all.

Fortunately, that's fine, since -legal is only a useful place to consult,
not the only way Debian can deal with people who want to make their
software available to Debian users.

 So, I don't think any reasonable person would prefer Sun's FAQ or emails
 when they aren't clearly explaining particular terms in an obvious way.

If you want to dismiss the people who disagree with you, including
myself, as unreasonable, then there's not really any point having this
conversation.

 Is there even any dispute that the DLJ indemnity seeks to overturn all
 the no warranty statements in debian and leave the licensee liable
 for the effects of everything in our operating system?

If you're actually claiming that's what it does, then I guess there is.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Who can make binding legal agreements

On Tue, Jun 06, 2006 at 11:47:03AM -0500, John Goerzen wrote:
 I am becoming increasingly concerned at the unilateral method in which
 you and/or the archive maintainers have taken this decision.
 
 The ability to enter into a legal contract to indemnify a third party
 should be, and arguably IS, reserved solely for the SPI Board of
 Directors.  

If SPI wish to withdraw from their relationship with Debian, then that's
entirely possible to arrange. I don't think it's at all proper that you
try to obtain veto power of Debian's activities as conducted by the duly
authorised members of that organisation.

 SPI projects shouldn't be taking advice from Sun's attorneys.  

Debian's relationship with SPI is as a helpful legal entity that allows
us to act in ways we would not be able to do so without it, not as Debian's
governing body.

 And I know you would like me to just go away and shut up about this, but
 this project is too important, and this action has too many unknowns at
 this stage, to just put blind faith in Sun's lawyers doing the right
 thing by Debian.

That would be a fair comment if it was actually what had happened. It's
not.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Who can make binding legal agreements

On Wed, Jun 07, 2006 at 12:02:16PM +1000, Anthony Towns wrote:
  The ability to enter into a legal contract to indemnify a third party
  should be, and arguably IS, reserved solely for the SPI Board of
  Directors.  
 
 If SPI wish to withdraw from their relationship with Debian, then that's
 entirely possible to arrange. I don't think it's at all proper that you

Nobody was suggesting that, and I fail to understand why it is in
anyone's interests for you to ratchet up the heat on this issue
another notch by making remarks like that.

 try to obtain veto power of Debian's activities as conducted by the duly
 authorised members of that organisation.

First, I don't believe that SPI has ever granted anyone the ability to
enter into legally-binding agreements to indemnify (which means to use
our resources to defend) third parties.  I may be mistaken, though.
Could you please point out where you believe you derive this ability?

Secondly, I am saying that you should have contacted SPI *first*, so
we could get advice from our attorney, and enter into agreements
properly.

  SPI projects shouldn't be taking advice from Sun's attorneys.  
 
 Debian's relationship with SPI is as a helpful legal entity that allows
 us to act in ways we would not be able to do so without it, not as Debian's
 governing body.

And Debian is not SPI's governing body.  Debian is not a legal entity
on its own (after all, that's why SPI was created).  If a legal entity
must enter into an agreement on behalf of Debian, that legal entity is
SPI.  No SPI member project is authorized to make contractual
arrangements like this on behalf of the whole organization, and thus
potentially harm not just their own project but also SPI and other
member projects.

Please re-read section 9 of the Debian constitution and the bylaws of
SPI.

So I ask again: where do you derive your authority to enter into a
legal obligation to indemnify Sun in this situation, and what legal
entity do you believe is bound to honor that obligation?

-- John


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

Re: Who can make binding legal agreements

John Goerzen [EMAIL PROTECTED] writes:

 First, I don't believe that SPI has ever granted anyone the ability to
 enter into legally-binding agreements to indemnify (which means to use
 our resources to defend) third parties.  I may be mistaken, though.
 Could you please point out where you believe you derive this ability?

I think I lost a thread of the argument here.  How does the acceptance
into non-free of a package by the ftp-masters commit SPI to a
legally binding agreement?

To start with, acceptance of a package is not signing a contract.  You
cannot be forced into a contract.  You can be in violation of the license
terms, in which case it may not be legal for you to distribute the
package, but it's a bit of a leap from that to legal indemnification.

But even setting aside the questionable assumption that the license could
actually create this situation, I think I missed where the Debian
ftp-masters are legal agents of SPI and are in any way capable of
committing SPI to any sort of binding contract.  We had this discussion
all the way back at the beginning of this thread, and I've yet to see how
the actions of the ftp-masters create any legal jeopardy for anyone other
than themselves and possibly non-free mirrors.

How does legal liability for SPI enter into this picture?  I'm confused.

 And Debian is not SPI's governing body.  Debian is not a legal entity on
 its own (after all, that's why SPI was created).  If a legal entity must
 enter into an agreement on behalf of Debian, that legal entity is SPI.
 No SPI member project is authorized to make contractual arrangements
 like this on behalf of the whole organization, and thus potentially harm
 not just their own project but also SPI and other member projects.

Which would imply that no legal agreement has been entered into on behalf
of Debian, yes?  If SPI is the only body who can do that, and SPI has not
delegated that authority to anyone who took an action in this situation,
problem solved, no?

The advice to check with SPI's lawyers I *do* agree with.  I think it
would be excellent if they were involved, and I think it would be an
excellent idea to involve them even now.  If nothing else, I expect that
would neatly cut through the uncertainty and legal speculation and provide
a real opinion on the license.

-- 
Russ Allbery ([EMAIL PROTECTED])   http://www.eyrie.org/~eagle/


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

Re: Who can make binding legal agreements

On Tue, Jun 06, 2006 at 07:43:10PM -0700, Russ Allbery wrote:
 John Goerzen [EMAIL PROTECTED] writes:
 
  First, I don't believe that SPI has ever granted anyone the ability to
  enter into legally-binding agreements to indemnify (which means to use
  our resources to defend) third parties.  I may be mistaken, though.
  Could you please point out where you believe you derive this ability?
 
 I think I lost a thread of the argument here.  How does the acceptance
 into non-free of a package by the ftp-masters commit SPI to a
 legally binding agreement?

The first paragraph of the license linked to by the original
announcement:

SUN MICROSYSTEMS, INC. (SUN) IS WILLING TO LICENSE THE JAVA PLATFORM
STANDARD EDITION DEVELOPER KIT (JDK - THE SOFTWARE) TO YOU ONLY
UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS
LICENSE AGREEMENT (THE AGREEMENT).  PLEASE READ THE AGREEMENT
CAREFULLY.  BY INSTALLING, USING, OR DISTRIBUTING THIS SOFTWARE, YOU
ACCEPT ALL OF THE TERMS OF THE AGREEMENT.

I'd say we pretty clearly are distributing the software.  

The indemnification clause is under section 2, and reads, in part: 

You agree to defend and indemnify Sun
and its licensors from and against any damages, costs, liabilities,
settlement amounts and/or expenses (including attorneys' fees)
incurred in connection with any claim, lawsuit or action by any
third party that arises or results from (i) the use or distribution
of your Operating System, or any part thereof, in any manner, or
(ii) your use or distribution of the Software in violation of the
terms of this Agreement or applicable law.  
  
Both from http://download.java.net/dlj/DLJ-v1.1.txt

 But even setting aside the questionable assumption that the license could
 actually create this situation, I think I missed where the Debian
 ftp-masters are legal agents of SPI and are in any way capable of
 committing SPI to any sort of binding contract.  We had this discussion

Exactly correct, and my point exactly.

It seems that we've got one of two pretty bad situations:

1) That the ftp-masters somehow do have legal authority to do this,
   and have just bound SPI to indemnify Sun without SPI even realizing
   it

2) That the ftp-masters lack the legal authority to do this, in which
   case Debian (and by extension, SPI) is in violation of the Sun
   copyright on Java by distributing it outside the terms of a valid,
   in-force license

 all the way back at the beginning of this thread, and I've yet to see how
 the actions of the ftp-masters create any legal jeopardy for anyone other
 than themselves and possibly non-free mirrors.

If Debian is violating a license, what is the target for a copyright
holder lawsuit?

Perhaps it is the individual ftp-masters, but I don't think that SPI
is very far removed from this picture.  And of course, if you're some
MegaCorp, you could just sue everyone in sight, just to be sure.

 How does legal liability for SPI enter into this picture?  I'm
 confused.

Does the above help explain a bit?

  And Debian is not SPI's governing body.  Debian is not a legal entity on
  its own (after all, that's why SPI was created).  If a legal entity must
  enter into an agreement on behalf of Debian, that legal entity is SPI.
  No SPI member project is authorized to make contractual arrangements
  like this on behalf of the whole organization, and thus potentially harm
  not just their own project but also SPI and other member projects.
 
 Which would imply that no legal agreement has been entered into on behalf
 of Debian, yes?  If SPI is the only body who can do that, and SPI has not
 delegated that authority to anyone who took an action in this situation,
 problem solved, no?

Nope, because now we are in the situation of Debian illegally
distributing software.

 The advice to check with SPI's lawyers I *do* agree with.  I think it
 would be excellent if they were involved, and I think it would be an
 excellent idea to involve them even now.  If nothing else, I expect that
 would neatly cut through the uncertainty and legal speculation and provide
 a real opinion on the license.

I would be very pleased if someone from Debian would like to post a
useful summary, with links, to spi-board (or whatever list is
apporpriate that Gregory reads).  

If Gregory thinks it is all sane, I wouldn't have a problem with it
going forward from SPI's point of view.

Though I do still maintain that the proper thing to do would be to
have brought SPI into the loop to begin with.

-- John


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

Re: Who can make binding legal agreements

John Goerzen [EMAIL PROTECTED] writes:
 On Tue, Jun 06, 2006 at 07:43:10PM -0700, Russ Allbery wrote:

 I think I lost a thread of the argument here.  How does the acceptance
 into non-free of a package by the ftp-masters commit SPI to a legally
 binding agreement?

 The first paragraph of the license linked to by the original
 announcement:

 SUN MICROSYSTEMS, INC. (SUN) IS WILLING TO LICENSE THE JAVA PLATFORM
 STANDARD EDITION DEVELOPER KIT (JDK - THE SOFTWARE) TO YOU ONLY
 UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS
 LICENSE AGREEMENT (THE AGREEMENT).  PLEASE READ THE AGREEMENT
 CAREFULLY.  BY INSTALLING, USING, OR DISTRIBUTING THIS SOFTWARE, YOU
 ACCEPT ALL OF THE TERMS OF THE AGREEMENT.

 I'd say we pretty clearly are distributing the software.  

You believe that it's pretty clear that *SPI* is distributing the
software?  Could you trace your reasoning here?

 It seems that we've got one of two pretty bad situations:

 1) That the ftp-masters somehow do have legal authority to do this,
and have just bound SPI to indemnify Sun without SPI even realizing
it

 2) That the ftp-masters lack the legal authority to do this, in which
case Debian (and by extension, SPI) is in violation of the Sun
copyright on Java by distributing it outside the terms of a valid,
in-force license

I and several other people have been saying for some time on this thread
that the actual situation is:

 3) SPI has no legal liability for the actions of the ftp-masters.  That
legal liability is born by the ftp-masters themselves and possibly
by the mirror operators who carry the software in question.

I still haven't seen anything that changes my opinion there.  Now, if I
were the ftp-masters, I'd be very uncomfortable with that and would really
prefer to have a liability shield for my actions, but that's really up to
them.

 If Debian is violating a license, what is the target for a copyright
 holder lawsuit?

*Debian* does not exist as an entity, which means that the only legitimate
legal target for such a lawsuit would be the legal entity that performed
the action.  Given, as you have said, the ftp-masters are not officers of
SPI or acting on behalf of SPI, it seems pretty clear that the buck would
stop with them.

 Perhaps it is the individual ftp-masters, but I don't think that SPI is
 very far removed from this picture.  And of course, if you're some
 MegaCorp, you could just sue everyone in sight, just to be sure.

Well, yes, but they can do that no matter what anyone did.  I'm not sure
the ability to target lawsuits at random entities not actually involved is
a persuasive argument for any position.

 Nope, because now we are in the situation of Debian illegally
 distributing software.

*Debian* does not legally exist, and therefore cannot possibly be
illegally distributing software.

-- 
Russ Allbery ([EMAIL PROTECTED])   http://www.eyrie.org/~eagle/


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

Re: Who can make binding legal agreements

2006-06-06 Thread George Danchev

On Wednesday 07 June 2006 06:11, Russ Allbery wrote:
 John Goerzen [EMAIL PROTECTED] writes:
  On Tue, Jun 06, 2006 at 07:43:10PM -0700, Russ Allbery wrote:
  I think I lost a thread of the argument here.  How does the acceptance
  into non-free of a package by the ftp-masters commit SPI to a legally
  binding agreement?
 
  The first paragraph of the license linked to by the original
  announcement:
 
  SUN MICROSYSTEMS, INC. (SUN) IS WILLING TO LICENSE THE JAVA PLATFORM
  STANDARD EDITION DEVELOPER KIT (JDK - THE SOFTWARE) TO YOU ONLY
  UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS
  LICENSE AGREEMENT (THE AGREEMENT).  PLEASE READ THE AGREEMENT
  CAREFULLY.  BY INSTALLING, USING, OR DISTRIBUTING THIS SOFTWARE, YOU
  ACCEPT ALL OF THE TERMS OF THE AGREEMENT.
 
  I'd say we pretty clearly are distributing the software.

 You believe that it's pretty clear that *SPI* is distributing the
 software?  Could you trace your reasoning here?

Nobody said that and you know it.

  Nope, because now we are in the situation of Debian illegally
  distributing software.

 *Debian* does not legally exist, and therefore cannot possibly be
 illegally distributing software.

I'm sorry, but that's really a poor agrument to stand after. Physically Debian 
distributes that software and some is found to be illigally distributed or 
the indemnify clause could be triggered in any way, then ligal actions could 
be performed against your options are, you guess:

* the persons who actually put it there - no assets, so of no any interest for 
them
* the first legal entity behind Debian having assests to indemnify them

p.s. remember SCO vs. IBM, not vs. single persons with no big assets to 
provide.

-- 
pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: Who can make binding legal agreements

George Danchev [EMAIL PROTECTED] writes:
 On Wednesday 07 June 2006 06:11, Russ Allbery wrote:

 You believe that it's pretty clear that *SPI* is distributing the
 software?  Could you trace your reasoning here?

 Nobody said that and you know it.

Uh, well, believe it or not, that really did seem to me to be what John
Goerzen was worried about.  It looked to me like he was concerned that SPI
was legally involved in this situation and had legal responsibility for
the distribution, and I don't see how that possibly could be the case.

 *Debian* does not legally exist, and therefore cannot possibly be
 illegally distributing software.

 I'm sorry, but that's really a poor agrument to stand after.

That's not an argument, it's an observation of fact.  My argument can be
found elsewhere in this thread and basically amounts to I think y'all are
making a mountain out of a molehill, but more importantly, it's not my job
to decide and as a Debian developer I think allowing people to do the jobs
they're responsible for is important.

Certainly given the controversy, I think it would be a smart move for the
ftp-masters to see if they can avail themselves of the legal opinion of
SPI counsel if for no other reason than that it's about the only thing
that stands a chance of stopping this extended thread.

 Physically Debian distributes that software and some is found to be
 illigally distributed or the indemnify clause could be triggered in any
 way, then ligal actions could be performed against your options are,
 you guess:

 * the persons who actually put it there - no assets, so of no any
 interest for them
 * the first legal entity behind Debian having assests to indemnify them

 p.s. remember SCO vs. IBM, not vs. single persons with no big assets to 
 provide.

SPI isn't exactly floating in money either.  If you're going to bring up
SCO vs. IBM scenarios, the entity sued would almost certainly be one of
the mirror providers with a corporate entity behind them, or an involved
DD who could be said to be working under the aegis of their corporate job.
(Like, say, suing Stanford for my work on AFS or Kerberos packages, since
some of my work on Debian is for my job with Stanford.  And indeed,
Stanford has liability insurance for things like that, I believe.)

However, I don't think we get very far trying to avoid taking any action
that might result in someone like SCO suing someone who works on Debian.
We end up with contorted logic and bizarre restrictions and then people
get sued anyway because SCO is after public relations, not a winnable
legal case.

-- 
Russ Allbery ([EMAIL PROTECTED])   http://www.eyrie.org/~eagle/


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

Re: Who can make binding legal agreements

On Tue, Jun 06, 2006 at 08:11:21PM -0700, Russ Allbery wrote:
 John Goerzen [EMAIL PROTECTED] writes:
  On Tue, Jun 06, 2006 at 07:43:10PM -0700, Russ Allbery wrote:
 
  SUN MICROSYSTEMS, INC. (SUN) IS WILLING TO LICENSE THE JAVA PLATFORM
  STANDARD EDITION DEVELOPER KIT (JDK - THE SOFTWARE) TO YOU ONLY
  UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS
  LICENSE AGREEMENT (THE AGREEMENT).  PLEASE READ THE AGREEMENT
  CAREFULLY.  BY INSTALLING, USING, OR DISTRIBUTING THIS SOFTWARE, YOU
  ACCEPT ALL OF THE TERMS OF THE AGREEMENT.
 
  I'd say we pretty clearly are distributing the software.  
 
 You believe that it's pretty clear that *SPI* is distributing the
 software?  Could you trace your reasoning here?

Sure.  SPI owns many of the machines that Debian owns.  If any of
these machines are being used to distribute this software, as I think
is likely, then SPI could be liable.

Not only that, but while the Debian constitution says that Debian
developers are not agents of SPI, and SPI (and I) agree with that, I'm
not so sure the line would be that clear to a court.  But maybe it
would, I don't know.

 I and several other people have been saying for some time on this thread
 that the actual situation is:
 
  3) SPI has no legal liability for the actions of the ftp-masters.  That
 legal liability is born by the ftp-masters themselves and possibly
 by the mirror operators who carry the software in question.

Well, the ftp-masters probably do have a liability, but as an entity
involved in distributing the software -- even if distributing them to
mirrors -- I wouldn't be too hesitant to rule SPI out of this picture.

  If Debian is violating a license, what is the target for a copyright
  holder lawsuit?
 
 *Debian* does not exist as an entity, which means that the only legitimate
 legal target for such a lawsuit would be the legal entity that performed
 the action.  Given, as you have said, the ftp-masters are not officers of
 SPI or acting on behalf of SPI, it seems pretty clear that the buck would
 stop with them.

The argument I fear is that Debian is a member project of SPI, and SPI
handles Debian's assets, and that the problem is with Debian,
therefore Debian's assets as held by SPI could be ripe for taking by
lawsuit.

But I understand your reasoning as well.

  Perhaps it is the individual ftp-masters, but I don't think that SPI is
  very far removed from this picture.  And of course, if you're some
  MegaCorp, you could just sue everyone in sight, just to be sure.
 
 Well, yes, but they can do that no matter what anyone did.  I'm not sure
 the ability to target lawsuits at random entities not actually involved is
 a persuasive argument for any position.

True enough.  I just would want to give people as little grounds for
any lawsuit as possible.

  Nope, because now we are in the situation of Debian illegally
  distributing software.
 
 *Debian* does not legally exist, and therefore cannot possibly be
 illegally distributing software.

Should I say Debian, Project of SPI here to keep us out of obscure
philosophy? ;-)

I can see what you're saying.  I fear that a line is not so clear to a
court or to an plantiff, and even an unsuccessful suit against SPI
could cause a good deal of damage.  I'd rather err on the side of
caution and not give anyone the opening, unless SPI's attorney
believes the license as-is is safe.

I believe that there is room for concern (the concerns that I've
voiced).  I don't know whether or not these concerns really have
merit.  But then, nobody else here does (as far as I know, no real
lawyer has chimed in here.)

This is the reason we run things by our attorney -- because he knows
about them better than we do, and can give us solid advice.  And, I
think, the reason it would have been good to run this by our attorney
before posting it online.

-- John


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

Re: Who can make binding legal agreements

John Goerzen [EMAIL PROTECTED] writes:

 Sure.  SPI owns many of the machines that Debian owns.  If any of these
 machines are being used to distribute this software, as I think is
 likely, then SPI could be liable.

Oh, very good point.  I hadn't thought of this.

 I can see what you're saying.

Thank you.  And I think I also see what you're saying; I snipped a lot of
it, just because I didn't have any further comment, but I think I
understand your concern much better now.  If that license requirement
really does have teeth and is invoked by someone, I can see how SPI may
get sucked in through a stronger chain than just sue anyone in sight.

 I fear that a line is not so clear to a court or to an plantiff, and
 even an unsuccessful suit against SPI could cause a good deal of damage.

This, alas, is certainly true.  It's true for a lot of free software,
which means that even if we feel like we have a strong legal case, there's
always a weighing of risk in doing anything that might conceivably spark a
lawsuit.

 I'd rather err on the side of caution and not give anyone the opening,
 unless SPI's attorney believes the license as-is is safe.

 I believe that there is room for concern (the concerns that I've
 voiced).  I don't know whether or not these concerns really have merit.
 But then, nobody else here does (as far as I know, no real lawyer has
 chimed in here.)

 This is the reason we run things by our attorney -- because he knows
 about them better than we do, and can give us solid advice.  And, I
 think, the reason it would have been good to run this by our attorney
 before posting it online.

I think these are all very reasonable statements.  Not being an
ftp-master, it's not really my decision to make, but my personal opinion
is that the above is good advice and the closer we can make the
relationship between SPI's lawyer and the ftp-master evaluation of
questionable licensing, the less I'll worry about weird license clauses
and questionable provisions.

-- 
Russ Allbery ([EMAIL PROTECTED])   http://www.eyrie.org/~eagle/


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

Re: Who can make binding legal agreements