The effect of this change should be that there is no need for a strong/weak
copyleft distinction of the historical (i.e. GPL vs. LGPL) sort.
A definition of 'Public Interface' needs to be provided.
This clarification is taken from GPLv3, where it was inserted to
mollify concerns of patent-holding companies overly worried about the
potential effects of GPLv3 on their portfolios. It is obvious from the
definition of Licensed Patents that it cannot extend to claims first
infringed by further modification of My Code.
This commit also clarifies the exemplary nature of Appendix A, moves
the "GPL" definition to 2c, and moves the Corresponding Source
definition to 2d, renamed 'Ordinary Corresponding Source'.
This provision incorporates the AGPLv3 interpretation of RMS and
bkuhn, according to which a mere distributor of a modified version
must design the software in such a way that, when run to provide a
network service, it reasonably can be expected to inform users how to
get the source code (in addition to the requirement applying to the
mere network-service-deployer of a version modified by the deployer).
This was inspired by Apache License 2.0 section 5. I think the value
of including this is not worth the effort of getting it right.
copyleft-next projects will live without this provision in an
inbound=outbound world and can be encouraged to make use of the DCO or
similar contribution mechanisms. There is also an argument that
including this provision suggests that it is necessary.
This was in a sense a partial legacy of GPLv3's 'internationalization'
feature. I am no longer convinced it is particularly useful. It is
true that now the license is clearly a creature of US copyright law
terminology, but the same may be said of so many FLOSS licenses which
see very wide use.
An appendix list of compatible licenses is introduced and is said to
be nonexhaustive and illustrative. The issue of conflicts between
copyleft-next and explicitly-compatible weak copyleft licenses (the
appendix lists MPL 2.0 and EPL) is addressed by saying that the 2c
copyleft condition can be ignored to the extent necessary to comply
with such weak copyleft licenses. It is also made clear that the the
license compatibility permission does not contract the scope of the
Corresponding Source requirement when Object Code is Distributed.
This removes the MPL 2.0-style conspicuousness of sections 12 and 13.
New section 13a allows distributors to include additional disclaimers
or to include a copy of copyleft-next with, for example, all or part
of the contents of sections 12 and 13 capitalized.
I note that in three decades or so of free software there has been no
known instance in which lack of conspicuousness in warranty
disclaimers or limitation-of-liability provisions had any adverse
consequence. I further note that a number of FLOSS licenses carefully
drafted by lawyers outside the US have corresponding provisions with
no typographical effort to improve conspicuousness. These licenses do
not cover a large amount of software, but they cover packages found in
mainstream Linux distributions distributed in the United States as
well as other countries.
I have deleted the final sentence on the assumption it is not really
needed.
Lack of need for "to the extent of Your copyright in the Patch" was
noted by Pam Chestek IIRC.
The purpose of this change is best explained with an example.
If a Python file foo.py contains the line 'import bar', where bar is a
library licensed under copyleft-next, the mere inclusion of 'import
bar' without anything more is not in itself enough to make foo.py a
Derived Work of bar (regardless of whether it might otherwise fit the
definition of Derived Work).
However, if bar also contains some statement from the licensor like:
Licensed under copyleft-next. Any code that imports bar, and which
otherwise meets the definition of 'Derived Work' of bar in
copyleft-next , shall be considered a Derived Work of bar even if
such code is not distributed with bar.
then foo.py in itself falls within the copyleft scope of bar provided
that it meets the definition of 'Derived Work'.
A substantive change here is that 'GPL' now means the GNU AGPL as well
as the GNU GPL, so the MPL 2.0-like compatibility mechanism of section
3, paragraph 2 now allows for AGPL compatibility directly. This is
done principally to reduce the verbosity that was previously
introduced into following section.
There is arguably some redundancy between the more specific section 3,
paragraph 2 and the more general section 4, paragraph 2, with respect
to 'GPL' compatibility (ignore the fact that 'GPL' includes the
non-OSI-Approved GPLv1). However, I think this is really not so, as
the 'compliance' in the 'GPL' case for section 4 purposes would not be
clear without section 3, paragraph 2. (?)
