* WARNING: Crypto software to be included into main Debian distribution

[jose]

  I don't know what the right list to bring this issue up is, so I write to all 
three lists to get to the right people. 
  
  Here are my views on the crypto on main subject.
  
  I suppose there has been debate on this subject before on other debian lists, 
but as I'm not subscribed to more than 3 and have no idea on where/when it may 
have sprung...

  My view is that by including crypto on main, and dissapearing it from non-us, 
the silly regulations from the US goverment are imposed on the US emargoed 
countries in an anti ethical way for two reasons:
1. Software in non-us was not developed inside the US and should not be 
restricted to 'export'  into other countries.
2. As I understand, the Free Software definition does not apply any sort of 
exception to US embargoed countries.

  So, either the Free Sofware definition gets reviewed and appends a clause 
stating that free software is 'free except in US embargoed countries', or 
Debian should stop saying it is Free software. Period.

  Restricting redistribution to a given country is in my opinion a blatant 
violation of the GPL which states that no further restrictions should be 
imposed on the software covered by it.

  There may be a third option which would be to move the main distribution 
servers of Debian outside the US (they are all within the US right now, aren't 
they?).

  I understand that this issue may not be easy to digest/understand for many US 
citizens, but Debian being an international effort, it seems shameful to me 
that it gets 'tainted' with this political play of embargos, which have nothing 
to do with the nature of Free Software and the Internet spirit of sharing and 
cooperating.

  I'd love to hear some input on this from people outside as well as inside the 
US.

  Greets.

 Jose

---
Instituto Tecnologico y de Estudios Superiores de Occidente
Guadalajara, Jalisco. Mexico.

Bug#96597: changing policy requirements for debian native packages to _MUST_

[Julian Gilbey]

On Sun, Mar 03, 2002 at 11:28:55PM -0500, Andres Salomon wrote:
> dh_installchangelogs (debhelper-3.4.11) currently bails if one attempts
> to install a non-debian changelog to
> /usr/share/doc//changelog.gz in a debian-native package.  Joey
> Hess has mentioned that various tools expect the changelog.gz for
> debian-native packages to parsable as debian-style changelogs.  Given

Such as?

Also, are you also installing a changelog.Debian.gz in the same
package?

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer
  Queen Mary, Univ. of London see http://people.debian.org/~jdg/
   http://www.maths.qmul.ac.uk/~jdg/   or http://www.debian.org/
Visit http://www.thehungersite.com/ to help feed the hungry

Re: * WARNING: Crypto software to be included into main Debian distribution

[Stephen Ryan]

On Mon, 2002-03-04 at 03:09, [EMAIL PROTECTED] wrote:
> 
>   I don't know what the right list to bring this issue up is, so I
> write to all three lists to get to the right people. 
>   
>   Here are my views on the crypto on main subject.
>   
>   I suppose there has been debate on this subject before on other
> debian lists, but as I'm not subscribed to more than 3 and have no
> idea on where/when it may have sprung...
> 
>   My view is that by including crypto on main, and dissapearing it
> from non-us, the silly regulations from the US goverment are imposed
> on the US emargoed countries in an anti ethical way for two reasons:

Actually, this has absolutely *nothing* to do with crypto.  The trade
embargo is (at least for some countries) total, meaning that *nothing*
may be exported to those countries or imported from those countries. 
Not "gcc".  Not even "hello".  NOTHING.  NADA.  ABSOLUTELY NOTHING.  So
the problem arises if you have (supposedly) Free Software on a public
Internet site and the United States involved in any way whatsoever.  

The US embargo may be anti ethical, but it applies regardless.

> 1. Software in non-us was not developed inside the US

Not always.  e.g. Kerberos and PGP were both developed inside the US,
legally exported and are now available outside the US and can be
imported back in.  Kerberos is Free, PGP is not (replaced by GPG which
is Free).

> and should not be restricted to 'export'  into other countries.

It isn't.  It just may not be exported FROM the US (and maybe other
countries; people who live in other countries need to be aware of the
local laws in their countries, and abide by them just as much as people
who live in the US need to be aware of the laws in the US and abide by
them).

> 2. As I understand, the Free Software definition does not apply
> any sort of exception to US embargoed countries.
> 
>   So, either the Free Sofware definition gets reviewed and appends
> a clause stating that free software is 'free except in US embargoed
> countries', or Debian should stop saying it is Free software. Period.

