Re: Summary : ocaml, QPL and the DFSG.
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.
> 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.
> 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."
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.
> DFSG 9) Well, since there is only mention of link-time restriction, and none
> whatsoever on distribution media.
More on this below.
> 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".
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.
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.
Seriously, the "only force distribution of linked code" argument is not
going to fly.
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:
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.
2) Linking *does* create a derived work. But so does modification. Where
does the distinction between modification and linking thus lie? "Anything
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.
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
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.
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.
> 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.
> 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.
> 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.
> 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.
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*.
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
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.
- Matt
Reply to: