Re: firmware status for eagle-usb-*
Mike Hommey wrote: On Tue, Oct 19, 2004 at 05:46:07PM -0700, Josh Triplett wrote: This is clearly not appropriate; it is not perfectly reasonable to install a driver package without the firmware, any more than it is reasonable to install a dynamically-linked binary without its shared library dependencies. In both cases, the functionality is limited to simply imforming the user that a necessary component was not installed. Except in the case of a driver that also works on devices that have the firmware embedded in a ROM chip. Agreed; under those circumstances, a Suggests is quite appropriate, and the driver can go to main, since it can Freely drive at least some hardware. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Is this software really GPL?
Note: I've left Anthony Youngman's email address in the headers, but I seem to have a local problem where email to Anthony bounces. [I can work around that, using telnet, but it's a pain.] quote I strongly suggest that you read the following two web pages: http://easyco.com/initiative/openqm/opensource/index.htm and the accompanying faq: http://easyco.com/initiative/openqm/opensource/faq.htm /quote On Tue, Oct 19, 2004 at 04:48:33PM -0700, Don Armstrong wrote: Yeah, those webpages are basically indicate that they haven't read the GPL and don't understand what it means at all. That's what I thought at first. Rereading it, I think those pages are OK. Basically, all they seem to say is that if you distribute under the GPL you have to supply full sources to what you distribute. -- Raul Sorry for lookout mangling my cut-n-paste - this isn't quite a proper reply ... Did you look at the thing about subsidiaries ... if you *choose* to distribute *source* to your subsidiaries, you are then *obliged* to *publish* your source to the *world*! Imho this sets off the GPL's self-destruct clause (6 and 7) with the result that you can't distribute under the GPL because you can't give your recipients the freedom to distribute to whomsoever they please ... Cheers, Wol This transmission is intended for the named recipient only. It may contain private and confidential information. If this has come to you in error you must not act on anything disclosed in it, nor must you copy it, modify it, disseminate it in any way, or show it to anyone. Please e-mail the sender to inform us of the transmission error or telephone ECA International immediately and delete the e-mail from your information system. Telephone numbers for ECA International offices are: Sydney +61 (0)2 8272 5300, Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1 212 582 2333.
Re: Is this software really GPL?
On Wed, Oct 20, 2004 at 08:04:31AM +0100, Anthony Youngman wrote: Sorry for lookout mangling my cut-n-paste - this isn't quite a proper reply ... And the guy who admins this system claims I should be able to email you now... so hopefully you won't have to do much more of that. Did you look at the thing about subsidiaries ... if you *choose* to distribute *source* to your subsidiaries, you are then *obliged* to *publish* your source to the *world*! The closest I can find to this is a claim that distribution to subsidiaries requires distribution under the GPL. Which seems reasonable. The most akward expression of that is: For instance, if you are a corporate IT department, and your corporation has franchisees, or locally incorporated subsidiaries, delivery to any of these would be a de facto breach of the GPL unless you also publish the full source of the application, including any changes or local customizations of the source, to an independent freely available solution. But even this doesn't say anything about having to distribute to anyone other than who you distribute to. Of course, it goes on to say: Please note that if you publish your work under the terms of the GPL, your competitors may fully use the knowledge and text you disseminate so long as they do so as permitted by the GPL. That doesn't mean you have to distribute the source to your competitors. Instead, it's pointing out that you can't prohibit employees [for example, ad subsidiaries] from distributing it to your competitors or to anyone else. If you did, you'd be violating the terms of the GPL. -- Raul
Re: Is this software really GPL?
On Wed, Oct 20, 2004 at 06:09:29AM -0400, I wrote: Instead, it's pointing out that you can't prohibit employees [for example, ad subsidiaries] from distributing it to your competitors or Er, I meant at, not ad. -- Raul
Re: Is this software really GPL?
On Wed, Oct 20, 2004 at 11:23:11AM +0100, Anthony Youngman wrote: But as I see it, they (QM) are adding an extra restriction, as proscribed by the GPL (clauses 6 and 7). If you distribute to subsidiaries, you may not stop them distributing to the world. But the GPL explicitly recognises internal distribution as a case where the GPL is not needed. I'm not sure what you're talking about here. I can't even find the word internal in the GPL. comment about SCO wasn't that justified. It's just that I tried to do exactly what they're trying to do, and I ended up being convinced it was impossible - to make sure nobody could wrest an Open Source project away from me ... TT can do it because they're trusted. MySQL can do it because they're trusted. EasyCo are trying to do it with legal finesse ... I'm not sure what you're talking about here, either. [I could guess, but how likely are my guesses to be accurate?] -- Raul
RE: Is this software really GPL?
Well, I'm using two different email addresses and computer systems - it's my home system that's subscribed to Debian Legal, and I was emailing from my work system ... But as I see it, they (QM) are adding an extra restriction, as proscribed by the GPL (clauses 6 and 7). If you distribute to subsidiaries, you may not stop them distributing to the world. But the GPL explicitly recognises internal distribution as a case where the GPL is not needed. QM are saying you must apply the GPL, even where the GPL itself says it does not apply. Or to word it slightly differently, you must not impose the normal rules of business confidentiality or employee contract. Actually, I think they've rewritten that section ... they pretty much said as much to me that they rewrote the web site yesterday based on previous emails I sent them. Unfortunately, I think my hard copy of the original is at home. When I get home, I'm going to compare what's there now with what was there last night. It should be interesting... Oh well, at least it proves they're open to rational argument, and my comment about SCO wasn't that justified. It's just that I tried to do exactly what they're trying to do, and I ended up being convinced it was impossible - to make sure nobody could wrest an Open Source project away from me ... TT can do it because they're trusted. MySQL can do it because they're trusted. EasyCo are trying to do it with legal finesse ... Cheers, Wol -Original Message- From: Raul Miller [mailto:[EMAIL PROTECTED] Sent: 20 October 2004 11:09 To: Anthony Youngman Cc: debian-legal@lists.debian.org Subject: Re: Is this software really GPL? On Wed, Oct 20, 2004 at 08:04:31AM +0100, Anthony Youngman wrote: Sorry for lookout mangling my cut-n-paste - this isn't quite a proper reply ... And the guy who admins this system claims I should be able to email you now... so hopefully you won't have to do much more of that. Did you look at the thing about subsidiaries ... if you *choose* to distribute *source* to your subsidiaries, you are then *obliged* to *publish* your source to the *world*! The closest I can find to this is a claim that distribution to subsidiaries requires distribution under the GPL. Which seems reasonable. The most akward expression of that is: For instance, if you are a corporate IT department, and your corporation has franchisees, or locally incorporated subsidiaries, delivery to any of these would be a de facto breach of the GPL unless you also publish the full source of the application, including any changes or local customizations of the source, to an independent freely available solution. But even this doesn't say anything about having to distribute to anyone other than who you distribute to. Of course, it goes on to say: Please note that if you publish your work under the terms of the GPL, your competitors may fully use the knowledge and text you disseminate so long as they do so as permitted by the GPL. That doesn't mean you have to distribute the source to your competitors. Instead, it's pointing out that you can't prohibit employees [for example, ad subsidiaries] from distributing it to your competitors or to anyone else. If you did, you'd be violating the terms of the GPL. -- Raul This transmission is intended for the named recipient only. It may contain private and confidential information. If this has come to you in error you must not act on anything disclosed in it, nor must you copy it, modify it, disseminate it in any way, or show it to anyone. Please e-mail the sender to inform us of the transmission error or telephone ECA International immediately and delete the e-mail from your information system. Telephone numbers for ECA International offices are: Sydney +61 (0)2 8272 5300, Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1 212 582 2333.
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Tue, Oct 19, 2004 at 04:59:37PM -0700, Josh Triplett wrote: True enough, but as processors get faster, so does bandwidth. I expect that ultimately, it will always need to be as fast as possible. Possibly; however, I think bandwidth grows far slower than CPU speed and overall system power. I do understand your concern, though. According to a course taught by my supervisor, processor speed quadruples every three years, as does link bandwidth. See http://www.dvs1.informatik.tu-darmstadt.de/lectures/ws/db2/slides/db2-folien4x1.pdf pages 7-9. I intend to find out his source for these slides b/c this is very important to know. Unfortunately, also according to those slides, installed bandwidth doubles every 9 months. In other words, the actual bandwidth people see increases 2* faster than processors. So, if anything, I need to make my program even faster in the coming years (until installation matches technology). Then, of course, there's the whole scare about this 'leakage' issue that has 'halted Moore's law'. Certainly there has been quite a dip in processors compared to projections from Moore's law lately... We'll see. However, FFT/FGTs are perfectly parallelizable, so multiple cores are as good as a clock speed increase. Anyways, I would hardly take it for granted that processors grow faster. Fortunately, I believe that bandwidth speeds depend on DSP speesd which depends on processors. So, probably if processors slow then bandwidth will also. gcc-3.3 is not an issue; it ICEs. gcc-3.4.2 is the version I was referring to. 1) Have you submitted a bug report on 3.3? Why? They already fixed it in 3.4. 2) Have you tried 3.5? A great deal of work has gone into making 3.5 far better at generating optimized code, particularly with vectorization and advanced instruction sets; much of this came about due to the merging of the tree-ssa branch. I don't know that it would be 2x faster, but I wouldn't be surprised if it was quite measurably faster. I have not. I will do so, but now that I (last night) ironed out the last bugs I need to do some quick measurements and writing to get this paper done. I will let you know how gcc 3.5 works out afterwards though (probably three weeks). (PS. rsgt is not the final name) Heh; naming is tricky but fun. What does rsgt stand for? Reed-Solomon Galois Transform -- the two important technologies I combine. Since it means nothing to the people who would use it, it's bad. For it to sit in contrib, would I have to include the source code in contrib as well? Or would the fact that the source code was in main already satisfy the GPL requirement of source availability? Packages in contrib must still be Free Software, which means they must have source available. I think this is a Policy problem, though I could be wrong. The only thing packages in contrib can do that packages in main can't is declare a Depends:, Build-Depends:, or Recommends: relationship with a non-main package; they must still follow Policy, and they must still be Free Software. I don't know that it is acceptable for the source to be in a separate source package. Sounds like it's probably not. I will include it twice then. You should also talk with the Debian OpenOffice.org team about this; they were in discussion about how to provide the contrib openoffice.org-java package (built with a non-free JDK) without needing a separate (huge) source package in contrib. My program is _much_ smaller than OO. So, I expect if they were split at all on the issue, it means that a package which is so much smaller should have source in both. As for the GPL issue, this is a difficult question: on the one hand, CD vendors and other distributors include contrib and non-free software at their own risk; on the other hand, the idea of the source package being available only in main is difficult. You would certainly be complying with the spirit of the GPL, but I don't know if you would be complying with the letter. GPL clause 3 is the relevant section; of that, Debian always ignores the offer option in GPL 3b and 3c, because 3b requires that the offer be valid for at least three years which Debian cannot guarantee, and 3c is only valid for non-commercial distribution. So looking at the rest of GPL clause 3: 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, [snip 3b and 3c] [snip OS exception] If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place
[no subject]
On Wed, Oct 20, 2004 at 11:23:11AM +0100, Anthony Youngman wrote: But as I see it, they (QM) are adding an extra restriction, as proscribed by the GPL (clauses 6 and 7). If you distribute to subsidiaries, you may not stop them distributing to the world. But the GPL explicitly recognises internal distribution as a case where the GPL is not needed. I'm not sure what you're talking about here. I can't even find the word internal in the GPL. Sorry, my goof. I shouldn't be sloppy. It's the FSF faq. Is making and using multiple copies within one organization or company distribution? . As I read that, it's simply saying that the you in the FAQ can be a company, and as such internal distribution is just use and the GPL doesn't apply. Cheers, Wol This transmission is intended for the named recipient only. It may contain private and confidential information. If this has come to you in error you must not act on anything disclosed in it, nor must you copy it, modify it, disseminate it in any way, or show it to anyone. Please e-mail the sender to inform us of the transmission error or telephone ECA International immediately and delete the e-mail from your information system. Telephone numbers for ECA International offices are: Sydney +61 (0)2 8272 5300, Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1 212 582 2333.
xchat is now shareware in windoze
Hello. Navigating in the xchat site (debian package xchat), I found in http://www.xchat.org/windows/ these sentences: Q. Has the license for X-Chat changed? A. The Windows version is shareware, however, you may still download the source code, released under the G.P.L. You may use X-Chat for Windows for free for 30 days. If, after this time, you would like to continue using the product, you are required to register. Registration is a one time fee of $20 USD (United States Dollars) or $25 AUD (Australian Dollars). You may pay using the Paymate service below, which accepts credit cards in both currencies. Note: source is GPL, but for windoze binaries it is *required* a registration. So I propose to the debian maintainer, not to send patch to upstream, without an explicit declaration that the patches are licensed GPL-only and thus not available in non GPL code. legal team: do you think it is good such requirement? What do you think about such mix free/shareware in debian? [note that I don't think all patch authors relicensed the code] ciao cate
Re: your mail
On Wed, Oct 20, 2004 at 01:51:29PM +0100, Anthony Youngman wrote: Sorry, my goof. I shouldn't be sloppy. It's the FSF faq. Is making and using multiple copies within one organization or company distribution? . As I read that, it's simply saying that the you in the FAQ can be a company, and as such internal distribution is just use and the GPL doesn't apply. That makes sense. Then again, easyco's page says: Local subsidiaries and franchisees are clearly separate business entities and considered distribution rather than use. Similarly, provision of non-GPL-compliant copies to independent contractors under non-GPL terms may constitute unpermitted distribution. When in doubt, have your attorney review your usage for compliance, or purchase a commercial QM license. There's a bit of fud in there, and a bit of sales pitch, but they seem to be leaving the boundaries in the same place as the fsf. Mind you, in most companies the data is likely a lot more significant than the code. Hard coding business secrets into a program likely indicates a lack of flexibility and is probably a sign that the business is in trouble. -- Raul
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Tue, Oct 19, 2004 at 04:59:37PM -0700, Josh Triplett wrote: Wesley W. Terpstra wrote: True enough, but as processors get faster, so does bandwidth. I expect that ultimately, it will always need to be as fast as possible. Possibly; however, I think bandwidth grows far slower than CPU speed and overall system power. I do understand your concern, though. Others have taken this up, but suffice to say: I wouldn't be so sure, unless you have concrete numbers. The main limiting factors on pushing bits these days are the price of lines (fiber is dropping that drastically, for various reasons, at least for long-haul) and the price of hardware that can push the bits at a high enough speed. I can't quote you numbers offhand, but having worked for 10+ years as a network engineer (up to and including senior engineer for an ISP covering 4 states), I can tell you what the budget looked like and why. Put the normal gcc version rsgt in main where the i386 deb has: Recommends: rsgt-icc You cannot put a Recommends from main to non-main; the strongest relationship you can declare is Suggests. rsgt-icc sits in contrib, completely built by icc (not just some .o s) Conflicts: rsgt Provides: rsgt Replaces: rsgt Right. If an i386 user (with contrib sourced) runs 'apt-get install rsgt' will that make apt install rsgt-icc? That's what I hope to accomplish. No, I don't believe it will. That's why when packages change names, it is common to still produce a binary package with the old name, which does nothing except depend on the new package. That doesn't help you in this case, of course. I think all you can do is add the Suggests: rsgt-icc to rsgt, have both packages Conflict/Replace/Provide the other, and provide a brief explanation in the README.Debian of both packages. Or have rsgt-icc and rsgt-dfsg, and have a package rsgt with: Depends: rsgt-dfsg | rsgt-icc Since the dependancy can be met only with items available from main, this is allowed (at least, as established in prior discussions), and is far more obvious to most people, I think, than a Suggests on the same package that one also has a Replaces/Provides/Conflicts. (In particular, 'Conflicts' and 'Suggests' together is likely to cause a great deal of brainache to the package install tools...) On a sidenote, the ability to tune into a stream of (potentially multicast) UDP packets at an arbitrary point, collect enough that you have = the size of the file, and know that you can recover the file is something with *serious* potential from the network world point of view. My one question, as an operator, is whether that sequence of packets has to be sequential (it sounds like it doesn't, especially with the 20% packet loss problem description). If not, something like this could have *very* far-reaching impacts; if one turned on checksumming (available for UDP packets natively, or one could do it in the protocol) to avoid bitrot, this opens up a huge path to potentially simplifying a large set of problems (and no, they're more or less nothing like the ones par can solve, as for reasons discussed earlier by the author). -- Joel Baker [EMAIL PROTECTED],''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Reproducible, precompiled .o files: what say policy+gpl?
Joel Baker wrote: On Tue, Oct 19, 2004 at 04:59:37PM -0700, Josh Triplett wrote: Wesley W. Terpstra wrote: True enough, but as processors get faster, so does bandwidth. I expect that ultimately, it will always need to be as fast as possible. Possibly; however, I think bandwidth grows far slower than CPU speed and overall system power. I do understand your concern, though. Others have taken this up, but suffice to say: I wouldn't be so sure, unless you have concrete numbers. It was pure speculation on my part, and I wouldn't be surprised if it turns out to be wrong. :) The main limiting factors on pushing bits these days are the price of lines (fiber is dropping that drastically, for various reasons, at least for long-haul) and the price of hardware that can push the bits at a high enough speed. I can't quote you numbers offhand, but having worked for 10+ years as a network engineer (up to and including senior engineer for an ISP covering 4 states), I can tell you what the budget looked like and why. You certainly have far more information to go on then. :) To be honest, I was thinking more about end-user Internet bandwidth, rather than general network bandwidth. Put the normal gcc version rsgt in main where the i386 deb has: Recommends: rsgt-icc You cannot put a Recommends from main to non-main; the strongest relationship you can declare is Suggests. rsgt-icc sits in contrib, completely built by icc (not just some .o s) Conflicts: rsgt Provides: rsgt Replaces: rsgt Right. If an i386 user (with contrib sourced) runs 'apt-get install rsgt' will that make apt install rsgt-icc? That's what I hope to accomplish. No, I don't believe it will. That's why when packages change names, it is common to still produce a binary package with the old name, which does nothing except depend on the new package. That doesn't help you in this case, of course. I think all you can do is add the Suggests: rsgt-icc to rsgt, have both packages Conflict/Replace/Provide the other, and provide a brief explanation in the README.Debian of both packages. Or have rsgt-icc and rsgt-dfsg, and have a package rsgt with: Depends: rsgt-dfsg | rsgt-icc Since the dependancy can be met only with items available from main, this is allowed (at least, as established in prior discussions), and is far more obvious to most people, I think, than a Suggests on the same package that one also has a Replaces/Provides/Conflicts. That is a good idea, and one that actually has some precedent in real packages, such as the libSDL packages. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: xchat is now shareware in windoze
On Wednesday 20 October 2004 08:19 am, Giacomo A. Catenazzi wrote: Hello. Navigating in the xchat site (debian package xchat), I found in http://www.xchat.org/windows/ these sentences: Q. Has the license for X-Chat changed? A. The Windows version is shareware, however, you may still download the source code, released under the G.P.L. Note: source is GPL, but for windoze binaries it is *required* a registration. This may be perfectly acceptable. Assuming that the sources for the Windows version include all the registration/validation logic, and are distributed under the GPL, providing a compiled binary of them is completely kosher. Of course, anybody with a compiler could hack out the time limit. Now, if the registration/validation logic is not part of those GPL'd sources, then we have a problem. -- John
Re: xchat is now shareware in windoze
Hi, Am Mittwoch, den 20.10.2004, 16:36 -0500 schrieb John Goerzen: Now, if the registration/validation logic is not part of those GPL'd sources, then we have a problem. If it only applies to the windows sources/binary, we don't have a problem. If anybody has a problem, then those who contributed GPLed code or whose GPLed code somehow else made their way into the windows sources, but did not agree with that licencing. Or is there anything that actually and legally should worry debian, besides a possible different view on free software from some upstream author? thx, nomeata -- Joachim nomeata Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata
Re: firmware status for eagle-usb-*
[EMAIL PROTECTED] wrote: Given that the entire purpose of the driver is to actually *drive a device*, and that it can't do that at all without the firmware, then the No, apparently you do not understand how the driver, hardware and firmware interact. The driver is fully functional as is: the firmware is needed by the hardware device, not by the driver. -- ciao, Marco
Re: xchat is now shareware in windoze
John Goerzen writes: On Wednesday 20 October 2004 08:19 am, Giacomo A. Catenazzi wrote: Hello. Navigating in the xchat site (debian package xchat), I found in http://www.xchat.org/windows/ these sentences: Q. Has the license for X-Chat changed? A. The Windows version is shareware, however, you may still download the source code, released under the G.P.L. Note: source is GPL, but for windoze binaries it is *required* a registration. This may be perfectly acceptable. Assuming that the sources for the Windows version include all the registration/validation logic, and are distributed under the GPL, providing a compiled binary of them is completely kosher. Of course, anybody with a compiler could hack out the time limit. Now, if the registration/validation logic is not part of those GPL'd sources, then we have a problem. Briefly perusing the CVS repository on SourceForge, there does not appear to be any logic for checking the license keys. The Win32 executable also seems to be linked against a modified version of a gtk+ library, with no source provided for that (it definitely includes minigtk.dll wand a gtkrc file with no explanation of the license for that). It also seems to be linked against OpenSSL (it includes libeay32.dll and libssl32.dll) without including the copyright notices required by those licenses. I know several contributors to X-Chat have complained about the shareware release and feel that it infringes their copyrights. In short, the Windows version seems to blatantly and willfully violate a number of copyrights. The maintainer makes it clear he will continue to redistribute code contributed under the GPL as shareware (at http://forum.xchat.org/viewtopic.php?t=533). This does not pose a direct problem for Debian, since Debian would not be distributing the Windows shareware version, but Debian may not want to support software whose authors do things like X-Chat's maintainer has done. Michael Poole
Re: firmware status for eagle-usb-*
On Wed, 20 Oct 2004, Marco d'Itri wrote: [EMAIL PROTECTED] wrote: Given that the entire purpose of the driver is to actually *drive a device*, and that it can't do that at all without the firmware, then the No, apparently you do not understand how the driver, hardware and firmware interact. The driver is fully functional as is: the firmware is needed by the hardware device, not by the driver. This comes back to the same issue: Is there a dependency relationship between the package that provides the driver and the firmware itself? If the package requires the presence of a firmware file which must be uploaded to the device at runtime in order to be useful at all, then the package has a dependency relationship with the firmware. If the package doesn't need to upload a firmware file to the device in order to be useful at all, then it probably doesn't have a dependency relationship with the firmware. In any event, whether or not a dependency actually exists really isn't a subject for this list to discuss as it has nothing to do with the license, legality, or DFSG status of a package; only policy and the package's Depends:x are at issue here. You can raise it on -devel if it actually occurs, or users can file bugs against such a package if they feel improper dependencies are in place. Don Armstrong -- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Academic Free License 2.1 -- free or not?
On Tue, 19 Oct 2004 07:05:08 +0200 Arnoud Engelfriet wrote: When accepting the terms of the GPL, I also must give up certain rights about warranties that I normally expect to have. I didn't see that way: I saw the disclaimer of warranty as a declaration(valid even if I don't accept the license and I merely use the piece of software without copying, distributing or modifying it). I think it's a part of the GPL and not just a declaration about a factual situation. I wonder what warranties I could claim if I do not accept the license. So do I. Which warranties do I loose by accepting the license? The software was legally distributed to me, and that gives me some entitlements under copyright law. Which ones? Please explain (IANAL, hence I'm not so knowledgeable...). If the law says the warranty *may* be disclaimed and the software has this disclaimer attached, I'm warned that there is no warranty: I loose no right in accepting the license, as I didn't have any such right in the first place. I'm not even sure if the issue of warranties is relevant to freedom of software. Even without any warranty you can always use, modify and distribute the software. And if it breaks, not only do you get to keep the pieces, you get to fix it! That is more or less what I was thinking... -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpzEsB9M7ENd.pgp Description: PGP signature
Re: AbiWord, trademarks, and DFSG-freeness
On Mon, 18 Oct 2004 09:09:17 -0400 Raul Miller wrote: However, let's take AbiWord as an example. We've been told that we do not have a license to use AbiWord on derivative works. We're clearly not required to retain AbiWord on those works. It seems correct. The question is: if we remove the trademarks that label the work, is the work then DFSG free? Yes, I would say. But is the original unpurged work DFSG-free? [...] If you are right, I think we would be able to deal with the unfortunate Debian logo issue in a much easier way. I don't know what problem you're trying to talk about. I was referring to the Debian Open Use Logo in main issue. If I didn't miss relevant data, its copyright license is still non-free. And no consensus has yet been reached about the more difficult question, that is Do we need to issue a permissive trademark license, too? Can we? Should we? There has been a long thread rather recently in this list... -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpRCVy4hUVGU.pgp Description: PGP signature
Re: Academic Free License 2.1 -- free or not?
On Mon, 18 Oct 2004 14:00:28 -0300 Carlos Laviola wrote: Still haven't subscribed, but I'm reading the archives periodically. It's mandatory, you know. It's just easier to manage... I'm in the middle of a lot of stuff -- just gave a talk about Debian at the university's 2nd annual week on FLOSS, have an Statistics and Calculus exam today and tomorrow, respectively, gotta go to the dentist, am moving out of my parents' house... Heh :-) May the Source be with you! :) It would be a hell of a lot easier for everyone involved if the FIGlet people would choose MIT/BSD style. I don't know what to do now. Try and persuade all the FIGlet copyright holders to agree on a big relicensing. Since they dislike copyleft, the best choice would be the Expat license (http://www.jclark.com/xml/copying.txt), IMHO. Other optimal choices can be: the X11 license (http://www.x.org/Downloads_terms.html) or the 2-clause BSD license (http://www.fsf.org/licenses/info/BSD_2Clause.html). This would nuke all the issues, once and for all. Maybe when Christiaan, the current FIGlet maintainer, comes back from vacation and release a new version with the license changes, Which license changes? To Academic Free License 2.1? If this is the case, I hope he changes his mind... I'll just *have* to upload to non-free. I don't know whether the current, Artistic-licensed version still qualifies for main; I don't think so, as the DFSG-freeness of that old Artistic license is questionable, IIRC. Moreover there are unsolved issues with unclearly licensed files. Worse: there are possibly undistributable files and this means the package is perhaps not even suitable for the non-free section, until you obtain clarification from relevant copyright holders... all I do now is that the people who held copyrights on FIGlet in the past are still very much interested in keeping it free software. *sigh* I'm sure I follow you correctly here: are you saying that many FIGlet copyright holders are willing to let FIGlet be free software? This would be great news... When I have a few hours of spare time, I'll compile everything I have so far and mail the list again, subscribe using something non-webmaily -- gmail is nice, but it's a bitch for mailing lists -- and, well, actually try to solve this situation. Good, I'm looking forward to seeing an update on this issue. This is a call for help; if you have some time, please subscribe to the figlet mailing list and start a discussion on this subject or something. Well, you are the Debian maintainer, hence you know upstream better than I do. You have more chances in being successful. And, last but not least, I spend time in keeping up with debian-legal... :p Thanks a lot for all of your help so far. You are welcome, I really hope we can work out a solution with upstream and get a DFSG-free FIGlet! -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpn8opBh4oKh.pgp Description: PGP signature
Re: AbiWord, trademarks, and DFSG-freeness
On Sun, 17 Oct 2004 23:48:06 -0400 Brian Thomas Sniffen wrote: You can't quite change the name of the work using a patch. You always have to distribute the original, which includes its name. If Abiword were under a patch-clause license, Debian'd have to distribute software which said This is Abiword on every startup... plus patches. But only the original would say This is Abiword. The patched one would not. We would be able to distribute (although in a technically inconvenient way, that is, through patches) a derivative work whose name is not Abiword. -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp4HB13mp8Ey.pgp Description: PGP signature
Re: AbiWord, trademarks, and DFSG-freeness
On Wed, Oct 20, 2004 at 11:55:30PM +0200, Francesco Poli wrote: But is the original unpurged work DFSG-free? I'm not sure that's the right question. Remember, we interpret the DFSG based on the spirit of the rules, rather than the letter. I think the right question is: how should we handle this work? And that question has various possible answers: If the work has been released in Stable, just leave it alone. We can fix security bugs, and generally do with it all that we need to do. If it's not been frozen yet, add semantics to the program so we can change its name, then change the name of the thing and add a Replaces: header, and a sentence or two to the package description. Alternatively, if the interpretation of the trademark holder is so broad that we wouldn't want to change the semantics of the program that far, consider the trademark to be a required legal notice and just live with it. If we're in the midst of a freeze, it's up to the release manager. These choices further the goals of the social contract, and abide by the spirit of the DFSG. -- Raul
Re: Academic Free License 2.1 -- free or not?
On Wed, Oct 20, 2004 at 11:39:56PM +0200, Francesco Poli wrote: Still haven't subscribed, but I'm reading the archives periodically. It's mandatory, you know. It's just easier to manage... Huh? Subscribing to debian-legal isn't mandatory. -- Glenn Maynard
