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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
