[Pan-users] GPLv2(+) discussion (Was: Pan 0.135 Win32 build update)

[Duncan]

Petr Kovar posted on Thu, 20 Oct 2011 19:12:21 +0200 as excerpted:

> When we're at it: I was recently told that GPL, the license we use for
> Pan, requires us to reference or include all patches and instructions
> needed to build Pan. So if we release a binary version of Pan,
> regardless of platform, we should also put all the needed patches and
> instructions somewhere and reference them.

This is true.  See below.

> Probably the easiest way here to meet the requirements is to simply
> commit the patch to the Pan repo, or patch the configure.in script after
> some #ifdef modifications.

This topic is of quite some interest to me as it regards my legal 
freedoms as a user in relation to my software.  As such, I've paid 
particular attention to discussions on the GPL and its requirements over 
the years, but I am not a lawyer so don't take this opinion as if I were.

FWIW, it may be useful when reading this to refer to an actual copy of 
the license, like the one available from pan's about dialog.

Section 3 of the GPLv2 covers permissions and and conditions for 
distribution, tho it should also be noted that the GPL is designed to 
give the user/distributor permissions beyond those they'd ordinarily have 
from copyright law, not to further restrict, so anything ordinarily 
allowable by copyright law (which may vary by country) remains allowed.  
Further, paragraph 2 of section 0 states that activities other than 
copying, distribution and modification are outside the scope of the 
license, and section 5 explicitly states that you don't have to accept 
the license, but that it's the authority by which you are granted 
copying, distribution and modification rights (as otherwise prohibited by 
law in most jurisdictions, at least), so if you are distributing, you're 
assumed to have accepted the license as you'd otherwise be breaking the 
law.   The intend is not to restrict ordinary use outside those three 
(copying, distribution and modification), as when simply running the 
program, etc.

So we'll take a closer look at section 3.

Basically, there are three options for compliance, covered in subsections 
a-c.  However, the third one (c), allowing simple downstream 
(re)distribution of binaries without modification by simply pointing 
those interested in sources back to to upstream providers, is more 
restrictive than the others (non-coor very common community development 
practices would be in violation and would have likely never become so 
common as a resultmmercial only, applies in practice only to further 
binary-only redistribution), so it's of little use except to simple users 
wishing to share with friends, etc.

That leaves the two alternatives covered in section 3, subsections a and 
b.

