Framework metadata

[Martin Graesslin]

On Thursday 19 December 2013 21:22:36 you wrote:
> On Thu, Dec 19, 2013 at 9:15 PM, Martin Graesslin <mgraesslin at kde.org> 
wrote:
> > On Wednesday 18 December 2013 21:35:33 Christophe Giboudeaux wrote:
> >> On Wednesday 18 December 2013 19:50:58 Alex Merry wrote:
> >> > On 18/12/13 17:54, Aurélien Gâteau wrote:
> >> > > We need to have at least a COPYING file in there, with the full
> >> > > content
> >> > > of
> >> > > the license.
> >> > 
> >> > I believe this was already done before the split.
> >> 
> >> I added COPYING files in each frameworks which have GPL files,
> >> COPYING.LIB
> >> files in frameworks with LGPL files and COPYING.GPL3 in two repos.
> >> 
> >> afaik, the BSD and MIT/X11 licensed files don't need a full text license
> >> and the MPL and BSD-3 clauses files almost all have a dual license.
> >> 
> >> Now, we also have countless problematic files which don't have any
> >> license
> >> or bogus headers.
> >> 
> >> See the attached file (created before the split)
> > 
> > thanks for the list. Looking at it, it seems to be dominated by code in
> > testing. Can we resolve those by just declare them as non-copyrightable
> > (below threshold of originality).
> > 
> > What strikes me is that there's one file I recently pushed and our git
> > system didn't complain. I would have expected that a file without
> > copyright cannot be pushed.
> 
> The hooks do not consider it a fatal condition if a file does not have
> copyright data attached.
> However, they will flag it in the commit mail sent to
> kde-commits at kde.org, and a copy of the mail will also be explicitly
> sent to you.
In that case it might be that I missed it, as the commit mails are sent with 
my email address and those get marked as read automatically (yes I know that I 
just pushed the change ;-)
> 
> It is also possible of course that the regexp's in the hooks aren't up
> to the job.
> 
> Which commit introduced the file?
cd33f0192122cb98105ba34daf6aeebf08707f6d

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131219/abe98492/attachment.sig>