Re: Summary : ocaml, QPL and the DFSG.
On Tue, Jul 20, 2004 at 11:03:05AM +0200, Sven Luther wrote:
> 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:
> > > 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:
[...]
> > > 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.
> > >
> > > 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 fact that my modifications must be under the terms of "this licence",
which, as I read it, means that the original author gets carte blanche over
my modifications.
That is *the* big problem with the QPL, IMO. The initial developer, by
virtua of being the plankowner of the software, gets special rights, which
no future developer gets. It's even worse, because who exactly the "initial
developer" actually is is not clearly specified. Am I, a future modifier of
the software, now one of the "initial developers" of the modified software?
Those problems *might* be ameliorated by an appropriate definition of
"initial developer", but the fact that one, special, person gets
preferential treatment under the licence basically kills it for me, no
matter what terminology you wish to use.
> > 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).
You consider the BSD licence to be a minor derivative of the GPL?
The difference between the GPL and the QPL in this area (mandating licence
terms for derived works) is that the GPL doesn't require the licence terms
that I have to use in my derived works to grant the initial developer
special rights to *my* code.
> 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..
I like to be clear on these points. I take it that you don't disagree with
my definition for the purposes of this discussion?
> > 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 ?
I don't know. There's no shortage of questionable language in licence
texts.
In these sorts of situations, we tend to get clarifications from upstream,
usually through the debian maintainer. Would you be willing to seek
clarification from upstream on this point, if it is not deemed "clean" by
consensus? I'm happy to accept an appropriate clarification from ocaml
upstream on this point.
> > 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.
You appear to believe that that just because the issue is discussed in one
clause it cannot be revisited later. Do you have any basis for that belief?
I would imagine that the licensor may wish to discuss different aspects of
the same act in different places.
> > 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 ?
I'm arguing the other way around. That modification is a form of linking,
and hence all modifications fall under clause 6. Linking isn't necessarily
modification, although considering that if you link against two
API-compatible libraries (even dynamic libraries) you'll get different
executables could be considered modification, especially if you can show
creative input into the process.
> > 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.
Linking is what we're talking about. Whether that (dynamic) linking creates
a derived work determines which of the options I gave comes into play.
> > 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.
Well you're getting very assumptive there. I would say that KDE, as a
source tarball, is a derived work of the Qt API. I've never been overly
keen on the "dynamic linking of program A to library B automatically makes
the source code A a derived work of library B", mostly because of the
drop-in replacement problem.
> > 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
How can you assure me I have a perfect understanding of this?
> 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 ?
Not particularly. In fact, it's a pretty counter-intuitive licence on the
whole. Clause 6 talks about works that I create which link to the QPL'd
software, but what about libraries that are linked to the QPL'd software?
What terms are related to them? Does this mean that I can't build my QPL'd
software on SCO OpenSewer because it would link to proprietary versions of
standard libraries, and I don't have the rights to distribute the code to
those? If that's OK, it's a short hop to doing a total end-run around the
licence by just rewriting bits and pieces of it as libraries which the QPL'd
program links to. In the dependency tree, those rewritten library bits are
used by the QPL'd program, not the other way around, so it's OK (for the
same reason that the QPL'd program is OK on OpenSewer).
These sorts of issues are rife in this licence. Looking at the practical
implications of this licence make it look worse and worse.
> > 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.
Nothing. It's an added problem with the licence. We can find extra reasons
why a clause is non-free.
As for whether requiring modifiers to send programs linking to the QPL'd
software is a fee, consider my modification to QPL'd program Q to use the
pre-existing, non-free library X. This library X wasn't developed to link
with Q (and hence, technically, is not covered by "you may develop ...
reusable components ... that link with the ... software", but nevertheless,
the modifications I make are useless to anyone without the library. If the
licence is read as to compel me to send my proprietary library to the
original author under the terms of the QPL, I hope you see that as being
non-free.
Note that the GPL's equivalent requirement is very different, as it merely
says that "everything related to this program must be GPL-compatible, if you
can't meet that, no distribution for you". The QPL's requirement is very
different.
> > 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.
So I can change who I'm a derived work of just by changing which compatible
ABI I'm using at the time? That's why I don't like the super-broad
interpretation of "derived work".
> > 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.
Not a copyright breach? I don't find that relevant. Does it constitute a
modification of the work, or linking, or both?
> > 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 ?
I wasn't talking about ocaml the language, I'm talking about the dynamic
libraries which the QPL'd ocaml components link with in the ordinary course
of business.
> > > 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 ?
Hiring competent legal counsel in a far-away jurisdiction is likely to be
significantly inconvenient. First you've got to find someone with
sufficient clue -- likely to be some overseas phone calls and whatnot. Then
you've got to retain their services, which might be fairly costly. And I
seriously doubt that a single letter saying "it wasn't me, it was the one
armed man!" is going to stop a lawsuit.
> And given the fact that you can get free counsel in france, this may be quite
Free counsel is available for overseas foreigners -- counsel appropriately
competent to properly protect my interests in a fairly technical and
complicted copyright infringement accusation? That's a country I want to be
a defendant in.
> 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.
Not a hope. See the link I sent you about the EmarketersAmerica suit. A
couple were europeans, but most were people just from other parts of the US.
Their debt, from memory, ran into the high tens of thousands of dollars, for
a suit which was about as frivolous as you can get without the litigant's
attorney showing up in clown shoes.
> > > 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.
That's nice. How does this address the problem that your word that you
don't think upstream will exercise their licence is all we have to go on?
> > > 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.
That's not the question asked in this paragraph. You asked "where do the
upstream author enter in consideration?", and I was asking how Debian can
damage an upstream author by not distributing their software.
By extension if we are damaging them by non-distribution, who is going to
package all of the software of the harmed authors out there?
> > 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.
That's bollocks, and I'm happy to say that to anyone who tries to assert it.
Authors gift their code to the community, we can't demand it.
However, free and equitable access to the source code is a precondition of
distribution in Debian, but we can't *demand* that of 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
>
> 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.
Yes, a bit. Objectively, it's a good choice, when combined with a copyright
assignment or permission grant from all contributors. That gives them
(effectively) the ability to sell the software under other licences to
generate revenue, but without hitting the problems which the QPL has.
> > 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.
I totally agree with that. But it cuts both ways.
- Matt
Reply to: