Re: Bug#383481: Must source code be easy to understand to fall under DFSG?
On Mon, Oct 30, 2006 at 04:52:13PM +0100, Ola Lundqvist wrote: The only thing is #2 above. The question is if someone must release all it knows when it release open source software (according to DFSG) or if you can release only enough to make something work. I can also put it as if you want to make good software, when you release something as open source? What I want to tell with this message is that we should stick to what the license tell. The important thing is that we do not build something binary that do not contain the code that can produce that binary. If we consider this as a violation of the DFSG (because of #2 above), then where do we draw the line between closed and open source? Notice that in the GPL case, the definition of free software (to use the FSF/GNU terminology, which is more fiting here) is pretty clear about the what is source, namely the prefered form of modification. Must software be easy to understand, or should we consider all software that have hardcoded values as closed source? Will all reverse engineered drivers with hardcoded values be considered as closed source? Must you always release everything that you know when you release somehting as open source? Must we release the instructions on how to paint an image, how to move the arm while painting if we release an image as open source? I think this is worth considering. Personally I think this bug can be closed. But your thinking are giving us an excellent way out. We could simply take all those binary blobs that are in the kernel, and try to take a guess about the instruction set which they are designed for, and disasemble them, and provide the dissasembled version under the GPL, as well as a instructions to re-assemble them into the actual binary blob. If we were to achieve that, i would be more than happy to consider these blobs and their corresponding reverse-engineered asm codes as actual source. One may argue that in this case, the actual documentation of the registers may be more of a source for such binary blobs, but it would in any case be no worse than any other reverse-engineering effort out there. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#383481: Must source code be easy to understand to fall under DFSG?
On Tue, Oct 31, 2006 at 09:06:50PM +0100, Ola Lundqvist wrote: Hi Sven On Tue, Oct 31, 2006 at 07:32:02PM +0100, Sven Luther wrote: ...CUT... Will all reverse engineered drivers with hardcoded values be considered as closed source? Must you always release everything that you know when you release somehting as open source? Must we release the instructions on how to paint an image, how to move the arm while painting if we release an image as open source? I think this is worth considering. Personally I think this bug can be closed. But your thinking are giving us an excellent way out. We could simply take all those binary blobs that are in the kernel, and try to take a guess about the instruction set which they are designed for, and disasemble them, and provide the dissasembled version under the GPL, as well as a instructions to re-assemble them into the actual binary blob. If we were to achieve that, i would be more than happy to consider these blobs and their corresponding reverse-engineered asm codes as actual source. One may argue that in this case, the actual documentation of the registers may be more of a source for such binary blobs, but it would in any case be no worse than any other reverse-engineering effort out there. I fully agree that this kind of work would be a good thing. Such improvements would most problably be a benifit for the open source community and maybe would give us better functionality in the end. Patches are welcome :) The question is if it is a violation or not to release as is. I doubt that there is any more sense in (re-)discussing this. The other good (or bad?) thing is that we would need cross-compilers for most major instruction-sets as reassembling probably mean compiling for a different architecture. Nope, because you can ship the source code and the object file if you wanted. Already now, major parts of debian/main are not cleanly buildable out of the box, due to cyclic bootstraping dependencies. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#383481: Must source code be easy to understand to fall under DFSG?
On Wed, Nov 01, 2006 at 12:55:45AM +0100, Francesco Poli wrote: On Tue, 31 Oct 2006 23:59:18 +0100 Sven Luther wrote: [...] Nope, because you can ship the source code and the object file if you wanted. Already now, major parts of debian/main are not cleanly buildable out of the box, due to cyclic bootstraping dependencies. But those major parts of debian/main are cleanly buildable using an already functioning installation of debian/main, aren't they? No, not always. At least I *hope* those major parts are buildable using only packages from debian/main, otherwise they would Build-Depend on out-of-main components, which is a Policy violation for a package in main, AFAIK. Well, It is not so much that you have to depend on out-of-main components, but that you have to hand-build some of them and stop in the middle and stuff like that. If what I have just said is true and confirmed, then *that* is the difference: one thing is having cyclic bootstrapping dependencies that make an already compiled and installed system necessary, a completely different beast is something that needs an out-of-main compiler in order to be compiled... Well, the cross compiler would be built from the same gcc source in main. There is just no binary package provided for those. Or am I completely off track?!? Not completely, but a bit yes. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Fri, Oct 20, 2006 at 02:10:37PM +0200, Arnoud Engelfriet wrote: MJ Ray wrote: While fairly simple, it is totally incorrect, as public distribution in breach of copyright carries criminal liability in England, as I previously posted. See the Copyright Designs and Patents Act as amended, under the criminal liability heading. http://www.jenkins-ip.com/patlaw/cdpa1.htm I suspect most of the EU has similar law these days, although I cannot name them. You're correct, there is criminal liability in most of Europe for intentional infringement of copyright. Many countries do however require the copyright holder to file charges against the infringer first. The police won't act by itself (how could they, they have no evidence of an illegal act unless the copyright holder files the accusation of distribution without a license). I do wonder, are the copyright holders of the firmware the only people with standing to sue? If the combination of firmware and GPL-licensed kernel is a derivative of the kernel, then anyone with a copyright interest in the kernel can sue for not obeying the GPL. Please check past debian-legal discussion about this. IANAL and everything, but all times we discussed the issue the opinion that prevaled, was that the firmware do not constitute a derivative work of the kernel, in the same way that if the firmware is contained in a flash on the card, it does not constitute a derivative work of the kernel, and in the same way a free compressor which can generate compressed archive with builtin uncompressor binaries, is not a derivative work of the compressed files it contains. More arguments on this can be found in the list archive. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote: The answer to the question in the subject is simple: NO. This is a matter of copyright law. If we do not have permission to distribute, it is illegal to distribute. GPL grants permission to distribute *only* if we distribute source. So, GPLed sourceless == NO PERMISSON. I will list the usual caveats so that nobody else brings them up. (1) Obviously if we have an alternate license (dual-licensing) which doesn't require source we can use that license. (2) If the material is so trivial it is uncopyrightable we can obviously distribute it. (The classic example is CRC tables, which contain no creative content beyond the CRC polynomial which is generally public domain.) Likewise if it was published prior to 1988 in the US without copyright notices, or is in the public domain for some other reason. (3) If the copyright holder for the firmware donated the firmware to Linux with the understanding that it would be redistributed by Debian and other distributors, this may constitute an implicit license to distribute. This would be a case of dual-licensing, but an unpleasant one because we'd be relying on an *implied* license. This requires tracing down the donation of the material to the Linux kernel and ascertaining the state of mind of the donor (perhaps by reading press releases). This clearly applies only to some of the firmware; other pieces have no such 'paper trail'. Also, this implicit license *does not* include a license to modify, because I've never seen any indication that any firmware donor intended that their firmware be modified. (4) If the hex lumps really are the preferred form for modification, then we have the source and this is not a case of 'sourceless firmware'. I have not yet seen a case where there is any evidence that this is true. It is, however, theoretically possible. If the firmware author came forward and said Yes, that's the form in which we modify the firmware, this would be the case. Thanks Nerode for this complete reply. It seems thay 3) is probably the best way we have to be able to distribute sourceless de-facto GPLed firmwares, but as you say, it will be a mess. I suppose the firmwares resolutions, both the one voted, and the one i proposed, both allow to include those firmwares into main under these conditions, for etch only, altough the resolution voted upon is probably much less clear in its wording. It is regretable that Manoj losed patience suddenly after more than a month an a half of discussing the issues. But we will see. I think we all now await impatiently the statement of the RMs on what will happend with the tg3 and acenic firmwares, and if we need a new vote or not. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Wed, Oct 18, 2006 at 08:06:19AM +1000, Anthony Towns wrote: On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote: The answer to the question in the subject is simple: NO. Thankyou for your opinion. I note you seemed to neglect to mention that you're not a lawyer. Anthony, Could you use some of the trunkloads of money available at SPI for debian, in order to consult a lawyer on these issues, instead of making such comments ? This should have been done months ago, and would have avoided probably much dispute of no-lawyer person trying to argue stuff. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Fri, Oct 06, 2006 at 11:18:09AM +0300, Markus Laire wrote: On 10/6/06, MJ Ray [EMAIL PROTECTED] wrote: I'd defer to Larry Doolittle on this one, but I think unless we have some reason to think there is another form used as source code, it's fine to consider the only codes our source code - for all we know, it was written that way. Best of all would be to get clarifications of what type each firmware is, but I doubt that's easy in all cases. However, if we strongly suspect that we don't have a valid permission to modify, distribute and so on, run a mile. I'd like to note a message[1] by Frank Küster concerning this on That message was from Larry, not Frank, since it was Larry who did the original audit, and listed relevant information on his web site, mirrored at : http://wiki.debian.org/KernelFirmwareLicensing#head-93ba883132bc3ebc09131100ec6bb6fbfb5e3e61 debian-vote which wasn't posted to debian-legal. A quote from that message: : In making the list, I left off all cases where I had any doubt. : I am not perfect, but I have plenty of experience using and writing : firmware of many kinds. I would be very surprised if any of the : listed firmware is not derived from a human-legible design file of : one form or another. : : So while it is perhaps a polite excuse that we don't know for sure : if these thousands of bytes of hex code were ever compiled from source, : no sane person would bet against it. (And my answer[2] was that IMHO it's not a polite excuse but a blatant attempt to knowingly violate the copyright law without actually admitting the violation.) [1] http://lists.debian.org/debian-vote/2006/10/msg00090.html [2] http://lists.debian.org/debian-vote/2006/10/msg00102.html Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Thu, Oct 05, 2006 at 07:09:53AM -0700, Steve Langasek wrote: On Wed, Oct 04, 2006 at 10:28:20AM +0200, Sven Luther wrote: There is some claims that some of those blobs represent just register dumps, This is a strawman, and Sven knows this as I have told him quite plainly that this is not my claim. Where did i say it was your claim ? And what exactly do you claim, your position on this, or at least the way you communicated your position has been changing all over, which makes reaching a consensus with you as was the intention of the DPL quite damn hard. So, the RMs are making claims that those sourceless GPLed drivers don't cause any kind of distribution problem, This is a red herring. The *relevant* claim I have made is that it is inappropriate to use our GR mechanism to attempt to *decide* whether GPLed drivers cause a distribution problem. The release team, the ftp team, and I suspect even most of the kernel team have no interest in a GR that authorizes any distribution of software which it at the same time asserts is illegal. Please read the new wording of the proposal on : http://wiki.debian.org/KernelFirmwareLicensing It should take care of all problems regarding your fears, but then, i guess nobody cares about my proposals, because they come from me, right ? It is not reasonable for the project to vote on questions of legality, nor is it appropriate to rely on debian-legal for questions of legality. If the relevant delegates/maintainers have questions about the legality of distributing a particular piece of software, they should consult a lawyer. Yeah, but it is ok for you to say we won't distribute illegal to distribute firmwares, while at the same time distributing firmware illegaly. As long as we don't say it, everything is fine, right ? Sven is incongruously insisting both that these firmware blobs must be included in etch, *and* that they're illegal to distribute. This is No, i believe in being honest and saying things like they are. But this is clearly a position which is not welcome in debian these days, and which needs even to be shuted down by aggresive bashing. nonsense; trying to convince the release team and the ftp team that these are illegal to distribute is contrary to his stated goal of including maximum hardware support in etch. He can't have it both ways, because no GR can compel the release team or the ftp team to knowingly break the law. Why do you want a GR then, why did you lose everyone's time by starting this huge threads, while the kernel team was working on a good and consensual proposal, which you didn't want to participate in, and hurried your own proposal out the door, with the result we know ? while i strongly believe that the GPL clause saying that all the distribution rights under the GPL are lost if you cannot abide by all points, including the requirement for sources. I have previously given my own understanding of why it is not a problem for us to distribute GPLed firmware blobs pending license clarifications, but I don't see any indication that Sven is interested in understanding that POV, only in tilting at strawmen; so I don't intend to lose any more time on discussing this point beyond this single clarification email. Yeah, because an opponent doesn't agree with you, you don't discuss his argument, but try to bring him down by dirty methods and FUD. I wonder if you are in connivance with Frans's new bashing against me, or if that was just coincidence. Hurt, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Wed, Oct 04, 2006 at 11:58:51AM +0300, Kalle Kivimaa wrote: [Restricting to -legal, feel free to widen the audience if neccessary] Sven Luther [EMAIL PROTECTED] writes: So, the RMs are making claims that those sourceless GPLed drivers don't cause any kind of distribution problem, while i strongly believe that the GPL clause saying that all the distribution rights under the GPL are lost if you cannot abide by all points, including the requirement for sources. If the copyright holder distributes the material under GPL, I would be surprised that a court would find redistributing that same material under GPL invalid. The copyright holder obviously believes that the No, because the copyright holder has the right to distribute the GPLed code without source, as long as he is the sole copyright holder. hex dump is the preferred method of modification in this case - why The case here is more insidious. There is ample evidence that this is not the preferred method of modification, and the license change of the broacom/tg3 driver for example clearly states : Derived from proprietary unpublished source code Which leaves little doubt about this. else would it be distributed under GPL instead of some no modifications, no redistributions -license? The broadcom/tg3 licence, which broadcom clarified after we approached them states : Permission is hereby granted for the distribution of this firmware data in hexadecimal or equivalent format, provided this copyright notice is accompanying it. so, syntactic modifications and distribution. The main point is that the actual reason for this mess is that those vendors provided these firmware blobs without thinking of the implication, and the upstream kernel folk took them in because it was more convenient to consider them as data (to the kernel). So, the implicit placement of these binary blobs under the GPL is an oversight, not something willingly done by the firmware copyright holders. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
Hi debian-legal, ... It seems the firmware kernel issue has reached a deadpoint, as there is some widely different interpretation of the meaning of the GPL over sourceless code. For some background, the kernel/firmware wiki page includes both a proposed GR, the draft position statement by the kernel team, as well as an analysis of how we stand : http://wiki.debian.org/KernelFirmwareLicensing. But this is beside the point. The real problem is that there are a certain amount of firmware in the kernel, embedded in the drivers, which have no license notice whatsoever, and as thus fall implicitly under the common GPL license of the linux kernel. The audit from Larry lists some 40+ such firmware blobs. There is some claims that some of those blobs represent just register dumps, but even then one could argue that the hex blobs doesn't in any way represent the prefered form of modification, but rather some kind of register name/number and value pair. So, the RMs are making claims that those sourceless GPLed drivers don't cause any kind of distribution problem, while i strongly believe that the GPL clause saying that all the distribution rights under the GPL are lost if you cannot abide by all points, including the requirement for sources. Since i am seen as not trusthy to analyze such problems, i think to deblock this situation, it would be best to have a statement from debian-legal to back those claims (or to claim i am wrong in the above). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Wed, Oct 04, 2006 at 09:31:27PM +0200, Frank Küster wrote: Walter Landry [EMAIL PROTECTED] wrote: Sven Luther [EMAIL PROTECTED] wrote: So, the RMs are making claims that those sourceless GPLed drivers don't cause any kind of distribution problem, while i strongly believe that the GPL clause saying that all the distribution rights under the GPL are lost if you cannot abide by all points, including the requirement for sources. When Debian distributes kernel binaries, Debian makes use of clause 3a (accompany with source code), not 3b (written offer) or 3c (pass on written offer). So source has to accompany everything, even if no one is asking. Well, I think Sven didn't make the point of disagreement clear. It is whether what in the course of the GR's has been called sourceless firmware is in fact sourceless. If I understood Anthony Towns correctly, the ftpmasters and many others want to give those drives the benefit of doubt and assume that they aren't sourceless, but are, e.g., just dumps of unnamed registers and therefore the preferred form for modification. After all, they were what was given to the kernel people when the driver was released as .c and .h files under the GPL. Indeed, but even in the case of pure register dumps, there is no way the actual firmware blob in the current kernel constitutes the preferred form of modification. That said, it is my experience that more often than not, those firmware blobs are indeed code, especially when one talks about a device with an embedded mips core for example. We could try to do a determination firmware by firmware, depending on its size and stuff like that, but we are particularly trying to postpone this work post-etch. So the real question is whether we want to do that, whether in the particular cases there's in fact any doubt, etc. The ftp-master position has always been one of erring on the side of caution though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Wed, Oct 04, 2006 at 09:31:27PM +0200, Frank Küster wrote: So the real question is whether we want to do that, whether in the particular cases there's in fact any doubt, etc. A quick survey based on the size of the firmware blobs suggests 1/3 of them may be register dumps, while 2/3 are most probably code. That makes a bit less than 30 problematic ones. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
On Sat, Sep 09, 2006 at 01:57:31AM -0400, Nathanael Nerode wrote: The arsenic case was more problematic, since the copyright seems to have landed at broadcom too, but they don't care since they don't sell it anymore, Given this, we actually should have a decent chance of getting them to license it under a free software license (after all, what do they care about it?) provided we can talk to the right people. Well, the thing is they can't be bothered to make sure they are actually the right people or something. Notice that even in a friendly case, like the ocaml library which ended up at HP, and i asked bdale over it, it was not possible to find the papers back, but then it was easier to reimplement that code. May guess is that the source code is lost in some obscure case and nobody cares, but right, if you find the right person ... and they probably are not even aware of the fact that they are actually copyright holders. FYI, there is a way to deal with a copyright of unknown ownership. Get a license from everyone who *might* have the copyright. Of the form *If* Broadcom holds any copyrights in this code, and we don't know whether we do, *then* Broadcom licenses its copyrights under license X. Broadcom does not license any copyrights which it does not hold as of date. Yes, i was thinking something such. Repeat with all other companies which might have some of the rights. Once you've gone through all of them, you have a proper license, even though you don't know who holds the copyright. :) This is essentially similar to getting quitclaims for contested land. :) I had a similar problem with some ocaml library, which was developed together byt the ocaml team and the digital labs, which ended up at HP, and even asking bdale about it, did not help free that code, which is now lost forever and upstream reimplemented it. At least we actually have the source for the acenic code, even though we don't have a free license for it. Euh, no, it is a binary-only firmware blob last i checked, but i may be wrong. I think the quote from bdale was i think i know in which set of boxes it may possibly be. I think that throwing Debian's name around with 'offical' status may be helpful to get responses from some of these companies; I didn't do that, since I couldn't! Well, assuredly, but i think that another difference may have been the more reasonable and well though-out mail with some legal analysis, and the fact that what we demanded was quite easy for them to do. Also, the timeline was maybe one of more maturity and sensibility on this subject, and we had a rather huge thread on LKML when it happened. From your past posts on the subject, i believe that maybe the wordings you chose where not the best ones, but as i have not seen said mails ... Probably not the best words. I was very polite to them, since I really figured it was just an honest mistake (which it was), but I probably came across as an unimportant nobody and they figured it wasn't worth wasting their time. Yep, which is why it is important to find out the list of licensors/copyright holder of the other problematic cases, and someone, preferably imbued with an official and announced delegation from our DPL, will contact them on Debian's behalf. Ideally, we would do it in such a way that it is precedeed with a slashdot article, and/or other widespread press campaign, or something. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Thu, Aug 31, 2006 at 10:30:07AM +0100, MJ Ray wrote: [-devel trimmed] Sven Luther [EMAIL PROTECTED] wrote: Please reread the discussion on debian-legal about this, where consensus was mostly found to support this idea, and also remember that we contacted broadcom with this analysis, who contacted their legal team, and i also mailed the FSF lawyers with it, and got no counter-claim to it. Which discussion? Err, the discussion about this exact issue hold on debian-legal and debian-kernel and partly LKML in fall last year. I made some detailed analysis of the problem, and got input from various d-l folk, i think i even remember you participating in it. What responses did you get from broadcom and FSF lawyers? (The above makes it sound like you maybe got no responses.) Broadcom consulted with its lawyer team, and then changed the licencing of the firmware blob accordyingly. Most if not all of this is public in debian-kernel, so you can check for yourself. I posted the FSF address for legal and lawyer issue, but got no reply, at least i don't remember a reply, as hinted above, altough i don't know if this was over busy-ness of their folk over things like the GFDL and GPL3 at that time, or whatever, but i believe that if my analysis was obviously wrong, they would have replied, given the importance of the non-free firmware to the FSF and the free software community in general, and that there was a rather big and emotional thread in LKML about this. Not sure though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, Aug 30, 2006 at 09:27:21AM +0200, Marco d'Itri wrote: On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote: Debian must decide whether it wants to ship BLOBs with licensing which technically does not permit redistribution. At least 53 blobs have this problem. Many of them are licensed under the GPL, but without source code provided. Since the GPL only grants permission to distribute if you provide source code, the GPL grants no permission to distribute in these cases. Many people disagree with this interpretation. A few very vocal people do. I guess they can be counted on the fingers of both hands or so. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, Aug 30, 2006 at 08:18:28PM -0400, Nathanael Nerode wrote: Sven Luther wrote: Since the firmware blobs are not derivative works of the kernel, but constitute mere agregation in the same binary format, the authors of other pieces of GPLed code fo the linux kernel cannot even sue us for distributing the kernel code with those GPL-violating binary BLOBs. This is not clear in the cases where the blobs are embedded directly into Please reread the discussion on debian-legal about this, where consensus was mostly found to support this idea, and also remember that we contacted broadcom with this analysis, who contacted their legal team, and i also mailed the FSF lawyers with it, and got no counter-claim to it. the kernel, particularly when they're embedded in the same source files. There's a case to be made that this is *not* mere aggregation, but creation of an enhanced combination work which is derivative of both the firmware and the other parts of the kernel. Simply putting files side by side is mere aggregation -- what's happening with the drivers and firmware might be mere aggregation, but nobody can be sure until a court case happens. Well, in the debian-legal discussion i gave plenty of counter examples, ranging from a firmware flasher (little C program with embedded firmware, exact same case as the kernel situation), to compressed binaries with uncompressing software embedded, passing by filesystem binaries containing both GPLed content as well as non-free content. So, all in all, unless you bring new evidence, there is really very little doubt about this, unless you want to consider your hardware a derived work of the linux kernel, but i doubt a judge will follow you on this one. IANAL, but there is a part of common sense and simple logic in most legal cases. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The Curious Case Of The Mountainous Molehill
On Tue, Feb 14, 2006 at 02:41:08PM +1100, Craig Sanders wrote: On Mon, Feb 13, 2006 at 08:55:35PM -0500, Anthony DeRobertis wrote: Craig Sanders wrote: the DFSG also allows that the modification may be by patch only. No, it does not. yes it does. Quoting DFSG 4, with emphasis added: The license may restrict source-code from being distributed in modified form _only_ if the license allows the distribution of patch files with the source code for the purpose of modifying the program at build time. THE LICENSE MUST EXPLICITLY PERMIT DISTRIBUTION OF SOFTWARE BUILT FROM MODIFIED SOURCE CODE. I have looked, and I can find no provisions in the GFDL explicitly permitting distribution of software built from modified source code. the GFDL is applied to documentation, not software. by your loony literalist interpretation, no documentation can possibly be free because you can't distribute software built from it. What happens if you have a document in some source format under the GFDL (let's say latex code or sgml stuff or whatever), and you are distributing the 'compiled' version (let's say a pdf) ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [tex-live] Re: License of fonts included in X.org sources
On Sat, Oct 22, 2005 at 03:57:15AM +0200, Reinhard Kotucha wrote: Daniel == Daniel Stone [EMAIL PROTECTED] writes: Yes. Can TOG be regarded as the legal successor of the X Consortium? From http://www.faqs.org/faqs/x-faq/part1/section-16.html Here is the text of the announcement posted by the Consortium to comp.windows.x on 1 July 1996: X Consortium to Transfer X Window System(tm) to The Open Group So you would say that TOG is the one who now has the right to the fonts ? As a last resort, maybe Thanh can ask Adobe with whom of the X Consortium they negotiated, maybe he can help. If nothing else, they must have a copy of the paperwork around. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [tex-live] Re: License of fonts included in X.org sources
On Sat, Oct 22, 2005 at 09:01:53AM -0300, George White wrote: Quoting Reinhard Kotucha [EMAIL PROTECTED]: When Sebastian presented pdftex at Adobe, they had been amazed that pdftex can do things they cannot do with their own tools (I suppose that Hans Hagen provided some files). This was years ago, but meanwhile Thanh provided many microtypographical extensions. If things evolve in the future as they did in the past, I suppose that pdftex is not good PR for Adobe, it's more likely that they regard pdftex as a competitor. In the past, Adobe has fixed Reader bugs that were triggered by files created with TeX (encodings using ASCII NUL, although TeX responded to the bugs with new encodings). Enlightened software vendors understand very well that the user community's investment in workflows forms the basis for long-term success. I suspect Adobe is happy to have the TeX community providing the tools to deal with mathematical typesetting, as the commercial market is probably too small in relation to the cost of developing/maintaining the tools. In my view, current intellectual property law misses the importance of the user community. This creates a danger that users can loose their investment in workflows through the demise of a vendor or outrageous price increases. While I don't think Adobe has immediate plans to cash out on PDF, history shows that successful companies can fail (e.g., by ill-advised moves into areas where they have no competence), leaving intellectual property in limbo, or be taken over by groups who will grab the cash and run. While there is currently little danger of Adobe doing anything to hurt pdftex (and if pdftex was harmed as an unanticipated consequence of some other action, Adobe would probably work to resolve the problem), there is no protection for pdftex from some unrelated business catastrophe. In such an event, pdftex users would be better off than users who rely entirely on Adobe tools. Current acrobat reader (well, it was at least a couple of years ago) licencing forbids it to be distributed alongside other pdf generating tools like pdftex, which is in big part why it was removed from non-free back then. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [tex-live] Re: License of fonts included in X.org sources
On Fri, Oct 21, 2005 at 10:26:14AM +1000, Daniel Stone wrote: On Thu, Oct 20, 2005 at 08:21:08PM +0200, Reinhard Kotucha wrote: Daniel == Daniel Stone [EMAIL PROTECTED] writes: Right. As I said earlier, it's probably tied up somewhere deep within TOG: no-one still involved with X today remembers this at all. Maybe it is sufficient to find someone at X.org who is willing to care about the legal stuff. It is a great advantage that Thanh found someone at Adobe who remembers. We have a couple of people who deal with legal stuff (a lot of the time it's me sitting there going, 'y'know, all rights reserved and nothing else doesn't bear well for us distributing this'), but the problem in this case is the multitude of organisations. It may have been granted to: * the defunct MIT-based X Consortium, * directly to The Open Group, * X.Org as part of TOG, * X.Org Foundation. All the XOF people swear that they haven't heard of it. If it's trapped in XC, then we're stuffed. If it's deep within the annals of TOG, then they don't know about it on a surface inspection, and it would take absolutely ages to find out either way. If it's within TOG-X.Org, then no-one who was around during those days knows about it, so it's likely been lost. See the problem? Can we not ask the original author to regrant us the rights ? Or clarify the statement ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linuxsampler license
On Thu, Sep 15, 2005 at 08:03:46AM +0300, Harri Järvi wrote: On Wed, Sep 14, 2005 at 16:26:15 +0200, Göran Weinholt wrote: On Tue, Sep 13, 2005 at 05:54:35PM +0300, Harri Järvi wrote: In addition there's a conflict between linuxsampler's aim to be an opensource software, and the license used. Restricting commercial use makes the software nonopensource by OSI definition and nonfree by Free Software Foundation's Free Software definition. I think upstream only meant to make it clear to developers of proprietary software that they need to ask for a special license if they don't want to follow the GPL. I wish it was so, but this is written on the project home page at http://www.linuxsampler.org/downloads.html: License LinuxSampler is licensed under the GNU GPL license with the exception that COMMERCIAL USE of the souce code, libraries and applications is NOT ALLOWED without prior written permission by the LinuxSampler authors. If you have questions on the subject please contact us. That is indeed non-free and fails DFSG #6, the package cannot be in main, but could be in non-free maybe. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dissident test (was re: CDDL)
On Wed, Sep 14, 2005 at 09:29:52AM +, MJ Ray wrote: Marco d'Itri [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: It seems grounded in the DFSGs 1. Free redistribution and 5. No discrimination against persons or groups. It may seem so if you are willing to stretch enough the meaning of the DFSG in ways it was never supposed to be. I'm not. If non-discrimination doesn't cover groups persecuted by governments, who does it cover for you? I think the point here is that a licence doesn't discriminate against such groups, it only forbids anonymous changes from being distributed. Apart from such anonymous changes using a pseudonym or something such, which would solve this for all considered, i feel that the main point is that if the DFSG is really about not forbidding anonymous participant to modify/distribute/whatever their code, it should then be said explicitly, instead of abusing DFSG #5 to include all sort of strange things. So, if you really believe we should allow for anonymity, please go ahead, and propose a a DFSG amendment, i will even second you on this. In April 2005, Shi Tao was imprisoned for 10 years for providing state secrets to foreign entities, partly because the local police traced his email address back to him (source Reporters Sans Frontiers). In that case, it was news of a censorship order, but why not news of a security vulnerability that state agents are exploiting? Anonymity has benefits for freedom. Sure, but irrelevant to the DFSG #5 as drafter. The DFSG clauses are meant to be clear and understandable, and not to resort to chancy interpretation not everyone agrees with. Also, i belive he got caught because he was careless in his email handling, not because he distributed a modified version of some free software with his email address in it. Also notice that nothing in the CDDL clause force you to include the email address or even your real name for code attribution, i think a pseudonym would be widely accepted in such cases as the above. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dissident test (was re: CDDL)
On Wed, Sep 14, 2005 at 12:08:33PM +0100, MJ Ray wrote: Sven Luther [EMAIL PROTECTED] wrote: On Wed, Sep 14, 2005 at 09:29:52AM +, MJ Ray wrote: If non-discrimination doesn't cover groups persecuted by governments, who does it cover for you? I think the point here is that a licence doesn't discriminate against such groups, it only forbids anonymous changes from being distributed. So a licence that doesn't discriminate against non-US, but forbids changes made with non-US keyboards from being distributed would be fine by you? (There's probably a better example.) This is word play, if you want to forbid anonymous distribution, then say so explicitly in the DFSG and submit an amendment to that effect. [...] Also notice that nothing in the CDDL clause force you to include the email address or even your real name for code attribution, i think a pseudonym would be widely accepted in such cases as the above. That depends what identifies You means in CDDL 3.3. Do you know whether pseudonymously edited versions of star would be tolerated by Joerg Schilling, for example? Well, he can hardly sue you if you are anonymous, now can he ? And all the rest is moot anyway, since you cannot force him to takeover his code. And if the change is noted as havign been written by chen zan or whatever, without email address, how do you know it is a pseudonym or not ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dissident test (was re: CDDL)
On Sat, Sep 10, 2005 at 08:38:19PM -0400, Catatonic Porpoise wrote: Marco d'Itri wrote: This might fail the Dissident test (and thus discriminate against Which is not part of the DFSG, so it does not matter. The Dissident test is a test for DFSG #5, so it does matter. See: http://wiki.debian.net/?DissidentTest http://people.debian.org/~bap/dfsg-faq.html Can we go back to interpreting the DFSG and the licence in real terms, instead of blindingly trying to apply random strange tests ? Do we really all agree that a licence is non-free if we don't allow anonymous modifications ? If so, please say : This clause doesn't allow anonymous modification, and thus we consider it non-free. And not speak about dissidents, desert islands and other such. Now, i believe this falls in the same category as the choice-of-venue clause, and namely that the DFSG #5 was drafted in order to not discriminate against specific group of people, as in : people born on halloween are the fruit of evil, and thus are excluded by this licence. (or whatever). Instead of going with very subtle and roundabout wys, and using discrimination for any random thing, like discrimination against poor people or people who want to be anonymous, which should, if we decide to go this way, be explicitly mentioned in the DFSG, instead of trying to deturn one of the guidelines into any random interpretation. Now, to the anonymous modification clause in itself. First it applies only to distribution of anonymous modifications, and more to the point, to integration of those anonymous modifications into mainline patches. My own interpretation of this CDDL clause is that the ai, of it is to maintian the copyright situation pure, in order to avoid SCO-like disasters over the code base. The same kind of practice is involved with the current handling of the mainline linux tree. What does this mean for someone who wants to make an anonymous contributions ? Well, since the contribution is anonymous, neither can his licence be revoked, nor anything can happen to him. If we discover who he is, the code is not anonymous anymore and the problem is solved. The only real problem is that the people caring about purity of code want to include such a patch, which is something they will not be able to do, in order to maintain the tracability of the copyright situation of the code. furthermore, how can you comply with 3.2 : You represent that You believe Your Modifications are Your original creation(s) and/or You have sufficient rights to grant the rights conveyed by this License. If you are not able to tell your own name ? And how will you then be able to respond someone suing us pretending we stole their code if we have no tracability information over who wrote it. So, in the post-SCO world, not only is the right of anonymous modifications not a DFSG violation, but i believe we would do well in explicitly forbiding integration in debian of anonymous code. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Sun, Sep 11, 2005 at 04:23:42PM +0200, Henning Makholm wrote: Scripsit [EMAIL PROTECTED] (Marco d'Itri) So finally we are up to the good old every restriction is a discrimination argument. Even if in the last two years it has become popular among some debian-legal@ contributors while the rest of the project was not looking, I believe that it is based on a misunderstanding of the meaning of DFSG #5. For what it's worth, I do not believe that DFSG #5 is a sensible reason to consider choice-of-venue clauses non-free. The sensible reason to consider choice-of-venue clauses non-free is the following general principle: A license can only be free if one can always accept the license without losing any right that one had before one received the license. (Those who think that licenses are not contracts and do not need to be accepted, feel free to substitue use the rights granted instead of accept). This is, in my opinion, the natural and direct extension of the explicit language that a license cannot require royalties or other fees to be paid in exchange for the rights described in the DFSG. Plain and simple, if it requires that you give up *anything* that you already had before, then it's not free. A choice-of-venue clause is a demand that I give up my right to have the specified foreign court automatically throw out a nuisance suit citing lack on the grounds of personal jurisidiction. Without the license I have this right; with it I don't. To try to shoehorn such a fundamental principle into the much more specific DSFG#5 just to please some literal-minded apologists who want the DFSG to be an objective ruleset rather than a set of guidelines, is just silly. So, what do you propose a new DFSG rule addition for the above principle ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dissident test
On Sun, Sep 11, 2005 at 11:40:41AM -0400, Benj. Mako Hill wrote: You seem to be making a call for interpreting the DFSG literally. I think this is impossible. We should stay as close to the spirit of the DFSG and we should rely on the text as our best clue. However, things will *always* come down to human judgment calls at one point or another. So, is the spirit of the DFSG #5 to forbid choice-of-venue clauses, or the anonymous contributions of the infamous dissident test ? And who is to interpret the spirit of the different DFSG clauses :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Fri, Sep 09, 2005 at 05:17:06PM -0400, David Nusinow wrote: On Fri, Sep 09, 2005 at 09:55:24PM +0100, Andrew Suffield wrote: Not really interested in the case where you actually did infringe on the license. I don't think it's worthwhile to worry about whether we discriminate against such people. Nuisance lawsuits are the canonical example of the important part here. That's the scenario where choice-of-venue is bad. Ok, thank you for clarifying that. I think we need to consider the point that Matthew has been raising though, that a choice of venue clause may be important for a program author to successfully defend their copyright. If the justification for this is to be grounded in the discrimination clause of the DFSG, we can't choose to discriminate against the program's authors. If this is to be grounded in the clause about not requiring a fee, we can't require that the program's author be forced to take on the burden of such a fee if they need to defend their copyright. Notice that the CDDL says : with the losing party responsible for costs, including, without limitation, court costs and reasonable attorneys’ fees and expenses how does that modify our acceptance of the choice-of-venue ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Fri, Sep 09, 2005 at 07:48:12PM -0400, David Nusinow wrote: Sorry, this sentence registers as complete nonsense to me. If you're going to claim that requiring certain things of *authors* before their code can be included in Debian is a fee, how is this particular fee different from the fee of publishing source code? If someone is going to file a lawsuit, someone has to pay for it. If the two sides live in different places, one of them has to travel no matter what, and thus pay for that expense. If we say that choice of venue clauses aren't Free, then the person bringing the suit will very likely have to travel and pay the fee (or that's my interpretation of Humberto and Michael Poole's responses). If not, then the person defending the suit will have to pay the fee. Either way, there is a cost involved. Why are we choosing sides if such a cost can't be avoided? Especially as the CDDL mentions that the loosing side has to pay the expenses. This leaves only the need to advance the money, and the problem with a given court having the risk of not being fair or just or whatever the name is, and in some way favour the author. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Sat, Sep 10, 2005 at 12:27:08AM -0700, Steve Langasek wrote: And remember that in many jurisdictions, it's also possible to sue for legal expenses under various circumstances. That means that the net (monetary) cost to a copyright holder for defending his copyright is potentially zero. Ah, but the CDDL does take that in account, and mentions explicitly that all epxenses will be paid by the loosing side. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Sat, Sep 10, 2005 at 06:10:46PM +0200, Marco d'Itri wrote: On Sep 09, George Danchev [EMAIL PROTECTED] wrote: [1] claiming that Debian has already accepted cddl by having cddl'ed star is weak arg because it easily could be clasified as bug. While it is obviously true that the ftpmasters are humans and therefore fallible beings, the fact that they have been accepting this kind of clauses in licenses since many years ago (QPL...) makes this interpretation unlikely. Well, since star was previously in the archive under a different licence, i believe more that they never even noticed that the licence did change. I believe packages are only examined if they pass NEW, but then maybe i am wrong on this one. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Sat, Sep 10, 2005 at 08:57:04PM +0200, Marco d'Itri wrote: On Sep 10, George Danchev [EMAIL PROTECTED] wrote: Not now. Debian (and I think every other distribution) has been distributing software with this kind of licenses for years, without any apparent ill effect on users. Not true. Many licenses that failed to comply with DFSG [0] has not been accepted. Many packages entered the Debian archive by incident has been removed. Past experience shows that licenses having choice of venue has been avoided [0][1]. You show that the same 5-6 debian-legal@ contributors do not believe that some licenses are free, but I do not see ftpmasters removing from the archive packages with a choice of venue clause in their license (I will not believe that they do not know about licenses like the MPL and QPL). Last time this came up about ocaml and the QPL, ocaml's upstream removed the choice-of-venue clause from the licence, under the menace of the package removal. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Fri, Sep 09, 2005 at 12:00:54AM +0200, Marco d'Itri wrote: On Sep 08, Sven Luther [EMAIL PROTECTED] wrote: Indeed, the choice of venue is a fee argument is just that: an opinion which has at best no clear roots in the DFSG, therefore it cannot make a license non-free. Yeah, but there is certainly more than a single person arguing that we should not distribute software with such licence. There is nothing wrong with this, and I'm not a fan of choice of venue clauses either, but they should try to modify the DFSG then. Claiming this is only a single person arguing that, when i pointed him to a 50+ thread where more than 10 person participated, well, i don't know what you think about lying and hypocricy, but i certainly find something wrong with it :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Fri, Sep 09, 2005 at 11:46:04AM +0200, Marco d'Itri wrote: On Sep 09, Josselin Mouette [EMAIL PROTECTED] wrote: It does not work this way. If you believe that a license is not free it's up to you explaining why. Well, I'm explaining that it isn't free because of DFSG#5. However, it seems that you are refusing such arguments de facto. I am refusing them as long as you cannot clearly show how DFSG#5 forbids some restrictions present in the CDDL. Marco, Remember the DFSG are guidelines, and it is ultimately to the responsability of the ftp-masters to take a decision, based on the DFSG, sure, but also on other consideration, as well as potential (legal) risk for our infrastructure, mirror network, and daughter-distribs and end-users. But then, it seems it is clear that the CDDL discriminates against any group of persons not living in the juridiction (juridiction is the same as choice-of-law, right ?) of the author suing them, or at least it seems clear that this is the argumentation used here. Now, this applies to choice of venue, not sure about choice of law,maybe too, but to a lesser degree, since it is possible that the defendant will have more trouble finding a lawyer familiar with the laws of a foreign juridiction. Now, i wonder what law and venue are applicable if no such clause is present ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Fri, Sep 09, 2005 at 07:23:10AM -0500, John Hasler wrote: Henning Makholm writes: I doubt that people who do not wish to become legally bound to appear at the the author's home court whenever he files a frivolous lawsuit can be meaningfully described as a group of persons that can be discriminated against. Why do you think that a copyright owner needs a choice of venue clause in order to file suit against you in his home jurisdiction? I had the impression that international law mandates that you can sue someone only where he lives, is established, or makes business, at least this seems to be the case in France. But then maybe this was only for contract law, or something, not sure, as IANAL. This is indeed a good question, and one which needs to be solved to solve this issue. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL
On Thu, Sep 08, 2005 at 07:28:46PM +0100, Andrew Suffield wrote: * 99.. MMIISSCCEELLLLAANNEEOOUUSS.. This License represents the complete agreement concerning subject matter hereof. If any provision of this License is held to be unenforceable, such provision shall be reformed only to the extent necessary to make it enforceable. This License shall be governed by the law of the jurisdiction specified in a notice contained within the Original Software (except to the extent applicable law, if any, provides otherwise), excluding such jurisdiction's conflict-of-law provisions. Any litigation relating to this License shall be subject to the jurisdiction of the courts located in the jurisdiction and venue specified in a notice contained within the Original Software, with the losing party responsible for costs, including, without limitation, court costs and reasonable attorneys' fees and expenses. The application of the United Nations Convention on Contracts for the International Sale of Goods is expressly excluded. Any law or regulation which provides that the language of a contract shall be construed against the drafter shall not apply to this License. You agree that You alone are responsible for compliance with the United States export administration regulations (and the export control laws and regulation of any other countries) when You use, distribute or otherwise make available any Covered Software. responsible for claims and damages arising, directly or indirectly, out of its utilization of rights under this License and You agree to work with Initial Developer and Contributors to distribute such responsibility on an equitable basis. Nothing herein is intended or shall be deemed to constitute any admission of liability. My own feeling is that this one is the real problem, and is dependent on how we decide on the choice-of-venue issue, and there is no clear precedent here, altough in the past many have expressed themselves against it. Friendly, Sven Luther
Re: CDDL
On Fri, Sep 09, 2005 at 04:51:56PM +0200, Henning Makholm wrote: Scripsit Andrew Suffield [EMAIL PROTECTED] o 3.2. Modifications. The Modifications that You create or to which You contribute are governed by the terms of this License. I think this is sloppy language - the licensor cannot unilaterally make his license apply to code produced by the licensee; he can only demand that the licensee does so - but I don't see it as a showstoppper. I believe that the Modifications here stand for code redistributed together with the original code, not just as separate patches or standalone code, and this is indeed how other licence works, you can only redistribute your modifications under the same licence or such. o 3.3. Required Notices. You must include a notice in each of Your Modifications that identifies You as the Contributor of the Modification. Dissident problem here. Anonymous contributions should be allowed. I disagree on this point, This is needed to protect against SCO like cases, in order to trace the modifications, and make sure they are not stolen or at least prove it so. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Fri, Sep 09, 2005 at 05:35:36PM +0100, Matthew Garrett wrote: George Danchev [EMAIL PROTECTED] wrote: On Friday 09 September 2005 18:24, Matthew Garrett wrote: But that's already possible. The majority (all?) of licenses that we ship don't prevent me from being sued arbitrarily. The only difference that choice of venue makes is that it potentially increases the cost for me. Within the UK alone, I can end up paying fairly large travel fees to deal with a court case. But I'll have to pay a lot more for a lawyer. Being sued in the US wouldn't be significantly more expensive for me than being sued here. The problem is not only with the expensive funny lawsuit trips, you may find some jurisdictions and local lows quite ... let's say just strange. That's choice of law, rather than choice of venue. I was under the impression that it was generally accepted. I wonder, let's say you are going to be judged in some random US court, even if it is with German laws, you still would fall into common US-practice legal or something such ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Fri, Sep 09, 2005 at 03:41:58PM +, MJ Ray wrote: [EMAIL PROTECTED] (Marco d'Itri) wrote: I am refusing them as long as you cannot clearly show how DFSG#5 forbids some restrictions present in the CDDL. It does not work this way. If you believe that a questionable license is free, then it's up to you to explain why it follows the DFSG and convince ftpmasters to admit the packages as a general rule. If you can't even convince this liberal crowd, ow! Naturally, you could try to get the package in on the sly, like apparently happeend with star :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Wed, Sep 07, 2005 at 04:08:51PM -0700, Mark Rafn wrote: On Wed, 7 Sep 2005, Joe Smith wrote: It is generally belived that the GPL 'derivative' clauses may actually be upheld in the case of static libraries. The fact that linking the .o's of the library directly with your program is equivelent to linking the library with the object files of your program, seems to verify this. The question still debated is whether Shared libraries are like this also. I haven't heard it debated very hotly in recent memory. General acceptance seems to be that it applies equally to static and dynamic linking. Dynamic linking DOES open up the possibility of distributing the using code and not distributing the library itself. The combination of the two may be un-distributable, however. Notice that the important thing here is not wheter the files are linked together and how, but wheter the combined work of them results in a derivative work, the way things are linked is only a technical detail of it, and the barrer to derivative works is a well defined interface between them or something such. The linux kernel 'copying' file states this: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of derived work. If that statement is true and if it does not qualify as a licence exception, then the following argument would hold: I think this is a license exception (or at least a clarification that applies specifically to this work). It is not a statement about GPL-licensed work in general. To quote RMS (this morning on the OpenSolaris list : The user programs link with libc but not directly with the kernel. People generally consider the kernel and libc not to be one combined program, so the GPL will not have effects across that boundary. Friendly, Sven LUther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
On Thu, Sep 08, 2005 at 10:27:20AM +0200, Florian Weimer wrote: * Måns Rullgård: The phrase running the Program is not directly applicable to a library, so we have to assume that for libraries, this translates into using the library, i.e. causing its code to be run, typically by running a program that uses the library. This act being unrestricted per the quoted paragraph, it follows that any program can link with a GPL library, no matter what license that program has. This only supports the widely held belief that you can do what you want with GPLed software inside your own four walls, without thinking too much about copyright issues. (I think this is quite an important freedom!) Indeed, the GPL only applies to redistribution, this is a widely known fact. And you only have to redistribut the source to the ones you are giving the binaries to, not the world at large. Usually, the interesting question is if you are permitted to distribute the linked program, and if dynamic linking makes a difference. nope, the only difference between dynamic linking and static linking is if you use the LGPL. I am told that also the distribution of something in the sole intent of being linked with GPL code, is already problematic, but that is up to interpretation i guess. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Thu, Sep 08, 2005 at 02:06:12AM -0700, Steve Langasek wrote: On Thu, Sep 08, 2005 at 10:14:50AM +0200, Sven Luther wrote: On Wed, Sep 07, 2005 at 02:48:15PM -0700, Steve Langasek wrote: On Wed, Sep 07, 2005 at 10:47:59PM +1000, Paul TBBle Hampson wrote: These two do not appear to be compatible (unless you think a license can be free with a venue choice that you do not consider sane), so I must have misunderstood one of them. Could you elaborate, please? If we replace sane with enforcable (which is what I think the OP was getting at) then they are in fact compatible. A license does not become non-free if it contains unenforcable components, unless it contains a component that specifies that any unenforcable clause voids the whole license. But choice-of-venue clauses, at least in contracts, *are* enforceable in some significant jurisdictions -- like the one which hosts ftp-master.debian.org. So their freeness is still an issue. I get the feeling that it is not the freeness of them which is an issue, they don't really make the software more or less free after all, since they enter in account only if the licence is broken No, they enter into consideration *whenever the copyright holder decides to sue you*. There have even been cases of one-time Linux kernel contributors flipping out and suing members of the community -- filing suit, of course, in their own home jurisdiction, where it's cheap for them to flood the courts with SLAPP filings. Do we really think it's a good idea to approve of giving copyright holders extra leverage for such lawsuits in their license, and just hope that none of these copyrights ever wind up in the hands of a hostile entity? , and we don't really can consider freeness definitions based on more or less broken local juridictions. In the past, when we have discussed broken jurisdictions, it has been in the context of licenses which don't go far enough to spell out freedoms that are taken for granted. When we talk about choice of venue clauses, however, this is a clause which has been actively included in the license and which is (IMHO) non-free in intent. I don't think we should accept such licenses as free just because they don't *succeed* in being non-free in all jurisdictions. Notice that we already accepted a CDDLed program in debian, namely the star packages which comes with this clause : 9. MISCELLANEOUS. This License represents the complete agreement concerning subject matter hereof. If any provision of this License is held to be unenforceable, such provision shall be reformed only to the extent necessary to make it enforceable. This License shall be governed by the law of the jurisdiction specified in a notice contained within the Original Software (except to the extent applicable law, if any, provides otherwise), excluding such jurisdiction's conflict-of-law provisions. Any litigation relating to this License shall be subject to the jurisdiction of the courts located in the jurisdiction and venue specified in a notice contained within the Original Software, with the losing party responsible for costs, including, without limitation, court costs and reasonable attorneys' fees and expenses. The application of the United Nations Convention on Contracts for the International Sale of Goods is expressly excluded. Any law or regulation which provides that the language of a contract shall be construed against the drafter shall not apply to this License. You agree that You alone are responsible for compliance with the United States export administration regulations (and the export control laws and regulation of any other countries) when You use, distribute or otherwise make available any Covered Software. So, i wonder why it was accepted, if it was non-free. But maybe we just passed it up silently and didn't notice ? Who was the ftp-master responsible for letting this one enter the archive, and can he comment on this ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Thu, Sep 08, 2005 at 03:10:56PM +0200, Joerg Jaspert wrote: Sven Luther schrieb: Notice that we already accepted a CDDLed program in debian, namely the star packages which comes with this clause : Wrong. Well, i installed the package in sid (star 1.5a60-2), and looked at /usr/share/doc/star/copyright and it was indeed the CDDL version 1. So, i wonder why it was accepted, if it was non-free. But maybe we just passed it up silently and didn't notice ? Who was the ftp-master responsible for letting this one enter the archive, and can he comment on this ? Please look up facts before you go this road. Yeah, well, i did an apt-get install star and looked at the copyright file, so i am not sure what facts i have to believe then. http://packages.debian.org/changelogs/pool/main/s/star/star_1.4a17-3/star.copyright Took about ten seconds to find out it was GPL before upstream relicensed and debian maint just copied that. Ah, ok, nice to know. For your info, the upstream author claims that Debian has accepted the CDDL as free, because the CDDLed star package has been accepted in debian. So i wondered if that was a real thing, or if the licence change just slipped in without anyone noticing, which may indeed be the case. Write a bug against the package if its non-free is your option now. Well, i want first to know if we indeed consider the CDDL and its choice-of-venue clause non-free, or not. And this is as good as any a place to start this discussion, so i will attaach the full licence file here. Friendly, Sven Luther This package was debianized by Pawel Wiecek [EMAIL PROTECTED] on Tue, 29 Jan 2002 12:10:43 +0100. It was downloaded from ftp://ftp.berlios.de/pub/star/ Project's webpage: http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/star.html Upstream Author: Joerg Schilling [EMAIL PROTECTED] Copyright: COMMON DEVELOPMENT AND DISTRIBUTION LICENSE Version 1.0 1. Definitions. 1.1. Contributor means each individual or entity that creates or contributes to the creation of Modifications. 1.2. Contributor Version means the combination of the Original Software, prior Modifications used by a Contributor (if any), and the Modifications made by that particular Contributor. 1.3. Covered Software means (a) the Original Software, or (b) Modifications, or (c) the combination of files containing Original Software with files containing Modifications, in each case including portions thereof. 1.4. Executable means the Covered Software in any form other than Source Code. 1.5. Initial Developer means the individual or entity that first makes Original Software available under this License. 1.6. Larger Work means a work which combines Covered Software or portions thereof with code not governed by the terms of this License. 1.7. License means this document. 1.8. Licensable means having the right to grant, to the maximum extent possible, whether at the time of the initial grant or subsequently acquired, any and all of the rights conveyed herein. 1.9. Modifications means the Source Code and Executable form of any of the following: A. Any file that results from an addition to, deletion from or modification of the contents of a file containing Original Software or previous Modifications; B. Any new file that contains any part of the Original Software or previous Modifications; or C. Any new file that is contributed or otherwise made available under the terms of this License. 1.10. Original Software means the Source Code and Executable form of computer software code that is originally released under this License. 1.11. Patent Claims means any patent claim(s), now owned or hereafter acquired, including without limitation, method, process, and apparatus claims, in any patent Licensable by grantor. 1.12. Source Code means (a) the common form of computer software code in which modifications are made and (b) associated documentation included in or with such code. 1.13. You (or Your) means an individual or a legal entity exercising rights under, and complying with all of the terms of, this License. For legal entities, You includes any entity which controls, is controlled by, or is under common control with You. For purposes of this definition, control means (a) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (b) ownership of more than fifty percent (50%) of the outstanding shares or beneficial ownership of such entity. 2. License Grants. 2.1. The Initial Developer Grant
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Thu, Sep 08, 2005 at 03:55:56PM +0200, Dalibor Topic wrote: Sven Luther wrote: Notice that we already accepted a CDDLed program in debian, namely the star packages which comes with this clause : 9. MISCELLANEOUS. [snip] The application of the United Nations Convention on Contracts for the International Sale of Goods is expressly excluded. [snip] That's my favourite bit of lawyerese in MPL-derivative licenses. I wish they had expressly excluded the sharia law on software licenses as practised by the late Taleban ruling Kandahar. So, is this non-free or not ? So, i wonder why it was accepted, if it was non-free. But maybe we just passed it up silently and didn't notice ? Who was the ftp-master responsible for letting this one enter the archive, and can he comment on this ? I guess it was a mistake. So, we need either to get back the old star version, or somehow kick the whole thing out of debian and into non-free ... star used to be under the GPL, and then Joerg Schilling changed the license to CDDL. The respective change was at http://packages.qa.debian.org/s/star/news/4.html and the license change did not seem to have been discussed on debian-legal. The discussions on CDDL in 2005-01 seem to have petered out inconclusively. ... but before taking such actions, we should probably decide on the CDDL. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Thu, Sep 08, 2005 at 04:53:12PM +0300, George Danchev wrote: On Thursday 08 September 2005 16:21, Sven Luther wrote: --cut-- Yeah, well, i did an apt-get install star and looked at the copyright file, so i am not sure what facts i have to believe then. http://packages.debian.org/changelogs/pool/main/s/star/star_1.4a17-3/star .copyright Took about ten seconds to find out it was GPL before upstream relicensed and debian maint just copied that. Ah, ok, nice to know. Note that the latest upstream development version is star-1.5a67.tar.gz [1] and is CDDL licensed with the following slight modifications: diff -Naur CDDL.Sun.txt CDDL.Schily.txt --- CDDL.Sun.txt2005-02-09 07:36:33.0 +0200 +++ CDDL.Schily.txt 2005-02-10 01:41:21.0 +0200 @@ -368,10 +368,9 @@ DISTRIBUTION LICENSE (CDDL) For Covered Software in this distribution, this License shall -be governed by the laws of the State of California (excluding -conflict-of-law provisions). +be governed by the laws of Germany (excluding conflict-of-law +provisions). Any litigation relating to this License shall be subject to the -jurisdiction of the Federal Courts of the Northern District of -California and the state courts of the State of California, with -venue lying in Santa Clara County, California. +jurisdiction and the courts of Berlin Germany, with venue lying +in Berlin Germany. [1] http://sourcewell.berlios.de/appbyid.php?id=1036 Yeah, this is the CDDL with the modular choice-of-venue and choice-of-law. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Thu, Sep 08, 2005 at 06:24:34PM +0100, Andrew Suffield wrote: On Thu, Sep 08, 2005 at 04:53:12PM +0300, George Danchev wrote: On Thursday 08 September 2005 16:21, Sven Luther wrote: --cut-- Yeah, well, i did an apt-get install star and looked at the copyright file, so i am not sure what facts i have to believe then. http://packages.debian.org/changelogs/pool/main/s/star/star_1.4a17-3/star .copyright Took about ten seconds to find out it was GPL before upstream relicensed and debian maint just copied that. Ah, ok, nice to know. Note that the latest upstream development version is star-1.5a67.tar.gz [1] and is CDDL licensed with the following slight modifications: Which constitutes a trademark violation at the very least (it's not the CDDL any more) and quite probably a copyright one (the CDDL isn't modifiable). Since the star upstream author is deeply involved with sun and the whole opensolaris guys, and he told me on the opensolaris list that he did ask for a modular choice-of-venue thingy and that none of the opensolaris guys from sun told him differently, i clearly doubt there is any such problem :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Thu, Sep 08, 2005 at 08:57:59PM +0300, George Danchev wrote: On Thursday 08 September 2005 20:24, Andrew Suffield wrote: On Thu, Sep 08, 2005 at 04:53:12PM +0300, George Danchev wrote: On Thursday 08 September 2005 16:21, Sven Luther wrote: --cut-- Yeah, well, i did an apt-get install star and looked at the copyright file, so i am not sure what facts i have to believe then. http://packages.debian.org/changelogs/pool/main/s/star/star_1.4a17-3/ star .copyright Took about ten seconds to find out it was GPL before upstream relicensed and debian maint just copied that. Ah, ok, nice to know. Note that the latest upstream development version is star-1.5a67.tar.gz [1] and is CDDL licensed with the following slight modifications: Which constitutes a trademark violation at the very least (it's not the CDDL any more) and quite probably a copyright one (the CDDL isn't modifiable). Interestingly enough he has already been told that he violates the CDDL itself [1]. Also a good dispute starts here (as mentioned by someone above) [2] and what I was surprised was the vigorous pushing of star and cddl into the obsd tree. Yes, altough he told me that : 1) Debian has accepted the CDDL as DFSG free, and as proof the star package is in. 2) Any argument i may have are only the lame repetition of the opinion of a single person here on debian-legal. So there are at least two kind of problems with cddl: *modifications in a weird way - which doesn't fit into the spirit of BSD *choice-of-venue and choice-of-law - floating sandy layers which could be dangerous for anyone on the Earth IMHO. [1] http://archives.neohapsis.com/archives/openbsd/2005-02/0407.html [2] http://archives.neohapsis.com/archives/openbsd/2005-02/thread.html#399 I feel that the author will convert sooner or later smake and cdrecord to cddl as a part of his anti-GPL campaign. Oh, he is the cdrecord guy. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CDDL, OpenSolaris, Choice-of-venue and the star package ...
On Thu, Sep 08, 2005 at 08:21:57PM +0200, Marco d'Itri wrote: On Sep 08, Sven Luther [EMAIL PROTECTED] wrote: 2) Any argument i may have are only the lame repetition of the opinion of a single person here on debian-legal. Indeed, the choice of venue is a fee argument is just that: an opinion which has at best no clear roots in the DFSG, therefore it cannot make a license non-free. Yeah, but there is certainly more than a single person arguing that we should not distribute software with such licence. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: [osol-discuss] Debian with OpenSolaris: a broken dream]
On Tue, Jul 26, 2005 at 06:33:17PM +0200, Florian Weimer wrote: * Alvaro Lopez Ortega: Florian Weimer wrote: Some days ago I asked about the viability the idea of creating a new architecture of Debian using the OpenSolaris stack. Just the kernel or libc as well? That is something in which we will have to think if there isn't any issue with the license. By the moment there isn't a detailed technical plan over the desk, it is just a proposal. The first step is to check if the CDDL meets with the DFSG. Ah, okay. A CDDLed libc is impossible for Debian because you can't distribute GPLed software that links to it. The operating system exception deliberately does not apply when you are distributing an operating system. A new data point on this, i belive it will be an effort concerning only the OpenSolaris kernel, with glibc and usual debian userland, exactly how the *BSD kernels with glibc is handled. This means that the only thing to consider is the freeness or lack thereof of the CDDL, and comatibility with the (L)GPL is not problematic for this. As i understand from previous posts here, the main problem was concerning the choice-of-venue clause, not sure if the other concerns of the start of the year did indeed change or not, as there where various variations of the licence. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: STIX fonts for free mathematics - comments needed on draft license
On Tue, Sep 06, 2005 at 02:17:54PM -0400, Steven G. Johnson wrote: Dear Debian folks, I noticed something where your input may be important. As you may know, there is a major effort by a consortium of scientific publishers and organizations, called STIX, to produce a comprehensive royalty-free font for mathematical typesetting (with almost 8000 glyphs): http://www.stixfonts.org/ These fonts are needed, for example, to fully support MathML in Mozilla (http://www.mozilla.org/projects/mathml/fonts/), which cannot currently bundle math fonts. (See also bug #146605). STIX is now almost complete, with the remaining 472 glyphs scheduled to be done by October 2005, and they have recently released a draft user license for comments: http://www.stixfonts.org/user_license.html Unfortunately, the license does not quite meet the free-software, open-source, or DFSG criteria. It allows you to add glyphs to the font, as long as you release the new font under a different name, but you cannot modify the existing glyphs (even if you rename the font). They are soliciting comments on the license (see above link), and I think it would be good for the FLOSS community to get involved (politely). The intentions of the STIX people seem good, and I'm hopeful that they can be persuaded that such license restrictions do more harm than good. See : http://lists.debian.org/debian-legal/2005/08/msg00270.html One week ago. I think the conclusion was that it is non free because there are a set of unmodifiable fonts. Not sure if the above thread was forwarded back to them though, or just debate in the empty. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian OpenSolaris port, exchange with Sun folks in webforum/MailingList
On Mon, Sep 05, 2005 at 08:59:10PM +0200, Andreas Schuldei wrote: I just chatted with Sun's FOSS embassador Simon Phillips and i asked if Sun would switch to a LGPL compatible license even for openSolaris in the course of the recent announcement. However he said it would stay with the CDDL and was not aware how that would hinder a debian port of openSolaris. Could the people who are interested in working on this please head over to http://www.opensolaris.org/os/discussions/ and more specifically to http://www.opensolaris.org/jive/forum.jspa?forumID=32 for the GNU-Solaris discussion to work on a way to resolve the issues (or clarify the problems, first)? Aparently there is even a mailling list interface to those formums. Feel free to figure it out yourself and mail here once you found out. (c: The Sun folks understand full well the power of a debian port of openSolaris and the lift they would get from it. (c: Did you per chance mean this one : http://www.opensolaris.org/jive/thread.jspa?threadID=1093tstart=30 Where there is some mention about the CDDL ? I don't see so much of a problem with the one you quoted about the mc, but then i may be missing something. What is the legal CDDL status anyway ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please check draft font license for StixFonts - is it suitably free?
On Wed, Aug 31, 2005 at 10:37:17PM +0200, Florian Weimer wrote: * Simos Xenitellis: The StixFonts project started 10 years ago by several publishing houses of academic journals, with the aim to create fonts for mathmetical publications. These fonts, StixFonts, are nearing completion and at this point a draft user license has been made available at http://www.stixfonts.org/user_license.html | The Font Software may not be modified or altered in any way, except | that: (a) the Fonts may be converted from one format to another | (e.g., from TrueType to Postscript), in which case the normal and | reasonable distortion that occurs during such conversion shall be | permitted; and (b) additional glyphs or characters may be added to | the Fonts, so long as the base set of glyphs is not modified or | removed. Clearly non-free. I can understand why people think that such a clause is a technical necessity (reproducible layout), but it still violates DFSG clause 3. What about a clause mandating that the layout size or whatever it is called, remains the same for existing fonts ? But i think the easiest way out here is to allow modifications of fonts, but forcing name change if there is modification of existing glyphs. BTW, i wonder why the vera bitstream licence could not be used as is by this project, in order to avoid yet another licence, and probably cut down lawyer fees. (That said, if you are discussing with the lawyer ...) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#321669: enigma: Copyright violation for menu.s3m
On Sun, Aug 28, 2005 at 09:09:33PM +0200, Erich Schubert wrote: Hi, Erich, applying the GPL to a documentation is ok, but don't you think you are pushing things a bit hard by applying it to a music file too ? It doesn't need to be GPL, but it needs to be DFSG-free. Well, i was just surprised that you listed the second alternative as asking the author to GPL it, instead of asking for a fre elicence, but i believe that in this case, any licence that allows distribution of the music track should be ok, not sure though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#321669: enigma: Copyright violation for menu.s3m
On Mon, Aug 29, 2005 at 01:38:29PM +0200, Erich Schubert wrote: Hi, Well, i was just surprised that you listed the second alternative as asking the author to GPL it, instead of asking for a fre elicence, but i believe that in this case, any licence that allows distribution of the music track should be ok, not sure though. Not by the post-sarge requirements AFAICT. Until then I think we allowed files you cannot modify (although mostly due to technical reasons, i.e. firmware) We spoke about documentation, firmware, and other such stuff which you have a reasonable reason to modify, but music for a game ? You are free to take the music and replace it with another, i suppose. We have a licence which allows free distribution along with enigma. This is not debian-specific - so it's fine for re-distributors like ubuntu - but still not DFSG-free. So, what is it you want ? Full redistribution right outside of enigma as well ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#321669: enigma: Copyright violation for menu.s3m
On Sun, Aug 28, 2005 at 02:48:27PM +0200, Erich Schubert wrote: Hi, I'm going to upload a new enigma package soon, since enigma in unstable is uninstallable now (depending on the old libzipios package, g++ transition to 4.0) I'd like to resolve this issue with the same upload - what do you suggest? I'm cc'ing debian-legal, too. Short version of the situation for debian-legal: Enigma contains a music file - menu title song - which I'd consider non-free with respect to Debian DFSG rules. Enigma was given the permission to distribute that song in an informal email. The author of the song is credited in the manual as Andrew Sega Menu music (Pentagonal Dreams) I basically see three solutions: - make an enigma 0.92.1 upload, removing the s3m file (eventually making a non-free enigma-music package, but I'm too lazy) - ask the author of the song if he'd GPL-licence it - move enigma as-is to non-free Erich, applying the GPL to a documentation is ok, but don't you think you are pushing things a bit hard by applying it to a music file too ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rules for submitting licenses for review
On Mon, Aug 22, 2005 at 10:48:13AM +, MJ Ray wrote: I was hoping to review the Open Game License[1]. Although not a software license, it has been used in the popular PCGen software application which could, hypothetically, be added to Debian at some point. [1] http://www.opengamingfoundation.org/ogl.html I think there's a small risk in the COPYRIGHT NOTICE wording if someone adds adverts in it and there's a half-implementation of trademark law in it, but I'm not sure it's enough to block a work under that licence. I don't understand why it needed a new licence for this. Because they where trying to ride the open source is cool wave with their gaming stuff, and people have been bothering them for ages about stuff like pcgen and others. They don't really come from the software community though, so probably didn't even consider the free software licences. Probably pushed for creation of NWN content and such also. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CECILL license status?
On Mon, Aug 15, 2005 at 05:32:37PM +0200, Achim Bohnet wrote: Hi, news about CECILL's DSFG status? As far as i understood, CECILL can be transformed into the GPL, so it is DFSG free by default. This seemed to be the concensus about this here last time it was discussed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: broadcom proposed firmware licence, please comment ...
On Tue, May 31, 2005 at 11:24:12AM -0400, Andres Salomon wrote: On Sun, 29 May 2005 05:48:55 -0400, Nathanael Nerode wrote: [...] Great! This license is totally distributable. I'm not sure, unfortunately, what counts as equivalent to hexadecimal. I think that's the only problem. If it was just permission to distribute, unmodified, in any form, it would be clear. Before you move the whole driver to non-free, you should know that I have made a version of the driver which loads the firmware from files if it is available (many tg3 users don't *need* the firmware), and I believe that is the one currently in Debian's kernel tree. I have also designed a package containing appropriate firmware files for this version of the driver. The only reason I have not published the package yet is that it was under this legal cloud. As I remember, upstream (jgarzik/davem) was not overly interested in such a patch to tg3. Is this still the case, or are they amenable to such changes? I'd rather not maintain a tg3 patch again, if possible. In the LKML thread they complained that nobody actually provided code, and that we where just brassing wind or whatever they say. So if there is such a patch, it should be proposed, together with a patch that rectifies the firmware licence, and they will hardly be able to reject it, or at least provide technical reasons why they do, which we can then fix. We need to provide a reply to broadcom soon too, preferably this week. I am overbusy this week though :/ Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: broadcom proposed firmware licence, please comment ...
On Wed, May 25, 2005 at 08:53:44PM -0700, Don Armstrong wrote: On Wed, 25 May 2005, Sven Luther wrote: + * Permission is hereby granted for the distribution of this firmware data + * in hexadecimal or equivalent format, provided this copyright notice is + * accompanying it. Just a minor question here: Would we actually be distributing the hexadecimal format, or would we be distributing the packed binary[1] representation of the hexadecimal format? I guess that if there is a 1-1 mapping between the two representations, then it falls under the equivalent format thingy. While it's probably ok the way it is written, if they're going to go through the trouble of drafting a change, they should make it clear that it's also ok to distribute the firmware data in the packed binary form, assuming that's actually what will be distributed. What good is this packed binary for ? Also, the way we are going to distribute it apart from under hexadecimal format, is by distributing the compiled binary driver, which is not clear in the above maybe ? I feel that it could be better, apart from the proposed clarification in the other subthread, to ask them to allow : 1) distribution of the firmware data in hexadecimal or equivalent format, provided the copyright notice accompanies it. 2) distribution as part of a binary module, without necessarily any copyright notice attached, which would be a pain. Since the GPL gives access to the source of the driver when the binary module is available, it also gives access by transition to the copyright notice in question under 1). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
broadcom proposed firmware licence, please comment ...
Hello all, It seems our crusade to solve the dubious licencing of firmware inside the linux kernel source is starting to show is fruits. After the QLogic feedback Andres Salomon reported in a previous mail, it is now Broadcom which is coming back to us with a licence proposal. Keep in mind that this was done under the assumption that a firmware embedded in the main kernel is an aggregate work (see mailing list archive for details, or discuss in a separate thread, CCing me if possible). This means that altough the firmware in itself remains non-free as far as the DFSG is concerned, it at least makes the whole file distributible again, which it was not while the firmware was distributed source-less under the GPL. The text of the new licence proposal is as follows : +/* xxx.h: Broadcom tg3 network driver. + * + * Copyright (c) 2004, 2005 Broadcom Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, except as noted below. + * + * This file contains firmware data derived from proprietary unpublished + * source code, Copyright (c) 2004, 2005 Broadcom Corporation. + * + * Permission is hereby granted for the distribution of this firmware data + * in hexadecimal or equivalent format, provided this copyright notice is + * accompanying it. + */ I would have liked a clear identification of the firmware blob, but i guess that to anyone familiar with C, it is immediately evident what is the firmware blob and what is normal code. So, before i reply to them, i would like to have feedback from debian-legal, and we can then move ahead and upload this driver to the non-free part of our archive, including a working .udeb. Thanks in advance, Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 09:06:58PM -0600, Eric W. Biederman wrote: Sven Luther [EMAIL PROTECTED] writes: It sounds like you are now looking at the question of are the huge string of hex characters the preferred form for making modifications to firmware. Personally I would be surprised but those hunks are small enough it could have been written in machine code. Yep, i also think it is in broadcom's best interest to modify the licencing text accordyingly, since i suppose someone could technicaly come after them legally to obtain said source code to this firmware. Unprobable though. Possibly. It sounds like that is what you want to do. No, i am making them aware of the possibility, and hoping they fix the issue, but we will see. If they fail to act on this, i don't understand why though, since it is just addition of a clarification. It is not as if i am asking for the release of all their chip specs or something such. since there should be at least some kind of executable code in it, independenlty of the fact that we claim that data is also software. Do you have any evidence that ``software'' was not written directly in machine code? Software is written directly in machine code when a programmer So what, i seriously doubt they where written using an vi in C, as the code currently stands, so we do need an additional level of source code, being it only some asm code or something. looks at the instruction set and writes down the binary representation of the instructions. I know ISC dhcpd has packet filter code that was written in that manner, so it is not a lost art. And it is done often enough when an assembler will not cooperate, and generate the correct instruction. But again, this is not the common assumption, so if this is so, they should write it down black on white in the copyright notice, and everyone would be happy. Without evidence that we don't have the preferred form of the software for making modifications I don't see how you can complain. No, it goes the other way around. Without evidence that all is clean, we have no right to distribute that code, and if what you describe was the case, a couple of lines telling us that fact would solve the issue, and not even need the involvement of their legal department. I would be somewhat suspisious though if all these guys came up and said they just wrote said firmware in binary directly though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free but distributable packages and kernel firmware
On Fri, Apr 08, 2005 at 03:57:26AM +0100, Henning Makholm wrote: Scripsit Michael Poole [EMAIL PROTECTED] This has the strong smell of ranking some DFSG criteria above others in importance. If you want this kind of distinction, I think a less discriminatory way would be to flag (internally or on a central web site somewhere) each package in non-free according to which parts of DFSG it fails. I think it would be more manageable to flag freedoms that the package still does provide, for example modified-noncommercial-redistribution unmodified-noncommercial-redistribution unmodified-commercial-redistribution all-freedoms-in-the-gfdl dfsg-freedom-of-all-runnable-programs dfsg-freedom-of-all-main-cpu-runnable-programs Euh, what are those two last ones ? or preferrably some shorter names :-) Yes. We should declare such a field, and provide a description of those flags, and then we can go and examine all of those packages in non-free and submit patches to the maintainer to include this line or NMU them. As aj said there is no in-principle opposition to this, anyone can do this job, i believe, but it is best to clarify the terms used first. That is, list reasons why somebody might want to *accept* the package on his machine (or his redistribution) rather than list reasons why somebody might wanto to *exclude* it. That way an overlooked tag would lead to failure on the side of caution, and new tags could be added to the system without retroactively reclassifying all packages in non-free. Seems cool. CCing to debian-legal in order to obtain advice on the different terms and classification. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 11:55:44PM -0400, Raul Miller wrote: Also, mere aggregation is a term from the GPL. You can read what it says there yourself. But basically it's there so that people make a distinction between the program itself and other stuff that isn't the program. On Thu, Apr 07, 2005 at 04:20:50PM -0700, David Schwartz wrote: It's also there because the GPL can only apply to either works placed under it by their authors and works that are legally classified as derivative. If you merely aggregate two works, there is no derivation. The GPL is making clear that it's not trying to exceed the scope of its authority (which is copyright law). The issue of whether or not the combined work is a derivative under copyright law is a copyright law issue. The GPL does concern itself with that issue, but not in the mere aggregation clause. The mere aggregation clause holds regardless of whether or not the combined work is a derivative under copyright law. [P.S. I've set the Reply-To: header on this message because I think this thread has drifted away from kernel issues.] Thanks. BTW, have any of you read the analysis i made, where i claim, rooted in the GPL FAQ and with examples, why i believe that the firmware can be considerated a non derivative of the linux kernel. The main points is that the firmware is not aimed to run in the same address space, even not the same cpu, as the rest of the linux kernel, and that there is a clearly defined communication channel between the GPLed driver and the target processor running the firmware. I further argumented that taking any different stance would bring us worlds of hurt as we would consider the bios as being a derivative work of the kernel they are running, or the bootloader, or the firmware present in proms on devices loaded into the system and so on. I think only the fact that if you consider firmware as being a derivative work, you should consider it a derivative work also when it is flashed on the prom of a pci card or what not, is decisive enough to make those firmware blobs not derivative works of the kernel they are under. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 09:03:01AM -0400, Richard B. Johnson wrote: On Thu, 7 Apr 2005, Humberto Massa wrote: David Schmitt wrote: On Thursday 07 April 2005 09:25, Jes Sorensen wrote: [snip] I got it from Alteon under a written agreement stating I could distribute the image under the GPL. Since the firmware is simply data to Linux, hence keeping it under the GPL should be just fine. Then I would like to exercise my right under the GPL to aquire the source code for the firmware (and the required compilers, starting with genfw.c which is mentioned in acenic_firmware.h) since - as far as I know - firmware is coded today in VHDL, C or some assembler and the days of hexcoding are long gone. First, there is *NOT* any requirement in the GPL at all that requires making compilers available. Otherwise it would not be possible, for instance, have a Visual Basic GPL'd application. And yes, it is possible. Second, up until the present day I have personal experience with hardware producers that do not have enough money to buy expensive toolchains and used a lot of hand-work to code hardware parameters. So, at least for them, hand-hexcoding-days are still going. HTH, Massa Well it doesn't make any difference. If GPL has degenerated to where one can't upload microcode to a device as part of its initialization, without having the source that generated that microcode, we are in a lot of hurt. Intel isn't going to give their designs away. Last time I checked, GPL was about SOFTware, not FIRMware, and not MICROcode. If somebody has decided to rename FIRMware to SOFTware, then they need to complete the task and call it DORKware, named after themselves. There is only two things, Hardware, which is stuff you can touch, and software, which you can't and runs on it. Or can you really give any serious argumentation on why you would consider firmware or microcode as something else as software ? I doubt a judge would follow you on this, and in any case any computer language theorist will strongly disagree with this. Stuff like FGPAs are on the threshold though, but anything which is not physical hardware is software. Dropping LKML, i hope that this is ok to all concerned. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 09:15:07AM -0300, Humberto Massa wrote: This is where you are wrong IMMHO. All that is needed for you to distribute the hexdump blob under the GPL is a declaration from the copyright holder saying this, to me, is the preferred form for modification of the firmware and hence the source code under the GPL. I strongly disagree. This could be an open door to to anyone claiming that whatever binary is the prefered form of modification. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 03:10:43AM +0100, Henning Makholm wrote: Scripsit Humberto Massa [EMAIL PROTECTED] After a *lot* of discussion, it was deliberated on d-l that this is not that tricky at all, and that the mere aggregation clause applies to the combination, for various reasons, with a great degree of safety. When was this alleged conclusion reached? I remember nothing like that. http://lists.debian.org/debian-legal/2005/03/msg00273.html and : http://lists.debian.org/debian-legal/2005/03/msg00283.html and the following thread. These where linked from the original mail in this thread. No-one is saying that the linker merely aggregates object code for the driver; what *is* being said is: in the case of firmware, especially if the firmware is neither a derivative work on the kernel (see above) nor the firmware includes part of the kernel (duh), it is *fairly* *safe* to consider the intermixing of firmware bytes with kernel binary image bytes in an ELF object file as mere aggregation. No, it is completely wrong to say that the object file is merely an aggregation. The two components are being coupled much more tightly than in the situation that the GPL discribes as mere aggregation. So read the analysis and comment on it if you disagree, but let's take it to debian-legal alone, ok ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 12:50:14PM -0600, Chris Friesen wrote: Josselin Mouette wrote: The fact is also that mixing them with a GPLed software gives an result you can't redistribute - although it seems many people disagree with that assertion now. This is only true if the result is considered a derivative work of the gpl'd code. The GPL states In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. Since the main cpu does not actually run the binary firmware, the fact that it lives in main memory with the code that the cpu *does* run is irrelevent. In this case, the Debian stance is that the kernel proper and the binary firmware are merely aggregated in a volume of storage ( ie. system memory). The problem is that you can only argue it is mere agregation, if the copyright notice doesn't de-facto put said firmware blobs under the GPL, thus making them undistributable by the selfsame definition of the GPL. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote: On Tue, Apr 05, 2005 at 03:57:01PM +0200, Sven Luther wrote: ... The other point is that other entities, like redhat, or suse (which is now novel and thus ibm) and so have stronger backbones, and can more easily muster the ressources to fight of a legal case, even one which is a dubious one, especially given the particularities of the US judicial system, where it is less important to be right, and more important to have lot of money to throw at your legal machine. Debian has nothing such, and SPI which would stand for this, is not really upto it either, so in this case, apart from all ideology and fanatism, it is for purely pragmatic reasons that they don't distribute undistributable files from the non-free part of our archive. You would do the same in their case. ... There are many possible legal risks for a Linux distribution. This thread is about one. Another one is that RedHat removed MP3 support in their distribution from programs like xmms ages ago because of the legal risks due to patents. The Debian distribution still contains software that is capable of playing MP3's. I'd say of the two above cases, the MP3 patents are far more likely to cause a lawsuit. YMMV. Yes, possibly, especially in these troubled times. If your statement was true that Debian must take more care regarding legal risks than commercial distributions, can you explain why Debian exposes the legal risks of distributing software capable of decoding MP3's to all of it's mirrors? I don't know and don't really care. I don't maintain any mp3 player (err, actually i do, i package quark, but use it mostly to play .oggs, maybe i should think twice about this now that you made me aware of it), but in any case, i am part of the debian kernel maintainer team, and as such have a responsability to get those packages uploaded and past the screening of the ftp-masters. I believe the planned solution is vastly superior to the current one of simply removing said firmware blobs from the drivers, which caused more harm than helped, which is why we are set to clarifying this for the post-sarge kernels. That said, i was under the understanding that after the SCO disaster, clarification of licencing issues and copyright attributions was a welcome thing here, but maybe i misunderstood those whole issues. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wed, Apr 06, 2005 at 09:34:44AM +0200, Josselin Mouette wrote: Le mercredi 06 avril 2005 à 02:10 +0200, Sven Luther a écrit : It merely depends on the definition of aggregation. I'd say that two works that are only aggregated can be easily distinguished and separated. This is not the case for a binary kernel module, from which you cannot easily extract the firmware and code parts. Josselin, please read the thread i linked to in debian-legal, and as nobody really gave reason to oppose it, i believe we have consensus that those firmware blobs constitute mere agregation, provided they are clearly identified and properly licenced, which they are not always. The fact that nobody cared to answer you shouldn't be considered as any kind of approval for your sayings. There were a couple of replies, but if you are going to argue this, please read the analysis i made, and reply to it. Read in particular : http://lists.debian.org/debian-legal/2005/03/msg00288.html Which contains a more formal analysis from Humberto Massa. So, given that this thread together with the GPLed firmware flasher thread got a respectable amount of replies, i believe we can claim consensus, and this is something the debian-kernel team has been acting upon, and i believe even aknowledged by the release managers and ftp-masters. If you have strong evidence that this is not the case, it would really have been nice to comment on it before the kernel team (not only me which you may dislike for past dealings or whatever) waste effort on something which is wrong in the first place, and i commend you to participate in the above thread asap, voicing your concerns (or remain silent forever thereafter :). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 09:19:24AM +0100, Ian Campbell wrote: On Mon, 2005-04-04 at 23:19 +0200, Sven Luther wrote: I am only saying that the tg3.c and other file are under the GPL, and that the firmware included in it is *NOT* intented to be under the GPL, so why not say it explicitly ? I don't think anyone here has disagreed. What almost everyone has said however is so go and do it -- go do the research, contact the copyright holders directly and get the permission to make patches, then post them here. Ok. I have some doubts about doing the work, and it then being rejected and i did the work first, which is why i asked. It seemed a reasonable thing to ask, and my analysis of the problem was sound, so why didn't i get a, yeah, go ahead, instead of this rejection ? There is really no point in discussing it here, just get on and do it. As i said, some may know things about relationship, or lack thereof, with the copyright holder, i believe that the people who added those firmware blobs are all reading this here, and it is from them that i wanted feedback, but it failed to produce that effect. /me will investigate bk and how to get the information on who signed those changes off and commited them :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 10:30:47AM +0100, Ian Campbell wrote: On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote: On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote: I don't think you did get a rejection, a few people said that _they_ weren't going to do it, but if you want to then go ahead. I think people are just fed up of people bringing up the issue and then failing to do anything about it -- so prove them wrong ;-) Actually patches to add firmware loader support to tg3 got rejected. Which is think is very unfortunately as we set the highlevel goal to move drivers over to it. I didn't know that -- you are right that it is unfortunate. I thought Sven was talking (at least short term) about adding copyright statements/exemptions/something to the binary blobs where they are now. Yes, indeed, i am searching for a short-time clarification, but in the long term the separate firmware solution is indeed better, altough more work and more involved. That said, the work to identify the firmware blobs and clarify their copyright/licencing situation is common for both alternatives. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 11:36:58AM +0200, Arjan van de Ven wrote: Second step is to make the built-in firmware a config option and then later on when the infrastructure matures for firmware loading/providing firmware it can be removed from the driver entirely. I think the infrasturcture is quite mature. We have a lot of drivers that require it to function. what seems to be currently missing is distro level support for using firmware for modules needed for booting (and tg3 falls sort of under that via nfsroot) and widespread easy availability of firmware in distros and for users. Well, apart from the installation case, simply using such kernel is easy enough, if you use an initrd. The mkinitrd script only has to be aware of this, and include the needed firmware in the initrd, as it does for the modules. Initial installation will have to either have the possibility to build custom initrds with the firmware blobs in it, or a way to easily get those firmware blobs (from CD, floppy, net, ...), or have support for a second initrd which would contain the firmware. I don't believe there is already support for a second ramdisk in todays kernel. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 09:03:21AM -0300, Humberto Massa wrote: Theodore Ts'o wrote: You know, the fact that Red Hat, SuSE, Ubuntu, and pretty much all other commercial distributions have not been worried about getting sued for this alleged GPL'ed violation makes it a lot harder for me (and others, I'm sure) take Debian's concerns seriously. I said in other e-mail, and I will repeat: it's not their (Debian's) fault. Their responsibility is greater. Why? Because when RedHat puts something it shouldn't in their distro it's *their* assets that will answer for some copyright violation damages. In Debian's case, it's the assets of: some DDs, the mirror network, derived-distro distributors, CD vendors, etc... This is just a case of Debian being fiscally responsible, i.e., not treating other people's money as trash. This is where you are wrong, and i believe this is caused because you don't understand how debian works on this. The ftp-master are the ones reviewing the licencing problems, and they are the ones handling the infrastructure, and putting their responsability on the stake. If they feel that some piece of software has dubious legal issues which come at a risk of having them personally come on the receiving end of a legal case, then they will say, no, we don't distribute this software, and that is the end of it. The other point is that other entities, like redhat, or suse (which is now novel and thus ibm) and so have stronger backbones, and can more easily muster the ressources to fight of a legal case, even one which is a dubious one, especially given the particularities of the US judicial system, where it is less important to be right, and more important to have lot of money to throw at your legal machine. Debian has nothing such, and SPI which would stand for this, is not really upto it either, so in this case, apart from all ideology and fanatism, it is for purely pragmatic reasons that they don't distribute undistributable files from the non-free part of our archive. You would do the same in their case. Also, you have to ask yourself what the above mentioned companies where to do if they where to be made aware of the issue, and ask their lawyers to attend this. Also you have to consider the case of some of those companies ending in the arms of a legally predative company and pulling another SCO at us. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 08:16:48AM -0400, Jeff Garzik wrote: Humberto Massa wrote: But, the question made here was a subtler one and you are all biting around the bush: there *are* some misrepresentations of licenses to the firmware blobs in the kernel (-- ok, *if* you consider that hex dumps are not source code). What Sven asked was: Hey, can I state explicitly the distribution state in the source files, by means of adding some comments?. I think even a clarification this firmware hexdump is considered to be the source code, and it's GPL'd would do, but I must put my asbestos suit everytime I say it. :-) We do not add comments to the kernel source code which simply state the obvious. The only thing here is that it has to be obvious not only to you, but to the judge too :) In this case, it is not comments, but proper copyright attribution, which was added in the tg3.c case since the first checkin : /* * tg3.c: Broadcom Tigon3 ethernet driver. * * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem@redhat.com) * Copyright (C) 2001, 2002, 2003 Jeff Garzik ([EMAIL PROTECTED]) * Copyright (C) 2004 Sun Microsystems Inc. * * Firmware is: * Copyright (C) 2000-2003 Broadcom Corporation. */ The firmware part was not present in the original checkin you did in 2002. Adding something about the licencing status of it would be enough. Or even adding some comment in the toplevel COPYING file saying that firmware blobs come under their own licence or something such, and then listing all the firmware blobs and their licencing condition in a separate toplevel file would be enough. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 08:56:09PM +0200, Josselin Mouette wrote: Le mardi 05 avril 2005 à 12:50 -0600, Chris Friesen a écrit : Josselin Mouette wrote: The fact is also that mixing them with a GPLed software gives an result you can't redistribute - although it seems many people disagree with that assertion now. This is only true if the result is considered a derivative work of the gpl'd code. The GPL states In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. Since the main cpu does not actually run the binary firmware, the fact that it lives in main memory with the code that the cpu *does* run is irrelevent. In this case, the Debian stance is that the kernel proper and the binary firmware are merely aggregated in a volume of storage ( ie. system memory). It merely depends on the definition of aggregation. I'd say that two works that are only aggregated can be easily distinguished and separated. This is not the case for a binary kernel module, from which you cannot easily extract the firmware and code parts. Josselin, please read the thread i linked to in debian-legal, and as nobody really gave reason to oppose it, i believe we have consensus that those firmware blobs constitute mere agregation, provided they are clearly identified and properly licenced, which they are not always. Let's take this to debian-legal only if you want to further discuss it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
non-free firmware in kernel modules, aggregation and unclear copyright notice.
Hello, quick sumary Current linux kernel source hold undistributable non-free firmware blobs, and to consider them as mere agregation, a clear licence statement from the copyright holders of said non-free firmware blobls is needed, read below for details. /quick sumary Please keep everyone in the CC, as not everyone reads debian-legal or LKML. Some kernel modules present in the kernel sources as distributed from ftp.kernel.org present some non-free binary only firmware that gets uploaded in the target chip by the controler. tg3, qla2xxx, acenix and a couple of others are example of such modules with non-free firmware blobs. This is no major problem per see, since, as discussed in this thread : http://lists.debian.org/debian-legal/2005/03/msg00283.html It is obvious in this context that the non-free firmware constitute a mere aggregation and not an act of linking with the rest of the kernel. This is at least the consensus that debian has reached with input from the debian-legal lists, and what we will stand by this. Naturally even if debian has come to the conclusion that these non-free firmware blobs are not a violation of the rest of the kernel GPL licence, it still doesn't make these non-free firmware blobs free software, and thus they and the drivers which contain it will be removed from debian/main, and put into the non-free section of our archive. Now, these non-free firmware are distributed in the same file as the rest of the module which uses it. This is still ok since it constitute agregation on a same distribution media, where the distribution media is the file in this case. But these files, as seen in the tg3.c case, have no special mention of the firmware in the file header, nor are they distinguished in any way from the rest of the content of that file, which places them de facto under the GPL, since. Accordying to the GPL, we thus needs the source files for this non-free firmware, which is not available, and thus makes the files undistributable. Even if we would consider these firmware as separate and not covered by the de-facto GPLing of the files in question, we still would have no licence allowing us to distribute those non-free firmware blobs, and thus we have again no right to distribute them as part of the kernel. The clean solution is to have a small notice in the header of those files or in the toplevel COPYING file, excluding those firmware blobs from the general GPLing of the files, and have a small comment inside the files to identify the firmware blobs as such and again excluding them from the GPL, and possibly a toplevel listing of all the files wich have such problems. This is an easy fix, and i believe even those who held the above analysis as non-sense or whatever will agree that this is something that should be done. The real problem being that nobody except the copyright holder of those firmware blobs is legally allowed to make said modification, and thus i bring this issue to everyone's attention, for comment and feedback, before trying to reach the copyright holders of those individual firmware blobs asking them to clarify the situation. I believe many of those read this list anyway, so would be able to fix the issue or comment on it without further proding needed. In hopes of quick resolution of these murky legalese issues nobody is really fond of, Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote: On Mon, Apr 04, 2005 at 04:16:47PM +0200, Sven Luther wrote: This is just the followup on said discussion, involving the larger LKML audience, in order to get this fixed for good. As said, it is just a mere technicality to get out of the muddy situation, all the people having contributed source-less firmware blobs, need to give us (us being debian, but also all the linux kernel community) either the source if they persist in distributing the code under the GPL, or a clear distribution licence for these firmware blobs, and clearly identificate them as not covered by the GPL that the file they come in is. What if we don't want to do so? You mean, you as copyright holder are not willing to mark the firmware blobs as not covered by the GPL, then it is simple, the firmware blob in question is covered by the GPL, and since it lacks source, the whole lot is non-distributable, and any contributor to the linux kernel can sue ftp.kernel.org or whoever else is distributing the kernel code. I don't know if users are able to sue you under the GPL for failing to provide the source code though. Seriously, it is just a couple of lines of comments on top of the file, who in his right mind would object to fixing this issue ? I know I personally posted a solution for this _5_ years ago in debian-legal, and have yet to receive a patch... Well, maybe, but *I* was not there 5 years ago, indeed i believe i didn't even was remotely connected to the kernel folks inside debian back then, nor even heard of debian-legal, so i would much like to hear of your proposal, care to give me a hint about the name of the thread it was in or something ? Discussing legal issues is all cool and nice for those that appreciates such sport, but it doesn't really make sense if it is not applied to acts later on. Then let's see some acts. We (lkml) are not the ones with the percieved problem, or the ones discussing it. Well, it is currently a violation of the GPL to distribute those firmware blobs without clearly saying that they are not covered by the GPL. What is the harm that comes by doing that ? All the other dubious points have been set aside by the discussion on the thread you probably didn't read. Right now, the licencing information is only present in the toplevel COPYRIGHT file, which is mostly the GPL (excluding user programs :), and since things like tg3.c which contain such non-free firmware blobs don't say anything else about the copyright of them, they de-facto fall under the toplevel COPYRIGHT, including their firmware blobs which lack sources. All i am asking is that *the copyright holders* of said firmware blobs put a little comment on top of the files in question saying, all this driver is GPLed, except the firmware blobs, and we give redistribution rights to said firmware blobs. The mention of acts was for the folk at debian-legal who like speaking a lot in circle and not bring anything forward, which your mention of patches above confirms :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote: On Mon, Apr 04, 2005 at 04:16:47PM +0200, Sven Luther wrote: This is just the followup on said discussion, involving the larger LKML audience, in order to get this fixed for good. As said, it is just a mere technicality to get out of the muddy situation, all the people having contributed source-less firmware blobs, need to give us (us being debian, but also all the linux kernel community) either the source if they persist in distributing the code under the GPL, or a clear distribution licence for these firmware blobs, and clearly identificate them as not covered by the GPL that the file they come in is. What if we don't want to do so? I know I personally posted a solution for this _5_ years ago in debian-legal, and have yet to receive a patch... Mmm, probably that 2001 discussion about the keyspan firmware, right ? http://lists.debian.org/debian-legal/2001/04/msg00145.html Can you summarize the conclusion of the thread, or what you did get from it, please ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 08:12:48PM +0100, Ian Campbell wrote: On Mon, 2005-04-04 at 20:21 +0200, Sven Luther wrote: On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote: Then let's see some acts. We (lkml) are not the ones with the percieved problem, or the ones discussing it. [...] All i am asking is that *the copyright holders* of said firmware blobs put a little comment on top of the files in question saying, all this driver is GPLed, except the firmware blobs, and we give redistribution rights to said firmware blobs. I think what Greg may have meant[0] was that if it bothers you, then you should act by contacting the copyright holders privately yourself in each case that you come across and asking them if you may add a little comment etc, and then submit patches once you have their agreement. Yeah, that is step 3, i mailed LKML, because maybe you would have some useful coment, or some of you who wrote said code may have contacts or something with the copyright holders, or some other insight. I also didn't want this to cause a problem if i blundered in some tense relationship or whatever. For example, the tg3 driver says : * tg3.c: Broadcom Tigon3 ethernet driver. * * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem@redhat.com) * Copyright (C) 2001, 2002, 2003 Jeff Garzik ([EMAIL PROTECTED]) * Copyright (C) 2004 Sun Microsystems Inc. * * Firmware is: * Copyright (C) 2000-2003 Broadcom Corporation. There is no contact for either sun or broadcom, but i believe that Jeff or David may know where this firmware blob may (or not) come from. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote: On Apr 04, Greg KH [EMAIL PROTECTED] wrote: What if we don't want to do so? I know I personally posted a solution Then probably the extremists in Debian will manage to kill your driver, like they did with tg3 and others. Nope, they were simply moved to non-free, as it should. I believe the package is waiting for NEW processing, but i also believe that the dubious copyright assignement will not allow the ftp-masters to let it pass into the archive, since it *IS* a GPL violation, and thus i am doing this in order to solve that problem. This sucks, yes. Not really. Once the, post-sarge, transition is done, you just will have to load the non-free .udeb from the non-free d-i archive, or install the module package from non-free, and you won't even notice. Sarge kernels are messed beyond recognition in this anyway, but they are freezed so ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 09:58:30PM +0200, Adrian Bunk wrote: On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote: On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote: On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote: Mmm, probably that 2001 discussion about the keyspan firmware, right ? http://lists.debian.org/debian-legal/2001/04/msg00145.html Can you summarize the conclusion of the thread, or what you did get from it, please ? That people didn't like the inclusion of firmware, I posted how you can fix it by moving it outside of the kernel, and asked for patches. Yeah, that is a solution to it, and i also deplore that none has done the job to make it loadable from userland. For now, debian is satisfied by moving the whole modules involved to non-free, and this has already happened in part. Does this imply your installer will use these non-free modules? The installer already has provision for loading additional .udebs from floppy or net, not sure about other media, and we don't build yet non-free d-i images with those non-free modules builtin, but it could be arranged. This is post-sarge issues though, and we still have some time to solve them. If the driver for the controller your harddisk is behind is not used by the installer you could simply remove these modules instead of moving them to non-free. yeah, the problem is a whole bunch of people have tg3 network cards it seem :) Nope, i am aiming to clarify this issue with regard to the debian kernel, so that we may be clear with ourselves, and actually ship something which is not of dubious legal standing, and that we could get sued over for GPL violation. ... If it was a GPL violation, it wasn't enough to contact only the small subset of copyright holders that worked on this specific file since this file might be compiled statically into the GPL'ed kernel. That is not a problem, since even if the firmware is built into the same executable as the rest of the kernel code, it still constitutes only mere agregation, where the kernel is the distribution media, in the GPL sense. Please read the mail i linked too in the original mail for detailed argumentation of this. The only problem to it constituting mere agregation is that the firmware blob is not clearly identified as such in the tg3.c file (for example), and that there is no licencing condition allowing their distribution apart the GPL, which these firmware blobs where evidently not meant to be put under. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 03:55:55PM -0400, Jeff Garzik wrote: Matthew Wilcox wrote: On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote: Then let's see some acts. We (lkml) are not the ones with the percieved problem, or the ones discussing it. Actually, there are some legitimate problems with some of the files in the Linux source base. Last time this came up, the Acenic firmware was mentioned: http://lists.debian.org/debian-legal/2004/12/msg00078.html Seems to me that situation is still not resolved. And it looks like no one cares enough to make the effort to resolve this... I would love an open source acenic firmware. Yep, but in the meantime, let's clearly mark said firmware as not-covered-by-the-GPL. In the acenic case it seems to be even easier, as the firmware is in a separate acenic_firmware.h file, and it just needs to have the proper licencing statement added, saying that it is not covered by the GPL, and then giving the information under what licence it is being distributed. Jeff, since your name was found in the tg3.c case, and you seem to care about this too, what is your take on this proposal ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 11:05:03PM +0200, Adrian Bunk wrote: On Mon, Apr 04, 2005 at 10:23:08PM +0200, Sven Luther wrote: On Mon, Apr 04, 2005 at 09:58:30PM +0200, Adrian Bunk wrote: On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote: On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote: On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote: Mmm, probably that 2001 discussion about the keyspan firmware, right ? http://lists.debian.org/debian-legal/2001/04/msg00145.html Can you summarize the conclusion of the thread, or what you did get from it, please ? That people didn't like the inclusion of firmware, I posted how you can fix it by moving it outside of the kernel, and asked for patches. Yeah, that is a solution to it, and i also deplore that none has done the job to make it loadable from userland. For now, debian is satisfied by moving the whole modules involved to non-free, and this has already happened in part. Does this imply your installer will use these non-free modules? The installer already has provision for loading additional .udebs from floppy or net, not sure about other media, and we don't build yet non-free d-i images with those non-free modules builtin, but it could be arranged. This is post-sarge issues though, and we still have some time to solve them. If the driver for the controller your harddisk is behind is not used by the installer you could simply remove these modules instead of moving them to non-free. yeah, the problem is a whole bunch of people have tg3 network cards it seem :) I was more thinking about SCSI controllers, but tg3 is also interesting. Additional non-free d-i images will for sure be required, or several hardware setups might make installation of Debian impossible without bootstrapping through a different OS or distribution. Well, you only need one free way to get access to external media, non-free d-i simply add a bunch of non-free .udebs to the initrd. Nope, i am aiming to clarify this issue with regard to the debian kernel, so that we may be clear with ourselves, and actually ship something which is not of dubious legal standing, and that we could get sued over for GPL violation. ... If it was a GPL violation, it wasn't enough to contact only the small subset of copyright holders that worked on this specific file since this file might be compiled statically into the GPL'ed kernel. That is not a problem, since even if the firmware is built into the same executable as the rest of the kernel code, it still constitutes only mere agregation, where the kernel is the distribution media, in the GPL sense. Please read the mail i linked too in the original mail for detailed argumentation of this. The only problem to it constituting mere agregation is that the firmware blob is not clearly identified as such in the tg3.c file (for example), and that there is no licencing condition allowing their distribution apart the GPL, which these firmware blobs where evidently not meant to be put under. This is one possible legal interpretation of mere aggregation. Whether judges in all jurisdictions of the world follow this interpretation or an interpretation of the GPL in one direction or another is the more interesting question. This is also hinted at by the FSF FAQ, and a verbatim interpretation of the actual GPL text. And you can proof by asburd that it has to be so, or you start facing no end of troubles :) The thread i linked, which is rather short, has some more legalese explanations (not by me :), if you are interested. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 04:55:27PM -0400, Theodore Ts'o wrote: On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote: Nope, i am aiming to clarify this issue with regard to the debian kernel, so that we may be clear with ourselves, and actually ship something which is not of dubious legal standing, and that we could get sued over for GPL violation. You know, the fact that Red Hat, SuSE, Ubuntu, and pretty much all other commercial distributions have not been worried about getting sued for this alleged GPL'ed violation makes it a lot harder for me (and others, I'm sure) take Debian's concerns seriously. They probably didn't care :) The problem may be that because Debian is purely a non-profit, and so it can't clearly balance the costs and benefits of trying trying to avoid every single possible risks where someone might decide to file a lawsuit. Anytime you do *anything* you risk the possibility of a lawsuit, and if you allow the laywers to take over your business decisions, the natural avoid-risks-all-costs bias of lawyers are such that it will either drive a company out of business, or drive a non-profit distribution into irrelevance. Yes, the problem is indeed that we don't have a legal department which can counter sue, and we are present in a much more widespread area than other companies you cited above. And ubuntu has those driver in their non-free equivalent also. If Debian wants to be this fanatical, then let those Debian developers who care do all of the work to make this happen, and stop bothering LKML. And if it continues to remain the case that a user will have to manually edit /etc/apt/sources.lists (using vi!) to include a reference to non-free in order to install Debian on a system that requires the tg3 device driver, then I will have to tell users who ask me that they would be better off using some other distribution which actually cares about their needs. I don't get this, and you threat me as fanatic. I am only saying that the tg3.c and other file are under the GPL, and that the firmware included in it is *NOT* intented to be under the GPL, so why not say it explicitly ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 04:47:36PM -0400, Jeff Garzik wrote: Sven Luther wrote: Yep, but in the meantime, let's clearly mark said firmware as not-covered-by-the-GPL. In the acenic case it seems to be even easier, as the firmware is in a separate acenic_firmware.h file, and it just needs to have the proper licencing statement added, saying that it is not covered by the GPL, and then giving the information under what licence it is being distributed. Who has meaningfully contacted Alteon (probably Neterion now) about this? What is the progress of that request? Nobody yet. I plan to do so as time allows though. But how do you respond about the firmware blobs being declared as GPL covered in the kernel ? Who put those firmware blobs there, and form where did they came ? Jeff, since your name was found in the tg3.c case, and you seem to care about this too, what is your take on this proposal ? Friendly, Bluntly, Debian is being a pain in the ass ;-) Thanks all the same, in this case, it is just me though, who want a clear solution to this, and you would too, i guess, especially as it is not much work to do it in the first place, so why is everyone making a problem of this ? There will always be non-free firmware to deal with, for key hardware. Sure, but then you don't claim they are covered by the GPL as is currently the case ? And i thought that the whole SCO affaire teached us to be more careful about this. It assuredly can't hurt to add a few lines of comments to tg3.c, and since it is probably (well, 1/3 chance here) you who added said firmware to the tg3.c file, i guess you are even well placed to at least exclude it from being GPLed. Is this not a reasonable request ? Which should get a reasonable answer, and not claims of being a pain in the ass, and other wild fanatical accusations ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 11:24:05PM +0200, Sven Luther wrote: It assuredly can't hurt to add a few lines of comments to tg3.c, and since it is probably (well, 1/3 chance here) you who added said firmware to the tg3.c file, i guess you are even well placed to at least exclude it from being GPLed. Is this not a reasonable request ? Which should get a reasonable answer, and not claims of being a pain in the ass, and other wild fanatical accusations ? Jeff, please ignore this last sentence, i should not have said it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH 00/04] Load keyspan firmware with hotplug
On Tue, Apr 05, 2005 at 12:23:29AM -0400, Jan Harkes wrote: On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote: On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote: Mmm, probably that 2001 discussion about the keyspan firmware, right ? http://lists.debian.org/debian-legal/2001/04/msg00145.html Can you summarize the conclusion of the thread, or what you did get from it, please ? That people didn't like the inclusion of firmware, I posted how you can fix it by moving it outside of the kernel, and asked for patches. None have come. Didn't know you were waiting for it. How about something like the following series of patches? [01/04] - add simple Intel IHEX format parser to the firmware loader. [02/04] - make the keyspan driver use request_firmware. [03/04] - converter program used to dump the keyspan headers as IHex files. [04/04] - result of running the previous program. This ofcourse doesn't actually solve Debian's distribution issues since the keyspan firmware can only be distributed as part of 'Linux or other Open Source operating system kernel'. Well, if this is the case, it can be distributed on the non-free archive. So I refuse to listen to talk about this, as obviously, no one cares enough about this to actually fix the issue. I got tired of always building my own kernels on Debian just to get my serial dongle to work since their included keyspan.ko driver is so useless that it isn't even worth having. The only way to use it with a Debian kernel is to have the dongle in a powered hub and first boot into Windows or a normal kernel.org kernel to get the thing initialized. The non-free driver package should solve that for you. Didn't send the patch earlier since I wanted to split off the pre-numeration part of the driver so that after intialization we can unload the unused parts of the driver as well as the the firmware class module. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question regarding QPLed plugins for a GPLed app
On Tue, Mar 22, 2005 at 11:02:41PM +, Anthony W. Youngman wrote: In message [EMAIL PROTECTED], Sven Luther I know, i argued the same thing, but it seems in legalese land there is only a fine step between distributing linked files and distributing files with the sole express purpose of linking. It may be a fine step, but I would have thought it was a very clear line... The distinction between me doing something that I have no right to do, and me doing something which permits someone else to do something they have every right to do, is to me (and, I presume, any judge) extremely clear. Well, there is the intention. If my plug-in does not contain any copyrightable portion of the main program, then I can distribute it. The fact that it can only be of any use in conjunction with a GPL program isn't my problem :-) As said, you may say that, but a judge will maybe have a different view. So, what you're saying, is that I can be guilty of copyright theft even if I haven't copied anything at all? Well, it depends on if you are the sole author or not. If you are the sole author you are better of putting an explicit exception to the GPL for your plugins. If I haven't copied anything, how on earth can there be any other author! Yep, but for how long ? Just use the explicit excepmption, and everyone will be happy. As I said, I intend to use this technique - but it would be me writing the main program, and others writing plug-ins. So I can do a Linus and say this is how I interpret the licence. If other people then send me plug-ins, and I do as I said I would do, then they don't have any real case against me :-) Sure, as long as you are the sole copyright owner, then it is no problem. If you start integrating random patches, other may also have right to sue though. But not if I made it clear - *before they sent their patches to me* - that that was the way I was going to interpret the licence. The doctrine of estoppel and all that ... See above. BTW, why did you drop -legal on this ? I don't see how there can be any controversy, so why waste everyone else's bandwidth? For documentation purpose, naturally. As I see it, if I write a plug-in that does not contain *any* copyrightable GPL code, I can't see why the GPL should affect it even if the program it plugs into is GPL. I am not distributing a work derived from GPL code and that's all there is to it. And that's what I was saying in my original reply to the OP. Yes, but it seems that legally you are wrong, and that there is not only the question of the linking also, but of the intent. Anyway, just put in an explicit excemption and everything will be fine. Something among the lines of : This code is under the GPL ... blah blah ... with the additional excemption that it is allowed to link with external plugins which conform to the plugin interface defined in .. blah blah ... Or phrase it differently, but say it explicitly. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Aggregation and firmware]
On Mon, Mar 21, 2005 at 08:08:07PM +, Matthew Garrett wrote: Sorry, I should have Cc:ed this here when I sent it. You saw the couple of threads i started about this topic, right ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
GPLed firmware flasher ...
is a free program plus another program, side by side, their rights will be clear. and : http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program. Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL--if you can't, or won't, do that, you may not combine them. What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. One wonders about the definition of modules, and one can consider that in this case there is no communication altogether between the the two parts, at least not when the code is run, and later once the firmware is installed, the communication method between the two being the IEEE 1275 standard, so there is no surprises. Additionally, the flasher program, or rather the flasher .o, which can be linked with a firmware object and produce a flasheable ELF file can easily enough be distributed in debian/main, and if it contains the firmware, it could be distributed in non-free if the licence on the firmware allowed it. Not that it would really make sense, since distribution is better done on the manufacturers web server, but still. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Non-free (or dubious) firmware in linux driver modules, a lengthy analysis.
it and communicating with the device running it are not derived works the one from the other, and that inclusion and distribution of them in the linux kernel source code or binary version doesn't represent a GPL-violation per se. 2) Are the individual firmware blob distributable at all ? But the above doesn't tell us that those firmware blobs are free, just that they can be distributed together with the linux kernel, either as source code or as binary modules or even builtin the kernel. This is clearly something that needs to be examined on a case per case basis. I have not examined all the firmwares in details, others can maybe fill in here, but i believe the problematic cases are the following a) firmware with source code, but some DFSG-non-freeness in the licence on them. b) firmware without source code with the needded right for distribution. c) firmware without source code but without the needed right to distribute them. All but c) can currently go in the non-free section of our archive, and we will need to do that. 3) Can we ship them in sarge's kernel in main ? The GR http://www.nl.debian.org/vote/2004/vote_004 does say : The Debian Project, affirming its commitment to principles of freeness for all works it distributes, but recognizing that changing the Social Contract today would have grave consequences for the upcoming stable release, a fact which does not serve our goals or the interests of our users, hereby resolves: 1. that the amendments to the Social Contract contained within the General Resolution Editorial Amendments To The Social Contract (2004 vote 003) be immediately rescinded; 2. that these amendments, which have already been ratified by the Debian Project, will be reinstated immediately after the release of the next stable version of Debian, without further cause for deliberation. Some would claim that : a) we used to ship those firmware blobs in the kernel in previous versions of the archive. b) it is a bit latr now in the sarge release process to remove them properly, and thus it is meaningful to keep them for the sarge kernel in main ? I am not entirely sure about the details, especially as said changes to the social contract got disguissed in 'Editorial Ammendements', but i believe that they included parts that where considered to be data and not programs (like fonts, documentation, dictionaries, geographical data and so on). I don't believe that those firmware blobs in question can be in any way described as data, since they are clearly programs destined to be run on the device cpu. It is true though that removing them would have grave consequences for the upcoming stable release, a fact which does not serve our goals or the interests of our users, but i don't believe this is enough to make us invoke the above GR to include them in the sarge main kernel. 4) Technical solution ... So, given the above we need to make sure of the following : a) Firmware included in drivers in the same source file as the drivers are clearly identified as such, and the copyright notice of said file should clearly mention that the firmware in question is not subject to the GPL, and only aggregated there for convenience. Ideally the firmware in question should be in a separate file. b) The individual modules containing the firmware are GPL compatible and thus DFSG free, they can thus be shipped in main if the firmware is stripped from them, or in non-free if the firmware is included. c) Should the modules be stripped of their firmware and kept in main, or simply moved to non-free, which would be way easier ? I believe moving the whole of the binary modules into non-free would be better. d) Can we keep the non-free firmware in the kernel-source in main, and have only the non-free binary modules moved to non-free ? I believe that this is more possible, since if we don't produce the binary modules from them, the firmware blobs are only data, but it is limit. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPLed firmware flasher ...
On Fri, Mar 11, 2005 at 12:28:32PM +0100, Michael Below wrote: Sven Luther [EMAIL PROTECTED] writes: My understanding of this is that neither the firmware constitute a derived work from the flasher, nor the flasher constitute a derived work of the firmware. The fact that they are individually packaged in the same elf binary does not constitute a linking act, nor a derivation/modification act, but mere aggregation, and is thus not a problem for the GPL. I think the opposite is right :) To the user, this doesn't appear as two separate works. He/she/it will see one program with pre-loaded data. If you are using already existing, copyrighted data (the firmware), this means you are building your work on top of the data. This is a derived work, I'd say (this doesn't imply anything to the weight of your work). See my discussion about this in the kernel driver module firmware email. I think it is misleading if you think about the firmware as a program, which indeed doesn't communicate with the flasher. As far as I understand, the firmware that is being flashed doesn't run during operation of the flasher. I.e. it is being treated as data. And this data isn't treated at arm's length, it is permanently incorporated into the executable. Well, no, the at arm length is about executable code, since you recognize it is data, the whole thing is moot and it is not a derived work. Consider the case of a compression program which produce auto-uncompressing files. Is the compressed file a derivative work of the compression program, or just data. I think if in that case there is no doubt, and the flasher is mostly the same case, since it basically uncompresses the firmware, and moves it to the flash instead of the filesystem. So I'd say you should either build the flasher in a more general, arm's length way (one flasher executable, potentially different data files). Or you should consider using the LGPL. It doesn't fit exactly, but it should come closer to what you want. Do you believe then also believe that a linux kernel with embedded initrd in a .initrd section of the elf kernel file constitute a derived work of said kernel ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPLed firmware flasher ...
On Fri, Mar 11, 2005 at 09:24:29AM -0300, Humberto Massa wrote: Despite the letter of the GPL and its post-amble, linking, generally construed as stitching together (normally executable) object (as opposed to source) files and resolving fixups so the result is an executable file does NOT make a derivative work. Derivative works are made when you have intelligent *transformation* of the original work. Linking is not intelligent -- much au contraire, it's fully automatic. So, no, if it doesn't fit, you must acquit -- IOW: the fact of embedding the flasher and the flash in the same ELF file does not make the combined work a derivative work on any of them; only a collective work on both. Collective works are treated separately by copyright law. To distribute a collective work, the distributor must comply with both licenses individually (flasher=GPL, flash=proprietary). If the flash albeit proprietary is redistributable, the combined ELF is Ok. Is this collective work the same thing as the 'mere aggregation' that the GPL and/or GPL FAQ mentions ? With the obvious caveat that it couldn't be distributed _by_ _Debian_. Well, no, but the flasher code with a script or makefile to link any random firmware in and produce a flasher would be. The combined work is also distributable in the non-free section of our archive. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPLed firmware flasher ...
On Fri, Mar 11, 2005 at 04:03:36PM +0100, Michael Below wrote: Do you believe then also believe that a linux kernel with embedded initrd in a .initrd section of the elf kernel file constitute a derived work of said kernel ? Don't understand... I'm not a developer, just a Debian user, and I don't use initrd (as far as I know). What is embedded where? The powerpc chrp kernel (but others do this too, this is only the one i know) uses a elf binary containing the plain kernel and a small bootloader. It can possibly use an initrd, but to boot it, unlike grub/lilo/yaboot/whatever, it embedds said initrd into a .initrd section of the elf file. The ELF stuff is a binary object format used for storing executables, and is used in linux since ages (since we used a.out back then). It comprises of a header, and any amount of sections, one of these section being the main section which the kernel (or the firmware in this case) knows how to execute. It can contain additional data in other sections, or comments or whatever. In this case the initrd and possibly the system.map are contained thus. Now the initrd is itself a filesystem image (ext2 or cramfs), and it can contain any amount of stuff, the most important of them being the /sbin/init (or whatever you decide with the init= kernel argument). Hope this clarifies it ? I believe that it's a derived work if one takes an existing work or part of it and creates something new out of it, so in the end there is only one work. I know this is not very precise. Yep, but in this case, it is mere aggregation (or a collective work), and this is even clarified in the GPL itself as being excluded from the GPL. That said : (http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation) ... If the modules are included in the same executable file, they are definitely combined in one program. ... Muddies the water, but i think we can dismiss it since it speaks of stuff which is much more high level than what we are considering here. Another example would be a GPLed bytecode interpreter (like a JAVA one), and its interpreted program placed in one sole binary elf file, which would be possible provided the interpreted program doesn't use runtime libraries provided by the interpreter. Friendly, Sven LUther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPLed firmware flasher ...
On Fri, Mar 11, 2005 at 08:00:59AM -0500, Jeremy Hankins wrote: Marco d'Itri [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: My understanding of this is that neither the firmware constitute a derived work from the flasher, nor the flasher constitute a derived work of the firmware. The fact that they are individually packaged in the same elf binary does not constitute a linking act, nor a derivation/modification act, but mere aggregation, and is thus not a problem for the GPL. Correct. The firmware is not some other code which the loader is interacting with, it's just some data which happens to be stored in an ELF binary. But anyway, the definition of derived work is something which can only be settled by a court. That last sentence is the key bit, I think. This is enough of a grey area that if you can tweak things so as to make the derived work question go more clearly in your favor, you probably should. Michael Below's suggestion of shipping the firmware as a separate data file, for example, would make it less likely that you get an unpleasant surprise down the road. That way it would more clearly be mere aggregation because your program could theoretically work with some other (as yet unwritten) firmware blob. Yeah, but consider that it is the usual practice in the firmware industry to ship them together, so the mere medium of distribution would do it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPLed firmware flasher ...
On Fri, Mar 11, 2005 at 12:05:58PM -0300, Humberto Massa wrote: The combined work is also distributable in the non-free section of our archive. I'm sure you mean it, but to clarify: IIF the flash is distributable. Yep, obviously, Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPLed firmware flasher ...
On Fri, Mar 11, 2005 at 03:32:12PM +0100, Michael Below wrote: Humberto Massa [EMAIL PROTECTED] writes: Despite the letter of the GPL and its post-amble, linking, generally construed as stitching together (normally executable) object (as opposed to source) files and resolving fixups so the result is an executable file does NOT make a derivative work. Derivative works are made when you have intelligent *transformation* of the original work. Linking is not intelligent -- much au contraire, it's fully automatic. Hm. So the LGPL is completely useless in practice? No, i think there are two different notions : 1) the fact of linking code together in a single binary file. You could obtain a similar effect with a plain : echo $SIZE_OF_A $SIZE_OF_B archive cat a archive cat b archive and not make a and b derivative works of each other. 2) the fact of A making use of the functions provided by library B, that they are linked together dynamically or statically. This is the notion that the LGPL addresses, which is totally orthogonal to the issue 1), which is mere aggregation in a commom media volum or medium of distribution. So, no, if it doesn't fit, you must acquit -- IOW: the fact of embedding the flasher and the flash in the same ELF file does not make the combined work a derivative work on any of them; only a collective work on both. I think you are right, we are talking about a collective work. But I still believe that the GPL demands the distribution of the flash image under GPL terms, when both image and flasher are distributed together. Nope, since it clearly exludes it in the last paragraph of clause 2 : In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. So, there can be no doubt. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPLed firmware flasher ...
On Fri, Mar 11, 2005 at 07:05:35PM +0100, Michael Below wrote: A teacher of mine used to repeat that sentence all the time: as a lawyer, always choose the most secure way. So that's what I would advise you, even if I'm not yet a lawyer. Notice that the more secure way is total immobilism, so this is obviously not an option. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPLed firmware flasher ...
On Fri, Mar 11, 2005 at 04:19:00PM -0300, Humberto Massa wrote: If you consider that the first one is correct (*), then the LGPL is just a marketing ploy. :-) If you consider the second one as being the correct, then the flash-flasher program is banned unless you clarify in flasher's license that I consider one ELF binary as a volume of storage or distribution medium in the terms of the last para of the section #2 of the GPL (yes, you can do that if you are the copyright holder). Or unless the context makes it clear, as said it is common practice to have firmware shipped inside the flash program binary, and at the low level considered, the eld binary is indeed a distribution medium. Even if you look at the actual aim of the whole thing, the flash program is only there to do the last part of the distribution of the firmware, namely making sure the firmware makes it to your board. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: When should -legal contact maintainers [Was: Re: Question for candidate Robinson]
On Thu, Mar 10, 2005 at 12:23:26AM -0800, Don Armstrong wrote: [This is wildly OT for -vote, MFT set to -legal and CC:'ed, please follow up there or privately.] On Thu, 10 Mar 2005, Wouter Verhelst wrote: On Thu, Mar 10, 2005 at 12:52:20AM +0100, Sven Luther wrote: Still, debian-legal should inform the maintainers and invite them to take part of the discussion when examining packages which have been in main for years. I think he's right about this. For one thing, as he just explained, he got upset precisely because he wasn't informed; it's reasonable to assume that the way in which his discussion would have been performed would have been 'slightly' different had he been informed in time. I *do* think it is good practice for d-legal contributors to inform a packages' maintainer if they are discussing its license; we do the same with other types of bugs. If -legal is specifically discussing a license of a package, the maintainer is generally informed[1] when the discussion is actually Can be, and if so it is nice, but it was not in this case, since the first mention i had was that consensus was reached and my package should move to non-free. And it was a nominal discussion about my package. And again, the mail saying the above was CCed to debian-legal, and nobody there bothered to correct the misconception. happening. However, (almost) no one bothers to inform the maintainers when general discussion of a license is occuring, in the first part because most of the discussion isn't particularly useful to most maintainers, and secondly, because people have better things to do[1] than track down which packages are covered by a license when the critical issues (if any) haven't been discussed or discerned yet. In the latter stages of the discussion, if there really are issues with a license that packages in Debian are using, bugs are typically opened against the packages, ideally with a short summary of the specific issues that the license has, and suggestions for what the maintainer can do to fix the license. (And quite often offers of help in explaining the problems to upstream as well.) And in this case, suggestion was ask upstream to GPL his software or dual licence, as trolltech did for Qt. not even bothering to examine the package in questionand noticing that none of the QPLed part of the package was indeed a library, and thus had no GPL-interaction problems. This shot first ask later attitude based on half informed guesses and backed by the fanatism of the debian-legal posters was what mostly irritated me back then, and also what makes me believe that debian-legal is not to be thrusthed on licencing issues, which makes ti totally useless. As far as the analogy to normal bugs goes, the preliminary discussion is generally on the order of is this really a bug? as is typically seen on -devel. [Or, in the extreme case, figuring out whether mass bug filing is sane.] Surely no maintainer expects to be notified every time someone asks on -user, -devel (or $DEITY forbid, IRC[3]) whether specific behavior from a package constitutes a bug. no, but maintainers get over-angry when people modify the seveirty of one of their bugs they have been ignoring for age, no ? And this reaction seems to be backed up by the powers that are, and a real analogy to the please ask upstream to GPL his software or we will recomend ftp-masters to remove it from main kind of request. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Sep 16, 2004 at 05:18:36PM -0700, Josh Triplett wrote: Sven Luther wrote: On Tue, Aug 24, 2004 at 12:30:31PM -0400, Brian Thomas Sniffen wrote: Sven Luther [EMAIL PROTECTED] writes: On Tue, Aug 24, 2004 at 12:13:31PM -0400, Brian Thomas Sniffen wrote: Sven Luther [EMAIL PROTECTED] writes: BSD license, C has freedom with respect to the code and could freely contribute it to Debian. If we got the Caml code that way, that would be great. Indeed, but this is not going to happen. I also would 100x prefer a GPLed ocaml over a BSSDish one though. It's hard to call the GPL a more free license than the QPL -- even if the QPL is called non-free for the sake of argument. They provide different freedoms under different conditions. Licenses are only a partially ordered set. Indeed. i was just expressing my personal preference. I understand, and even agree. But I was referring to your proposed QPL or any more free license -- and the GPL probably wouldn't qualify. I can't see INRIA going for a QPL/GPL split either, sadly. Ok, what about QPL or DFSG-free licence ? To clarify: if INRIA did accept a QPL/GPL dual-license, that would be wonderful. I believe Brian was simply stating that they might be hesitant to do so. Please let this thread die as it should. I don't even remember the full background of this thread. I also seriously doubt that they would go with the GPL, altough i think it more probable than a BSDed ocaml. Friendly, Sven Luther
