Project needs a CLA

[stuartpb]

@jonsneyers In this Hacker News comment, you stated that you intend to relicense the project under a more permissive license (as desired by issues #3 and #9) after the project has matured slightly.

However, if you wish to change the project's licensing terms at a later point, you need to have contributors release their contributions under the terms of a Contributor License Agreement starting now. Otherwise, at said point of future maturation, you'll have to get everybody who's ever contributed a patch to the project to explicitly sign off on your desired relicensing, which is a pain (as the maintainers of projects which have had to do this in the past, such as Bootstrap, can attest).

http://www.harmonyagreements.org/ has a relatively simple generator for CLAs - once you've generated one, you can add it to the repo, and then request in any pull request that contributors explicitly state that they agree to the terms of the CLA and release their contribution under it (you can also automate this with cla-assistant, clahub, and/or clabot). You can (and should) also add a mention and further explanation of these terms to a CONTRIBUTING.md file in the repo's root.

With these agreements in place, you will be able to relicense the project in the future under whatever terms you decide, without having to get unanimous agreement from every user you choose to accept contributions from (no matter how minor).

[FLIF-hub]

OK, I added a CLA and a CONTRIBUTING.md file. I hope I didn't mess things up; IANAL!

[FLIF-hub]

Is it OK now? Can I close this issue?

[stuartpb]

I would paste the CLA's text into a Gist and set the repo up for having cla-assistant review pull requests (and maybe include the HTML version of the CLA in the repo rather than the PDF), but other than that, it looks good.

[hrj]

Just an idea: What we have done for our projects is setup a separate repo for CLA. There is a template text file which people can copy, edit and then send a PR back to the repo. This leaves a verifiable trail (short of getting a hard copy).

[stuartpb]

@hrj That's actually what I was thinking would be best - what I'd like to see is an ability in cla-assistant (or a fork of it) to operate on repos like that automatically.

[lmarcetic]

@jonsneyers The CLA you've generated looks very nice, except that it unfortunately only effectively allows relicensing to AGPLv3 (hypothetically also to GFDL). The reason is that LGPL is not on the FSF's list of "Recommended copyleft licenses", presumably because it is "suggested for use in more narrow circumstances". You could either hand-pick licenses that you're considering, or just select the OSI-approved licenses option for now, even though not all of them are free software licenses.

I hope that you will still stick to copyleft in spite of this annoyance, and despite the overwhelming peer pressure interspersed with FUD in virtually all FLIF discussions around the web. But if you decide it is essential that proprietaryLGPLv3-incompatibly-licensed apps in the Apple's App Store too use your FLIF library, I would suggest choosing Apache license v2 over other non-copyleft licenses, because patent clauses are good thing.

[stuartpb]

I didn't look too closely at the CLA's content - @lmarcetic is right. For the outbound licensing, you should pick the comprehensive OSI-approved list, which would allow you to move to non-GPL copyleft licenses like the Mozilla Public License (which I recommend as the next step for keeping the library copyleft while not forcing it for unrelated code), as well as non-copyleft but still open-source licenses like the Apache license and the MIT license (@lmarcetic raises a good point about patent concerns, though I think there will need to be much more discussion before a call can be made on the patent front).

The FSF-approved list of "recommended copyleft licenses", as @lmarcetic pointed out, is effectively just a euphemism for the Affero GPLv3 (it doesn't even include the LGPL, which @jonsneyers mentioned he was considering).

In the long-term, I don't think sticking to copyleft will be necessary, and replacing copyleft with a permissive license will help the project without limiting contributions (the way the MIT license has worked for projects such as Lua, Node.JS, and Bootstrap) - however, this is a long-term issue. For now, all that needs to happen is that the CLA needs to be changed so that these options are kept on the table.

[Lord-Nightmare]

Agreed; The current CLA pdf text is insufficient for the licenses listed in CONTRIBUTING.md since it only allows re-licensing later with a license listed on the FSF's 'Recommended Licenses List', which does not include the licenses in CONTRIBUTING.md, afaik.

This needs to be fixed ASAP, before the list of contributors becomes too large to handle having people re-sign the CLA.

[heavyk]

this is silly. can't it just read something like,

by contributing to this project, you agree that your contribution can be relicensed
to one of the licenses listed in the FSF's 'Recommended Licenses List'

and leave it at that?

this is the most unproductive discussion... I think everyone is interested in this being successful. (err, more than discussing licenses endlessly, that is - I hope).

[Lord-Nightmare]

CONTRIBUTING.md: "That allows us to relicense FLIF, including your contributions, under a more permissive license like for example the GNU LGPL v3+, MIT, BSD or Apache 2.0 license."

disagrees with:

FLIF-CLA.pdf: Section 2.3: Outbound License:
"As a condition on the grant of rights in Sections 2.1 and 2.2, We agree to license the Contribution only under the terms of the license or licenses which We are using on the Submission Date for the Material or any licenses on the Free Software Foundation's list of "Recommended copyleft licenses" on or after the Effective Date, whether or not such licenses are subsequently disapproved (including any right to adopt any future version of a license if permitted)."

The FSF list of "Recommended copyleft licenses" (which can be found at http://www.gnu.org/licenses/recommended-copylefts.en.html ) only lists 3 licenses currently as of writing this comment:
"Software licenses
The GNU General Public License, version 3 or any later version
The GNU Affero General Public License, version 3 or any later version

Documentation licenses
The GNU Free Documentation License, version 1.3 or any later version
"

[heavyk]

oh, I dunno man... this is silliness.
perhaps, it should read, "you forfeit all rights to your contribution in interest of relicensing to a more permissive license in the future."

then, by contributing your contribution is your signature.
and no more CLA and no more license discussions.

[Lord-Nightmare]

Not silly at all. The CLA should allow the project author to later, at his/her discretion, re-license the project to at least the licenses listed in CONTRIBUTING.md

[Lord-Nightmare]

@jonsneyers's intent is clear in CONTRIBUTING.md: he wants this to be relicensable under a permissive license in the future. It is not our place to make this decision for him. The issue is that the CLA here does not allow relicensing it under such a permissive license.

[FLIF-hub]

OK, I think it should be better now.

[boutell]

Pleased to see this, it was my only concern about getting behind the FLIF phenomenon.

Sorry to be a pain, but FLIF-CLA-template.txt still has a list of outbound licenses that disagrees with those listed in CONTRIBUTING.md.

— The original PNG guy

[FLIF-hub]

Wow, very exciting to see Thomas Boutell here!

And yes, oops, you're right about the list of outbound licenses. I now removed those mentions of the BSD and MIT license from CONTRIBUTING.md, because they're not mentioned in the CLA template.

So at the moment it's GPL v3, but we can add LGPL v2.0, v2.1 and/or v3.0, AGPL v3 and Apache 2.0.
I don't really see a reason to add even more permissive licenses (like MIT or BSD) to that list. I think Apache 2.0 is probably the best choice for a library version of FLIF. Once the format is finalized, and it is actually a library :)

[stuartpb]

The big appeal of the MIT and BSD licenses is that they are significantly more simple than the Apache license (they can be read and understood by most humble programmers), though they are maybe more appropriate for projects like programming languages that are less likely to step on toes in the patent arena.

In any case, the current list of languages is still very narrow - it should really be the OSI-approved list, since that allows the potential to discuss these other options, while still accepting pull requests. There's very little downside to keeping the outbound options broad - I've never seen somebody contribute a useful patch but refuse to release it under the terms of a CLA with outbound OSI licensing.

[Calinou]

Please note there are several BSD licenses: 2-clause, 3-clause, 4-clause and even 5-clause. It is important to clarify which one is being used.

This is why I recommend the MIT license, which doesn't have that "number of clauses" issue.

In any case, the current list of languages is still very narrow - it should really be the OSI-approved list, since that allows the potential to discuss these other options, while still accepting pull requests. There's very little downside to keeping the outbound options broad - I've never seen somebody contribute a useful patch but refuse to release it under the terms of a CLA with outbound OSI licensing.

The OSI approves non-free licenses like the NPOSL and the OpenWatcom license. It also doesn't approve CC0. This is a much better list of free licenses that also comes with comments: https://gnu.org/licenses/license-list.html

---

To date, the CLA says this:

2.3 Outbound License

As a condition on the grant of rights in Sections 2.1 and 2.2, We agree to license
the Contribution only under the terms of the license or licenses which
We are using on the Submission Date for the Material or the following additional
licenses: Apache License 2.0, GNU General Public License v3.0 only,
GNU Library General Public License v2 only, GNU Lesser General Public License v2.1 only,
GNU Lesser General Public License v3.0 only, or GNU Affero General Public License v3
(including any right to adopt any future version of a license if permitted).

Am I reading it right? No "or later" clause? Only the long and GPLv2-incompatible Apache 2.0 license as permissive license?

[FLIF-hub]

What I meant is GPLv3.0(+), LGPLv2, LGPLGv2.1, LGPLGv3.0(+), AGPLv3(+) and Apache 2.0.
Should I add MIT? Do we really want people to improve things without sharing back? Most projects would just want to use the decoder and shouldn't need to change anything in it, so LGPL or Apache2 should be good enough for them.

Anyway, does it really matter that much? This is just a reference implementation, I think the thing to focus on now is to finalize the format (in a future-proof way) and write out the specification.

[lehitoskin]

The LGPL/Apache2 are just fine. Listing all the other licenses when the maintainer himself isn't too keen on them is cruft.

[Calinou]

Should I add MIT?

Yes, definitely. It is a very simple license, making it attractive for users and developers. It also is the most used license on GitHub.

Do we really want people to improve things without sharing back?

Isn't Apache 2.0 the same thing? It lacks copyleft too. If you absolutely want this, then you can choose LGPLv2.1 or later, but this will complicate adoption on extremely closed platforms like iOS.

[boutell]

I would go with the most permissive license you can possibly stand, if your
end goal is to see the format in use in all major web browsers and devices.

libpng found its way into all major browsers and is still there. That
played a major role in its acceptance. I would advise not overestimating
the zeal with which people will rush to write independent implementations.

A good question is, what is the goal of using a copyleft license? If it is
to ensure that those making improvements and fixes contribute them back, it
makes sense to look at the history of libraries like libpng and the
Independent JPEG Group library. Both of these have very permissive
licenses, yet people have contributed fixes and optimizations. And both
appeared in major browsers at one point or another, although again
independent implementations may eventually have appeared.

Sourceforge has an incorrect statement that the IJG library is GPL. The IJG
library's license is even less strict than MIT, while the libpng license is
essentially an MIT license.

But that was before these licenses were so widely recognized, and in this
day and age it would be much better for broad acceptance to be
straightforward and just be under the "MIT license," rather than "almost."

On Sun, Oct 4, 2015 at 4:10 PM, Calinou notifications@github.com wrote:

Should I add MIT?

Yes, definitely. It is a very simple license, making it attractive for
users and developers.

Do we really want people to improve things without sharing back?

Isn't Apache 2.0 the same thing? It lacks copyleft too.

—
Reply to this email directly or view it on GitHub
#14 (comment).

*THOMAS BOUTELL, *DEV & OPS
P'UNK AVENUE | (215) 755-1330 | punkave.com

[FLIF-hub]

OK. I changed the template and CONTRIBUTING.md and now explicitly refer to a broad list
(https://gnu.org/licenses/license-list.html#GPLCompatibleLicenses) that includes the MIT license.

For now, I want to keep this GPL. I do want to give the FOSS world "a head start", and I absolutely don't mind if Adobe Photoshop or Microsoft Internet Exploder don't support FLIF from the beginning -- they would probably support it poorly anyway. If I can help to give The GIMP and other FOSS image tools and browsers a competitive advantage, then why not?
Of course eventually broad adoption will be needed to make this really work as an image format, especially on the web. So when it is a bit more mature, I want to move to LGPL, and then probably to even more permissive licenses, maybe the MIT license.

The point of copyleft in this particular case is that there is no spec yet, and no formal standard defining group or anything like that either. So I think it is important to avoid allowing proprietary variants of FLIF that are better in whatever way and which becomes the de facto file format, perhaps not even with a public spec. If I would have released this as public domain software without any form of copyleft, that could very well happen.

So, is the current version of the CLA good enough? Can we move on to discussion about the actual file format now? :)

[boutell]

That sounds better.

I understand the desire to avoid incompatible implementations before
there's a spec.

I was about to ask about the spec (:

On Mon, Oct 5, 2015 at 8:04 AM, Jon Sneyers notifications@github.com
wrote:

OK. I changed the template and CONTRIBUTING.md and now explicitly refer to
a broad list
(https://gnu.org/licenses/license-list.html#GPLCompatibleLicenses) that
includes the MIT license.

For now, I want to keep this GPL. I do want to give the FOSS world "a head
start", and I absolutely don't mind if Adobe Photoshop or Microsoft
Internet Exploder don't support FLIF from the beginning -- they would
probably support it poorly anyway. If I can help to give The GIMP and other
FOSS image tools and browsers a competitive advantage, then why not?
Of course eventually broad adoption will be needed to make this really
work as an image format, especially on the web. So when it is a bit more
mature, I want to move to LGPL, and then probably to even more permissive
licenses, maybe the MIT license.

The point of copyleft in this particular case is that there is no spec
yet, and no formal standard defining group or anything like that either. So
I think it is important to avoid allowing proprietary variants of FLIF that
are better in whatever way and which becomes the de facto file format,
perhaps not even with a public spec. If I would have released this as
public domain software without any form of copyleft, that could very well
happen.

So, is the current version of the CLA good enough? Can we move on to
discussion about the actual file format now? :)

—
Reply to this email directly or view it on GitHub
#14 (comment).

*THOMAS BOUTELL, *DEV & OPS
P'UNK AVENUE | (215) 755-1330 | punkave.com

[FLIF-hub]

About the spec: let's move that discussion elsewhere. Maybe to #17 ?
Because the biggest thing missing atm is metadata. I appreciate PNG's chunky stuff, but I think something like #17 would be easier to work with: keep the pixel data / "critical chunks" in one place, put all the metadata somewhere else. What do you think?

Another thing missing is robustness wrt transmission errors. PNG has CRCs on every chunk, while FLIF atm just has one big CRC at the very end, and that's it. Maybe some extra CRCs could be useful, but then again, I think it shouldn't be the responsibility of the file format to detect transmission problems. Perhaps those extra CRCs could be optional and part of the metadata?

[boutell]

The chunks are nice for metadata.

PNG got kicked around on the playground at first because very small GIFs
got bigger as PNGs due to chunk and CRC overhead. But I haven't heard
anyone complain about that seriously in a decade or more (:

.tar itself is archaic and probably a can of worms you don't want to open.
I understand the impulse to go with a pre-existing container format... but
perhaps PNG's chunk format is that format. Look at how PNG's chunk naming
conventions ward off the casual introduction of incompatible stuff.

By reusing a more general-purpose container format you might inadvertently invite
"kitchen sink syndrome" and wind up with TIFF (: