Update 2012-09-19
by Richard Fontana
Here's an update on the copyleft-next draft:
I merged some changes suggested by Mike Linksvayer to the
outbound-(A)GPL-relicensing section and the later-license-versions
section.
I attempted to solve the problem of not knowing how to redefine the
system library exception by modifying the definition of 'Separate Work'.
The current draft of vanilla copyleft-next feels close to what I'm
thinking of as an 0.01 release (notwithstanding the complete neglect
of the AGPL-ish 'supp' file).
Word counts: copyleft-next vanilla draft 1356, vs. GPLv3 5644, Apache
License 2.0 1581. :-)
- Richard
11 years, 7 months
Update 2012-09-08
by Richard Fontana
I haven't had too much time to work on copyleft-next lately because of
some recent work, vacation, and conference commitments. Here's most of
what's happened since the previous update:
Based on a discussion I had with Bradley Kuhn at LinuxCon about
clarifying the Harvey Birdman Rule, a patch from Bradley was merged.
I added a clarification to the GPLv2-ish 'Later License Versions'
section to the effect that mere inclusion of a copy of "this"
particular version of copyleft-next does not signify restriction to a
particular license version for purposes of that section. This resolves
an ambiguity that occasionally arises in GPL practice. If some code
has a COPYING file containing GPLv2, but no other statement about
license versions, is the author limiting downstream use (let's assume
we know what that means) to GPLv2 or is this instead a case of what
GPLv2 means by "the Program ... not specify[ing] a version number of
this License"? copyleft-next says it's the latter: i.e., if the author
wants to restrict downstream recipients to v1.0, the author must say
so in some way more explicit than merely including a copy of
copyleft-next v1.0. (That could be something quite minimal, like
separately saying "Licensed under copyleft-next v1.0.")
I've made a change to the Corresponding Source definition that Bradley
might not like, but I assume he hasn't seen it yet. I've made it a bit
less GPLv3-ish and a bit more GPLv2-ish in style, removing the set of
verbs we see in the definition in GPLv3. The intention is not to alter
the scope of what is Corresponding Source but to maximize clarity.
I removed the reference to the Open Source Definition in the
Proprietary-Relicensing section, because (to the extent I ever did) I
no longer consider the Open Source Definition to be a useful
definition of open source (a point I explained in my talk at LinuxCon).
Finally, I have adopted MPL 2.0's approach in relaxing the requirement
to include a copy of the license text to "inform[ing] recipients how
they an obtain a copy". This was motivated by some recent discussion
on the OSI license-discuss list, and also by a conversation I had at
LinuxCon about a related issue.
- Richard
11 years, 7 months
Allow linking with any FSF/OSI approved license
by Richard Fontana
A GitHub person recently reported the following issue:
- begin -
IMHO one of the worst problems of the GPL is that it don't allows
linking (static or dynamic) programs licensed under the GPL with some
of the FSF/OSI approved licenses (OpenSSL,CDDL,PHP License...)
I think it will be a good idea to add an exception to this license
that allows linking the software with ANY of the licenses considered
as free software license by the FSF/OSI while at the same time forbids
to link the software with any proprietary license.
Perhaps something like:
In addition, as a special exception, the copyright holders give
permission to link the code of portions of this program with any
software licensed under a license that satisfies either the Free
Software Definition, version 1.111, as published by the Free Software
Foundation ("FSF") or the Open Source Definition, as published by
the Open Source Initiative, and distribute linked combinations
including the two.
- end -
- RF
11 years, 7 months