The licence file is now included in the repository (called README), so this
issue is resolved.

Looks great! :-)

I think it looks fine.

Here is a draft of the LICENSE file we would add to the repository (besides a
file with the GPL v3 text). Any suggestions for changes? One point that can be
removed is the "or (at your option) any later version" part (but I would leave
it in).



Fast Downward is a domain-independent planning system.

The following directories are not part of Fast Downward as covered by this
license:
./benchmarks
./src/VAL
./src/search/ext

For the rest, the following license applies:

Copyright (C) 2012-2016 Florian Pommerening
Copyright (C) 2003-2015 Malte Helmert
Copyright (C) 2008-2015 Gabriele Roeger
Copyright (C) 2010-2015 Jendrik Seipp
Copyright (C) 2010, 2011, 2013-2015 Silvan Sievers
Copyright (C) 2013, 2015 Salome Simon
Copyright (C) 2014, 2015 Patrick von Reth
Copyright (C) 2015 Manuel Heusner, Thomas Keller
Copyright (C) 2009-2014 Erez Karpas
Copyright (C) 2014 Robert P. Goldman
Copyright (C) 2010-2012 Andrew Coles
Copyright (C) 2010, 2012 Patrik Haslum
Copyright (C) 2003-2011 Silvia Richter
Copyright (C) 2009-2011 Emil Keyder
Copyright (C) 2010, 2011 Moritz Gronbach, Manuela Ortlieb
Copyright (C) 2011 Vidal Alcázar Saiz, Michael Katz, Raz Nissim
Copyright (C) 2010 Moritz Goebelbecker
Copyright (C) 2007-2009 Matthias Westphal
Copyright (C) 2009 Christian Muise

Fast Downward 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 3 of the License, or
(at your option) any later version.

Fast Downward 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, see <http://www.gnu.org/licenses/>.

For contact information see http://www.fast-downward.org/.

As discussed offline: I suggest we don't change the source files themselves, but
go with a more minimalistic solution of only adding text files describing the
licence and contributors.

Gabi and I have also discussed the list of pre-Mercurial contributors offline.

I would be willing to generate the GPL header for each file. My attempt would be
to retreive the authors information from the mercurial history. Should we
include contributions that stem from merges? What about contributions from
earlier (svn) times?

That should have been "So let's go with GPLv3", of course. :-)
Thanks to Jendrik for spotting this.

We've had a discussion of this on the downward-dev list, with some people
speaking up in favour of GPLv3 and nobody favouring GPLv2. So let's go with GPLv2.

As an aside: One of the authors of GPLv3 also works on a new GPL license that's 
supposed to be a simplification of GPLv3. 
gitorious repo: https://gitorious.org/copyleft-next/
German article: http://www.golem.de/news/copyleft-lizenzen-fontana-arbeitet-an-
gplv3-nachfolger-1207-93123.html

This discussion is a good start / summary:
- http://stackoverflow.com/questions/41460/what-are-the-differences-between-gpl-
v2-and-gpl-v3-licenses

I haven't really done a proper comparison of GPL v2 or v3 -- I only vaguely seem
to recall that v3 has some kind of anti-tivoization clause. Anyone with more
knowledge of the matter care to explain the differences and/or make a
recommendation?

Fair enough. It's mainly the parsing that I hoped to pull in (src/translate/pddl + 
instantiate.py (and its required imports)), and I'll just keep the pddl parsing part 
of the library separate (and under GPL) until I can re-implement things. I've faced 
some unfortunate dismissal of libraries in the past because of the GPL nature -- 
many universities / organizations here refuse to use / promote software that has an 
infectious license when linked to.

Is the planner meant to be GPL v2 or v3? The README / COPYING file could probably 
just be placed in the three planner directories to cover everything (translate, 
preprocess, and search). It would also let you avoid tying things together with VAL 
(as far as I'm aware FD doesn't link / modify VAL).

I pretty much agree with Malte (maybe I am even more inclined to the full GPL).
I am definitely against generally putting the translator under the LGPL, but if
there are good reasons for a special license for a certain part and version of
the code, this is indeed conceivable.

> Any further progress on this?

Not really; the code is under the GPL, but that's not properly documented yet.
If someone has time to step up and document this properly (add a README file and
the COPYING file which I think is required; mention it on the website in a
suitable place; whatever else is necessary -- but please no boilerplate headers
in all source files!), I'd be happy about that.

We also need to address the issue of code contributions in some way, along the
lines of what Andrew wrote.

> On a related note, could I have permission to use code found in the
> following two directories as LGPL?
> - src/translate
> - scripts/stuff/sas_tasks
>
>  I'm hoping for LGPL so they can be used in a library with an LGPL license
> (which would allow people to use the library without license infection as
> long as they don't change anything).

You have my blessing to do with scripts/stuff/sas_tasks whatever you want --
consider it BSD-licensed. Note that this wasn't updated when we last changed the
translator output format (and maybe not even for the previous change that added
action costs) -- patches welcome.

Regarding the translator, the infectiousness of the code is intentional. While
I'm not as radical as RMS, I do agree with the basic points of
http://www.gnu.org/philosophy/why-not-lgpl.html.

We've made exceptions to specially license certain versions of the code in the
past in a few cases, but in each individual case there must be a compelling
reason that outweighs the benefits of promoting openness in the way that the GPL
does.

A priori, I see the possibility of developing closed code that uses major parts
of the planner as a library as a disadvantage of the LGPL, not an advantage. We
don't want people to build systems that are 95% our code plus 5% proprietary code.

Further comments on this welcome -- especially, but not only, from the people
who have made major contributions to the translator.

Any further progress on this? On a related note, could I have permission to 
use code found in the following two directories as LGPL?
- src/translate
- scripts/stuff/sas_tasks

  I'm hoping for LGPL so they can be used in a library with an LGPL license 
(which would allow people to use the library without license infection as long 
as they don't change anything).

  Cheers

Very good point, thanks!

Having option i) available for the bulk of the contributions sounds like what we
want, but of course that means this needs to be made very clear to contributors.
The Python project for example requires people who make substantial
contributions to sign a license agreement. I don't know if we should be *that*
formal, but we should at least bring the point up with all contributors.

Just having noticed the 'GPL but open to discussion' stance, a quick shout-out
to the issue of how you handle patches, based on what I've seen go wrong in
larger projects.  Specifically, the Qt library upon which KDE is built is
available in both open and closed-source forms, and bug fix submissions to Qt
either have to be:

  i) written by someone who's agreed that the Qt owners (Nokia) can relicense
with impunity should they choose to do so
 ii) re-implemented from scratch by someone in category (i)
iii) ignored - there's only limited manpower to re-invent wheels, so (ii) only
happens for important fixes

(The GPL but open to discussion stance is the one we take with our planners, and
we have been approached, and provided, a closed-source release for use in an
area steeped in NDAs and confidentiality.  The code was exclusively ours, so
there weren't any problems, but then, the downward code has been written by many
more pairs of hands, from different institutions and countries.)

Aye, a message indicating the possibility of a dual license should be fine. The 
LGPL doesn't allow closed advances to be made on the code though -- only allows 
third party software to use it as a library without having their license 
affected. But as you point out it's probably best to deal with those issues on a 
per request basis (eg. if anyone comes looking for an LGPL version of 
src/translate/pddl)

> It may also be worth putting parts of FD under the LGPL rather than pure GPL --
> would allow researchers to include the parser, etc as part of their code
> without infecting their license.

For academic research, I think openness is important and hence the
infectiousness of the GPL may be a good thing. For people with non-GPL needs,
maybe it's enough if we make it clear that we're open to discussion.

VAL -> GPL:
- http://hg.fast-downward.org/file/145e4c0a50c5/src/VAL/README.new

LP -> CPL:
- https://projects.coin-or.org/Osi
- This doesn't infect the license of a project that links in thinks in it.

IPC:
- This could be quite difficult to figure out...likely best under some CC 
licensing, but tracking down the domain authors could be an issue.

----

  It may also be worth putting parts of FD under the LGPL rather than pure GPL -
- would allow researchers to include the parser, etc as part of their code 
without infecting their license.

We need to add licensing information to the codebase.

 * The planner shall be put under the GPL.
 * We should check under what terms we can redistribute VAL.
 * We should check under what terms we can redistribute the LP libraries.
 * We should check under what terms we can redistribute the IPC domains.
 * We could check all other pieces of foreign code, e.g. in the misc directory.