Nothing in the Free Software definition (or the GPL) requires anyone to
violate local law in the process.  The worst thing that happens (in the
case of irreconcilable contradiction) is that you may not distribute the
software at all.  Nothing - I repeat, absolutely nothing, in either the
Free Software definition or the DFSG or any of the licenses involved,
requires me to distribute the software to *anyone*.  It only states what
must happen *if* and when I do distribute the software.  If local law
requires that I not distribute the software to certain persons, then I
am in violation of that law should I do so and I should rightly expect
to have the local law enforcement officials coming to bust my ass if I
break that law.

A friendly reminder that you should not break the law, and a few steps
to make sure that I do not break the law, does not make the software not
Free.  Free Software does not mean "scofflaw" - if the developers of
Free Software really were scofflaws, then none of us would bother
writing Free Software at all - we'd just pirate proprietary software
instead ["we" in a very loose sense of the word, since my personal Free
Software contributions are still quite small].  But we don't, because
that would be a violation of copyright law.  

>   Restricting redistribution to a given country is in my opinion a blatant 
> violation of the GPL which states that no further restrictions should be 
> imposed on the software covered by it.

Actually, no.  Read section 8 of the GPL, which explicitly *includes*
such a clause.

>   There may be a third option which would be to move the main distribution 
> servers of Debian outside the US (they are all within the US right now, 
> aren't they?).

Nice idea in theory.  Some of the folks I work with have a map which
shows worldwide backbone bandwidth.  If you cut the US out, you cut out
something between 75% and 90% of world-wide Internet bandwidth;
furthermore, those servers are donated; you'd have to find equivalent,
also donated servers outside the US in order to do that.  Servers and
bandwidth ain't cheap, but if you do find some, I'm sure the Debian
project would be pleased to accept.  You'd also have to find developers
outside the US to replace all those inside the US, since (as others have
already observed) the act of uploading something to a site known to
export to an embargoed country could be interpreted as a knowing act of
export to that country, and therefore a chargeable offense under US
law.  Your proposal would just make it more likely that all US
developers would have to quit, since every upload would be an export.
-- 
Stephen Ryan
Technology Coordinator
Center for Educational Outcomes at Dartmouth College

Re: * WARNING: Crypto software to be included into main Debian distribution

[Thomas Bushnell, BSG]

[EMAIL PROTECTED] writes:

> 1. Software in non-us was not developed inside the US and should
> not be restricted to 'export'  into other countries.

Lots of stuff in non-us was developed in the US.

Bug#96597: changing policy requirements for debian native packages to _MUST_

[Chris Waters]

On Sun, Mar 03, 2002 at 11:28:55PM -0500, Andres Salomon wrote:
> dh_installchangelogs (debhelper-3.4.11) currently bails if one attempts
> to install a non-debian changelog to
> /usr/share/doc//changelog.gz in a debian-native package.

Ok.  I think maybe that's a bug, but I'm willing to be proven wrong.

> Joey Hess has mentioned that various tools expect the changelog.gz
> for debian-native packages to parsable as debian-style changelogs.

What tools?  I would definitely say that any such tool has a bug.

> Given this expectation, one of two things should be done; either
> policy should be changed to explicitly allow multiple changelogs for
> debian-native packages, or explicitly disallow more than 1.

"Given this expectation", sure, but I *don't* give that expectation.
If changelog.Debian.gz exists, that should be considered the Debian
changelog.  If it doesn't, then changelog.gz should be considered the
Debian changelog.  A tool which doesn't work this way should be
considered broken, IMO.

> The current interpretation of it (section 13.8), for debian-native
> packages, reads as "if the package only has 1 changelog, put it in
> changelog.gz".

That seems reasonable, and meets my definition above (there's no
changelog.Debian.gz, so changelog.gz is the Debian changelog).  Note
that any Debian package _must_ have a Debian changelog, so, if there's
only one changelog, it must be the Debian changelog.

>  This should be changed to something like:
> "If the package is a debian-native package, the changelog installed in
> /usr/share/doc//changelog.gz MUST be the debian changelog.

No.  Current policy seems fine to me.

> The exact quote from the current policy is:
> "If the package has only one changelog which is used both as the Debian
> changelog and the upstream one because there is no separate upstream
> maintainer then that changelog should usually be installed as
> /usr/share/doc/package/changelog.gz; if there is a separate upstream
> maintainer, but no upstream changelog, then the Debian changelog should
> still be called changelog.Debian.gz."

Frankly, as far as I'm concerned, if something is a Debian-native
package, it should only have one changelog.  If there's any reason for
maintaining two, then that probably counts as sufficient justification
for NOT creating a Debian-native package!  A proposal which made this
into policy might have my support.  The current proposal does not.

In other words, I doubt if I approve of what you seem to be trying to
do in the first place.  Although, without more details, it's hard to
be sure.

In any case, the argument for the current proposal seems to be that
existing tools make assumptions that do not match what policy says.
Unless and until an effort to fix those tools fails, I think we should
leave policy as it stands.  Especially since policy has been frozen
for months now.

So, I guess I have two questions: 1. What are these tools that joeyh
refers to, and why can't they be fixed?  2. Why the heck are you
trying to make a Debian-native package with two changelogs?  Without
reasonable answers to both of these questions, I'm afraid I'll have to
oppose the proposal.

cheers
-- 
Chris Waters   |  Pneumonoultra-osis is too long
[EMAIL PROTECTED]   |  microscopicsilico-to fit into a single
or [EMAIL PROTECTED] |  volcaniconi-  standalone haiku

Bug#96597: changing policy requirements for debian native packages to _MUST_

[Andres Salomon]

On Mon, Mar 04, 2002 at 03:21:39PM -0800, Chris Waters wrote:
> 
> On Sun, Mar 03, 2002 at 11:28:55PM -0500, Andres Salomon wrote:
> > dh_installchangelogs (debhelper-3.4.11) currently bails if one attempts
> > to install a non-debian changelog to
> > /usr/share/doc//changelog.gz in a debian-native package.
> 
> Ok.  I think maybe that's a bug, but I'm willing to be proven wrong.

I'm not sure.  It would be nice if it _was_ a bug; make my life easier
as an upstream debian package maintainer..

> 
> > Joey Hess has mentioned that various tools expect the changelog.gz
> > for debian-native packages to parsable as debian-style changelogs.
> 
> What tools?  I would definitely say that any such tool has a bug.

You'll have to ask him, I don't remember him giving any examples.  Joey?

> 
> > Given this expectation, one of two things should be done; either
> > policy should be changed to explicitly allow multiple changelogs for
> > debian-native packages, or explicitly disallow more than 1.
> 
> "Given this expectation", sure, but I *don't* give that expectation.
> If changelog.Debian.gz exists, that should be considered the Debian
> changelog.  If it doesn't, then changelog.gz should be considered the
> Debian changelog.  A tool which doesn't work this way should be
> considered broken, IMO.
> 
> > The current interpretation of it (section 13.8), for debian-native
> > packages, reads as "if the package only has 1 changelog, put it in
> > changelog.gz".
> 
> That seems reasonable, and meets my definition above (there's no
> changelog.Debian.gz, so changelog.gz is the Debian changelog).  Note
> that any Debian package _must_ have a Debian changelog, so, if there's
> only one changelog, it must be the Debian changelog.
> 
> >  This should be changed to something like:
> > "If the package is a debian-native package, the changelog installed in
> > /usr/share/doc//changelog.gz MUST be the debian changelog.
> 
> No.  Current policy seems fine to me.
> 

Should be changed if it breaks tools, I mean.


> > The exact quote from the current policy is:
> > "If the package has only one changelog which is used both as the Debian
> > changelog and the upstream one because there is no separate upstream
> > maintainer then that changelog should usually be installed as
> > /usr/share/doc/package/changelog.gz; if there is a separate upstream
> > maintainer, but no upstream changelog, then the Debian changelog should
> > still be called changelog.Debian.gz."
> 
> Frankly, as far as I'm concerned, if something is a Debian-native
> package, it should only have one changelog.  If there's any reason for
> maintaining two, then that probably counts as sufficient justification
> for NOT creating a Debian-native package!  A proposal which made this
> into policy might have my support.  The current proposal does not.

Policy states that history should not be rewritten; ie, past changelog
entries should remain as they were.  What happens when maintainership of
a package moves upstream?  The old changelog entries in ./debian/changelog
have to stick around, while new changelog entries may be written to
./ChangeLog.  Or, perhaps you have a package like e2fsprogs, where there
are upstream changelogs in various directories?  In that case, it would
be only natural to give the debian subdirectory its own changelog..


> 
> In other words, I doubt if I approve of what you seem to be trying to
> do in the first place.  Although, without more details, it's hard to
> be sure.
> 
> In any case, the argument for the current proposal seems to be that
> existing tools make assumptions that do not match what policy says.
> Unless and until an effort to fix those tools fails, I think we should
> leave policy as it stands.  Especially since policy has been frozen
> for months now.
> 
> So, I guess I have two questions: 1. What are these tools that joeyh
> refers to, and why can't they be fixed?  2. Why the heck are you
> trying to make a Debian-native package with two changelogs?  Without
> reasonable answers to both of these questions, I'm afraid I'll have to
> oppose the proposal.

I've CC'd joey on this, hopefully he can clarify his earlier
statement(s).  As for #2, see above.


> 
> cheers
> -- 
> Chris Waters   |  Pneumonoultra-osis is too long
> [EMAIL PROTECTED]   |  microscopicsilico-to fit into a single
> or [EMAIL PROTECTED] |  volcaniconi-  standalone haiku
> 

-- 
"I think a lot of the basis of the open source movement comes from
  procrastinating students..."
-- Andrew Tridgell 

Bug#96597: changing policy requirements for debian native packages to _MUST_

[Joey Hess]

> > > Given this expectation, one of two things should be done; either
> > > policy should be changed to explicitly allow multiple changelogs for
> > > debian-native packages, or explicitly disallow more than 1.
> > 
> > "Given this expectation", sure, but I *don't* give that expectation.
> > If changelog.Debian.gz exists, that should be considered the Debian
> > changelog.  If it doesn't, then changelog.gz should be considered the
> > Debian changelog.  A tool which doesn't work this way should be
> > considered broken, IMO.

The method of finding a package's changelog that I had always assumed
would be used is:

if (the package is native via dpkg)
return /usr/share/doc/package/changelog.gz
else
return /usr/share/doc/package/changelog.Debian.gz

I hadn't considered searching for changelogs in the way you describe,
though it is probably more robust.

I have no idea what methods the current set of tools that search out
debian changelogs use, and I would be leery of breaking them by changing
policy, if they do happen to use the technique I'd assumed they'd use.

It looks like apt-listchanges for one does look for both changelogs, at
the expense of running dpkg-deb --fsys-tarfile twice for native
packages. Note that in this case if it could be assured of my method
working, it could be sped up since it already knows the version number
of the package.

-- 
see shy jo

Bug#96597: changing policy requirements for debian native packages to _MUST_

[Chris Waters]

On Mon, Mar 04, 2002 at 08:42:11PM -0500, Andres Salomon wrote:

> Policy states that history should not be rewritten; ie, past changelog
> entries should remain as they were.  What happens when maintainership of
> a package moves upstream?

Aargh, why should anything happen?  Is the package suddenly specific
to Debian?  And if not, why on earth should it be a Debian-native
package?

As upstream maintainer for WMRack, I document my changes in ./CHANGES.
As Debian maintainer for WMRack, I document my changes in
debian/changelog.  I see no reason to treat WMRack differently, than,
say, WMMail, for which I'm only the Debian maintainer.  Neither WMRack
nor WMMail is in any way, shape, or form, Debian-specific.  Thus,
neither one is a Debian-native package.

Is it more work for me that way?  Well, technically, yes.  I probably
spend *dozens* of seconds adding in a "new upstream release" entry in
debian/changelog after I've made a new upstream release.  I think I
can spare that many seconds.  And, if I find a debian-specific problem
(say, bad build-depends), it saves me *and everyone else* time and
trouble if I just release a new debian version, and don't bother to
release a new upstream version.  (Why should I?)  Plus, it leaves
everyone less confused.

-- 
Chris Waters   |  Pneumonoultra-osis is too long
[EMAIL PROTECTED]   |  microscopicsilico-to fit into a single
or [EMAIL PROTECTED] |  volcaniconi-  standalone haiku