It came to my attention earlier this week that the Eclipse Foundation
had begun public discussion of the drafting of a new version of the EPL.
So far little has been said on the relevant mailing list:
This caught my attention though:
http://dev.eclipse.org/mhonarc/lists/epl-discuss/msg00013.html as it
relates closely to the 'rule vs standard' issue that in the past was
The suggestion made by Jim Wright is interesting as at a high level it
bears some relationship to what I have been thinking about lately for
copyleft-next. It starts out with MPL-style copyleft as a conceptual
basis and tries to define something more extensive, but (unlike EPL
1.0) attempts to do so by articulating something bright line instead
of relying on some legal notion of derivative works.
After a considerable and unfortunate hiatus I have resumed development
of copyleft-next and feel it is close to appropriate for release of
v.0.4.0. Especially given the dormancy I thought I would point any
remaining and interested readers of this list to the latest draft:
The most notable changes are the following:
(Non-GPL) license compatibility is now dealt with through reference
to a brief illustrative appendix list of licenses (which include MPL
2.0, EPL 1.0, and LGPLv3 as well as some non-copyleft licenses).
The issue of compliance with export control regulations is dealt
with, something which I have come to view as sorely lacking in the GPL.
This is a new section containing an attempt at an Affero-style
condition. Don't laugh at this attempt without trying it yourself
first (though I should disclose that my attempt took place within the
space of an hour at most this evening). The inclusion of this condition
is notable given that at an earlier stage I specifically had decided
not to have an Affero-like condition in the main body of the license.
The original licensor can opt out. There is a special 'Corresponding
Source' definition here that is not identical to the one for
distribution of Object Code.
Section 4: The old 'poison pill' provision now includes a definition of
I have eliminated the effort to include an Apache License 2.0 section
5-style mechanism for formalizing the 'inbound=outbound' rule.
I'm preparing to package a new version of crda for Debian and therefore
I'm looking at the text of its new licence, copyleft-next 0.3.0.
This seems to meet the DFSG, making the new version of crda suitable
for inclusion in Debian, yet I'm not certain that we and our
distributors would currently comply with its terms:
> 5. Conditions for Distributing Object Code
> You may Distribute an Object Code form of a Covered Work, provided that
> you accompany the Object Code with a URL through which the Corresponding
> Source is made available, at no charge, by some standard or customary
> means of providing network access to source code.
> If you Distribute the Object Code in a physical product or tangible
> storage medium ("Product"), the Corresponding Source must be available
> through such URL for two years from the date of Your most recent
> Distribution of the Object Code in the Product. However, if the Product
> itself contains or is accompanied by the Corresponding Source (made
> available in a customarily accessible manner), You need not also comply
> with the first paragraph of this section.
Since we don't keep old releases in the main FTP archive, the source
URLs that APT is configured to use can become stale within 2 years of
receiving a CD/DVD (or could even be stale already). So far as I can
see, our CD/DVD distributors cannot comply with this by making the
sources available in the same way - they must provide a URL for network
We can now advertise stable URLs for source packages on
http://snapshot.debian.org, but we do not include such URLs in binary
packages. Perhaps it would be sufficient to document the site somewhere
in the base system?
> 15. Definitions
> "Corresponding Source" of a Covered Work in Object Code form means (i)
> the Source Code form of the Covered Work; (ii) all scripts,
> instructions and similar information that are reasonably necessary for
> a skilled developer to generate such Object Code from the Source Code
> provided under (i); and (iii) a list clearly identifying all Separate
> Works (other than those provided in compliance with (ii)) that were
> specifically used in building and (if applicable) installing the
> Covered Work (for example, a specified proprietary compiler including
> its version number). Corresponding Source must be machine-readable.
> "Separate Work" means a work that is separate from and independent of a
> particular Covered Work and is not by its nature an extension or
> enhancement of the Covered Work, and/or a runtime library, standard
> library or similar component that is used to generate an Object Code
> form of a Covered Work.
I'm not sure quite what we need to for item (iii) of Corresponding
Source. Are the Build-Depends and Build-Depends-Indep fields in a
Debian source package sufficient? Or do we need to record which
versions were actually used to build each binary package? We do log the
versions of build-dependencies for auto-built binaries, but not for
developer-uploaded binaries. We don't advertise the URLs for build logs
anywhere in the installed system.
If it jams, force it. If it breaks, it needed replacing anyway.
in order to dual-license software using your copyleft license and a
proprietary one, someone with copyright for all contributions might
simply remove the anti-dual-license clause in copyleft-next.
one might wish to deny the copyright holder permission to use a
derivative of the copyleft-next license, to use the copyleft-next name
for their license in order to prevent this. i'm not sure how i'd feel
about trademarking the name of a license under CC0. i think licensing
the license under CC0 is pretty cool.
as long as as copyleft requires a foundation of copyright and it isn't
directly expressed as set of optional laws, dual licensing may remain
hard to avoid. if copyleft were expressed as a set of laws, it's
unlikely that all jurisdictions would concurrently have the same or
i am concerned with the potential for a plethora of copyleft-next
variants which would be difficult to make sense of, keep track of, and
combine. one potential solution for this may be to include in the cl-n
license a request that any modifications and derivatives of the license
be included in a standard separate file, or apparent in some standard way.
asking coders to mention the non-vanilla status of a source code file's
license in its header would be very helpful.
welcoming quality upstream submissions might reduce the number of small
and not-so-small copyleft-next forks, not to discourage independent
changes, but because keeping track of many licenses is complicated.
an additional request could be for the license modder to choose an
alternative name for their license, such as "copyleft-next-deriv", or
the "i-like-beards license", or to clearly state somewhere near the top
that the license was changed inline.
p.s. i talked with another in private regarding paragraphs 1 and 2 some
I'll try to record, in imperfect form, a few questions and thoughts.
1) 0.3.0 says
"non-exclusive, worldwide, perpetual, royalty-free, irrevocable
copyright license, to reproduce, Distribute, prepare derivative works
of, publicly perform and publicly display My Work."
"Distribute" means to distribute, transfer or make a copy available to
someone else, such that copyright permission is required."
1.1) Is "to someone else" necessary, or "public" is suitable?
If I compare the wording with the copyright act, it seems that
106 (1) and (2) are individual acts, while (3)-(6) all refer to the
"To someone else" compared with "to the public" has a more extensive
connotation, it seems to catch cases which may apply to more than public
distribution/performance/display/transfer. (whatever that would strictly
"such that copyright permission is required" probably takes the
extension (if there was any indeed) back to only the cases specified in
the enumeration of exclusive rights, so maybe it's no big deal. Still,
if all else is equal, I wonder if it's better to use the term "public"
instead of "someone else".
1.2) What is the reason for the inclusion of the concept of "making
available a copy"?
2) Latest draft, with the Affero provision, says
"Network Service means delivery of software functionality to third-
party users in which distribution of most of the software does not
occur, with users instead primarily accessing such functionality
remotely, through network requests made by a client program, such as a
web browser, to a server running the software."
2.1) Is "in which distribution of most of the software does not occur"
I think the definition stays the same without it.
2.2) Some critics of the AGPL remark that it doesn't refer anymore to
distribution, but to using or running the program on one's own server.
That's perceived as a restriction on running the program, and it
sometimes raises doubt about its freeness. Unfortunately, it seems easy
to understand Affero provision as expanding the definition of
distribution, or as restrictions on running the program, although none
of them is what happens in Affero.
I'd ask something else: what exclusive privilege exactly is
impacted in the activity targeted by Affero?
I think public performance is impacted, not distribution.
Reproduction - and making derivatives - are also impacted, of course,
because "you" made a copy, but these lead to the doubts above, and
they're not the point. I can make copies and derivatives and run them
with no effect. But Affero needs to kick in when I offer a /public
What do you think about an attempt to draft it about public performance?
I tentatively submit that to me it seems a corresponding expression of
the Affero trigger in copyright terms, and I think the imagery can
convey better the intention of the provision. Although the concept of
public performance has not entered public conscience as applied to what
a network service does in relation to the software package, still it
illustrates what happens here, and it makes perfect sense to condition
it where appropriate.
I'm at loss what other legal effects would be though... Just thinking
I'd better submit this idea instead of not doing it.
2.3) "You may prepare a Derivative Work that is designed primarily to
provide a Network Service"
This seems to limit the trigger for Affero provision to derivative works
that are specifically designed to provide a Network Service.
AGPLv3 says "if your version supports such interaction".
In my reading, "if your version supports" is more expansive than
Do I understand this correctly, is the Affero condition intended to NOT
apply to certain applications or libraries, which use an AGPLed library
and may support interaction through a network, but are not "primarily
designed" for it?
"Excuse me, Professor Lessig, may I ask you to sign this CLA, so we can
*legally* have your permission to distribute your CC-licensed works?"
Part of http://faif.us/cast/2014/aug/05/0x4B/ with Fontana and VanL
concerned a desire for patent grant covering more than just
contributor's contributions/in combination with work, or whole work at
time of contributor's contributions (as I [mis]understand them, Apache2
and EPL do former, MPL2 and GPL3 latter).
This reminded me to look at copyleft-next again. I assume it is intended
to do latter, that is
"My Code" means the particular work of authorship I license to You
under this License.
refers to my contributor version, not the code contributed by me?
Near the end of the podcast Bradley said (roughly) that if free software
license patent grants aren't covering enough, the those licenses should
be fixed. As opposed to using CLAs which offer more coverage -- in
theory, though it was noted they usually don't -- any examples that do?
I was kind of hoping that I'd discover recent copyleft-next commits
adding patent coverage beyond single work, but alas. Any in the
pipeline? What are the possible scopes of coverage beyond single work?
I'd guess a list of works, but this would be kind of messy, having to be
specified elsewhere, or all free software. Latter would be unattractive
to many companies, but they already have options.