Update 2012-08-02
by Richard Fontana
Here's an update of what's been going on with the copyleft-next draft.
Deletion of dl-supp
===================
The biggest change of the past week was my deletion of "dl-supp". In
an earlier commit, I moved the "anti-Tivoization" provisions derived
from the second part of GPLv3 section 6 into a supplementary document
which an initial licensor could place on a new program. I now see no
point in even having it as a supplement.
Thus, copyleft-next has no anti-Tivoization provisions, and so the
patch originally proposed by mcgrof (see
<https://lkml.org/lkml/2012/7/12/401> ) has now effectively been applied.
A lot of careful thought and discussion went into the corresponding
provisions of GPLv3. They represent the result of a difficult
compromise, and are motivated by policy goals for which I have deep
personal sympathy. I contend that they are among the best-drafted
parts of that license. The policy concern about locked-down consumer
devices with effectively nonmodifiable GPL-licensed software has
become more relevant in the years since those provisions were drafted.
Yet, with respect to GPLv3, it has been my own intuition that few
projects consciously choosing that license do so because of the
anti-Tivoization provisions. I do not have the sense that the
inclusion of these provisions in GPLv3 has had the effect of
increasing users' freedom to modify software in consumer devices they
own. To the contrary, it appears if anything to have motivated
risk-averse companies to avoid use of GPLv3-licensed software. That is
not dispositive but it is relevant. (There may be evidence to the
contrary that I am unaware of.)
I'm open to being convinced that this deletion should be reverted, but
if no one successfully convinces me, it is likely to stay deleted.
Part of what influences me is the availability of outbound (A)GPLv3
compatibility. As with the more obscure 'contractor' provision of
GPLv3 section 2, those who care strongly about these provisions will
be able to incorporate copyleft-next code in GPLv3-licensed works.
Deletion of first part of anti-anti-circumvention provision
===========================================================
While I currently continue to feel it is worthwhile for copyleft-next
to explicitly address anti-circumvention law, I no longer consider the
first paragraph of what was GPLv3 section 3 to be desirable.
The basic idea here was the hope that courts would be influenced by a
general declaration by the licensor that covered works are, in some
sense fundamental to the license, not 'effective technological
protection measures'. There is no known history of use of this
provision by those defending against invocation of anti-circumvention law.
This strikes me as being an inherently weak provision, but, the less
weak one assumes it is, the more problematic it becomes from a free
software perspective, since it approaches something like a field of
use restriction. That certainly is not what the FSF intended, but that
lack of intent does not make the discomfort go away.
The reason for effectively two (or three, depending on how you look at
it) anti-anti-circumvention provisions had to do with concerns about
differences between US and EU approaches to anti-circumvention law. I
consider it better to come up with one provision suitable for major
jurisdictions in which the license is likely to be granted. A
modification of the second part of what was GPLv3 section 3 is a
better basis for such a provision.
Further changes to termination
==============================
In response to discussion on the mailing list, I have changed the
EPL-inspired "reasonable time period" cure to a 30-day cure.
I have also eliminated the relatively complex "automatic termination
-> provisional automatic reinstatement -> permanent automatic
reinstatement' feature which was originally added to GPLv3 section 8
in the final draft. I have explained this in a posting to this list
made earlier today.
Deletion of liberty-or-death example
====================================
This is a noteworthy change. If people think that we need the example
given in GPLv3 section 12, let me know.
- Richard
10 years, 12 months
Update
by Richard Fontana
Here's an update on some of what's been going on in the copyleft-next
draft since a week ago.
One of the more significant changes is a substantial simplification of
the termination section. For what are best summarized as "historical
reasons", GPLv3 has effectively two cure provisions (interestingly,
MPL 2.0's drafters chose to adapt much of the GPLv3 language). I've
replaced it with one cure period and I just refer to a "reasonable
time period" (cf. EPL 1.0) instead of the 30-day and 60-day periods of
GPLv3. I'm not convinced that it's better not to have a fixed time
period for cure, though I am convinced that a 30-day and a 60-day
provision are not both needed.
The structure of having automatic termination coupled with automatic
reinstatement upon cure is preserved. This is unusual but it reflected
concerns expressed by those active in GPL enforcement in Germany that
automatic termination facilitated enforcement under German law.
I have added a 'severability clause' which is a common feature of
contracts and is found in a number of FLOSS licenses. The FSF opted
not to have a severability clause in GPLv3 out of concern that it
could lead to unpredictable judge-made alterations of the GPL that
might frustrate basic policy objectives. The advantages of a
severability clause seem to me to outweigh this concern. (GPLv2 has a
limited severability clause in its 'liberty-or-death' section, which
was removed from GPLv3.)
I added a section at the beginning giving a 'general rule of
construction', in some ways replacing one function the GPL Preamble
ought to serve. The language here was adapted from the Preamble of
Allison Randal's experimental short GPLv3 alternative which she
drafted in 2007.
I deleted the lengthy yet narrow provision I call, for lack of a
better name, "child of downstream shielding" (GPLv3 section 11
paragraph 5). This is actually a very important provision for
historical reasons, as a guide to understanding the FSF's
interpretation of the GPL, but I believe it has proven to have little
value in the license itself. With this deletion, note that all the
patent-related provisions of GPLv3 are now gone except for the
Licensor's patent license grant (which has been restructured but, at
least as I conceive it currently, is not different in scope from the
patent license grant of GPLv3).
Sadly, vanilla copyleft-next is still over 100 lines longer than the
Apache License 2.0, but great progress has been made. :-)
- Richard
11 years, 1 month
Harvey Birdman cure
by Richard Fontana
Today I had a telephone conversation with Bradley Kuhn in which I
noted that copyleft-next (vanilla version) was nearly ready for its
0.01 release, the main obstacle being that the definition of "System
Library" remains undone. I suggested (though I wasn't quite this
specific) that an explicit GPL-style system library carveout from
"Corresponding Source" (or from "Derived Work") might not even be
necessary.
- RF
11 years, 1 month
Update 2012-08-08
by Richard Fontana
Here's an update of what's been going on with the copyleft-next draft
during the past week:
While Bradley Kuhn's attempted resurrection of the anti-lockdown
provisions has failed, I incorporated some of his suggestions for
improvements in the definition of Corresponding Source (including a
recent change that addresses the 'know-how' issue).
I have put a "FIXME" for the System Libraries definition, as, to be
frank, all definitions of this exception in all versions of the GNU
GPL are suboptimal and if we wish to preserve this concept at all we
need to start over. (Query whether it's actually needed anyway.)
I deleted the 'rule of construction' in response to some criticism
from Luis Villa, but I might restore it in response to some of his
further comments on said deletion.
I deleted the "inbound=outbound" provision adapted from the Apache
License 2.0. I think this is difficult to draft *well* and may not be
worth the effort. In many cases, contributions to a hypothetical
copyleft-next project will be themselves 'Derived Works', and I have
argued publicly in various talks and writings that FLOSS legal culture
features the inbound=outbound custom anyway.
The patent license grant is arguably broadened from GPLv3 by referring
to 'Covered Works', although perhaps this is best seen as a
clarification. In this I was influenced by the patent license grant in
the Microsoft Public License.
I considered and discussed on the mailing list a provision that would
attempt to achieve compatibility with EPL. I ended up not including
this, though I am still open to the idea.
The anti-anti-circumvention waiver/disclaimer is clarified as
something that the initial licensor and all 'Distributors' make. At
least with the deletion of the first part of what was GPLv3 section 3,
it was not clear that the initial licensor was making the same
waiver/disclaimer as downstream parties.
I applied Luis Villa's proposal to delete the written offer option
from the object code distribution section. No one came to its defense
on the mailing list. It is gone!
In the past few days I've been experimenting, probably too much, with
rearranging sections and subsections and typographical presentation
and such.
I deleted the anti-patent-litigation condition descended from the end
of GPLv3 section 10 and replaced it with a provision closely modeled
on the patent peace provision in MPL 2.0 (and put it in the
termination section). I did so despite having some concerns about the
breadth of the MPL provision.
The old liberty-or-death provision is now reduced to one sentence in
the no-further-restrictions section.
I removed the ancient clarification that you can charge for
distribution or services, as hopefully obvious by now.
Apart from the draft, I made some modifications to the Harvey Birdman
Rule (as it is again known).
copyleft-next (ignoring ws-supp) continues to shrink: it is now at 270
lines and 1620 words. Of course, that's with the placeholder System
Libraries definition.For comparison, the Apache License 2.0 is 202
lines and 1581 words.
The Object Code Distribution section makes up about one quarter of
copyleft-next
- Richard
11 years, 1 month
What do copyleft licenses gain from an acceptance clause?
by Bradley M. Kuhn
The following is a Harvey Birdman Rule conversation disclosure.
At LinuxCon, Fontana and I were discussing his change in:
commit 5823daf41d2bbb757e49b87b8e697fd793317019
Author: Richard Fontana <fontana2012(a)gmail.com>
Date: 2012-07-05 18:44:45 -0400
Wherein he removes the acceptance clause entirely from copyleft-next. I
argued briefly that perhaps the acceptance clause was useful, because it
allowed a contract claim to more easily be brought when copyright
infringement has occurred (basically as a secondary cause of action
and/or legal claim, which could be argued in the alternative of
copyright infringement).
Ultimately, I agreed with Fontana that perhaps the acceptance provision
isn't terribly useful from an enforcement perspective, because copyright
law gives us all the tools we need, and we don't get specifically an
additional enforcement claim simply because the entity engaged in
activities governed by copyright law is reminded of their obligations
and that they have no other license.
However, this question probably deserves more study, as if there is some
additional benefit that GPLv2 and GPLv3 families of licenses are getting
from having an acceptance clause, then one should also be present in
copyleft-next.
In particular, Fontana notes that it might be possible that the
acceptance clause is doing something different entirely unrelated to
bringing forth a contract claim.
--
-- bkuhn
11 years, 1 month
best way to describe the contents of "Corresponding Source"
by Luis Villa
On Sun, Aug 5, 2012 at 7:30 AM, Bradley M. Kuhn <bkuhn(a)ebb.org> wrote:
> Luis Villa wrote at 22:57 (EDT) on Friday:
>> That should be "any scripts..." not just "scripts", no?
>
> What is the point of adding 'any'?
In this context, "any" would typically be read to mean '"every", with
the additional implication that "every" was not used because there
might not be such scripts. So long as no other part of the language
does not explicitly require such a script to exist (which is currently
the case), it is essentially the same as your proposed "all," because
both "any" and "all" permit the case where no such scripts exist.
I suggested this because Richard's original language, without either
"any" or "all", was ambiguous as to whether or not the scripts were
required, and my sense is that "any" (i.e., permitting there to be no
scripts existing) was what was intended.
If instead the license is intended to require that such scripts exist
(which is perfectly reasonable) neither "any" nor "all" does that with
100% clarity. It would be much better to say something like "and must
include the scripts and instructions necessary..." Or perhaps, better
integrated into the rest of the definition
"Corresponding Source" of a work means all the Source Code needed to
build, compile, generate, modify, install, and run the work (to the
extent those activities are meaningful for the work), * including
scripts, instructions and configuration files that can be used [are
used?] to perform those activities.*
Obviously "are used" is extremely strong, as it prohibits having
parallel build systems (one that can be used internally and one used
by GPL licensees).
I dislike "know-how" because it is insanely vague. Much better to list
the things (like configuration files) that might contain such
know-how.
>> I've never been sure what "control" means in this context. Given that
>> "perform" is probably broad enough to completely encompass "control,"
>> and given how comprehensive the list of tasks is now (it's arguably
>> impossible to "perform" a build without some form of control) I'd be
>> inclined to replace "control and perform" with simply "perform," or
>> else give a more specific definition of "control" (e.g, by reference
>> to configuration files.)
>
> I actually think "scripts used to control compilation and installation
> of the executable" is effectively the same as what I wrote in my
> original patch, but I've seen weasely lawyers argue otherwise to defend
> their GPL-violating clients, so I
> think we need as much text in there as possible. We should keep adding
> verbs until we can't think of any more.
I'm not necessarily against adding more verbs (especially in the first
group (build, compile, etc.)) but I think the license is stronger when
the drafters can clearly explain and describe what each verb they put
in means :) Control has always been problematic this way because in
common parlance scripts don't "control" - they perform or act, and
configuration files or command-line options control. So I like the
simple "perform" because it makes clear that the goal is to do that
first set of actions, instead of burying it in other verbs.
[Building on that last sentence, here's a radical rewriting of the
sentence at issue, though I'm not 100% sure it works:
"Corresponding Source" of a work means the Source Code of all
materials needed to enable You to generate, install, and run the
Received Work, including [but not limited to] scripts, instructions,
and configuration files."
I like this because it puts the emphasis on enabling the recipient's
rights; if the recipient can't generate/install/run the work, then by
definition they are not enabled and the requirement is not satisfied.
I like "generate" because again it focuses on the outcome (that the
work is generated from the Corresponding Source) rather than specific
technical means of achieving that end (building, compiling).
I put [but not limited to] in brackets because, while commonly used,
it probably shouldn't be:
http://www.adamsdrafting.com/2007/04/02/including-without-limitation/
I don't like that this makes it theoretically impossible for a
Distributor to know, a priori, if they are in compliance, since they
don't know who "You" will be, or what capabilities You will have, but
obviously that can be read as a feature and not a bug. :)
]
Luis
11 years, 1 month
Some initial comments on the copyleft-next draft
by Richard Fontana
Hi,
During the past two weeks I've been working on modifying a document that
started out as the text of the GNU GPLv3 but which is now quite
different. I've had gracious help from several other people, but so far
it's fair to say that most of the *policy* decisions underlying the
various changes have come from me (IOW you can blame me for almost
anything in the draft thus far if you disagree with it). I thought I'd
provide a summary description of the more interesting aspects of what's
been done.
I deleted the following elements:
* The Preamble and the 'How to Apply' appendix
* The patent-related provisions that were introduced to GNU GPLv3 in the
wake of the Microsoft/Novell deal of late 2006
* The old requirement to preserve legal notices in user interfaces
* The acceptance provision (proposed by James Vasile)
I removed the so-called 'anti-Tivoization' provisions of GNU GPLv3
section 6 out of vanilla copyleft-next and into a separate document
currently called "dl-supp". I also added a separate document called
"ws-supp" containing substantially similar text to the first half of the
GNU AGPLv3 section 13. I don't think I really explained this in the
commit logs so I'll go into that a bit here. The idea is that the
vanilla version of copyleft-next won't have an 'Affero clause' (much as
GNU GPLv3 doesn't) and, unlike GNU GPLv3, it won't have
'anti-Tivoization' provisions. Only the *initial* licensor (someone
who's starting a new work from scratch) can choose to supplement
copyleft-next with one of those "supp" documents. Currently, vanilla
copyleft-next is incompatible with {copyleft-next + dl-supp} and
{copyleft-next + ws-supp} (much like "GNU GPLv2-only" is incompatible
with GNU GPL3) (i.e. there's nothing corresponding to GPLv3/AGPLv3
cross-compatibility), though this is just because I deferred thinking
about whether there should be compatibility or not.
I added a provision similar to Apache License 2.0 section 5 which is
something like a built-in "inbound=outbound" contributor agreement for
projects. (While I like this Apache feature very much it is a bit
awkward in copyleft-next in its current form.)
I added a provision to the basic copyleft clause that is designed to
remove the copyleft requirement if the licensor separately offers a
proprietary commercial version of essentially the same software. Maybe
this isn't worthwhile, but it was something I'd wanted to experiment
with trying to implement for a long time.
I added a provision making copyleft-next relicensable under GNU
GPLvn/AGPLv (the importance of this was impressed on me by Mike
Linksvayer and it also addresses the FSF's reasonable concerns about GNU
GPL derivatives).
I added a "no trademark rights granted" clause (similar to what's in MPL
and the Apache License 2.0).
The old additional terms section has been drastically simplified and
combined into the 'no-further-restrictions' section.
I won't go into detail about the remainder of the changes in this
message but I'd describe them generally as aimed at substantial
simplification and normalization of language and structure. To take one
example, the patent license grant of GNU GPLv3 is essentially the same
but it is presented very differently: it now accompanies the basic
copyright license grant in the 'basic permissions' section early in the
license (this is more like how other free software/open source licenses
with patent license grants are structured, and I think it may be easier
to understand).
I consider nothing of what I've done to be necessary or above criticism,
but I think it gives you a sense of the direction I'm generally going in.
This might be the most lightly trafficked mailing list in the entire
legal history of free and open source software, but I'd be happy if it
could serve as a forum for discussing, suggesting or criticizing ideas,
and also as one way of submitting patches against the license draft.
For those who don't know, currently I've been hosting the repository at
https://gitorious.org/copyleft-next and mirroring at github
https://github.com/richardfontana/copyleft-next
There's an IRC channel #copyleft-next on Freenode though so far the only
discussion there has been bcotton and I talking about today's weather in
Massachusetts. :-)
- Richard
11 years, 1 month
app stores and copyleft.next [was Re: has anyone done a proof of concept permissive.next based?]
by Luis Villa
On Thu, Sep 27, 2012 at 6:17 AM, Richard Fontana
<fontana(a)sharpeleven.org> wrote:
> On 09/27/2012 02:47 AM, Kuno Woudt wrote:
>
>> A license which is currently "missing" on that spectrum is a copyleft
>> license compatible with the current popular app stores.
>>
>> The microsoft and apple app stores are fairly hostile toward free
>> software developers, but they do have a considerable market share. So I
>> think there are free software developers who would be interested in a
>> license which achieves the aims of copyleft insofar that is allowed by
>> the common app store agreements.
>>
>> Has anyone given this any thought?
>
> I haven't thought about it (until now) in connection with
> copyleft-next, but this is a good suggestion to consider. The problem
> seems analogous to the problem that the old GPL system library
> exception was trying to solve (or clarify).
For what it is worth, I don't think that this should be something
"along the spectrum" of licenses; it should be possible even with
strong copyleft licenses, assuming a "neutral" app store (i.e., one
that does not impose additional technical or legal restrictions). But
I also think copyleft.next takes care of this as already drafted.
e.g., as far as I know, most app stores would:
* comply with the first two points Sec. 4 of copyleft.next (which
really should be (a) and (b) for ease of reference, Richard, not
bullet points)
* comply with Sec. 5 (the only arguable derived work the store is
distributing is the binary; they're not otherwise modifying the work,
so this should present no obstacle for the stores)
* comply with Sec. 6 (note that this really isn't something you can
"comply" with; it's not really a condition so I think perhaps the
reference to it in the third bullet of Sec. 4 is incorrect?)
* comply with Sec. 8(b), presuming that the person who uploads to the
app store ensures that "clear directions" are present and that
distribution from a web location is considered a "reasonably
equivalent manner" to an app store (which IMHO it should be).
Sec. 7 is the tricky one. As long as some requirement of that sort is
maintained (which I think it must be, or else you open a gaping
loophole in the license) then each app store has to be evaluated
separately with regards to both their legal and technical policies, to
see if they introduce further restrictions. But that's a concern for
particular app stores, not the concept of app stores generally.
Luis
11 years, 2 months