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

Re: authoritative list of DFSG-free licenses

On 13085 March 1977, Stefano Zacchiroli wrote:

>> The whole of ftp* agrees that it would be nice to have a place
>> documenting this. So much so that we started something for it in 2009,
>> see http://ftp-master.debian.org/licenses/ for it.
> Oooooohhhh, that's awesome! I had no idea something like that existed,
> and I can't find it listed anywhere: can you people please link it from
> http://ftp-master.debian.org/ ?

Well, it is not, as it is currently not useful. It is (still) a
proof-of-concept, thats why it isn't linked anywhere. Sure that will
change when we get a bit more.

>> And here is an ikiwiki instance in a git, check it out, ftp*".
>> got it around 31 commits far, and then it "slept in". It *is* entirely
>> dull and non-fun and just boring work, with no direct payoff (in
>> NEW/rm you at least have that direct "payback" :) ).
> For those willing to play with it, the associated Git repository seems
> to be at http://ftp-master.debian.org/git/licenses.git/


> Joerg, it would be nice to rebuild it adding the repolist plugin
> http://ikiwiki.info/plugins/repolist/ , which would add the rel-vcs
> metadata, making the following work nicely out of the box with mr:
>   $ webcheckout http://ftp-master.debian.org/

I don't see why I need a plugin (and whatever settings) for a one-line
change, so I just went and added

<link rel="vcs-git" href="http://ftp-master.debian.org/git/licenses.git"; title="licenses.git" />

to the page.tmpl. It isn't supposed to change location every other day. :)
But feel free to get me patches to change it, if you think it should.
I'm not set on it.

> I haven't found the ikiwiki configuration in Git, so I'm unable to
> provide a patch for that.

You are blind. :) It's all in git, but we don't use a setup file. The
ikiwiki foo is in ikiwiki/ and the way we call it from our git hook is
documented in README.

I just did the few changes that it works with ikiwiki 3.x, so people can
look at it at home too.

>> That said, we would be happy to get it back to live and end up with it
>> (either where it is now or wherever fits) being a useful place. Seeing
>> how it directly touches us (decide if $foo can go into the archive and
>> be distributed or not), it certainly makes sense to have it within FTP*
>> overview.
> Ideally, what I'd love is then to see that page replacing what we
> currently have at http://www.debian.org/legal/licenses/ .

Agreed, we don't need multiple.

> MJ, has you seem to have participated in the maintenance of the latter
> page, what do you think of that? Of course, we'll first need to bring
> the ftp-master page up to date.

And actually cover a number of licenses, not just the initial ones I put

> Also, I think Charles' idea of also publishing stats about which
> licenses are currently found in main/non-free would be useful. It can be
> toned down wrt the claim that "these licenses are DFSG-free" and
> presented as mere factual data of what we currently have in the
> archive. Doing it on the basis of machine parseable debian/copyright
> sounds reasonable and might further encourage adopting the new format.


> Any taker for writing a script that gather the corresponding
> statistics?

Two good places to run/integrate that:
 - Using the tree we export for packages.d.o, with all changelogs,
   copyright files and README.Debians, one can go over that and grep
   around, counting it.
   Pro: Easy to get started
   Contra: Low performance.

 - Patch it into dak. We do extract the files anyways, at that point one
   can extract information from them and put them somewhere easy to
   access (hello projectb).
   Contra: Slightly harder to get started. Hello dak python
   Pro: Performance is good. Queries later can be anything you can
   imagine in sql. And I bet UDD would leech the data too.

>> That said, it is clear it can't be the FTP Team who is doing the work
>> - the oh-so-recentness of it shows that it is a task that won't get
>> done. There is too much else for us and we are few people only.
>> But we would be happy to work with / lead / whatever-one-names it with a
>> group of volunteers together. Exact details of how that works out are to
>> be found, but im sure we can. If there are volunteers for it...
> Fair enough. Of course good part of the work will be reviewing the
> licenses that are already found in the archive and marking them as
> DFSG-free in your table.

Or opening bugs, when one finds a license that slipped through but
shouldn't be in main, yeah.

> Which "review status" would you (as in ftp-masters & assistants) want
> for those licenses? More generally, is there a specific work-flow, or
> state chart, you want to follow? That would help in proposing patches
> to the ikiwiki repo...

There is, not yet, a defined workflow. So the details have to be worked
out with whoever volunteers. I'm pretty open here for suggestions.

Technically I would think it ends up somewhere along

- volunteers clone from the central place and do their work.
- every now and then they ping one of ftp*, to have us review it, merge
  it (or reject the change) and push it to the central place.

That would allow anyone to contribute, while keeping the FTPTeam, with
us masters being delegates, the ones who publish it. Similar like policy
editing works, IIRC.

And discussion around it, happen on IRC and (for a start)

> The other big part of it is keeping up to date with future
> DFSG-free-ness ruling by ftp-masters. As pointed out in this thread, you
> usually send motivated REJECTs to maintainer only. How would you like to
> proceed to keep track of motivation for new licenses? Is Cc:-ing
> -project, as you did for the Ubuntu Font License and then indexing a
> link to the list archives something that would work for you? If not,
> what would?

I don't think we should CC every reject to a public list, and right now
we don't have the feature to turn on CCs for selected rejects.
Could add that, but that seems error prone, easy to forget to use.

I'm sure we will find some way over time, I don't think it is the most
pressing point right now.

Much more interesting is to get it all started, soooooo

 - Do we have volunteers? Who wants to? Keep in mind it will start with
   a heavy load. Which will go down when we got most of the stuff
   documented, but it will never end.
   Damn Humans, always get up with new licenses...

bye, Joerg
Free Beer is such a good thing and Free Speech too. Debian is about the

Reply to: