On Tue, Jul 09, 2013 at 02:14:47PM +0300, Engel Nyst wrote:
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?
This is meant to be comparable to the case of a source file licensed
under the GPL but incorporating GPL-compatible elements. It's
basically just taking one common license compatibility scenario and
relaxing orthodox criteria for GPL compatibility.
Cf.
http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
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...
Ah, that's a good point.
3) Trivial stylistic comment
The definition of Modified Code doesn't sound as nice as the previous
definition of Derived Work :-) (sorry!)
Hmm, I don't know if that's a trivial comment, since I consider making
the text sound nice an important substantive goal. :)
I wonder if it is necessary to entirely replace the use of the verbs
(i.e. adapt, transform) with addition and deletion operations?
Oh, the use of 'addition' and 'deletion' is a nod to the MPL/EPL
licenses. I'm not entirely satisfied with this. The language here is
specifically influenced by MPL 2.0 as I recall.
The problem with 'adapt' and 'transform' is that those are different
ways of saying 'derivative work' (essentially) and I'm trying to see
if I can avoid reference to such legally charged language as much as
possible. What I now like about the MPL family (though I was in denial
about this for a long time, as I may have said) is that it starts out
with a correct understanding of what FLOSS code is and how it gets
changed (files of [usually] text (copyleft-next experimental is trying
to express the additional observation that these files bear certain
interfunctional relationships
What I like about the MPL family -- I don't know if I've already
mentioned this -- is something I was in denial about for a long
time. It starts out, implicitly, with a correct social observation
about what FLOSS code is and how it is developed. It's a set of files
that normally get modified through textual editing.
(I realize that going down such a path implies a rejection of
copyleft-next as being strongly suitable (than other widely-used FLOSS
licenses) for non-software works.)
I think to me, it'd seem natural if some of these verbs would be
expressly applied to source code in files.
Maybe in a file-specific context they would be useful. I'll think
about that.
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.
Yes, or 'the GPL'.
Neighboring code, code using the copyleft-next-ed code, is free and
open
source. (within some limits)
That's the rough idea.
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.
Right, there isn't a clear difference.
- RF