Re: Encoding the name in the file contents (was Re: Towards a new LPPL draft)
Henning,
> > In other words, I challenge you that in this case you don't live up to your
> > social contract in particular to #4 of it. I.e. you are not guided be the
> > needs of your user _and_ the free-software community but guided only by one
> > singular interpretation of what is free-software (a view that is sensible in
> > many cases, but not necessarily in all).
>
> This paragraph, and the rest of the article, is looking disturbingly
> like an attempt to start a flamefest.
sorry, and applogised. email is not always an easy medium.
My intention is and was to point out that while it was several times expressed
that the user is on your mind as well as the developer my impression is that
it is heavily weighted towards the latter and in this particular case (in my
opinion) partly sacrifying the former. My intention in that mal was therefore
to rethink your position with respect to these goals (which may of course
result in -- wrong impression, because)
that way acceptable?
> Really, all that's going on is that we try to make sure that users of
> the second kind can get their work done without meeting any excessive
> legal or technical barriers on the way.
ok. understood and never questioned (asa goal)
> We believe that it is possible
> to protect the needs of users of the first kind using the free
> software community's normal social mechanisms, combined with a few
> natural requirements that users of the second kind do not misrepresent
> what they are doing.
And this is where our believes differ (for LaTeX type software because too
many people believe small changes are not changes) don't want to rehash the
arguments here.
> We don't think that using courts to force the
> second group to put the first group's needs before their own will
> actually improve the situation of the first group enough to justify
> the disadvantage that the second group will suffer.
i don't really think it is the courts. but be honnest. how many people do you
think within Debian or some commercial TeX provider or ... would happly
replace article.cls by something better (as it has its "bugs") and stick it
into the texmf tree as a replacement if we only had some guideline document
saying please don't do that. On the other hand how many people would do it if
the license says you are not allowed to? and instead provide debarticle.cls
(under LPPL (making it ULL) or under som other license.
or alternatively providing article.fcl ---- remember i offered to have LaTeX
come already with a second format that contains the remapping feature.
our experience is they do (without going to court) while they didn't earlier
on, when Leslie Lamport only expressed this in separate statements.
the problem is (and that is my experience from by now 15 years of working in
that community) that there are a few people (but enough) not realizing that
inplace modification is breaking the ULL into pieces unless there is a way to
determine (automatically) that the resulting file is not part of ULL.
> The discussion at the moment is focused on determining
>
> a) How much disadvantage for group 2 your legal measures are in
> practise.
>
> b) How much disadvantage we can let group 2 suffer and still have
> good conscience about telling them that we think they will be
> able to get their work done.
>
> c) Whether there are alternative (legal or technical) measures that
> will provide the first group with the protection you desire yet
> yield a larger probablity that we can make (a) and (b) meet.
>
> These things (plus some more, and various fallout from things we have
> covered, and editorial questions about understanding what your
> proposed legal solution is at all) are going on in parallel. That can
> be confusing, especially because (b) is basically an internal Debian
> debate where there is yet no unanimous consensus and no authoritative
> test that can easily resolve the matter. However, that's the way
> things have to be, given the social structures in which they unfold.
i agree with that
> > From my perspective (which is undoubtely biased) this looks this
> > looks as if some people are very hard trying to ensure, that the
> > above type of user has no way at all to detect that, she is not
> > getting what she things she is getting.
>
> This is simply false. No people at all have been arguing against
> requiring modified versions to have all applicable identification
> strings and comments changed or amended with clear statements about
> the changes made. (Indeed, in several jurisdiction an author cannot
> even legally waive his right to have derived works clearly labeled
> as derivates).
but people strongly trying to push that onto the level of Debian packaging
(basically). I can understand that from the developers point of view but it
doesn't haelp users from group 1 at all if the work is allowed to falsely
identify itself as the original work towards LaTeX.
As long as that is a main requirement I think the statement is true. For group
1 the outer packaging name of the work is of minor importance the inner is.
> Your perspective looks as if you're claiming that any way of
> inspecting the software that is based on anything but looking at its
> filename and only its filename, is "no way at all".
close but not fully. And again I don't claim "filename" the LPPL right now
talks about file name because that is essentially what is behind it in most
installations, but the correct thing to talk about is the works identification
towards LaTeX itself.
I'm not agreeing to solutions that require users of group 1 to unessarily
inpect logs each time they run the same document on a different machine, nor
do i think it is acceptable for this group to check such an installation
manually and verify all packages contained therein to whether or not they
belong to ULL on this box.
I have however tried to find other ways to overcome the problems that some see
in the filename restriction, eg
- the idea of full separate trees (unresolved yet)
- the idea of having an identication that something is part or not part of ULL
frank
ps i presume you are also on debian legal so that i don't need to cc you?
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: