Something first off -- if we get together a complete list of issues we have with the licence (which are, after all, mostly matters of interpretation), do you believe that OCaml upstream will get shirty if you ask them for clarification of intent with regards to those issues?
If so, that may be of more use than these swings and roundabouts we seem to be enjoying so much. Oh, and by the way, I've been getting bounces on my posts to debian-ocaml. On Wed, Jul 21, 2004 at 11:37:57AM +0200, Sven Luther wrote: > 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: > > 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. OK, but rest assured that 3b *is* a problem, and by dropping it from this thread, you're only prolonging your time here. > > > > 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. You seem to have trouble keeping your arguments straight. You yourself have said that section 6 deals with linking, not modification. We're not supposed to be talking about modification here. And yet you are. And what you say I'm saying is not what I'm saying. You said "[A] work linked with the GPLed software has no choice but to be the GPL (or some minor derivative)". The straight 2-clause BSD licence is suitable to be linked with GPLed software. Hence, by your reasoning "GPL (or some minor derivative)", the 2-clause BSD is either the GPL or some minor derivative. > > > > 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. You'll waste more of your time if we're talking at cross-purposes because of differences in definitions. > > > > 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 ? Because there's no guarantee that the arguments used in court will necessarily contain common sense. > > 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 : And did you notice that trolltech is not a copyright holder on OCaml, and therefore their opinion isn't worth a hill of beans? Annotations are useful to determine the state of mind of a copyright holder. A statement from the copyright holders of OCaml stating that their views match those expressed in the Annotated QPL would go some way to solving these problems. > This is a license designed for libraries, therefore we must also talk about [...] > Is there still some doubt after that ? And how does it apply to some > program who is not a library. Why is INRIA trying to apply a licence for libraries to a regular program? I suspected that was a large part of the problem. > > > > 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. Whose authority prevails if we both hold our beliefs? I haven't read the annotated QPL from Trolltech, because it has infinitesimal bearing on what INRIA thinks of the licence. > > > > 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. I think it's quite funny. You think that merely by saying "bogus arguing" you can make my argument disappear. If it's bogus, show it to be so. Bald assertions have very little mass. > > > > 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. The formulation of section 6 in what way? That it talks about linking? I think we've established that. If you've got something more to add, please add it right here. The "explained above" could cover any number of paragraphs that you'd written. > 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. You seem to really relish calling arguments bogus, but don't actually show *how* their bogus. If all my arguments are made of straw, why aren't you pulling them apart? Instead you resort to pure assertion, and hope nobody notices. > > > 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 ? I did kinda cover why it's important to consider them in the next section... > 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. OK, let me go with a bit of ASCII art here to show this. QPL 6: "You may develop application programs, reusable components and other software items [A] that link with the original or modified versions of the Software[B]." There's two ways of reading this: 1) Either clause 6 applies to all A which is combined with B, regardless of the direction of the relationship; or 2) It only applies to items A which rely on B for operation, but does not apply to items A which B relies on. To put it in Debian terms, it applies to packages A which Depend: on B, but not packages A which B Depends: on. If the first interpretation is the correct one, then in order for me to be able to make a modified version, I have to have the ability to distribute the source of every library my modified version links against to the initial developer on request. That includes proprietary system libraries that might be on my crapola commercial Unix. (The GPL gets around this by having a system library exception, of which there is none in the QPL). Nor can we use "available to the general public", because those proprietary system libraries aren't. Hopefully, you can see that interpretation 1 is unworkable. If the second interpretation is correct, then I can hide my proprietary modifications in a library which the QPL'd program uses, because I only need to provide source to anything that relies on the QPL'd program. That's a loophole you can drive a truck through. I'll give you a hint as to how you can rebut this point: you can give another workable interpretation of the above quoted sentence; you can show that both of my interpretations above are flawed; or you can attempt to demonstrate that my extrapolations from both readings are flawed. > > 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. Done. > > 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. OK, that might have been a bit of hyperbole. > > 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 ? No, for the reasons given the first time you raised the annotated QPL above. > > > > 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. If you're talking about the issue I think you're talking about, the header files were considered to not constitute a derived work because there were not a creative work, and therefore didn't enjoy copyright protection. > > > > 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. That's quite interesting, as the whole reason you're here, I thought, was because the OCaml licencing situation affects you as the maintainer. I was raising a problem with the linking clause of the OCaml licence. You should probably spend some time addressing the points raised, rather than just deciding to discuss something else. > > 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. They don't cause problems because of the licences of the libraries, they cause problems because of the licence of OCaml. > > > > > 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. The important word there is "competent". Over here, some lawyers are good and some are poor. I imagine the situation is similar in France. Picking someone out of the phonebook is not likely to produce a competent lawyer. > > 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. But it doesn't matter, because the letter isn't going to be the end of it. > > > 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 ? I believe that the plaintiffs and their cheap-suited lawyer are incapable of having a conscience, but that's something of a different matter. And I don't see what the conscience of a plaintiff has to do with the fact that the defendants in a foreign-jurisdiction lawsuit are going to be out of pocket to the tune of some tens of thousands of dollars. > > > > > 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 ? Let's try that again: "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?" All we have to go on is your word. You are probably quite sure that upstream won't exercise their licence. That's great for you. But what about everyone else? Are you seriously standing up and saying "trust me"? I believe that's what US presidential candidates do. > > > > 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 ? Probably because I didn't see it. Nobody brought it to my attention, and as chief bollocks-sayer of debian-legal (self-appointed), I believe I should have been alerted to the fact that someone was saying something bollocks-worthy. > > 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. It will also harm Debian if we distribute something to our users, who proceed to use it in a manner consistent with the DFSG, and then they get properly sued for copyright infringement. > > 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. A request: please demonstrate exactly *how* my theories are wild. You appear to be very good at assertion, but your reasoning seems weak. > Well, thereis always redhat, suse, and other suches. Upstream distribute .rpm > packages anyway on their site, so ... ... people can download those and use alien. Problem solved. - Matt
