Re: Summary : ocaml, QPL and the DFSG.
On Tue, Jul 20, 2004 at 03:31:34PM +1000, Matthew Palmer wrote:
> On Tue, Jul 20, 2004 at 04:06:22AM +0200, Sven Luther wrote:
> > The reproach which is being done is twofold :
> >
> > 1) 6c of the QPL. I believe there has been some serious misunderstanding on
> > all parts about this clause in almost all posts previous to this.
> >
> > Let's quote the whole of section 6).
> >
> > 6. You may develop application programs, reusable components and other
> > software items that link with the original or modified versions of the
> > Software. These items, when distributed, are subject to the following
> > requirements:
> >
> > a. You must ensure that all recipients of machine-executable
> > forms of these items are also able to receive and use the
> > complete machine-readable source code to the items without any
> > charge beyond the costs of data transfer.
> >
> > b. You must explicitly license all recipients of your items to
> > use and re-distribute original and modified versions of the
> > items in both machine-executable and source code forms. The
> > recipients must be able to do so without any charges whatsoever,
> > and they must be able to re-distribute to anyone they choose.
>
> I have no problems with either of these clauses. They form a nice copyleft.
Indeed.
> > c. If the items are not available to the general public, and the
> > initial developer of the Software requests a copy of the items,
> > then you must supply one.
> >
> > Well, i have some feeling that this is a clause directly targeted to try to
> > void the GPL incompatibility, at least point a nd b, i will come to c later
> > on.
> >
> > Notice, and this is the point we have missed previously, that this doesn't
> > even remotely apply to modified versions of the software, which are mentioned
> > earlier, and where not subject to DFSG-doubt.
>
> If you're talking about the fact that the software is linked, I think you're
> out of luck, but I'll talk about that later.
Well, the link is mentioned in the main 6 part, so ... It clearly means that
it doesn't mention the original piece of work, or modifications thereof, which
are covered by the clause 3 and 4. And it doesn't mention piece of software
merely agregated with the work on the same media or such. But more to this
below.
> > Now, the clause which causes problem is the 6c, which states that upstream
> > might also want to get those works linked with the software. I understand that
> > this may be considered non-free, but let's go over the DFSG points one by one,
> > and not start with discutable chinese disident or desert island stuff which
> > only muddy the water.
> >
> > DFSG 1) it was claimed that giving the linked items back to upstream on
> > request is considered a fee, which may invalidate this licence. How much of
> > this claim is realistic, and does it constitute a fee ? After all, you lose
> > nothing if you give it to upstream, so it doesn't cost you.
> >
> > DFSG 2) and 3) Obviously fine given 6a and 6b.
>
> I believe that DFSG #3 disallows compelled distribution of derived works to
> the original author. To whit:
>
> DFSG #3: "The license must allow modifications and derived works, and must
> allow them to be distributed under the same terms as the license of the
> original software."
Well, what is stopping you from licencing it back to the author under the QPL ?
> The licence of the original software was "must distribute
> (changed|linked)[1] versions to O. Author". Now, does the licence of the
> modifications Q say "must distribute changes (of the modifications) to O.
> Author" or "must distribute changes (of the modifications) to J. Modifier"?
> If the former, then J. Modifier, the author of the modification Q, is being
> denied options that original author had, which is a DFSG #5 problem, and if
> the licence is the latter, it fails DFSG #3 because the licence is not the
> same as the original.
Well, compare it to the GPL ? The original authour had the choice of of using
whatever licence he wanted, but a work linked with the GPLed software has no
choice but to be the GPL (or some minor derivative).
> > DFSG 9) Well, since there is only mention of link-time restriction, and none
> > whatsoever on distribution media.
>
> More on this below.
Let's quote DFSG 9) for clarity :
9 License Must Not Contaminate Other Software
The license must not place restrictions on other software that is
distributed along with the licensed software. For example, the license must
not insist that all other programs distributed on the same medium must be
free software.
> > Even if it does indeed constitute a royalty, notice that QPL 6) mentions :
> >
> > 6. You may develop application programs, reusable components and other
> > software items that link with ...
> >
> > So my understanding is that this only applies with the stuff that links to the
> > QPL covered work. Which would mean that the QPL covered work is a library.
>
> Right, here is where we start to disagree violently.
>
> Firstly, what exactly is meant by linking? I'd say "the inclusion (by
> inclusion or reference) of some (typically) object code into an executable
> for the purpose of future execution".
Whatever, we are both in the software world, as is the author of ocaml, as is
the author of the QPL, and we all clearly know what is meant by linking..
> If the original code is entirely contained within A.o, and I make various
> modifications to A.c (producing A'.c) and recompile (producing A'.o), my
> modifications are essentially linked with various parts of the original A.o
> to produce A'.o. Hence, essentially every modification I make is a linked
> work, especially considering that the QPL only allows patch distribution.
I don't believe this is what is meant here, and if so, why did the QPL not
choose another language ?
> To make a clearer example, consider an original work with A.c and B.c. If I
> create a C.c, which replaces B.c, my modifications are very definitely
> linking with A.o when I compile.
Sure, all this is known from the technicalities of the GPL, which goes to some
length to ensure that hidden modification using a linked library is not
allowed. But both of we know what is meant here, and i doubt a judge would be
sympatic to use tiptoeing around it. Furthermore, the normal modification is
covered by section 3 to 4.
> Seriously, the "only force distribution of linked code" argument is not
> going to fly.
Reread :
6. You may develop application programs, reusable components and other
software items that link with the original or modified versions of the
Software.
How do you justify your vision that any work linked with the software is a
modification thereof, given the above sentence construction, which nominatedly
mentions the modified version of the software ?
> To attack the problem from an entirely different perspective, I think we
> need to revisit the question of "does linking qualify as creating a
> derivative work?". I don't want to really try and answer the question, and
> I don't think it matters in this case, but here are the options:
Well, explain to me how the formulation of 6. explained above enters in this
consideration.
> 1) Linking does *not* create a derived work. In that case, the QPL has no
> basis in copyright law for asserting control over another, unrelated, work,
> and the QPL thus fails DFSG #9 because it attempts to contaminate other
> software merely by being "bundled" (linked) with it.
Notice that a derived work, and a modified version of the work may be two
different things, are they not ? Let's step back in reality, and consider the
Qt/KDE example, which is most fitting here. Everyone knows what a modified Qt
means, and that KDE is a derived work of Qt.
> 2) Linking *does* create a derived work. But so does modification. Where
> does the distinction between modification and linking thus lie? "Anything
This is playing with words, i can assure without doubt that both you and me
and everyone involved here has a perfect understanding of this, and that also
the intuitive understanding of everyone which will do the modification will
point to the above meaning. The wording of 6. explicitly support that
intuitive understanding, does it not ?
> that fiddles with the distributed source code" might be a workable
> definition, but I wouldn't take that as gospel. Especially since, in the
> case of dynamic linking, there are a number of different libraries which
> would satisfy the requirements of being the "linked-to" library.
But the question would be, is there a difference between the modified work and a derived work.
Also in any case, how does it modify my original conclusion, that the real
question is if we consider sending the code to upstream author a royalty or
fee.
> If I recompile against a different version of a library, I am producing a
> different executable. Is that modification? Probably not. What if I
> recompile against another library with a compatible API? Might be a little
Err, i seriously doubt that if you had a work which links against the original
work, and then link it later with a replacement library, that it stays a
derivative work of the original library.
> closer. What about changing the software to reorder a few arguments to make
> the software compile work with a library with an
> almost-but-not-quite-the-same API? It's a nightmare.
Notice that FSF counsel i had over my parted contribution and the amiga
headers, mentions that it is ok to ship the header files, and it is not
copyright breach. So a changing to stay compatible with the API would be of
same kind.
> There is also an additional issue with this linking clause: it applies to
> libraries which OCaml links with. I imagine this is, in fact, the reason
> Trolltech made it apply to linking -- they didn't want people burying their
> own code in other libraries, modify the QPL code to rely on it, and then
> refuse to release the (proprietary) library. But for dynamic linking, that
> doesn't work, because I might give you essentially a stub library, which
> provides the API with minimal functionality, while using a different
> (ABI-compatible) library for my own private purposes.
As ocaml doesn't support dynamic linking, the point is moot though, isn't it ?
> > Ok, i believe i have the first point Josh mentioned covered, let's go to the
> > second one.
> >
> > 2) Choice of the court of venue being set to versaille, france, this being
> > the domicile of the ocaml authors, not some court chosen for tactical
> > reasons like the amsterdam court in the original QPL licence.
> >
> > First point to notice, that the choice of law in the licence of being the
> > french law has not been disputed here, and there thus seems to be a general
> > consensus of it being ok.
>
> Choice of law is essentially OK because it doesn't cause a major imposition
> on either party, and is in fact nice (for d-legal at least) because we can
> analyse the interaction between the laws of the chosen jurisdiction and the
> licence, rather than having to consider all sorts of issues of varying
> jurisdictions.
>
> > Second, it is argued that the choice of venue is not DFSG free, because it
> > means a trigger happy lawsuit harrasment from the upstream author over some
> > user could be possible.
>
> That doesn't require choice of venue in order to occur, but it does badly
> screw up the defendant in said frivolous lawsuit, because they may have to
> be put to considerably more expense in order to defend themselves.
As in hiring a legal counsel fluent in french law, and sending a letter
explaining its innocence ? Or like hiring a french counsel local to the venue,
and informing him through long distance communication off your position ? And
given the fact that you can get free counsel in france, this may be quite
cheap ? Come on, we live in the ago of telecommunication, not in the stone age
where this would represent a major hurdle. Phone, quick letters, email, video
conferencing, all this make the choice of venue probably moot.
> > Well, as my personal knowledge of both the french judicial system (but IANAL),
> > and the upstream authors, and with the authority of over 6 years of
> > maintainership and good interaction with them, i believe this threat to be
> > bogus, and thus had a real hardtime accepting it.
>
> That is a package analysis, not a licence one. Unfortunately, saying "oh, I
> know them and they won't do that" holds absolutely no water whatsoever,
> because (the royal) we have no knowledge of this, and things can change. If
> the licence allows it, we have to assume it will be executed.
Well, sure, first came the generic analysis, and then how it applies to the
ocaml package.
> > Also, in any sane legal system, it should only affect those users who
> > willingly violate the licence, even after a cease-and-desist letter, and i
> > would say they deserve what they get.
>
> Sane legal systems don't exist.
Hehe.
> > I will go over the DFSG points in a while, but let's first mention another
> > point. Altough the Social contract places our priorities at our users and
> > free software, where do the upstream author enter in consideration ? The
> > upstream authors without with debian would hardly exist.
>
> What can Debian do to an upstream author? Refuse to distribute their
> software? We can do that, poor licence or not. I don't buy "it will harm
> authors if their software isn't in Debian" as an argument.
Well, it will most assuredly harm the users of said software, and thus
diminish its distribution.
> The lack of the software might be a harm to our users, but you're not making
> that argument, you're saying that it would harm *authors*.
Well, the point is one of respect, and some of the participants in the
previous threads have clearly stated that the free availability of the
upstream code is a due, and that upstream should behave.
> We respect software authors, we try to be civil and reasonable, and not
> hassle them unnecesarily. Hell, most (if not all) Debian developers are
> authors in some way, from the bit of scripting required to put a package
> together, to major developers in some of our biggest packages. So we don't
Yes, but this is not an attitude shared by everyone participating here, and
there is a certain lack of respect in not considering the case at hand, and
just saying "they should GPL it". Mmm, i am probably ranting again.
> want to mistreat software authors, because we're only beating ourselves.
> But at the end of it all, helping authors isn't our reason for existence --
> our users and the cause of Free Software are our priorities.
Well, i was claiming that without the authors in the first place, debian would
not exist as such. Also, that if we make live too difficult on upstream
authors, they may just say, to hell with the debian zealots, i just plain
don't care about this anymore, and this would be a lose both for us and for our
users.
Friendly,
Sven Luther
Reply to: