Re: Summary : ocaml, QPL and the DFSG.
On Tue, Jul 20, 2004 at 08:47:54PM +1000, Matthew Palmer wrote:
> 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.
Well, section 6) states :
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.
Please tell me what in the above stops you from covering the code under the
QPL or GPL ? And the carte blanche comes not from 6c, but 3b, which upto now
has not been mentioned here, please start a separate thread about it.
> 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?
Well, whatever, it is another issues, so please don't muddle the water.
> 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.
This may be discussable, but offtopic in this thread.
> > > 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?
Ah, you claim that you can get some GPLed code, make modifications to it, and
then release it under the BSD ? I seriously doubt that and would like you to
reconsider, or give some real argumentation of it.
> 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.
Well, sure. but this is not a result of 6c.
> > 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?
Well, i disagree with discussion for the purpose of discussing, let's get
things done, as this already lost enough of my time.
> > > 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.
Sure, and just making bogus interpetations of it, is not going to advance us,
why not use some common sense instead ?
> 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.
And did you read the annotated QPL from trolltech, it says :
This is a license designed for libraries, therefore we must also talk about
application programs or other libraries (components) that are linked with the
software, as these include portions of Qt when in binary form. Of course,
given the term "link", there is no differentiation between static and dynamic
linking.
In essence this clause says that you may develop programs that link with Qt
provided that you develop Open Source software.
http://www.trolltech.com/licenses/qpl-annotated.html
Is there still some doubt after that ? And how does it apply to some program
who is not a library.
> > > 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.
Do you have any belief on the contrary ? Did you even read the annotated QPL
from trolltech, i believe i or someone else has posted the link here before.
> > > 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
Bogus arguing, please don't delay this just for the fun of it, it is _NOT_
funny.
> 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.
Trolltech, clearly state in the annotations what they mean about linking, so
this is the sense given to it here, and also the sense hinted to in the
wording. And saying that there has been confuse wording in licences in the
past is no reason enough to ignore what is written here, and indeed the
wording of QPL 6 clearly make a distinction between a modified work and a
linked work, both being considered as derivative works.
> > > 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.
Thanks for not responding to my question. It is clear you decided not to read
QPL 6, and refuse to take the formulation of it into consideration. Thus your
argument here is unreceivable.
> > > 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.
And ? I agree with you, but i am claiming that KDE is _NOT_ a modification of
the Qt library, but a work linking with it. Care to claim the contrary ? And
please, real argumentation.
> > > 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?
Because i believe you are not stupid, and know what you are speaking about. IF
this is not the case, please go inform yourself, but in any case, this makes
your contribution here somewhat doubtfull.
And i am not interested in following bogus argumentation just for the fun of
it. Let's go to the real problems, and not create new ones just to delay 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 about them ? They are linked to it, so what ? This would include a
library wrapper over Qt for example. They are thus derived works, linked with
the library, but not modifications thereof.
> 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
Err, care to argument with real reference to the library stopping this ?
> 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).
I don't buy this, please provide real argumentation, rooted in the licence.
> These sorts of issues are rife in this licence. Looking at the practical
> implications of this licence make it look worse and worse.
Again, please provide real analysis, and not just bogus claims.
> > > 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.
A bogus one though, only there to delay the issue, or for the fun of unending
discussion. Especially as it is so poorly argumented.
> 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.
Well, indeed, you have a point, linking indeed goes both way. Now, is the
annotated QPL enough to solve this ?
> 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.
Well, very simple, and it goes to length to explain about the system library
loop hole designed to have gcc and others run on sunos back then.
> > > 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".
Whatever, please discuss this in another thread.
> > > 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?
It is acceptable to reproduce the needed info found in headers needed to link
with another work. As thus, even though my modification reuse the headers
defining the RDB partition table format, it doesn't constitue a derived work
of tge amiga OS code base.
So, a code that is made to link with a library remains a derived work as long
as there is only one library implementing this API, and once there is another
free replacement of the library, the code becomes a derived work only once it
links with the original library.
> > > 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
Well, i am. I have no interest whatsoever in loosing time discussing generic
stuff which doesn't affect me.
> libraries which the QPL'd ocaml components link with in the ordinary course
> of business.
Ah. Well. i guess that means the libc and a few others. Since you can link
them with prorietary software too, i doubt they would cause problems.
> > > > 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
Oh, come on, the french phone directory is available online, so the cost is an
internet connection and a phone call, followed by a few formal letter
exchanges.
> 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.
But you could get local legal advice in order to help you draft that letter.
Since the choice of law is not under question, you anyway need to find someone
fluent in french law, even if it the hearing would be in your living room.
> > 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.
Yeah, you may be right about this.
> > 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.
Sure, but they clearly hadn't clear concience, did they ?
> > > > 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?
Well, i am the maintainer, am i not ?
And you have all the generic discussion before anyway.
> > > > 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.
Err, i was asking more about respect of them and elementary courtesy, than
what you are speaking about. upstream's author giving out of free software is
by no way a due, and approaching them with "you should GPL your software, or
burn in hell, err be dragged in never ending debian-legal flamewars" is
a kind of communication with upstream that makes me ashamed to be part of
debian.
> > > 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.
Then why didn't you ?
> Authors gift their code to the community, we can't demand it.
But in exchange of their gift, they should get at least basic courtesy, don't
they ? Please never forget that. And i doubt it is courteous and respectfull
to go upstream with half backed legal theories and asking them to modify their
licence. In the long run, it will harm debian.
> However, free and equitable access to the source code is a precondition of
> distribution in Debian, but we can't *demand* that of authors.
Sure.
> > > 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
Hehe.
> 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.
Sure, but i believe that a courteous and respectfull way would be to give some
proper arguing of what the problems are, without far fetched desert island and
chinese dissident stuff, and wild theories without any real legal backing.
> > > 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.
Well, thereis always redhat, suse, and other suches. Upstream distribute .rpm
packages anyway on their site, so ...
Friendly,
Sven Luther
Reply to: