/* Copyright (c) 2018 Lawrence Livermore National Security, LLC. Produced at
* the Lawrence Livermore National Laboratory (cf, AUTHORS, DISCLAIMER.LLNS).
* LLNL-CODE-658032 All rights reserved.
*
* This file is part of the Flux resource manager framework.
* For details, see https://github.com/flux-framework.
*
* 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. Additionally, Flux libraries may be redistributed
* under the terms of the GNU Lesser General Public License as published
* by the Free Software Foundation, either version 2 of the license,
* or (at your option) any later version.
*
* Flux 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 terms and conditions of 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/>.
\*****************************************************************************/
There are still some issues to deal with regarding code imported from other projects (described in #1084, and possibly we have accrued some more), but we can minimally put this on new code, and update the old code that was developed by the Flux team.
We seem to be inconsistent with including boilerplate in header files and test files. Shall we come to some agreement on what types of files it gets added into? Should we also consider adding it to the adoc files and other misc documentation?
In other projects I've worked on, I add it to everything humanly possible. But perhaps just my personal analness.
Maybe we can discuss that over in #1084?
My main point here was let's not check in new copies of the old boiler plate that we'll have to change later.
Oh duh, this is the right place to discuss that. Sorry my bad! I thought I was in the subprocess PR!
IMHO it's most critical on actual code (where the real IP lies) and installed headers (where the license of a library may be advertised). I've been pretty lax about internal tests and headers, but I could be convinced otherwise. it is a little annoying when length of boiler plate exceeds content.
Instead of "Additionally, Flux libraries...", can you list the specific libraries? I'm thinking it might be best to be more specific in the copyright boilerplate to remove any potential ambiguity. Or is that impractical because the list of libraries is still in flux (_bonus pun!_)?
Makes sense. "Additionally, libflux-core and libpmi..." I guess?
At this point I would vote we go with a straight LGPL header on all source files built into libflux-core, rather than the header proposed above, for two reasons: 1) in our case, hardwiring the name of libraries seems doomed to require a change down the line at some point (to _every source file_), and 2) I don't think we gain much by offering a choice of GPL or LGPL, since the LGPL license allows GPL code to include it.
So my vote is:
/*****************************************************************************\
* Copyright (c) 2018 Lawrence Livermore National Security, LLC. Produced at
* the Lawrence Livermore National Laboratory (cf, AUTHORS, DISCLAIMER.LLNS).
* LLNL-CODE-658032 All rights reserved.
*
* This file is part of the Flux resource manager framework.
* For details, see https://github.com/flux-framework.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU Lesser General Public License as published
* by the Free Software Foundation; either version 2.1 of the license,
* or (at your option) any later version.
*
* Flux 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 terms and conditions of the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
* See also: http://www.gnu.org/licenses/
\*****************************************************************************/
(I used LGPLv2.1 because LGPLv2.0 is not called the "Lesser General..." It's the "Library General"...)
Sorry to waffle. Is anybody not OK with this?
Let's define this issue solved once all the Flux-produced source files linked into libflux-core have the updated Flux LGPL boilerplate (independent of the 3rd party code that we need to do something else with in order to be able to declare libflux-core LGPL through and through).
_Library General_ sounds like something from _The Pirates of Penzance_ :
It is the public license called GNU Library General
It protects user freedoms of code that's redistributable
This should have been closed by #1788
Most helpful comment
Instead of "Additionally, Flux libraries...", can you list the specific libraries? I'm thinking it might be best to be more specific in the copyright boilerplate to remove any potential ambiguity. Or is that impractical because the list of libraries is still in flux (_bonus pun!_)?