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, 5 months
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, 5 months
in defense of the TGPPL idea
by Zooko Wilcox-O'Hearn
Folks:
Mike Linksvayer asked me if I was aware of Ted Ts'o's Temporary
Proprietary License. I was not consciously aware of it when I
developed the Transitive Grace Period Public Licence. I exchanged
email with Ted about it later.
One particular detail of my TGPPL that I value and that I'm not sure
the TPL provides is that if you take advantage of the permission to
keep a derived work temporarily proprietary, then this obligates you
to offer the same permission to people who make worked derived from
your derived work.
Make sense? So when I publish source code under the TGPPL, I'm not
offering people the option of making a derived work, keeping it
proprietary for a limited time, and then releasing it under a strict
copyleft which disallows others from making time-limited proprietary
derived works of it. On the other hand, I *am* offering people the
option of making a derived work, making it Free/Open immediately, and
disallowing others from making a proprietary derived work from it,
even for a limited time.
The latter option is currently the case for Tahoe-LAFS and the other
software that I release in this way because I offer the recipient the
choice of GPL or TGPPL. So if you want to make a derived work of
Tahoe-LAFS without allowing anyone "downstream" of you to make a
proprietary derivation of your work, even for a limited time, then you
can do so by releasing your derived work solely under GPL.
I'm interested in developing a "TGPPLv2" which is expressed as an
"Additional Permission" to GPL. That would have exactly the same
consequences as the current TGPPLv1, sketched above, but it would
probably be better in a lot of ways to have it expressed as an
"Additional Permission" to GPLv3+.
Mike posted some criticism of the very idea of TGPPL which I'd like to
(briefly‽) address.
Mike wrote:
> It may be possible to demonstrate theoretically that an in-between tweak is necessarily superior to both, but not with any precision, and I'm dubious even of this.
I agree that reliable evidence about this is difficult to come by.
Nonetheless, I believe I should act based on my current understanding
rather than hesitate while looking for better data.
I personally have pretty high confidence that copyright maximalism,
including "Limited Time → ∞", will yield a worse social outcome than
some alternatives. More controversially in some circles (presumably
including this one), but less controversially among mainstream
economists, I have pretty high confidence that pure copyleft, in which
"Limited Time = 0", will yield a worse social outcome than some
alternatives.
My reason for believing that latter assertion is that I think the
production and usage of Free/Open software on earth has grown only
modestly over the last couple of decades, while production and usage
of all software has exploded immeasurably. Software has changed
everything for billions of humans, it appears likely to do so even
more rapidly in the coming decades, and Free/Open software is less and
less important to that. Free/Open software is a tiny and rapidly
shrinking sliver of all software, as measured by human values -- how
much time people spend with it, how much of their money, their
memories, their rights and freedoms they entrust to it, etc.
A typical situation is that the lower-layer and more commoditized
parts of the software stack are more likely to be Free/Open, e.g.
operating systems and web browsers, and the higher-layer and newer
parts are more likely to be proprietary and to otherwise deny freedom
to their users, e.g. Facebook and more or less the entirety of the
Web. It is those newer and higher-layer services that are most
valuable to users and most dangerous to their freedoms. For the vast
majority users it would make little difference to them if you switched
their Windows for Linux or their MSIE for Firefox, but it would be
unthinkable for them to leave Facebook, or migrate off of Oracle, or
stop subscribing to the software vendors and web sites that they rely
on, etc.
So, I personally believe Free/Open software is a social good that is
massively, drastically under-produced, just as simple economic theory
would predict. I think -- or rather I hope -- that a better social
outcome is possible somewhere in the middle, between the two extremes
of 0 and ∞. TGPPL is my stab at it. We can't do much worse than we are
already doing. ☹
I recognize that this may be surprising or unpleasant to this
audience. I mean no offense. You are the big fish in a pond. I'm
asserting that beyond this pond, the world of bigger ponds is growing
at an incredible rate. I very much value and respect your
contributions, including those of Red Hat, which can be measured in
real money.
> The nearest practice I know of was Aladdin's,
I don't think it is a valid comparison. Aladdin never offered to
anyone the option that they could make a proprietary derived work for
a limited time. So it provides no evidence on whether anyone would
have been interested in that option.
Now Tahoe-LAFS *has* offered people that option, and so far, to my
knowledge, nobody has taken us up on it. This probably just shows how
there is little commercial interest in Tahoe-LAFS, but it could also
be taken as evidence that the TGPPL is not itself a big draw for
investment.
By the way, commercial interest in Tahoe-LAFS is growing -- there are
now three companies offering commercial services based on it including
my own startup, and I'm aware of a few other expressions of commercial
interest.
Thank you for your attention. Please accept my bold, normative
statements in the spirit of constructive criticism that I intend.
Regards,
Zooko Wilcox-O'Hearn
Founder, CEO, and Customer Support Rep -- Least Authority Enterprises
https://leastauthority.com
11 years, 7 months
[PATCH] Handling extraordinary private communications via publication.
by Bradley M. Kuhn
It seems to me that private communication is inevitable in a project.
Here's a patch that I propose to add a rule to CONTRIBUTING to handle
the issue.
Not sure what the preferred protocol for patch submission/pull requests
is in this project yet, so I just did everything that was possible.
A Gitorious Merge request:
https://gitorious.org/copyleft-next/copyleft-next/merge_requests/8
You can pull the change via:
git pull git@gitorious.org:~bkuhn/copyleft-next/bkuhn-copyleft-next-proposals.git bkuhn/public-forum-pub-of-private-conversations
And, for good measure, the patch is attached:
Fontana, for future reference, which of this do you actually prefer?
--
-- bkuhn
11 years, 7 months
Re: [copyleft-next] "reasonable time period" Termination enforceability (was Re: Update)
by Joshua Gay
I too have witnessed potential violators claiming that 180+ days is reasonable amount of time to come into compliance.
"Bradley M. Kuhn" <bkuhn(a)ebb.org> wrote:
>Richard Fontana wrote:
>> One of the more significant changes is a substantial simplification of
>> the termination section. .... I've replaced it with one cure period and
>> I just refer to a "reasonable time period" .. 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.
>
>And thus master branch of copyleft-next now reads:
>>> However, if You cure such failure within a reasonable time period after
>>> becoming aware of such noncompliance, then Your rights are reinstated.
>
>I strongly believe this will make copyleft-next de-facto unenforceable.
>We'd have to litigate it all the way to the bitter end to get a ruling
>that "reasonable time period" is less than the average life cycle of most
>electronics and software products.
>
>In my experience, nearly all copyleft violators believe it's reasonable to come
>into compliance only after a product is off the market. And most would
>happily say "see you in Court" if a copyright holder says otherwise.
>
>Even those violators who make vague, half-hearted attempts to come into
>compliance still believe heavily protracted schedules are reasonable. For
>example, I've got compliance actions open today that were first opened last
>fall, and I'm sure the lawyers would argue, that they're still "within a
>reasonable time period" and tell me to sue them if I disagreed (of course,
>I already do disagree). As everyone knows, because I know the community
>prefers that we avoid lawsuits, I desperately avoid them until there is
>just no other choice, but violators' lawyers now know this too, of course,
>and play chicken.
>
>Since most of my compliance work is GPLv2, it means such violators are
>(of course) dead to rights. Think about it: even with GPLv2's termination
>clause, which everyone agrees very strict (from a policy perspective), most
>violators take nearly the entire product lifecycle to come into compliance,
>even when they know they've gotta beg for their rights back at the end of it
>or face continued copyright infrigement even when *in* compliance on all
>other non-termination points. If the termination clause says "reasonable
>time", what incentive will be left to get them into compliance, ever?
>
>My point, simply: I think copyleft-next will have to chose between naming
>a specific number of days, or be effectively unenforcable. Also, realize that
>*whatever* time frame you pick will be the minimum time by which we get code
>from companies gaming the system with delayed releases (which is already common,
>even with GPLv2).
>
> -- bkuhn
>_______________________________________________
>copyleft-next mailing list
>copyleft-next(a)lists.fedorahosted.org
>https://lists.fedorahosted.org/mailman/listinfo/copyleft-next
11 years, 7 months
Temporary Propietary License
by Theodore Ts'o
This is something I wrote up almost ten years ago, and since the
copyleft-next is an opportunity to consider some different variations
on copyleft, I thought I would throw this out there.
The full proposal, complete with rationale, can be found here:
http://web.mit.edu/tytso/www/TPL.html
But the tl;dr summary of the proposal is this:
The Temporary Proprietary License (TPL) allows derivative works to be
released without source code (i.e., in a proprietary fashion), but
only for a limited amount of time. After N months (where N would
likely be somewhere between 12 and 18 months) of the software being
released, the company/person doing the proprietary distribution must
make the sources available under terms which specify that the
contributed code must be made available under the terms which are no
more restrictive than that of the original code base, and must send a
copy of the modified sources to the original maintainer. The original
maintainer must be notified before derivitive works can be distributed
under the terms of the TPL.
In my original conception, source code would be released under a
dual-license of the TPL plus the GPL, which is how someone would be
allowed to make propietary changes, but be required to release them
some time later. It might be useful to consider use the supplemental
framework in copyleft-next for this option.
I'm curious what people think of this idea; is it workable? Are there
some fundamental flaws with this approach?
Thanks,
- Ted
11 years, 8 months
test
by Richard Fontana
This is a test.
11 years, 8 months