Many people off-list have been asking me to comment on this discussion, because (like Richard Fontana) I'm a co-author of AGPLv3, and I also (back in the early 2000's) invented the original licensing idea behind the AGPLv1.
I thus care deeply about the license and believe it's an important policy plan for the future of freedom in the age of network services. (I gave a talk at SCALE 2013 about this specific issue, if folks are curious about that: https://lwn.net/Articles/541981/ .) Upon catching up on this thread, I believe most of what needs to be said about the issue for Debian's perspective has been said. Nevertheless, I do want to point out that I think three separate issues have been conflated in this thread: (a) Is the AGPLv3 a DFSG-free license and should it remain such? (b) Is it a bad policy decision for Debian generally to have a core library, used by many other packages under AGPLv3 -- thus causing a move of licensing of more packages toward an effective AGPLv3 license, due to the combining those packages with an AGPLv3'd library. (c) Even if (a) and (b) are settled in as "Yes", and "No", respectively: is Oracle, given its history of abusive copyleft enforcement (by refusing to allow full compliance as an adequate remedy and demanding the purchase of proprietary licenses by license violators), too dangerous for Debian and its downstream? On (a), I think Paul Tagliamonte has summarized the issue best: Paul Tagliamonte wrote at 09:15 (EDT) on Tuesday: > The AGPL is a DFSG free FSF approved and OSI approved free software > license? We made a decision, it's *free software* and fit for main. I too believe that issue is decided and should be left alone. On (b), I think the discussion about apt needing to be (effectively) AGPLv3-or-later to continue using BDB is salient. I, for one, would like to see such a thing, but I'm a biased party who co-authored AGPLv3 and believe in its policy goals; I'd like to see more software under AGPLv3! But, I also see it from the point of view of Debian developers who might feel this sort of policy change is too drastic a move to the strongest copyleft available. I know that some have complained that compliance with AGPLv3 may require more work by Debian redistributors. That is a reasonable concern, but I think the issue can be mitigated. The argument is roughly analogous to this one: complying with GPLv2 is more difficult than complying with the Apache license. But, unless Debian wants to take a wholesale position opposed to copyleft, I don't think this issue is or should be considered insurmountable. Indeed, I think that issue is what's being considered in this exchange between Ondřej and Fontana: Ondřej Surý wrote at 12:20 (EDT) on Tuesday: >> 2. AGPLv3 is incompatible with Apache 2.0 license (http:// >> www.apache.org/licenses/GPL-compatibility.html) Richard Fontana wrote at 13:03 (EDT) on Tuesday: >>> Only in the same sense that GPL or LGPL (any version) is >>> incompatible with any noncopyleft license in the >>> copyleft-to-permissive direction. The Apache License 2.0 is >>> compatible with AGPLv3 in the other direction. I wouldn't frame the debate as Fontana has, but I agree that there's an issue that copyleft has a certain one-way magnetism to it (by design). And, the stronger the copyleft, the stronger the magnet. Once a package has copylefted parts, the whole package must be considered to be licensed under the strongest copyleft present. That may be too big a leap for apt, but again: that's a policy decision for Debian developers. Finally, I suggest that the last issue, (c), should be decided separately from those first two. Even *if* programs like apt can reasonably be placed under the AGPLv3, we know that Oracle, per its MySQL aggression... Ben Hutchings wrote at 09:48 (EDT) on Tuesday: >>>> If the relicensing is real and not another misconfiguration of the >>>> build/release system (like with MySQL docs), this sounds like a >>>> shakedown for proprietary users of Berkeley DB. GPLv2-licensed >>>> users are collateral damage. ... is known to use copyleft licenses as aggressive weapons to force the sale of proprietary licenses. Note, however that Sleepycat had roughly the same business model with its "copyleft license hidden behind BSD-like" license drafting. As such, the only *real* changes I see here are: (0) an even stronger copyleft is being used and (1) Oracle has a lot more resources for aggression than Sleepycat did before acquisition. Admittedly, though, (c) is a very complex policy question, and it's precisely why I have great trepidation when a codebase is single-copyright-held by one for-profit company. BTW, I'd suggest a rather unorthodox solution if developers are interested: fork this AGPLv3'd version of BDB, and begin making substantial improvements and changes under AGPLv3. That way, Oracle isn't the sole copyright holder, and if Oracle were to take action under a clause of AGPLv3, other copyright holders could intervene and indicate they disagreed with Oracle. If the case went to litigation, Oracle would have a tough time because the other copyright holders would be expert witnesses (in the USA sense -- not sure what the equivalent is elsewhere in the world) who were saying Oracle was acting unfairly and over-reading the license terms. (I'd certainly be willing to be an expert witness as the license's co-author in such cases.) This solution is better than forking under the old Sleepycat license, since it will help establish estoppel against Oracle being the only valid interpreter of AGPLv3 with regard to the BDB. Other copyright holders of the fork will have a big say, and perhaps a greater say than Oracle, ultimately. Doing that for the Sleepcat license seems somewhat pointless, given it's not a one-off license used only (now) for old versions of BDB. I remain willing to assist Debian as it investigates these questions. I'm subscribed to debian-legal and will see posts there, but please cc me on debian-devel side, as I'm not a subscriber there. -- -- bkuhn -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehbfmzch....@ebb.org
