Re: DFSG-free Project
MJ Ray clearly stated on -vote something that's been simmering
in my mind for quite some time now.
Could the Debian (or similar) project by entirely DFSG-free?
We've had licensing 'debates' on the Debian logo's, as a result
of the GFDL issue that came up last year.
We have various documents that form the pseudo-legal/ social
structure of debian - voting guidelines, the social contract
and what not, and we have procedures for changing these and
procedures for changing the procedures (all these ultimately
being documents somewhere).
So could all such documents be encumbered in only a DFSG-Free
sense, or would, as MJR implies (see below, from -vote),
On Wed, 2004-02-25 at 23:51, MJ Ray wrote:
> On 2004-02-25 11:57:30 +0000 Zenaan Harkness <firstname.lastname@example.org> wrote:
> > It kind of feels intuitively attractive to me, to have an entirely
> > DFSG-free project producing DFSG-free deliverables.
> Trying to apply the DFSG to the project doesn't seem to work, as I
> don't know any definition of software that would include the actual
> project acts. We could try to write DFSG-like DFPG, but I am not
> clever enough to see how to get a viable project if it can't
> discriminate against those who work on destroying it.
Let's assuming we leave "acts" out of the discussion since we
can't license acts, and talk from a documentation and software.
Logos, policies and procedures can (should) be considered
documentation, and at least licensed as such.
All infrastructure (software - autobuilders and the like) would
be licensed DFSG free to be considered part of the project.
This seems to lead to a "top level" document (under DFSG license)
describing the project, and the requirements for any piece of
documentation, software (etc?) to be part of the project:
- it must be licensed DFSG-free
- it must be packaged according to Packaging Guidelines.
- it must be packaged with a statement saying it is part of
the project (and yet is only _actually_ a part of it if it
meets all these "requirements".
FTP Masters self-affiliate themselves with the project.
This then leads me to these two points:
Clear(er) sovereignty from an individual point of view.
A possible reversal of (some of) the points of power
(namely, back to individuals).
So the questions become ones of what makes most sense in terms
of drawing the lines in the sand - what should be responsibility
of individuals, what of "committees", what of the "project leader".
I guess any/ all these aspects could be made subject to voting.
Of course that may conflict with sovereign individuals who wish
to do things in their own way regardless of vote.
So where does it make sense for individuals to work as a group?
And then documentation on this would be useful to bring like
Perhaps this is the real question from all of this:
Is Debian's bureaucratic friction quotient optimal?
* Debian Enterprise: http://debian-enterprise.org/
* Homepage: http://soulsound.net/
* PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.