This ticket had assigned some Differential requests:
D135

Since we have this discussion, this is what my favorite license header looks like:

# -*- coding: utf-8 -*-
# Copyright 2009-2014, Red Hat, Inc.
# License: GNU General Public License version 2 or later

And this is what my non-favorite header looks like:

# -*- coding: utf-8 -*-
# Copyright 2014, Red Hat, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
#
# Authors:
#       Tim Flink <tflink@redhat.com>
#       Josef Skladanka <jskladan@redhat.com>

My impression is that the single License: line is fully sufficient. If someone knows what it means (i.e. knows the license definition or can look it up on FSF web or - more correctly - at our project base directory), he/she can use the code. If someone doesn't know what it means, he/she can't use the code (this world has "full rights reserved" by default), until the person finds out how it works. Yes, this is probably not the "best" approach to do - the lawyers always recommend dumping an essay at the top of every single file - but their solutions are mostly very impractical. They tend to recommend the most defensible approach at court, not the most practical-while-still-valid one (which partly stems from the fact that there's nothing like //valid// in law, there's only the //judge//). There are many projects which don't provide any license information in the individual files, just in the root of the project directory, and I haven't yet heard about any real problems with it. So //my favorite header// is a reasonable middle ground, I think.

As for warranty disclaimer, I don't think it's necessary, because it's already covered in GPL text (even the essay above says so).

And lastly, I really dislike putting the author names in the header. They are almost never true. People just don't bother to update it with every single small patch (and why should they). Sometimes after some refactoring there's 0% of the original code, but the author is still claimed to be the original person. That just loses the purpose. It's a habit from pre-VCS era, now we can retrieve much better information with git log. The authors section makes sense in cases where the file was retrieved from some third-party location or written by a third-party person and we want to keep his contact at hand.

So, obviously, I'm a supporter of the first, succinct way, which doesn't force me to scroll down madly as my first action in every single file I open. But, of course, IANAL.

I concur with @kparal here. I dislike having a giant glob of boilerplate text in every file, but also IANAL.

Interesting how similar your non-favorite header is to [[http://www.gnu.org/licenses/gpl.html#howto|the per-file header recommended by the FSF]] :)

I'm definitely OK with removing the authors section but I'm not seeing many other examples of that style of license abbreviation out there.

Below are I've listed the status of the License Header in all the source files. A lot of files have no header, and most of the ones that do are all in the short
format. Any file I didn't list has the longer header in it (I started out just looking for files with no header at all.

No License

.arcconfig
libtaskotron.spec
runtask.py
setup.py

conf/
- all
docs/
- all
testing/
- functest_python_directive
- pytest.ini
- some_loadable_test
- test_bodhi_comment_directive
- test_koji_directive
- test_python_directive
- test_resultsdb_directive
- test_runner
- test_yumrepoinfo_directive
- test_directives/test_directive
libtaskotron/
- init
- file_utils
- runner
libtaskotron/directives/
- init
- createrepo_directive
- dummy_directive
- koji_directive
- python_directive
-

Short License

testing/
- functest_config
- functest_yumrepo
- test_bodhi_directive
- test_bodhi_utils
- test_config
- test_koji_utils
- test_python_utils
- test_rpm_utils
- test_taskyaml
- test_yumrepoinfo
libtaskotron/
- bodhi_utils
- check
- config
- config_defaults
- exceptions
- koji_utils
- python_utils
- rpm_utils
- taskyaml
- yumrepoinfo
libtaskotron/directives/
- bodhi_directive

I'd be for something in the likes of

  # -*- coding: utf-8 -*-
  # Copyright 2009-2014, Red Hat, Inc.
  # License: GNU General Public License version 2 or later (see LICENSE file in the project's root directory for more details)

/me is not that fond of the wall of text we currently have, so if this would be possible to do... ::yay::

License: GNU General Public License version 2 or later (see LICENSE file in the project's root directory for more details)

The only problem with doing this is that the project is distributed as GPL3 while the source is gpl2+. I suppose that we could have a LICENSE.gpl2 file and leave the LICENCE file as GPL3

I'm really not understanding why having an extra 12 lines is such a big deal to adhere to an accepted standard but as far as I can tell, I'm very much on the losing side of this argument.

As a compromise, would using headers in the style that [[http://git.denx.de/?p=u-boot.git;a=tree|uboot]] is using (converted to python syntax) be acceptable?

  # -*- coding: utf-8 -*-
  # Copyright 2009-2014, Red Hat, Inc.
  # SPDX-License-Identifier:     GPL-2.0+

Let's use license identifier in a SPDX format, that's probably a good idea.

But SPDX-License-Identifier tag seems to be an invention of uboot. When I look somewhere else, people use a native tag for their language, like @License: in java. Why not use simple License: in our source code? I find that more readable and clearer for anyone finding our source code on the Internet.

So we could end up with something like this:

# -*- coding: utf-8 -*-
# Copyright 2009-2014, Red Hat, Inc.
# License: GPL-2.0+ (see LICENSE file for more details)

As shown in that article, we might also decide to append the license URL as well, although I'm not sure it's necessary:

# -*- coding: utf-8 -*-
# Copyright 2009-2014, Red Hat, Inc.
# License: GPL-2.0+ <http://spdx.org/licenses/GPL-2.0+> (see LICENSE for more details)

The LICENSE file would include a short description saying that we use multiple licenses in our source code, that people need to look at file headers to see that particular file's license, and that our project-level license is GPL3. Then it would point people to read licenses/GPL-2.0+.txt and licenses/GPL-3.0+.txt or any other license we happen to include files under in the future.

If the LICENSE file is short enough, we can include that information in README instead, in a "Licensing" section.

I suppose either of those would work.

I still don't like making stuff up like this instead of using what the FSF recommnds or what another project is using but I suppose it's good enough as long as we have proper LICENSE and/or COPYING files.

Any other thoughts on whether to use the link or not?

I do not have any strong preferences - if the SPDX-License-Identifier: is a standardized tag, we can use it. Otherwise I'm not against # License: GPL-2.0+ <http://spdx.org/licenses/GPL-2.0+> (see LICENSE for more details) either.

Maybe "see LICENSE file for more details" is even clearer.

I'm torn on this because IANAL. I don't like the wall of text - but if it ever came down to it I would want to have something the FSF recommends because I trust them more than myself when it comes to legalese.

The more I think about it the more I'm ok with dealing with a bit of extra scrolling while reading the code. If we decide to go with the short version though, I have no strong preference for either format.

In the interest of getting this done, let's do:

# -*- coding: utf-8 -*-
# Copyright 2009-2014, Red Hat, Inc.
# License: GPL-2.0+ <http://spdx.org/licenses/GPL-2.0+> (see LICENSE for more details)

I don't think that there are any files in the libtaskotron codebase that haven't been authored by non-RH employees, so leaving the copyright like that should be fine.

There's a revision for this here: https://phab.qadevel.cloud.fedoraproject.org/D135