[Geany-devel] AUTHORS && THANKS files

Lex Trotman elextr at xxxxx
Sat Sep 24 05:31:08 UTC 2011

Hi all,

I thought I should make it clear why I think this is worth a few
seconds consideration.

As the Geany project is not an entity any issues with copyright will
be directed at individuals. and lately there seems to have been an
increasing willingness to do so.  And in many countries.

So we need to show reasonable efforts to manage copyright, which is
what the licensing is based on.  This might not be protection, but it
may be mitigation.

> Given the other information you provided, I'd say, at least after the Git
> switch that the AUTHORS (and COMMITTERS) files should just be generated from
> git log for tarballs.  If someone just provides a plain diff for a patch,
> you can still set the author to them (not sure can SVN do this?).  If they
> send a pull request/git format-patch it's automatic.

Yes, the more automatic we can make it the better, fewer mistakes.

>> If they are going to be kept up to date, now before release is the
>> time.  IMHO thanks should be *everyone* [1].
> Seems to make sense, though it could be a pain.  IMO, the bug number that's
> currently used (I think) is enough for bug/feature tracker stuff.
>  Otherwise, you'd have a lot of these in the THANKS file:
> ...
> Anonymous <http://accounts.google.com> - reported some bug
> Anonymous <no known email address> - requested some feature
> ...

I think it should just be a list of names, what the thanks is for is
never up to date, eg just taking the first name, it seems Frank hasn't
done any work in the translation area :).

Since the project doesn't work on Karma or points there should be no
attempt to distinguish levels of thanks, and the names should be
sorted (in Unicode code point order to avoid language sorting

>>> On a similar topic, I noticed in the source files, on top of the license
>>> in
>>> the comments, some files list Nick and Enrico as the copyright holders,
>>> some
>>> [...]
>> Copyright assignment is used by some projects but as you say there
>> needs to be a legal entity to receive it.  And what country would this
>> legal entity exist in? Who would own it and how wold it be run and
>> paid for. And legal paperwork is needed for contributions, including
>> employer disclaimer (to prove they don't own the software you write).
>> All in all Noooooooo.
> For Geany I would've said the project lead/maintainer with the copyrights
> getting transferred when the person filling that role changes.  But yeah,
> way too much hassle for all the legal requirements.
>> Copyright law isn't uniform around the world, but I have been advised
>> that the most common is that:
>> 1. the originator has copyright whether they want it or not, and
>> usually automatically without having to claim it
> Which means just having a proper VCS log (with proper author) would be
> enough to track all the bits and pieces of who owns copyright on what? Seems
> like that would be better than listing every single copyright info for
> everyone who ever changed the file.  If the ChangeLog is generated from the
> VCS log, IIUC it will have all the required info for tarballs.

Thats the idea, note that not all legal advice says this is enough,
but in lieu of paper it is reasonable, especially if the repositories
are hard to forge.

>>> Also, if someone contributes a significant amount of code to one or more
>>> files, does that mean they hand-over the copyright of that code to one
>>> (or
>>> maybe all?) of those people listed in the various file headers?
>> Too complex, and who?
> Ok, just was curious whether the act of submitting code to the Geany project
> implicitly signed over copyright.  I guess it doesn't work like that :)

No, IIUC assigning copyright is a much heavier transaction than
granting a license and must be explicit, so it is ok for permission to
grant a GPL license to be implied (especially if we add it to
hacking), but assigning copyright still needs unforgeable
documentation, which pretty much means paper with signatures :(


More information about the Devel mailing list