Section 3 subsection a covers concurrent distribution of binaries and 
sources.  In practice, this tends to be the easiest compliance option for 
commercial distribution and those distributing modifications (who 
therefore can't use subsection c) as unlike subsection b, there's no
3-year mandate.  Section 3 paragraph 3 (last paragraph before section 4) 
makes clear than offering "equivalent access" to the sources (see below) 
at the time of binary distribution is enough, regardless of whether the 
third party actually procuring the binary (executable or object code) 
chooses to take the sources as well, or not.

That leaves section 3, subsection b.  This second option (the third we've 
discussed) allows accompanying the binary with a written offer to supply 
the sources, but there's a couple significant limitations that make 
subsection a preferable to most, once they've actually considered the 
options.

First, such offer to supply sources now applies to ANY requester, NOT 
just to those who originally got their binaries from you.  This is in 
fact the other end of subsection c, since you're now supplying not just 
those who originally got their binaries from you, but all those to whom 
/they/ may have further distributed those binaries in accordance with 
subsection c, and in fact, to any requester at all, since it's not 
required for such requester to have actually received a binary -- any joe 
blow can request the sources from you now.  (There is however one 
redeeming bit to this, the supplier is allowed to recover costs limited 
to those of physically performing source distribution.  Back before 
Internet distribution became the norm, this allowed the supplier to in 
effect recover postage and media costs.  I'm not aware of a case in which 
such charges were disputed, but it's pretty clear that charges in the 
hundreds of dollars aren't allowed, so it's quite possible they were if 
someone tried to take undue advantage of that.)

Second, there's a three-year clock that resets every time the supplier 
distributes a binary -- the sources must remain available for three years 
after the supplier distributed their last binary.

This one's the real kicker for most non-commercial and non-big-time 
distributors, including most community Linux distros, as maintaining the 
availability of legally compliant sources (again, see below) for three 
years after ceasing binary distribution can be a *BIG* compliance burden.

If the subsection b option is chosen, that means the distributor must 
track what exact version of sources (and automated build-scripts, etc) 
correspond exactly to each version of binary distributed, and ensure that 
they remain available to supply upon request to anyone who should ask, 
for three years AFTER they've quit distributing that binary!  Simply 
providing CURRENT sources (and build-scripts) is *NOT* enough, it must be 
possible to rebuild from the provided sources the SPECIFIC version that 
corresponded to a SPECIFIC binary for A FULL THREE YEARS after 
distribution of that binary ceased.

That's a *LOT* of rather precise record keeping and source and script 
archiving (the build-scripts potentially being the kicker in addition to 
the record keeping itself, since source management itself isn't a big 
deal these days as it's quite automated and has been for some time) for 
your typical small-time or individual developer community distributor.

So as I said, most distributors choose the concurrent availability option 
(3a) once they've examined the alternatives, since that way, once they've 
distributed the binary and the one procuring it has made their choice as 
to whether to procure the sources along with it or not (and procured them 
if so), the GPLv2 license obligations of the distributor are fulfilled, 
no three-year-clock and complicated record and archive keeping to worry 
about.

OK, the major point is covered, but there's still a couple loose ends to 
tie up, one of which was alluded to above but is important enough to 
consider on its own, especially as it's thread-topical.

The second sentence of section 3 paragraph 2 is worth quoting verbatim:

>>> For an executable work, complete source code means all the source
>>> code for all modules it contains, plus any associated interface
>>> definition files, plus the scripts used to control compilation and
>>> installation of the executable.

FWIW, sentence 3 of the same paragraph is the famous (in GPL context)
"system component exception", allowing GPLed works on MS Windows, for 
instance, to make use of system services without making the work legally 
unredistributable due to (otherwise) requiring distribution of the 
corresponding MS Windows sources.  This is what allowed the GPL to "work" 
in the early days, when virtually all GPLed software was built to work on 
proprietary systems, because there /were/ no freedomware systems to build 
and work on.

The legal implication of the above is that (with the system component 
exception), it's not just traditional source code that must be provided, 
but that source code, together with the make files and any further 
scripted automation of the build and/or installation process.  Gentoo 
users in particular should be aware of the significance of the scripts 
inclusion, since in that context, it'd include the package ebuild, any 
referenced eclasses, and probably the profile information as well.  (The 
package manager itself, and its dependencies, would probably be excluded 
under the system exception, however.  But again, IANAL.)  For RPM-based 
binary distros, it'd be the SRPMs and related spec files at least, and 
for other binary distros, the corresponding source-rebuild scripts and 
specification files, whatever they're called.


*** It's worth noting here what is arguably the most commonly held myth 
within the free software community:

*** Myth:  Distributing binaries and pointing to one's modification 
patches along with upstream sources is GPL compliance.

*** Fact:  At least according to the Free Software Foundation (FSF) and 
thus applying to software they own and distribute under the GPL (for 
other GPL software, the copyright owner or owners would make the decision 
as to whether they consider such an action sufficient or not, or arguably 
more importantly, whether it's worth pursuing legal action over), 
distributing one's patches as source and pointing to upstream for the 
sources they apply to is *NOT* legal compliance with the GPL, if one is 
distributing the resulting binaries as well (obviously one can distribute 
only the patch diffs as source, if not distributing the resulting 
binaries).  In effect, that's misuse of section 3 subsection c, which as 
explained above, applies only to non-commercial distributors of 
unmodified binaries.

This is an important principle since it helps to facilitate the 
availability of multiple distribution points, in effect making the free 
software system more robust and resistant to single-point failure, since 
it effectively requires anyone distributing modified binaries to be a 
distribution point for all required sources (not just the modifications), 
as well.

It can be noted, however, that there's nothing in the GPL preventing 
"outsourcing" the entire thing:  If the entity (company or individual) 
distributing modified binaries has a legally enforceable agreement with 
someone else to "host" the sources they're legally required by the GPL to 
provide, that's entirely fine.  Just be sure that you're comfortable with 
the legal viability of said agreement to the same degree (or higher) that 
you are with your compliance with the GPL, because in effect, that IS 
part of said compliance.

Thus, Petr's observation is absolutely correct.  If pan binaries for MS 
Windows are being distributed (as they are), whoever's building and 
distributing them is legally required to provide the full sources for 
those binaries, not just the modifications, including any scripts, etc, 
used to automate that process.

Of course, that's where the discussion above about concurrent 
distribution of binaries and sources, vs. written offer to provide upon 
request, with the latter valid for a minimum of three years after 
distribution of the binaries terminates, comes in.  Again, the concurrent 
offer is generally held to be FAR less trouble to manage, and with the 
three-year-clock offer in practice mostly relegated to those who haven't 
actually studied their options and the implications thereof, and to those 
who comply only reluctantly and are in general hoping nobody actually 
requests the sources.

(It's also worth noting the tactics of sveasoft and the like, here.  They 
do give registered users, only, the choice of getting sources, but upon 
the user actually availing themselves of that opportunity, they cancel 
the contract and the user gets no further updates, etc.  The cost of 
registration is sufficiently high to discourage most users from 
requesting sources, thus terminating further services under the 
contract.  Obviously the free software world isn't particularly happy 
with this sort of thing, but it does happen occasionally.  This is a 
legal shadow area that I don't believe has been fully resolved, I believe 
in part because at least the Linux kernel folks have a somewhat wider 
interpretation of the GPLv2 than does the FSF, and nobody owning rights 
to at least the kernel code has been willing to take these folks to court 
and settle the issue.  But definitely talk to a lawyer on this if it's of 
personal interest to you, since my knowledge of the area is very limited 
-- in practice as a user I simply steer well clear of such entities, and 
as a potential developer I'm not sufficiently skilled to have had to 
worry about pursuing legal recourse on code I own the rights to.)

If said modifier/builder/distributor of the binaries is not comfortable 
with their ability to provide full sources either concurrently or on 
request (for three years after distribution of the binary ceases), as is 
very likely to be the case here...

Then yes, by *FAR* the simplest solution is to get those modifications 
upstream, so there's no longer any modifications from the original to 
worry about.

Another option I've seen, especially with DSCM (distributed source-
control-management, like git, tho there are others) based repos, is 
upstream itself hosting multiple branches or entirely separate trees, one 
for each contributor/distributor.  The Linux kernel itself has just this 
sort of arrangement on git.kernel.org (recent security issues and 
subsequently more secure policies as it has come back up aside), and I 
was recently reading about some critical package, I think it was actually 
glibc but might be mistaken, where Red Hat actually has its own branch 
(or possibly entire tree/repo, IDR) in upstream itself.  (That actually 
makes quite a bit of sense for Fedora/RedHat and glibc, since it's a 
RedHat employee that's upstream lead developer as well.  I wouldn't be 
surprised if they have similar arrangements for other packages as well, 
given their position in the community and the number of lead devs for 
various packages they employ.) went into which historic binary releases.

A closely related variant on this is already in use to some extent for 
pan, given the number of pan2 github-based "forks" out there.

*** As a practical matter, all a pan-on-MS dev really needs to do is 
create a github account, fork a pan repo into it from his choice of 
available upstream forks already available there, upload his 
modifications to his github pan2 repo, and ensure that any time he links 
a new pan binary, he links the appropriate tag/branch/treeish on github 
as well, thus quite reasonably complying with pan's GPLv2 (3a).  Since 
it's a concurrent link, he doesn't have to worry, at least in terms of gpl 
compliance, about github failing or ceasing to offer free accounts for 
free software in the three-year-clock period, since the 3-year-clock only 
applies to (3b), and he's using (3a).  The only requirements would be to 
ensure that he always posts the two links together (or only the sources 
one, never only the binary one), that the sources link is to the sources 
corresponding to the specific code used to build the binary (keep them in 
sync), and that if github /does/ go down, disappear, out of business, 
whatever, he ceases posting links to the binary until such point as other 
source provision arrangements are made.  Since the link was concurrent 
for previous posts of the binary, there's no clock to have to worry about 
and no need, at least for gpl compliance reasons, to worry about tracking 
precisely what version of the code corresponded to specific historic 
binaries.

That's what I'd try to do if it were me shipping those modified binaries.

One more time, in case anyone forgot in the above discussion.  I am not a 
lawyer.  Don't mistake me for one as that might prove quite an expensive 
and disastrous mistake!


That leaves one more loose end, which I've been meaning to ask about for 
some time.  This would seem the appropriate time.

As far as I can see, pan is GPLv2 only.  Not GPLv2 or later, not GPLv3, 
not whatever future GPL there might be, GPLv2 only.

This would seem to be the case because I don't see the usual "version 2 
or any later version" language, but DO see GPLv2, specifically, in 
various places including the source code files themselves, so it would 
appear to be GPLv2 only (see section 9).

I haven't the foggiest idea what Charles thought on that, except in as 
much as the code /does/ seem to indicate (by omission of other 
indication) v2 only, that he might at least have had questions in regard 
to GPLv3.

Further, given the apparent GPLv2 status and the number of contributions 
from others over the years, it may not be practical to relicense pan to 
GPLv3+ even if the current developers (and Charles) wished to.  But, it's 
likely that the C++ rewrite first released publicly as pan 0.90 
eliminates much or all of the issue for previous code (fortunately, 
copyright, unlike patents, only applies to verbatim code and direct 
derivatives, not the ideas behind them), so it's not as impractical to 
consider GPLv3 and/or other relicensing, were it desired, as it would be 
were we still using the old C code base (thru 0.14/0.15-ish).

So, five questions:

1) Confirmation: Does this observation appear correct to others, or is 
there an "or later version" that I've overlooked?  (I've obviously seen 
the mention in section 9 of the GPLv2 itself, but that doesn't specify 
pan's version.)

2) What are the thoughts of others here, particularly developers, 
concerning the GPLv3 and/or "or later version" language, either specific 
to pan or in general?

3) To those with any code in pan at all, patches or otherwise, do you 
claim ownership or not (trivial patches are often viewed as 
uncopyrightable, but the borderline on just what "trivial" is, is a 
definite gray area, so...)?  (This obviously assumes that Charles and 
others didn't require signing over rights, but I'm not aware of any such 
requirement for pan, ever.  Maybe in some prehistoric (to me, switching 
in 2001) 90s era...)

4) If you claim ownership, would you even consider a different license, 
and under what conditions (strict copyleft, loose copyleft like the MPL, 
liberal MIT style, other considerations)?  (This obviously assumes that 
such relicensing is decided to be practical at all.)

5) Perhaps most importantly, is anyone aware of any pending or future 
license compatibility issues with pan either remaining at GPLv2, or 
switching to GPLv3 or other.  (FWIW, at least gentoo lists gtk+ as 
LGPLv2, so pan should be fine there with GPLv2, GPLv2 or later, or a more 
liberal MIT style license, at least, for some time.  AFAIK they've cited 
LGPL as a feature, so they're unlikely to move from that, tho conceivably 
they could try LGPLv3.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman