On Thu, 24 Jun 2004 14:01:36 +0100 MJ Ray wrote:
> On 2004-06-24 10:40:01 +0100 Francesco Poli <frx@firenze.linux.it>
> wrote:
>
> > Anyway, IMHO, summaries of /license/ analyses are still useful.
>
> Oh, I agree, but I think we need to make a few changes to how they're
> being done, now we've seen them in action for a while.
>
> There seem to be two types of licence summary needed:
>
> 1. for licence authors, which was the original suggestion.
[...]
> 2. for developers, which seems to be the aim of the /legal/licences/
> page.
[...]
So, IIUC, you propose that summaries should be split into two
`variants': in your opinion, every license should be summarized by one
document intended for the license authors (who may be willing to
improve their license) /and/ by another document intended for developers
(people who choose licenses for their software) and users (people who
choose software taking into account licensing issues).
Don't you feel that this would be too much effort to be done effectively
for a significant number of debian-legal discussions?
I mean: very few `monotype' summaries have been done so far and you
suggest to double the number of summaries per discussion... :o
Wouldn't it be better if one single summary variant could be tuned to be
well-suited for both uses (improving licenses /and/ choosing a license
or checking if a piece of software is _probably_ free)?
> > Moreover the summaries are good references that avoid us to explain
> > again and again why license L is clearly non-free.
>
> ;;;; warning - semi-rant follows. Skip down to conclusion if you are
> new here.
>
> Yes, I think you've found the exact reason. These "developer
> summaries" should aim to be a sort of FAQ, not a checklist of
> free/non-free judgements. debian-legal is ill-suited to be FSF++ or
> OSI mark 2 and should not be turned into that. I have realised that
> this list's members have a role to play, helping to make debian a
> distributable free software operating system, so let's stick to that
> role.[...]
The FAQ use is certainly /one/ use of the license list, but not the only
one, IMHO.
It's not about becoming FSF++ or OSI mark 2.
But, hey!, what can you do when you realize you don't quite agree with
FSF's or OSI's criteria and you feel that Debian's criteria are the ones
you agree best with?
It's unfortunate that these three organizations don't agree exactly on
freedom criteria, but it's a fact. Well, OSI doesn't even speak about
freedom, but that's another matter...
Given that the Debian project judges freedom with (slightly?) different
criteria, I would like that a sort of database of conclusions (based on
these criteria) is set up.
So that anyone who wants to know how a package licensed under a
particular license would *probably* be judged by debian-legal, can find
out without spending at least one day digging in the archives and
reading all the (often long and verbose) discussions.
Note that this `anyone' could be the license author, a developer who
consider choosing the license for his own software, a user who considers
to choose a piece of software released under the license, ...
> ;;;; skip to here
>
> In conclusion: if some debian-legal contributors want to try to make
> another org to approve and reject licences, please go do it somewhere
> else. Let's improve the summaries so that they better serve our job.
> I'm interested to know whether anyone agrees with the "two types"
> idea.
Well, Debian should not approve and reject licenses, I agree.
But it should publish some sort of vademecum, even though it must be
stated clearly that there is *no warranty* that a package under a `good'
license will go in main for sure.
I mean: a package under a `good' license could be very well judged as
non-free and viceversa, but anyway it's still useful to provide a
guide... otherwise people could begin to think that having a package
included in Debian (main) is a sort of lottery.
I know that the DFSG are there just to explain Debian criteria and are
themselves /guidelines/.
But many people don't understand them very well or are not interested in
reading them carefully.
A database of their practical consequences would be helpful, IMHO.
Of course, again, with *no warranty*...
--
| GnuPG Key ID = DD6DFCF4 | You're compiling a program
Francesco | Key fingerprint = | and, all of a sudden, boom!
Poli | C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO,
| 31B5 78F4 279B DD6D FCF4 | version 1.8.0
Attachment:
pgpTrdH9QEvrr.pgp
Description: PGP signature