The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.

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

contrib/non-free policy



> On Sun, Jul 20 1997 8:52 EDT Alex Yukhimets writes:
> > Sure, in case of gnuplot, we can just have binary-only release in contrib.
> > But the world would be way too simple to deal with if all the software
> > satisfy our FSG. And all attempts to simplify it failed in the past.
> > (I am sure you can come up with examples yourself, in case you would like
> > to know what I mean, I can explain in private email - this is not the
> > topic suitable to this list).
> >
> > Don't you think that in addition of shiny goal (FSG for all) we would also
> > have solid and reasonable rules to deal with the real world.
> 
> No. The FSG is here to ensure portability accross different Unix-like systems (e.g. different binary format, CPU types, FSSTND etc).
> At least the main distribution is portable: you can build for example an
> Alpha or a SPARC distribution (or a PPC if you want), since you
> a) have the source code, _and_
> b) are allowed to change it.
> There aren't any binary stumbling blocks in it (Motif, QT, XForms, ...)
> which would prevent porting.
> 
> David

Great. I completely agree. But as soon as kernel is ported to a different
architecture, we shall port our 'main' (FSG compliant) distribution which
will provide most of the basic utilities and some applications. 
What happens after that is that "binary stumbling blocks" of not_free
(I will distinguish from now on non-free - allowed to be placed on
ftp site from not_free - all not free software) libraries will appear
on the market for this architechture. What would be our next step?
Surely to port many applications which depend on these libraries and
place them _outside_ of "main" to provide users with fully functional and
versatile system. What I am trying to get to is that it is high time for
this step for i386 architechture.

Let's first come to some agreement regarding this my statement and then
reconsider the structure of our semi-supported (aka non-free/contrib)
distribution. 

First of all, let's our policy be to place (port) as much as possible
of this not_free software into the distribution to give user _choice_.
Some of this packages will replace ones from the main distribution
(like we have gs now, and would probably have cygwin32 or something).
Let's not hesitate to put application in whatever from allowed - binary
only, unmodified source only, installer, etc. Use every possible special
agreement of copiright holders with Debian, etc. Of course, we will have
limited abilities to support that but we could at least forward bug
reports to the upstream developers.

Thank you.

Alex Y.

-- 
   _ 
 _( )_
(     (o___           +-------------------------------------------+
 |      _ 7           |            Alexander Yukhimets            |
  \    (")            |       http://pages.nyu.edu/~aqy6633/      |
  /     \ \           +-------------------------------------------+


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .