A few comments on the experimental branch.[1]
1) Section 4, copyleft conditions, 3rd paragraph, says that you could
distribute "a Modification under this License even if it incorporates
third-party material governed by a license that is both OSI-Approved and
FSF-Free". It seems to amount to distribution of code under two
licenses, in the sense of juxtaposing code under different licenses in
the same file, which sounds very confusing. I suppose this reading is
incorrect, or there is some reason for this?
2) I'd think the licensing condition on a patch (section 6) should be
licensing by default under the free and open license of the file as
applicable, like the DCO language, or I'm not sure how it'd work
otherwise...
3) Trivial stylistic comment
The definition of Modified Code doesn't sound as nice as the previous
definition of Derived Work :-) (sorry!)
I wonder if it is necessary to entirely replace the use of the verbs
(i.e. adapt, transform) with addition and deletion operations?
I think to me, it'd seem natural if some of these verbs would be
expressly applied to source code in files.
4) Copyleft conditions
To summarize (please correct me if this is wrong), as long as a file has
copyrightable code under copyleft-next, the file is licensed under
copyleft-next.
Neighboring code, code using the copyleft-next-ed code, is free and open
source. (within some limits)
One reason why I support this experiment, is that to me, there isn't a
clear difference between the neighboring code in
copyleft-next-experimental and the code incorporated as open licensed in
copyleft-next-master (under section 4).
I mean this in the sense that code incorporated as open licensed (under
section 4 master) can lead to neighboring code easily during
development, without necessarily realizing it. But any recipient should
be able to trust it has the open license under which it's distributed.
Accepting neighboring code as open licensed in the license, makes that
clear.
5) A remark
MPL copyleft is IMHO the closest match for the 'strongest layer'. I mean
I think it's a very understandable definition of the first layer for the
copyleft-next scope. And I think the reason is indeed as noted by
Fontana in another thread: because MPL boundary is the same with almost
all other licenses (MIT, BSD) boundary: the copyrightable code, the
source of licensing conditions on the code.
An open source developer will know when there's MIT code in a file to
respect its attribution conditions accordingly; or BSD code, or AL2.0
code. The criteria for MPL are no different. The file headers reflect
copyright and any license under which there is copyrightable code in
this file. (AFAIK, it's much more common to write headers with copyright
and license information in files; even if this information is of course
also per package.)
I'd say it's routine in an open source project, and I'd say it's simple.
I'll add here some thoughts I've been having, not in an organized
manner, I will only note them down, for the list.
Richard Fontana reminded in a previous email thread on this experiment,
of GPLv2 section 2, the 2nd and 3rd paragraphs. I remember reading these
paragraphs years ago, and finding the concept *fair*.
I'm not sure GPL really does that, though. Or the way it does it,
through relicensing every open license, or reject combination with it if
it can't (calling it incompatible), is arguably not ideal.
(which is not necessarily to say there is another objectively better
way, but other ways with different trade-offs.)
When there's no copyrightable code in a file, it's work written entirely
by someone else. Taken in itself.
It applies to a package, a library, an application. It doesn't matter if
individual developers may happen to be the same, because the *license*
matters more in many ways. And the license on that file can be BSD. Or
MIT, AL2.0, or MPL. It might be more obvious for web applications in
some interpreted languages, with open repositories. (or for permissive
projects).
OTOH, when there's no copyrightable code in a file/package, the code
_written entirely by someone else_ might interact with copylefted code,
add behavior or change behavior, such that the result of their
combination will be a work of authorship standing on its own too. Or, it
might not; it can be very loosely related, a package with an
implementation which has nothing to do with another, except there's a
call to tie the two. (such as 'import' and use some method, as it's been
noted lately on this list)
In copyleft-next-experimental, as long as work "written by you" is
combined with "my" code to form a new work, then I will ask you
explicitly only to offer users the same freedoms as any open licensed
software does: your code can be BSD, MIT, MPL licensed. Only that it
will be as software should be: free and open software. Not copyleft-next.
Experimental branch copyleft-next-ed code accepts around it any free and
open license as it is. It doesn't (re)license neighboring code to
copyleft-next, and it doesn't disallow code/data sharing if they're not
relicensable to it.
If I include a BSD file, in a copyleft-next-experimental project, it's
unambiguously BSD. Whether it uses the copyleft-next code or not.
If I take away a BSD file, from the copyleft-next-experimental project,
it's BSD. It can be licensed proprietary separately (*its* downstream).
But *not* as long as it's part of a work that incorporates the
copyleft-next-ed code: the copyleft-next license guarantees that.
Copyleft-next-ed code is incompatible with *proprietary* licensed code.
Not as much open licensed.
It can't be incorporated in proprietary software.[2] This is an
essential goal of strong copyleft, and it never changed.
Its intention is to be incorporated in open source software.
The concept is "weaker" than practically relicensing any part of the
derivative/collective work. It doesn't do that.
But, its scope extends beyond "weak" copyleft. It enables an ecosystem
of free and open source software around it.
To me, this license and its *clarity* would be very valuable, if it's
possible. I should say I am biased, though, and I surely can miss
otherwise very obvious issues.
I think perhaps copyleft doesn't have to be a "license of all licenses,
which converts everything to it, or rejects sharing". Copyleft is the
guarantee of freedom. A guarantee to downstream users, in a way that
enables free and open software to build upon it.
I wonder if the concept is contradictory in some way I don't entirely see?
Or unenforceable. It unambiguously allows every open license to set its
own conditions only, when the software, source or binary, is distributed
*separately*. (as Fontana mentioned in the idea thread).
What would the worse scenario?
[1]
https://gitorious.org/copyleft-next/copyleft-next/blobs/experimental/Draf...
[2] cf GPLv2 and v3 last paragraph.