10:31 p.m.
Here's an idea, or rather half or so of an idea, I have.
Suppose all there is is source code (more precisely the preferred form
for making modifications); we live in a universe where there is no
object code or where object code is beyond the scope of copyright
(this is just for simplicity). A work is necessarily something digital
and presented as a set of one or more files. This is of course the
explicit basis for the weak approach to copyleft in the MPL and its
ancestors and progeny.
Although one might argue it is not so obvious from the language of any
version of the MPL (or ancestral or derivative licenses -- I'll just
say "MPL"), I think the common understanding, and certainly what makes
MPL a 'rule-based' (and possibly-necessarily) weak copyleft, is that
copyleft extends only to source files that are verbatim copies or new
downstream files which copy sufficiently from upstream ones. To try to
go further than this is what Jim was proposing in the epl-discuss
posting I noted in my previous post. The implicit, and sometimes
explicit, critique of MPL-family licenses by advocates for
orthodox-discourse GPL strong copyleft interpretation, is that this
leaves some possibility for circumvention of copyleft that is avoided
either by the actual language of the GPL or by some consensus around
its proper interpretation. The problem with the latter is the "legal
angst" that was referred to in the epl-discuss thread, which kind of
implies an absence of consensus, even in the weak copyleft context of
EPL 1.0.
Suppose I create a set of source files, S1. Someone downstream creates
S2 by copying some files in S1 verbatim, modifying some S1 files (such
that those files contain what is indisputably nontrivial literal
copying from S1), and adding some new files that indisputably do *not*
contain nontrivial literal copying from S1 (let us call that set of
new files N). Regardless of the source code programming language, in
the general case there will be dependency relationships among some of
the files in S1, and, independently, among some of the files in S2.
S2 might contain copyrightable code from third parties (as might S1)
but ignore that complication.
If I apply the MPL 'rule', I can easily figure out what files in S2
are in the scope of the copyleft coming from S1; I'll call that subset
T. It will not include anything in N.
There is a subset of the files in N, I'll call it N', that have direct
or indirect programmatic dependency relationships (according to the
nature of the particular programming language at issue) with files in
T.
Suppose the copyleft rule is this: as in MPL, files T must be licensed
under copyleft-next. Files N' can be, but need not be, licensed under
copyleft-next, and instead can be licensed under some sort of
acceptable FLOSS license, copyleft or noncopyleft. GPL, MIT, whatever.
Suppose further that the rule allows anyone to avoid the condition for
the licensing of files N' by distributing them separately. If you want
to distribute N' under a proprietary license, do it
separately. (Ignore the possibility of some definitional problem
here.) Otherwise those files have to be FLOSS, but the precise license
doesn't matter (within some defined limits).
Suppose further that copyleft-next has a clause (as some early
versions did) clarifying that no lawful uses under copyright law are
limited or excluded.
Also suppose that copyleft-next has some kind of safe harbor for
package-oriented operating system distros, app store vendors, and
similar things (such that the separate distribution circumvention is
something that the distro or app store vendor or whatever can engage
in without having to worry too much about it until notice is
received).
This is a strange idea, but it is a kind of stronger copyleft than
exists under MPL-like licenses. (Depending on the situation, and how
one interprets the LGPL, it might be weaker or stronger than the
LGPL.) It resolves the 'legal angst' in a number of ways: reducing
copyleft analysis to something like a simple static analysis problem;
making separate distribution an excuse (explicitly not so in GPLv3),
potentially avoiding a lot of the perceived problems of license
incompatibility across source file boundaries, ensuring closely
related code (distributed together) is FLOSS (even if noncopyleft in
isolation -- this is no different from what we see in some GPL works
today, and cf. GPLv2 section 2, antepenultimate paragraph). It
certainly allows modes of circumvention that are assumed to be absent
under interpretive-orthodoxy GPL (which itself is understood to allow
some modes of circumvention).
But apart from that, is this a bad idea, or a nonsensical idea?
- RF