Re: Towards a new LPPL draft
Branden,
thank you very much for that detailed set of comments.
> Sure. Before getting to your hypotheticals, I'll try and give you a
> direct, if generalized, answer.
>
> A license must be tested against DFSG 4 when either of the following are
> true:
>
> A) the license places restrictions on the form in which modifications to
> the Work are distributed;
> B) the license places restrictions on the manner in which the Work is
> named or versioned.
okay. that is because DSFG 4 exists.
> Without DFSG 4, *any* license term did either of the above would violate
> violate DFSG 3.
stepping more and more into that type of legal thinking ... (sorry if i'm a
bore, but I really like to understand) ... I don't see that anything like the
above follows from DSFG3.
to my (proably simple) mind DSFG3 says absolutely nothing about "how" the
licenses must allow modification other than it must allow them to be
distributed under the "same terms" as the original software. Eg if the
license puts restrictions on naming or versioning (the same restrictions on
the original as well as the modifictions) then to my understanding the "same
terms" is not violated at all.
I can however understand that if a license make modification in principle
possible but makes modification so difficult that in practise it *is*
impossible or nearly impossible that this would violate DFSG3.
I'm therefore happily tried (and i think succeded) in removing the cascading
file renaming obstacle out of the way.
> > Question 1:
> >
> > Suppose you have a program source foo.c with some license. Suppose
> > this license "restricts" foo.c from being modified but allows
> > distribution of foo.c plus a patch file, e.g. foo.dif and allows to
> > patch foo.c at built time, i.e.
> >
> > patch < foo.dif
> > gcc foo
> >
> > NOW: would it be acceptable for the license to disallow distribution
> > of the modified built
>
> No. Quoting DFSG 4:
>
> "The license must explicitly permit distribution of software built from
> modified source code."
question mostly withdrawn (as it anyway isn't applicable to LaTeX related
software)
> > is that what you think
> >
> > The license may restrict source-code from being distributed in
> > modified form _only_ if the license allows the distribution of
> > "patch files" with the source code for the purpose of modifying
> > the program at build time.
> >
> > means? I guess the answer might be no, but i would like to get a clear
> > picture.
>
> You are correct. I do not think that DFSG 4 can plausibly be read to
> permit the the restrictions you posit in your hypothetical.
okay, thouhg I think one can make a case for arguing that there is nothing
explicit that says you are not allowed to require the the binary has a
different name. I do however submit that the intention of clause for is to
disallow it (but since we here are so often and quite rightly into exact
wording (hallo Jeff:-) i think you might consider making this clear, but
perhaps I miss something that follows from combining other points ...)
> > Question 2:
> >
> > I don't know if you use LaTeX or TeX but assuming you do to some extent,
>
> I have used LaTeX in the past but only at a highly rudimentary level; I
> understand almost nothing of its internals.
>
> > what exactly do you consider "source" and what "built" in case of a LaTeX
> > work
>
> That's an excellent question and it illustrates a vagueness in the
> wording of the DFSG. The DFSG misleadingly speaks in terms of "source"
> and "binary" when in many situations, as folks have noted on this list,
> the distinctions are not applicable, at least not in the same way that
> they are to compiled C programs.
thank you. let me start by saying that i don't want to trick anybody to
submitting something that they actually do mean. I'm trying to figure out
where the common grounds are (if any)
[definition of meaning of source and binary ommitted]
okay. sounds good to me. As I said in my post I think stuff like latex macros
really don't fit nicely into this scheme as bing both source and binary more
or less.
> In my opinion, my interpretation of the source/binary binary dichotomy
> is more consistent with Debian's tradition, in that we are not looking
> for loopholes through which we will tolerate the suppression of users'
> rights to modify the software they get from Debian, and redistribute
> their modifications to their neighbors.
i htink both can be argued for (or even that both would need to apply) but in
any case i wasn't looking for loopholes but for a common ground and if that
part isn't the point to meet, too bad :-)
but i would liketo sumarize on what I understand (and don't) perhaps one or
the other is joining in at this point
a) My understanding is that the outlined LPPL rewrite behind Jeff's mail
"Concluding the debate"
would be DSFG free as the rights we offer through would be complient with
DSFG #3 since
- it allows modification (and there is no question that it allows it
only theoretically but not in practice, ie with ease)
- it allows derived works
- it allows them to be distributed under the same terms as the license of
the original work
(it clearly doesn't state that it has to allow the distribution of the
modifications in place of the original work disguising itself as the original
work. This is in fact in my opinion further exemplied by explicitly giving
sentence three in DFSG #4)
b) As far as DSFG 4 is concerned, I haven't so far seen an argument (sorry
when I missed it) why it should forbid file renaming as a way to mark
version or name change (it even talks about "file" in the parentheses)
- i've seen several people not liking it much as an requirement butthat
is different
- i've seen an accepted the argument that it might lead to violating
first sentence of DSFG #3 if the modification gets too complicated
but that particular thing we are confident to 100% prevent by something
outside of the work being licensed (so that modification of the work
wouldn't change that status!)
> I concur with Jeff Licquia's suggestion. If one can avoid the filename
> renaming requirement by simply renaming the entire Work and not
> representing it as "LaTeX" but rather as "SniffenTeX" or whatever, then
> that would be the avenue that Debian could use in the event we ever
> needed to change LaTeX. From our perspective, LaTeX would be
> "dual-licensed". That both licenses would be embodied in the same
> document isn't really important.
I'm certainly prepared to think further about the possibility to dual licenses
(though that has its own difficulties as some of the sub-threads have shown)
But I would be glad if you, on the other hand, also discuss a bit more the
"Concluding debate proposal" by Jeff and come to a more firm conclusion.
good night
frank
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: