[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Non-free section



Lars Wirzenius:
> Our top level directory is getting a bit big. We might want to
> re-organize the whole directory tree so that all parallel
> distributions that should work together are put into the same
> subdirectory:
> 
> 	bo/
> 		contrib/
> 		debian/
> 		non-free/
> 		non-US/

Now, _that_ looks like a good compromise to me.

> The stable and unstable symlinks at the top level would remain,
> and would point at rex/debian and bo/debian, respectively.

Maybe they should point at rex and bo, respectively?

	stable/debian/
	stable/contrib/

rather than

	stable/
	stable/../contrib/

(looks too much like a kludge to me, but how do we avoid using the
project internal code-names otherwise?)

> Note that we can't move the files at once. We would have to
> do it bit by bit, starting with the release after bo. Otherwise
> we'll kill mirror sites.

Experience shows that, just before every release, all files disappear,
mirrors delete them, and later have to fetch them again anyway :-).

As long as we don't move files around in the "stable" release, it
shouldn't be much of a problem to do that even now.  If you mirror
"unstable", you expect that to be, well, unstable...

> > - add new flags in the package control information.
> 
> Modifying dpkg for this is overkill, I think. Especially in the
> way you suggest. If we start to make detailed explanations of

Do you have better suggestions?  (That still solve the problem:
distinguish non-freely-distributable, non-freely-useable, and
non-freely-modifiable packages - all these restrictions affect
potentially different people.)

> the legal status of packages, we are going to have to be very
> precise. A certain lawer-happy country might also interpret
> this as legal counsel, which we are not allowed to give.

We would give a LONG ALL CAPS DISCLAIMER :-).  (The information here
is not guaranteed to be correct, always ask your lawyer before you do
_anything_, keep it out of reach of children, etc.)

Is it necessary to modify dpkg?  Maybe just package maintainers could
add the extra flags to the debian/control files, once they know the
legal status of the package (it wouldn't be required, just recommended
for now).

> 	non-free: there's something funny about the legal issues,
> 		please examine and decide for yourself

The GPL can be considered "something funny about the legal issues" too,
in the case of development libraries.  But non-free would be too strong
(it's still freely distributable, but with some use restrictions).

> > Only packages that are not freely distributable would need to be placed
> > in non-free.
> 
> No! Packages that are not freely modifiable or usable must
> also go in non-free, because the user (installer, distributor)
> needs to be aware of special conditions for that package.

That's where our policy seems to be inconsistent.  Binary-only packages
are in contrib, but packages with read-only sources (better than no
source at all - we can at least find and report bugs) are in non-free.

> dpkg --fsys-tarfile foo.deb | tar xOf - usr/doc/foo/copyright.gz | zcat

Not easy enough - it needs to be a single option.  Maybe even some
separate tool, easily ported to non-Debian systems as well.  (The
distributors do not necessarily use Debian.)

> > How about this: packages that are freely distributable, but depend on
> > non-free packages, should be placed in contrib.
> 
> That is current policy. (Policy manual, 2.3.)

That's good.  Does this mean that packages that depend on pgp (auto-pgp,
mailcrypt, premail) - they are free as far as I can tell - don't follow
the policy?  Should I report bugs against them?  (they are in non-free,
but should be in contrib)

> It doesn't help the patent issue to move the distribution out of the
> country. Use of patented software without a license is illegal even
> if you ftp'd the program from abroad.

I think it does help because the distribution itself wouldn't be affected
by patents (and export restrictions: crypto can be imported into the US,
just not exported) - it should be the user's problem, not ours.

(Also, in the long run, if more and more companies move their businesses
outside the US because of all these problems, the US won't receive their
tax dollars - maybe the US government will then see the light, change the
patent law, and remove the ITAR restrictions?  OK, I'm dreaming...)

I think it is reasonable to expect the end user to check any local laws,
patents, etc.  We can't possibly know them all, in all countries - and
so we shouldn't be concerned about them, unless they are the same in
almost all countries (like copyrights).

Suppose that the patent law in some country X allowed someone to patent
a "software packaging system with dependencies", thus making dpkg (and
RPM, too) illegal in country X.  Does this mean that we remove support
for dependencies from dpkg, just to keep users in that country happy?
Nope, users in country X will simply have to stick to Slackware...

Marek


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com


Reply to: