Re: LCC and blobs
Brian Thomas Sniffen wrote: So would a web-based firmware loader, that never saved the firmware to disk allow the drivers to be in main? Of course not. It's fetching software, then using that software. ICQ software merely mentions messages, but doesn't use them. ICQ uses the messages as instructions telling it what glyphs to display on your screen. That part of the message, though, might be free. It does use significant features from non-packaged software --- message routing, buddy list management, buddy tracking, file transfer, etc. We've elected to ignore ICQ's dependency on an ICQ server. We've elected to ignore a driver's dependency on firmware burnt in ROM or stored in flash --- even when it executes that code on the main CPU. We've elected not to ignore firmware that resides in RAM instead. I'm not sure how to make a consistent (and still useful) position out of all that.
Re: LCC and blobs
Raul Miller wrote: On Fri, Dec 31, 2004 at 05:02:15PM -0500, Anthony DeRobertis wrote: The social contract says ...but we will never make the system depend on an item of non-free software. not but we will never make the system depend on an item of non-free software /which we must distribute/. We don't make the hardware. Took me a while to figure out exactly what you're saying, but is it essentially that we could say: We are not making our system depend on an item of non-free software. Your hardware vendor did, not us.
Re: LCC and blobs
Josh Triplett wrote: I would like to suggest an additional option, which I think covers most cases quite well: If Debian were to package (a copy of) the non-free item in the non-free section, would the Free package express a Depends, Recommends, or Build-Depends on the non-free package? If so, the Free package should be in contrib. That's an interesting criteria. It winds up working for flash and ROM-based devices because they are like Essential: yes packages. However, it has one pitfall I can think of: If a package requires a certain version of an essential package, we'd normally declare a Depends: on that version (or later). I'm not sure what we'd do for firmware, though it'd probably be either a 'Suggests' or 'Recommends'.
Re: phpldapadmin 0.9.5, is it free?
On ср, 2005-01-05 at 23:25 +0100, Andreas Barth wrote: * Fabio Tranchitella ([EMAIL PROTECTED]) [050105 20:50]: Here there is the text grabbed from that page: While phpLDAPadmin costs 49.95 for commercial download, we are providing it for free to home users. If you purchase the commercial download, you get the added benefit of support from the original developers. As far as I know, sourceforges policy is to host only software free for everybody. Though their policy is not the same as ours, I think this violates even their policy. Why would this be a violation? Everyone can sell free software. (not freeware, but free/open source software) Here is what is said on http://www.phpldapadmin.com/faq.php: [...] Q. Is phpLDAPadmin Open Source? A. Yes. It is licensed to you under the GNU General Public License. This is very good news for phpLDAPadmin users. [...] Q. Can you really charge for phpLDAPadmin? Isn't it Open Source software? A. Yes and yes. The GPL specifically allows sellers to charge for the service of distributing and/or supporting users of GPL-licensed software. Here is an article that may help with this question: http://www.pbs.org/cringely/pulpit/pulpit20040722.html [...] So it's obviout to me that the author distributes the code with license and this license if free (GPL). In fact, if someone forbids comercial use or charging for support etc., then the program would be non-free for Debian. P.S.: Anyway, I would recommend contacting the author... just to be sure everything is ok :) It's no big deal, the guy might be even pleased by the interest in his code :P -- | Iassen Pramatarov |a.k.a. turin | home: http://iassen.projectoria.org/book/ | jabberID: xmpp:[EMAIL PROTECTED] | Projectoria team | Free Software Association - Bulgaria \_ http://projectoria.org | http://fsa-bg.org \
Re: Hypothetical situation to chew on
On Wed, Jan 05, 2005 at 10:03:44PM -0500, Nathanael Nerode wrote: Note that this email message is subject to copyright, and can't legally be reprinted without permission (except for fair use, such as quotation rights). Under pre-1986 US law, it would be public domain, because I didn't affix a copyright notice. I'm not sure that reprinted is a meaningful characterization of the sorts of limits which are in effect. For practical reasons, your message probably was never printed in the first place. Likewise, you can't really prevent people from printing copies of the message. If someone does something seriously unreasonable with the message, then you'd have grounds for taking them to court. In other words: [1] People have some rights to use any copyrighted material that they have received legally -- regardless of what rights have or have not been granted to them. [2] Reasonable expectations play a part in the interpretation of copyright laws and licenses. This issue of implicit copyright is significant, but it's not quite as extreme as you've presented it. -- Raul
Re: phpldapadmin 0.9.5, is it free?
On Thu, Jan 06, 2005 at 08:44:38AM +0200, Iassen Pramatarov wrote: While phpLDAPadmin costs 49.95 for commercial download, we are providing it for free to home users. If you purchase the commercial download, you get the added benefit of support from the original developers. Why would this be a violation? Everyone can sell free software. (not freeware, but free/open source software) The wording of the above implies that the author does not intend commercial users to be allowed to use the free to home users version. Of course, this contradicts the GPL itself. It probably means either that the author is confused, or simply wrote the above text poorly. Q. Can you really charge for phpLDAPadmin? Isn't it Open Source software? A. Yes and yes. The GPL specifically allows sellers to charge for the service of distributing and/or supporting users of GPL-licensed software. Here is an article that may help with this question: http://www.pbs.org/cringely/pulpit/pulpit20040722.html This is an odd approach, though. It seems to make much more sense to simply offer the software, and then charge for the support itself. (After all, I'd expect anyone paying for this support to simply use the GPL version, and only purchase the commercial version to get support if it actually becomes necessary, so it ends up being the same thing.) -- Glenn Maynard
Re: mozilla thunderbird trademark restrictions / still dfsg free?
MJ Ray wrote: MJ Ray [EMAIL PROTECTED] wrote: By the way, the trademark FAQ doesn't tell me how to build without including the proprietary logos. Can anyone tell me how? Spotted another thread (mail is slow here this week) and replaced the branding dir. Rebuild underway. Still need to replace titlebar? I apologise that we don't have a better document detailing this process. - The default build for Firefox and Thunderbird uses non-trademarked logos - The names can be found in files called brand.dtd and brand.properties http://lxr.mozilla.org/mozilla/find?string=browser.*brand (for Firefox) This should change the vast majority of instances. There are a few it doesn't; these are either bugs or unavoidable due to the words being in other pieces of code, like the installer. But try that and see how far you get. Gerv
Re: Hypothetical situation to chew on
On Wed, 5 Jan 2005 22:03:44 -0500, Nathanael Nerode [EMAIL PROTECTED] wrote: Let me clarify. :-) I have few complaints with the treatment of material for which the authors *claim* copyright. My complaint is about material distributed willy-nilly by its authors with *no* copyright statements and *no* licensing information. Clearly the authors didn't intend all rights reserved, but that's what current law assumes. In contrast, pre-1986 (I think) US law specified that works published (== deliberately distributed to the public by their authors) without a copyright statement went into the public domain. Note that this email message is subject to copyright, and can't legally be reprinted without permission (except for fair use, such as quotation rights). Under pre-1986 US law, it would be public domain, because I didn't affix a copyright notice. This change has, frankly, made a freaking mess. This is why projects have to have statements like By submitting a patch, you agree to license it to us under (license of choice). Under the old law, submitting a patch of your own authorship to a public bug tracking system would be publishing it, and if you did so without a copyright notice -- public domain. As I understand US law (though my knowledge of it is just marginal), the publishing without copyright notice wouldn't make it public domain, but just not-enforceable. Very often in litigation, one would register an already (long before) published work, to be able to enforce it in the upcoming litigation. I am not sure about this, but as a defense (the 'no, I am not infringing your copyright'), it probably doesn't have to be registred, but to be sure you should ask a US lawyer. kind regards batist
OleMiss Email Account cnlawren DEACTIVATED
This account is no longer active. Thus, your mail regarding [PMX:VIRUS] Re: will not be received.
Re: More mmcache concerns
On Wed, Jan 05, 2005 at 07:57:12PM -0800, Elizabeth Fong wrote: Jonathan Oxer: The big question though (and this is where legal advice may be required) is what happens to copyright when the copyright owner ceases to exist? It is auctioned off by the liquidators, along with all other property of the defunct company. Somebody probably owns it. Probably somebody with no conception of what they own (things of little or no value are usually auctioned in large batches just to get rid of them). You'll also probably never find out who, unless it gets acquired by a litigation company (like SCO). In the unlikely event that nobody bought it, the details vary with jurisdiction. For example, in the UK, it would revert to the crown (I think). According to copyright law the copyright for works made for hire exists for 95 years from the date of publication or 120 years from the date of creation, whichever is shorter. It's considered work for hire so unless he had a contract with Turcksoft to the contrary he is *not* the copyright holder. So... I guess the question is, what _can_ we do? Wait about a century for copyright to expire and hope that it doesn't get extended again. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Hypothetical situation to chew on
On Wed, 05 Jan 2005 18:43:02 -0800 Josh Triplett wrote: I'm not referring to those who sell proprietary licenses to a separate version of the software; I'm referring to those who use a copyleft license and sell exceptions for people who want to link their proprietary software against that copylefted software. So you were thinking about libraries and the like, as I suspected... In that case I can understand the rationale behing this business model. In other cases, I find it hard... -- 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 pgpUX3hhUJ3WY.pgp Description: PGP signature
Re: mozilla thunderbird trademark restrictions / still dfsg free?
On 06 Jan 2005 01:30:02 GMT MJ Ray wrote: Using MF's trademarks seems to require some sort of licence to be granted specifically to debian and not to its users. That seems not to follow DFSG 7 or 8, doesn't it? Alternatively, if the names are changed to firebird/tbird/mozzarella or anything else avoiding the MF trademarks, no extra licences are required. Describing the heritage in the description line will let users find the right debian package, while still being honest. If MF is really going to insist that it gets magic veto rights over the work of the debian maintainer and users, changing the name is the easiest solution. If MF want us to use the trademarks, make that solution easier by relaxing the policy enough to follow the DFSG. I think it's fine to insist on prominent marking of differences, but it's too severe to revoke permission based on random unspecified quality judgements. I agree entirely. At present, it seems we really *need* to replace MoFo trademarked names and logos in order to satisfy the DFSG. Sad but true. :-( -- 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 pgpxMfuWYJ3nJ.pgp Description: PGP signature
Re: Hypothetical situation to chew on
On Wed, 5 Jan 2005 22:20:37 -0500 Glenn Maynard wrote: The only case where what you say holds is where the licensee purchasing the proprietary license would have otherwise used the GPL license and released source. Which case--encouraging companies to GPL source, or funding the further development of the work itself--is more beneficial is an open question, Well, I was referring to a situation like this, more or less... -- 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 pgpCA9CdqK5nb.pgp Description: PGP signature
Re: Hypothetical situation to chew on
On Thu, Jan 06, 2005 at 12:21:06PM +0100, Francesco Poli wrote: On Wed, 05 Jan 2005 18:43:02 -0800 Josh Triplett wrote: I'm not referring to those who sell proprietary licenses to a separate version of the software; I'm referring to those who use a copyleft license and sell exceptions for people who want to link their proprietary software against that copylefted software. So you were thinking about libraries and the like, as I suspected... In that case I can understand the rationale behing this business model. In other cases, I find it hard... You're selling a licence to your app so that the recipient can modify and resell, but they don't want to GPL their changes. I probably wouldn't do it myself, but I can certainly envisage it as a possibility. - Matt signature.asc Description: Digital signature
Re: mozilla thunderbird trademark restrictions / still dfsg free?
On Thu, 06 Jan 2005, Francesco Poli wrote: On 06 Jan 2005 01:30:02 GMT MJ Ray wrote: Using MF's trademarks seems to require some sort of licence to be granted specifically to debian and not to its users. That seems not to follow DFSG 7 or 8, doesn't it? At present, it seems we really *need* to replace MoFo trademarked names and logos in order to satisfy the DFSG. Sad but true. :-( And even if one were to ignore the DFSG, I'd be surprised if the maintainers were willing to agree to the type of restrictions necessary to even use them. I know if I were maintaining it, I would be very worried that the trademark license would be pulled or similar, and I would be in the very wierd position of trying to pull the packages from a stable release and dealing with all of the problems that that would cause for the users of the packages. Don Armstrong -- Quite the contrary; they *love* collateral damage. If they can make you miserable enough, maybe you'll stop using email entirely. Once enough people do that, then there'll be no legitimate reason left for anyone to run an SMTP server, and the spam problem will be solved. Craig Dickson [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu
Re: mozilla thunderbird trademark restrictions / still dfsg free?
MJ Ray [EMAIL PROTECTED] wrote: Using MF's trademarks seems to require some sort of licence to be granted specifically to debian and not to its users. That seems not to follow DFSG 7 or 8, doesn't it? I don't see why. We don't require that trademark licenses be granted to our users in any case - us having an extra permission above and beyond the freedoms we expect for our users doesn't seem to be a problem. -- Matthew Garrett | [EMAIL PROTECTED]
Re: mozilla thunderbird trademark restrictions / still dfsg free?
Gervase Markham [EMAIL PROTECTED] wrote: - The default build for Firefox and Thunderbird uses non-trademarked logos Are you sure? The graphics seem to have the words Firefox in them, which doesn't seem a permitted use of the trademark to me. - The names can be found in files called brand.dtd and brand.properties http://lxr.mozilla.org/mozilla/find?string=browser.*brand (for Firefox) Ah, I found another directory mozilla/dist/branding as well as the mozilla/other-licenses/branding one that I knew about. Which of these are actually used? Still the About box and about: page have Firefox graphics. Grrr. Where do they come from? This should change the vast majority of instances. There are a few it doesn't; these are either bugs or unavoidable due to the words being in other pieces of code, like the installer. But try that and see how far you get. Well, the titlebar and some of the names are now correct. I still have a browser that uses the Firefox trademark repeatedly to describe itself. Can I distribute it? Is MF implicitly licensing the trademarks by making it so hard to remove them when performing acts permitted by the copyright licence? Actually, I have no idea whether implicit trademark licences exist. I was only told about implicit patent licences last year. I'd rather not rely on that idea if I don't have to ;-) Amusingly, the About FireWWW box says it is copyright contributors, but pressing the credits button displays a box empty apart from FireWWW \n The browser, reloaded. How do Mozilla contributors feel about not being credited on the About box at all? -- MJR/slef
Re: mozilla thunderbird trademark restrictions / still dfsg free?
Matthew Garrett [EMAIL PROTECTED] wrote: MJ Ray [EMAIL PROTECTED] wrote: Using MF's trademarks seems to require some sort of licence to be granted specifically to debian and not to its users. That seems not to follow DFSG 7 or 8, doesn't it? I don't see why. We don't require that trademark licenses be granted to our users in any case - us having an extra permission above and beyond the freedoms we expect for our users doesn't seem to be a problem. We're distributing some files which cannot be modified and distributed if MF considers the resulting work confusingly similar. Are there many other packages afflicted by such agressive registered trademarks? The other one which I remember is Apache and I think their trademark was another source of tension once. I would agree with your view if one doesn't need an MF trademark license to modify and distribute any of the work from debian main. Is this similar to deciding whether we would delete invariant sections from GNU FDL'd works if it were possible and they were the only problem? -- MJR/slef
Re: Non-free files in source packages?
On Thu, 06 Jan 2005 01:28:35 +0100 Simon Josefsson wrote: I believe it would be useful for the Debian community to let the IETF know about Debian's position on this. Preparing a statement and posting it to the IETF IPR working group seem appropriate, and would be appreciated. I agree: we should try and persuade them to release DFSG-free RFCs. -- 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 pgpifpHpz16wI.pgp Description: PGP signature
Re: mozilla thunderbird trademark restrictions / still dfsg free?
MJ Ray [EMAIL PROTECTED] wrote: Matthew Garrett [EMAIL PROTECTED] wrote: I don't see why. We don't require that trademark licenses be granted to our users in any case - us having an extra permission above and beyond the freedoms we expect for our users doesn't seem to be a problem. We're distributing some files which cannot be modified and distributed if MF considers the resulting work confusingly similar. Are there many other packages afflicted by such agressive registered trademarks? The other one which I remember is Apache and I think their trademark was another source of tension once. But we're also distributing files that the user can't modify without renaming, so I'm not entirely sure what the issue is. If Mozilla's /copyright/ license said You may not modify this without renaming it, unless you have a separate agreement with us, would you object to Debian having permission to call the code Mozilla? Would you object if we then distributed it under that name, even if our users didn't have permission to do so? -- Matthew Garrett | [EMAIL PROTECTED]
Re: mozilla thunderbird trademark restrictions / still dfsg free?
MJ Ray wrote: Gervase Markham [EMAIL PROTECTED] wrote: - The default build for Firefox and Thunderbird uses non-trademarked logos Are you sure? The graphics seem to have the words Firefox in them, which doesn't seem a permitted use of the trademark to me. The default build removes the trademarked logos (the fox-on-globe or the bird-on-envelope) but not the trademarked words. This is because our current trademark policies are more strict about the use of the logo compared to the word, so more people (e.g. all our localisers) use the word. Of course, there's a big under construction sign on all this, so I wouldn't be surprised if reality differs a little from the ideal. - The names can be found in files called brand.dtd and brand.properties http://lxr.mozilla.org/mozilla/find?string=browser.*brand (for Firefox) Ah, I found another directory mozilla/dist/branding as well as the mozilla/other-licenses/branding one that I knew about. Which of these are actually used? mozilla/dist is the built version of Mozilla. mozilla/other-licenses/branding shouldn't be pulled or built unless you've set MOZ_USE_OFFICIAL_BRANDING: http://lxr.mozilla.org/aviarybranch/source/Makefile.in#208 This is done using the --enable-official-branding switch to configure. If a clean CVS pull without that switch is pulling and building in that directory, that's definitely a bug. :-) Is MF implicitly licensing the trademarks by making it so hard to remove them when performing acts permitted by the copyright licence? No. :-) Amusingly, the About FireWWW box says it is copyright contributors, but pressing the credits button displays a box empty apart from FireWWW \n The browser, reloaded. How do Mozilla contributors feel about not being credited on the About box at all? If you wait, it scrolls - or it should do. There are also more contributors at about:credits. Gerv
Re: LCC and blobs
Anthony DeRobertis [EMAIL PROTECTED] writes: So would a web-based firmware loader, that never saved the firmware to disk allow the drivers to be in main? Of course not. It's fetching software, then using that software. ICQ software merely mentions messages, but doesn't use them. ICQ uses the messages as instructions telling it what glyphs to display on your screen. That part of the message, though, might be free. That's a dangerous route to follow. By that logic, all the https browsers have dependencies on non-free software: the private keys associated with their CA root certificates. It does use significant features from non-packaged software --- message routing, buddy list management, buddy tracking, file transfer, etc. We've elected to ignore ICQ's dependency on an ICQ server. We've elected to ignore a driver's dependency on firmware burnt in ROM or stored in flash --- even when it executes that code on the main CPU. We've elected not to ignore firmware that resides in RAM instead. No. Firmware resident in RAM but put there by, say, the BIOS is fine. We've elected not to ignore firmware which is to be handled and installed by Debian software. You're having trouble making a coherent position out of this only because you keep recasting it in terms which aren't equivalent. The issue at hand is whether somebody might ever download software from Debian and find it useless without additional software which he could download... but not from Debian, since it's not Free and not packaged. If I download an ICQ client, there are lots of reasons I might find it useful: I might not have anything to say, or I might have no network connection, or I might have no friends to talk to. Debian is not responsible for providing me with creativity, connectivity, or friends. I think the example provided elsewhere in this thread -- that we'd never say an ICQ client Depends: icq-server -- is excellent. We'd also never mark something Depends: bios, because the BIOS is essential and assumed to be present. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: LCC and blobs
Brian Thomas Sniffen [EMAIL PROTECTED] wrote: If I download an ICQ client, there are lots of reasons I might find it useful: I might not have anything to say, or I might have no network connection, or I might have no friends to talk to. Debian is not responsible for providing me with creativity, connectivity, or friends. I think the example provided elsewhere in this thread -- that we'd never say an ICQ client Depends: icq-server -- is excellent. We'd also never mark something Depends: bios, because the BIOS is essential and assumed to be present. Why is Debian any more responsible for providing you with the firmware? The manufacturer can do that. And, without it, the driver is about as much use as an ICQ client without an ICQ server. -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
Brian Thomas Sniffen writes: No. Firmware resident in RAM but put there by, say, the BIOS is fine. We've elected not to ignore firmware which is to be handled and installed by Debian software. You're having trouble making a coherent position out of this only because you keep recasting it in terms which aren't equivalent. The issue at hand is whether somebody might ever download software from Debian and find it useless without additional software which he could download... but not from Debian, since it's not Free and not packaged. Why do you insist on the downloadable part of useless without additional software which he could download? I see no basis for that qualification in the DFSG or policy. I could manufacture a device that requires loadable firmware, and a driver for it, yet forbid distribution of the firmware. Ergo, the required firmware would not be downloadable. Would that make the driver satisfy your definition of free software? If I download an ICQ client, there are lots of reasons I might find it useful: I might not have anything to say, or I might have no network connection, or I might have no friends to talk to. Debian is not responsible for providing me with creativity, connectivity, or friends. We require licenses to allow inhabitants of a desert island to exercise all their DFSG rights even though they live on a desert island. We should not accept software that becomes useless when used on a desert island. I think the example provided elsewhere in this thread -- that we'd never say an ICQ client Depends: icq-server -- is excellent. We'd also never mark something Depends: bios, because the BIOS is essential and assumed to be present. I think it merely illustrates that Depends is not the be-all or end-all of dependencies. Michael Poole
Re: LCC and blobs
On Thu, Jan 06, 2005 at 01:54:19PM -0500, Brian Thomas Sniffen wrote: aren't equivalent. The issue at hand is whether somebody might ever download software from Debian and find it useless without additional software which he could download... but not from Debian, since it's not Free and not packaged. I agree that this is the important part: if there's a piece that should be distributed by Debian for some package to use, and the only reason it's not is because it's non-free or not redistributable, and it'd be Depended on if it was packaged, it's a dependency. It doesn't matter which CPU that piece of data gets executed on (that's a very brittle metric). The idea of sticking firmware on some remote server and wgetting it is a fairly transparent case of ignoring and sidestepping the SC. On the other hand, the case of AIM clients that need to handle CRC requests from the server to verify themselves proxying these requests to some remote server (to avoid having to actually access the data) doesn't intuitively feel wrong. I'm not sure why, though. (Maybe it's because it's a legitimate way to work around blatent copyright abuse, so it gets more slack than blatent SC evasion; but I can't put my finger on any tangible difference in these cases, and maybe there isn't one.) -- Glenn Maynard
Re: LCC and blobs
On Thu, Jan 06, 2005 at 02:42:50PM -0500, Michael Poole wrote: Brian Thomas Sniffen writes: No. Firmware resident in RAM but put there by, say, the BIOS is fine. We've elected not to ignore firmware which is to be handled and installed by Debian software. You're having trouble making a coherent position out of this only because you keep recasting it in terms which aren't equivalent. The issue at hand is whether somebody might ever download software from Debian and find it useless without additional To nitpick: somebody might ever is backwards. We don't care if somebody might ever find the software useless; what we care about is whether everybody will find it useless. Stuff goes in main as long as somebody can use it (for some reasonable value of use, eg. not including Marco's contrivances that would imply the elimination of contrib entirely). software which he could download... but not from Debian, since it's not Free and not packaged. Why do you insist on the downloadable part of useless without additional software which he could download? I see no basis for that qualification in the DFSG or policy. I could manufacture a device Well, all software is downloadable (if not necessarily easily or legally), so I think that word is a no-op. I think the focus, here, is since it's not Free and not packaged: there seems to be a violation of SC#1 if the data should be included in the package for its basic use, but isn't for legal/freeness reasons. We require licenses to allow inhabitants of a desert island to exercise all their DFSG rights even though they live on a desert island. We should not accept software that becomes useless when used on a desert island. Extending the desert island test in this way isn't useful. If you're on a desert island, an ICQ client (and a mail client, and bittorrent, and lots of other things) isn't useful to you, even if you have a server to connect to. The desert island test is about being able to execute freedoms in a vacuum; let's leave it there. -- Glenn Maynard
Re: LCC and blobs
Glenn Maynard writes: On Thu, Jan 06, 2005 at 02:42:50PM -0500, Michael Poole wrote: Brian Thomas Sniffen writes: No. Firmware resident in RAM but put there by, say, the BIOS is fine. We've elected not to ignore firmware which is to be handled and installed by Debian software. You're having trouble making a coherent position out of this only because you keep recasting it in terms which aren't equivalent. The issue at hand is whether somebody might ever download software from Debian and find it useless without additional To nitpick: somebody might ever is backwards. We don't care if somebody might ever find the software useless; what we care about is whether everybody will find it useless. Stuff goes in main as long as somebody can use it (for some reasonable value of use, eg. not including Marco's contrivances that would imply the elimination of contrib entirely). Anyone with a copy of the firmware and the device being driven may of course use the driver, although I suspect you define that as unreasonable. The ambiguity of use is perhaps why the SC does not define free software or dependency with that term. software which he could download... but not from Debian, since it's not Free and not packaged. Why do you insist on the downloadable part of useless without additional software which he could download? I see no basis for that qualification in the DFSG or policy. I could manufacture a device Well, all software is downloadable (if not necessarily easily or legally), so I think that word is a no-op. I think the focus, here, is since it's not Free and not packaged: there seems to be a violation of SC#1 if the data should be included in the package for its basic use, but isn't for legal/freeness reasons. The legal reason applies much more to AIM than to Debian. The freeness issues are where we disagree: I consider the firmware to be part of the (inherently non-DFSG-free) hardware; you want to treat it as related only to the driver. The ICQ server is not free and not packaged. Why does it get a pass? We require licenses to allow inhabitants of a desert island to exercise all their DFSG rights even though they live on a desert island. We should not accept software that becomes useless when used on a desert island. Extending the desert island test in this way isn't useful. If you're on a desert island, an ICQ client (and a mail client, and bittorrent, and lots of other things) isn't useful to you, even if you have a server to connect to. The desert island test is about being able to execute freedoms in a vacuum; let's leave it there. I cited an example (which you snipped) where an IM program is useful in such a vacuum. None of the DFSG require that the general public be able to use the software -- it is such a fundamental right that it is assumed -- but you want to leave this isolated user with software that will not work as designed. Michael Poole
Re: Hypothetical situation to chew on
On Wed, 5 Jan 2005 23:48:40 +, Andrew Suffield [EMAIL PROTECTED] wrote: On Wed, Jan 05, 2005 at 01:36:46PM -0800, Michael K. Edwards wrote: The classical forms of intellectual property -- copyright, patent, trademark, and trade secrets -- were developed to protect very different kinds of intangible assets. That's a myth, spread by a propaganda campaign run by large corporations over the past few decades. They want people to believe it so that they can claim moral authority for the continued protection of these assets. With regard to developments in the last two decades, extending the life and scope of existing copyrights in a way that benefits only a few corporate owners of entertainment properties, I largely agree. But I think you present a somewhat one-sided view of the European history of abstract property rights, and by implication of 19th and most of 20th century US and world history in this area as well. I'm no historian (and no lawyer), but I don't think the record's hard to read. At least in England and its colonies, the creation of statutory property rights in commercial applications of knowledge has fairly consistently been an improvement over the previous practice. There have been periods of backsliding and regulatory capture (as we face in the US today), but legislators and judges have generally done a better job of keeping an eye on the public interest than ministers and guilds. Granting limited protection to commercial enterprises involving originality, inventiveness, quality assurance, and organizational mastery is good public policy -- as long as the public interest is served by the encouragement of creative efforts, the eventual release of knowledge into the public domain, and reliable access to high-quality goods at reasonable prices. If the current state of law about software consistently fails these public interest criteria (as I believe it does), then perhaps we need new and better law, not anarchy. [snip] This process culminated in 1710, with the enactment of the Statute of Anne in the UK, marking the first form of copyright as we know it today. It permitted anybody to print anything, with certain restrictions designed to protect the revenue stream of the publishers (essentially the ones we have now, time limit 28 years). ... [snip] ... and was enacted in an environment where previously no property right in ideas or expression was widely recognized, and the only recourse available to authors was to demand that their authorized publisher seek enforcement of the limits of the royal grant on other publishers. See Donaldson v. Beckett 1774 (http://www.copyrighthistory.com/donaldson.html ), and in particular Lord Camden's review of the legal history of printing prior to the Statute of Anne. While I find Lord Camden's assessment that Glory is the reward of science, and those who deserve it, scorn all meaner views rather overblown, he puts the case well that no property right in authorship of a work once published could be found prior to 1710. Copyright was not designed to protect assets. It was designed to take them away. Rights of authors did not enter into it, nor was there any 'trade' of rights between publishers and the people (another popular myth). The purpose of copyright in its modern form was to grant the people the right to copy works, which they did not previously have. That just doesn't fit the history. The Statute of Anne created a legal foundation for an automatic exclusive right of publication, something that was previously subject to the whim of royal ministers. This right was transferable (and generally transferred) from author to publisher. To protect other publishers from inadvertent violation, a copyright registry was established. To protect the public from monopolistic price gouging, a judicial price review mechanism was detailed. To preserve public access to knowledge in the long run, copyright was made to expire after a maximum of 28 years from first publication, and to give authors a shot at an upside for works of lasting interest (and a second chance with another publisher if the first one didn't generate demand), copyright reverted to the author after 14 years, forcing a renegotiation of terms. The system was far from perfect, but it succeeded in creating a statutory property right where previously there existed only executive prerogative. It didn't so much grant or deny anyone the right to copy works; it recognized authors as the moral owners of their works, and granted them the right to authorize a particular publisher to make copies, within constraints motivated by public policy considerations. [snip] Patents follow a fairly similar story; they began as monopolies on a certain trade, prohibiting anybody else from competing with a specified person, this time created by the state rather than the churce, as a method of raising funds. Widespread abuse led to them being locked down in 1624 by the Statute of
Re: More mmcache concerns
* Elizabeth Fong: So... I guess the question is, what _can_ we do? How much code are we talking about? Perhaps a clean room reimplementation is the cheapest solution.
Re: More mmcache concerns
On Thu, Jan 06, 2005 at 11:14:45AM +, Andrew Suffield wrote: On Wed, Jan 05, 2005 at 07:57:12PM -0800, Elizabeth Fong wrote: Jonathan Oxer: The big question though (and this is where legal advice may be required) is what happens to copyright when the copyright owner ceases to exist? It is auctioned off by the liquidators, along with all other property of the defunct company. Somebody probably owns it. Probably somebody with no conception of what they own (things of little or no value are usually auctioned in large batches just to get rid of them). You'll also probably never find out who, unless it gets acquired by a litigation company (like SCO). In the unlikely event that nobody bought it, the details vary with jurisdiction. For example, in the UK, it would revert to the crown (I think). According to copyright law the copyright for works made for hire exists for 95 years from the date of publication or 120 years from the date of creation, whichever is shorter. It's considered work for hire so unless he had a contract with Turcksoft to the contrary he is *not* the copyright holder. So... I guess the question is, what _can_ we do? Wait about a century for copyright to expire and hope that it doesn't get extended again. Or convince someone (quite possibly the origional author) that it is worth their time to re-implement it. Doing work for hire means you don't own that copy, but it is in no way a prohibition against you making another copy on your own time, even if it were to look almost completely identical. That whole origional authorship defense, after all (which is why so many companies use NDAs, non-compete agreements, the infamous We own your firstborn and any code you write on your own time clause, and other such to try to protect themselves from you writing a duplicate work in your own time, at home, based on the experience you gained while they paid you to develop it). Whether it IS worth it or not... that's another question entirely. :) -- Joel Aelwyn [EMAIL PROTECTED] ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Non-free files in source packages?
* Lewis Jardine: In the case of data tables, in many jurisdictions, a mere collection of facts is not copyrightable; the classic example is a telephone directory (everything in it is an uncreative fact; that there are thousands of them, which may have taken a lot of effort to gather, is immaterial). Databases are already copyrighted in many jurisdictions. AFAIK, this is also on the agenda of U.S. lawmakers.
Re: AROS License DFSG ok?
Gürkan Sengün [EMAIL PROTECTED] writes: Is the AROS license DFSG ok? http://www.aros.org/license.html Likely problems: 8.2. If You initiate litigation by asserting a patent infringement claim (excluding declatory judgment actions) against Initial Developer or a Contributor (the Initial Developer or Contributor against whom You file such action is referred to as Participant) alleging that: (a) such Participant's Contributor Version directly or indirectly infringes any patent, then any and all rights granted by such Participant to You under Sections 2.1 and/or 2.2 of this License shall, upon 60 days notice from Participant terminate prospectively, unless if within 60 days after receipt of notice You either: (i) agree in writing to pay Participant a mutually agreeable reasonable royalty for Your past and future use of Modifications made by such Participant, or (ii) withdraw Your litigation claim with respect to the Contributor Version against such Participant. If within 60 days of notice, a reasonable royalty and payment arrangement are not mutually agreed upon in writing by the parties or the litigation claim is not withdrawn, the rights granted by Participant to You under Sections 2.1 and/or 2.2 automatically terminate at the expiration of the 60 day notice period specified above. Some people believe that this kind of termination clause violates the DFSG. (b) any software, hardware, or device, other than such Participant's Contributor Version, directly or indirectly infringes any patent, then any rights granted to You by such Participant under Sections 2.1(b) and 2.2(b) are revoked effective as of the date You first made, used, sold, distributed, or had made, Modifications made by that Participant. I read this as meaning that a lawsuit claiming any patent infringement by a Participant not related to the software terminates the patentee's license, which seems unreasonable. The relationship of 8.2(a) and 8.2(b) is ambiguous; it seems to only make sense if you assume the appropriate conjunction is or, but it would be good to get a clarification. Michael Poole
Re: More mmcache concerns
Hi Florian, How much code are we talking about? Perhaps a clean room reimplementation is the cheapest solution. Unfortunately a non-trivial amount (about 15k lines), and not simple code either - it's pretty tightly written, and it requires an intimate knowledge of the internal workings of the Zend engine. A number of people have looked at it in the past and decided it was way beyond them. I don't expect there would be many people capable of writing anything similar (which is no doubt why Zend hired Dmitry away!). Cheers :-) Jonathan Oxer
Re: AROS License DFSG ok?
* Michael Poole: [something close to the anti-patent clause from the MPL] Some people believe that this kind of termination clause violates the DFSG. But this is not specific to the AROS License, it's inherited from the MPL (although I haven't compared the licenses word-for-word).
Re: AROS License DFSG ok?
Florian Weimer writes: * Michael Poole: [something close to the anti-patent clause from the MPL] Some people believe that this kind of termination clause violates the DFSG. But this is not specific to the AROS License, it's inherited from the MPL (although I haven't compared the licenses word-for-word). I did not compare it word-for-word either. I have said before that I think that termination clause (as opposed to the second one) is a reasonable mechanism for dealing with software patents; I mentioned it only to save the trouble of someone else pointing it out separately. Michael Poole
Re: LCC and blobs
On Jan 06, Josh Triplett [EMAIL PROTECTED] wrote: An ICQ client wouldn't Depends: icq-server; it might Suggests: icq-server, but that's OK. A driver might at most Suggests: burned-in-firmware-for-reflashing, but it would Depends: or at a minimum Recommends: firmware-loaded-by-driver. I can't see how you did come to these conclusions. We all understand what Depends:, Recommends:, and Build-Depends mean; we Not if they refer to things which are not debian packages. -- ciao, Marco signature.asc Description: Digital signature
Re: Non-free files in source packages?
Lewis Jardine [EMAIL PROTECTED] writes: In the case of data tables, in many jurisdictions, a mere collection of facts is not copyrightable; the classic example is a telephone directory (everything in it is an uncreative fact; that there are thousands of them, which may have taken a lot of effort to gather, is immaterial). It may be the case that the data could be plucked from the RFC and freely distributed, albeit only in places that don't allow 'sweat of the brow' copyrights. I know I answered this already, but I thought I'd add that [EMAIL PROTECTED] suggested that the tables from RFC 3454 might not be copyrightable, because they lack the creativity required for copyright. So to take the example of libidn, which extract tables from 3454, this could mean it could stay in Debian anyway, I think. They mentioned 'sweat of the brow' though. Which jurisdictions allow for that kind of copyright? Do Debian worry about those jurisdictions? Thanks, Simon
Re: LCC and blobs
Michael Poole wrote: Glenn Maynard writes: On Thu, Jan 06, 2005 at 02:42:50PM -0500, Michael Poole wrote: Brian Thomas Sniffen writes: software which he could download... but not from Debian, since it's not Free and not packaged. Why do you insist on the downloadable part of useless without additional software which he could download? I see no basis for that qualification in the DFSG or policy. I could manufacture a device Well, all software is downloadable (if not necessarily easily or legally), so I think that word is a no-op. I think the focus, here, is since it's not Free and not packaged: there seems to be a violation of SC#1 if the data should be included in the package for its basic use, but isn't for legal/freeness reasons. The legal reason applies much more to AIM than to Debian. The freeness issues are where we disagree: I consider the firmware to be part of the (inherently non-DFSG-free) hardware; you want to treat it as related only to the driver. The ICQ server is not free and not packaged. Why does it get a pass? If the ICQ server were packaged in the Debian non-free section, would you make ICQ clients Depends: or Recommends: on the ICQ server? If not, then if the ICQ server were packaged, the ICQ client would still be in main. Therefore, the ICQ client can be in main. In general, Debian doesn't make clients for a network protocol depend on servers for that protocol. I think that's a perfectly reasonable policy, given that you could run the server elsewhere, not on the local machine. Similarly, consider if the firmware were packaged in non-free. If the device didn't require the driver to load firmware, the driver would at most Suggests: firmware, and could go to main. If the driver must load the firmware, the driver Depends: or Recommends: firmware, so the driver can't be in main. If we don't use a mechanism similar to this, then we end up in a situation where if the firmware becomes distributable, ends up in Debian, and the driver can then express proper dependencies, the driver would have to move to contrib. That would make no sense. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: LCC and blobs
Josh Triplett writes: If the ICQ server were packaged in the Debian non-free section, would you make ICQ clients Depends: or Recommends: on the ICQ server? If not, then if the ICQ server were packaged, the ICQ client would still be in main. Therefore, the ICQ client can be in main. A, ergo B, ergo A. In general, Debian doesn't make clients for a network protocol depend on servers for that protocol. I think that's a perfectly reasonable policy, given that you could run the server elsewhere, not on the local machine. How can I run an ICQ server? Until the answer is install this package from Debian, I believe that the only way to interpret the DFSG consistent with your argument is to move the ICQ client to contrib. Similarly, consider if the firmware were packaged in non-free. If the device didn't require the driver to load firmware, the driver would at most Suggests: firmware, and could go to main. If the driver must load the firmware, the driver Depends: or Recommends: firmware, so the driver can't be in main. This establishes at most an indirect dependency on the firmware: The driver depends on the device which depends on the firmware. Since Debian cannot express the second dependency, you insist that it express driver depends on firmware. You inconvenience the owner of the device simply because their device has a certain characteristic. This is identical to the ICQ case: The client depends on the server (service) which depends on the server (software). Debian cannot express the second dependency, so following your approach, we must insist client software depends on server software. If we don't use a mechanism similar to this, then we end up in a situation where if the firmware becomes distributable, ends up in Debian, and the driver can then express proper dependencies, the driver would have to move to contrib. That would make no sense. Many things which are not true make no sense. Michael Poole
Re: LCC and blobs
Marco d'Itri wrote: On Jan 06, Josh Triplett [EMAIL PROTECTED] wrote: An ICQ client wouldn't Depends: icq-server; it might Suggests: icq-server, but that's OK. A driver might at most Suggests: burned-in-firmware-for-reflashing, but it would Depends: or at a minimum Recommends: firmware-loaded-by-driver. I can't see how you did come to these conclusions. I'll assume for the moment you are only disagreeing with the driver-firmware dependencies, not the client-server dependencies, since the latter is standard Debian policy. If the firmware we have packaged in non-free comes standard on the device, then the driver does not need a copy of the firmware, so it does not have a dependency on it. It is also possible that the driver might Suggests: the firmware, for use in the situation you have previously suggested in which the user might want an alternate firmware. However, the driver package certainly doesn't need the user to install the firmware in order to run. On the other hand, if the driver must load the firmware, then the driver cannot correctly function if the firmware is not present, so the driver should Depends: the firmware. I also included the possibility of Recommends:, for the situation you have previously proposed in which the user doesn't want the version Debian packages; I would tend to argue, however, that there is no difference between that and wanting another version of any other packaged software in Debian. In any case, I think that the loosest dependency that makes sense is the definition of Recommends from Policy 7.2: The `Recommends' field should list packages that would be found together with this one in all but unusual installations.. We all understand what Depends:, Recommends:, and Build-Depends mean; we Not if they refer to things which are not debian packages. I'm saying that from the perspective of checking the dependencies of a package in main, we should treat anything that is too non-free for non-free as identical to things packaged in non-free. Otherwise, we end up in the absurd situation in which if the non-free item becomes distributable (slightly less non-free) and someone packages it in non-free, such that the driver can then properly express its dependencies, the driver suddenly needs to go to contrib. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Questions about legal theory behind (L)GPL
The only form in which the GPL can be read as requiring any conduct from licensees (such as the provision of copies of source code on demand and the extension of the GPL to the licensee's copyright in derived works) is as an offer of (bilateral) contract, duly accepted by the licensee, in return for valid consideration. If anyone can cite legal precedent to the contrary, now would be a good time to mention it; [EMAIL PROTECTED] doesn't seem to have any to offer. Nathanael Nerode [EMAIL PROTECTED] wrote: [snip] I noticed something interesting on groklaw the other day (in http://www.groklaw.net/article.php?story=20041221062757984 ): In law school, first-year law students are taught that a contract is an exchange of promises: a promise for a promise ...As stated above, a contract is an exchange of promises. A glaring exception is gifts. Often, a promise to make a gift, with no return obligation whatsoever, is an enforceable contract. I think this clarifies the issue here. What we have been saying about not a contract was based on a, shall we say, first-year understanding of the law. The GPL is not necessarily an exchange of promises -- it may not have consideration. Perhaps, but the Groklaw article doesn't have much to say about this; it talks about donee beneficiaries as a category of third-party beneficiary, which doesn't apply to the parties to the GPL (presuming that acceptance is established). However, if the contract formed in the GPL isn't such an exchange, then it can only be one thing: a promise to make a gift. And presumably one of a variety which is an enforceable contract. To the extent that it purports to restrict the behavior of the offeree, it can be another thing: an illusory contract and hence unenforceable on the offeree. That's the conclusion that courts usually reach when consideration is not found. In any case, a gift is a transfer of ownership, and a non-exclusive copyright license is not; courts in the US have consistently declined to find implicit transfers of ownership or of the right to sub-license, and only a valid contract can bind a copyright holder to issue a license. As with most contracts, the terms of a non-exclusive license may be implied by conduct in the absence of a clear written agreement (see, e. g., Foad v. Musil Govan Azzalino at http://caselaw.lp.findlaw.com/data2/circs/9th/9856017p.pdf ), or where the wording of the agreement is in conflict with principles of equity. However, at least in the US, transfer of copyright ownership is unusual in that it can only be done in writing and undivided, per courts' interpretation of the Copyright Act of 1976. (There was a doctrine of informal assignment under the 1909 Act -- see Self-Realization v. Ananda Church at http://laws.lp.findlaw.com/9th/9717407.html -- but the Ninth Circuit found in Effects v. Cohen that the 1976 Act required written assignment.) (Interestingly, the Foad v. Musil decision contains an opinion by Kozinski, concurring in the result but not in the reasoning, which comes closer to articulating a form of copyright license not governed by state contract law than anything else I have read. Unfortunately for the FSF, the authority cited by Kozinski (Corbin on Contracts) defines this type of implied contract as created otherwise than by assent and without any words or conduct that are interpreted as promissory -- hardly applicable to the GPL. Kozinski reads this type of implied license into the Effects v. Cohen decision, but only as a matter of opinion and not of precedent.) For a case in which the court further limited the scope of implicitly granted rights, finding that an exclusive license does not automatically convey the full ownership rights associated with a copyright assignment, see Gardner v. Nike 2002 ( http://caselaw.lp.findlaw.com/data2/circs/9th/0056404p.pdf ) and the Second Circuit's similar decision in Morris v. Business Concepts 2001 ( http://caselaw.lp.findlaw.com/data2/circs/2nd/007509.html ; subsequently modified in http://caselaw.lp.findlaw.com/data2/circs/2nd/007509v2.html ). See also Walthal v. Corey Rusk 1999 ( http://laws.lp.findlaw.com/7th/981659.html ), in which the Seventh Circuit found that a grant of license with no explicit term was terminable at will under Illinois law, in contradiction to the Ninth Circuit's ruling in Rano v. Sipa Press 1993. [snip] If you do X (distribute binaries) you must do Y (redistribute source) seems like a fairly normal conditional-promise formula to me. It may look like it, but it really has an odd difference. If you do X (which I am giving you a license to do, and you may not do otherwise), you must also do Y (which I am giving you a license to do, and you may not do otherwise). There's a reason I used the analogy of You may walk on my property, provided you walk barefoot. It's different from You may walk on my property, provided you give me five dollars. Despite the formulation, it actually
Re: Questions about legal theory behind (L)GPL
On Thu, Jan 06, 2005 at 05:19:04PM -0800, Michael K. Edwards wrote: The only form in which the GPL can be read as requiring any conduct from licensees (such as the provision of copies of source code on demand and the extension of the GPL to the licensee's copyright in derived works) is as an offer of (bilateral) contract, duly accepted by the licensee, in return for valid consideration. If anyone can cite legal precedent to the contrary, now would be a good time to mention it; [EMAIL PROTECTED] doesn't seem to have any to offer. While there are elements of this argument which are jurisdictional in nature, it's false for many jurisdictions. More specifically, the GPL doesn't impose any restrictions on the actions of the copyright holder. You'd have to conflate copies of the program with the copyright holder to imagine that the GPL had anything to say about what the copyright holder will do. At the point which someone else has received a legal copy of some GPLed software, they have received all the GPL rights. No further action is required on the part of the copyright holder, unless it's something built into the copyright law for the jurisdiction in question. -- Raul
Re: AROS License DFSG ok?
Michael Poole wrote: Gürkan Sengün [EMAIL PROTECTED] writes: Is the AROS license DFSG ok? http://www.aros.org/license.html Likely problems: 8.2. If You initiate litigation by asserting a patent infringement claim (excluding declatory judgment actions) against Initial Developer or a Contributor (the Initial Developer or Contributor against whom You file such action is referred to as Participant) alleging that: (a) such Participant's Contributor Version directly or indirectly infringes any patent, then any and all rights granted by such Participant to You under Sections 2.1 and/or 2.2 of this License shall, upon 60 days notice from Participant terminate prospectively, unless if within 60 days after receipt of notice You either: (i) agree in writing to pay Participant a mutually agreeable reasonable royalty for Your past and future use of Modifications made by such Participant, or (ii) withdraw Your litigation claim with respect to the Contributor Version against such Participant. If within 60 days of notice, a reasonable royalty and payment arrangement are not mutually agreed upon in writing by the parties or the litigation claim is not withdrawn, the rights granted by Participant to You under Sections 2.1 and/or 2.2 automatically terminate at the expiration of the 60 day notice period specified above. Some people believe that this kind of termination clause violates the DFSG. This particular termination clause is less problematic than most: it only terminates your rights to the software if you sue *claiming that the software infringes your patent*. Most of the termination clauses people have problems with terminate your rights for any patent-related suit, not necessarily related to the software; for example, clause (b) below. :) (b) any software, hardware, or device, other than such Participant's Contributor Version, directly or indirectly infringes any patent, then any rights granted to You by such Participant under Sections 2.1(b) and 2.2(b) are revoked effective as of the date You first made, used, sold, distributed, or had made, Modifications made by that Participant. I read this as meaning that a lawsuit claiming any patent infringement by a Participant not related to the software terminates the patentee's license, which seems unreasonable. This clause does indeed seem to terminate your patent license from that one participant if you sue that participant over any patent, which is far stronger than the previous clause, and possibly problematic (though still better than clauses that terminate the copyright license). I think (a) is not a problem at all, but (b) might be. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: AROS License DFSG ok?
Scripsit Gürkan Sengün [EMAIL PROTECTED] Is the AROS license DFSG ok? http://www.aros.org/license.html In addition to the patent termination, I don't thinkt this is a free condition: | 3.2. Availability of Source Code. | Any Modification which You create or to which You contribute must be | made available in Source Code form under the terms of this License | either on the same media as an Executable version or via an accepted | Electronic Distribution Mechanism to anyone to whom you made an | Executable version available; and if made available via Electronic | Distribution Mechanism, must remain available for at least twelve | (12) months after the date it initially became available, or at | least six (6) months after a subsequent version of that particular | Modification has been made available to such recipients. You are | responsible for ensuring that the Source Code version remains | available even if the Electronic Distribution Mechanism is | maintained by a third party. And regardless of freedom, Debian's mirror network cannot comply with this condition, so it would seem that it cannot even go into non-free, unless absolutely no upstream changes are necessary (in which case security updates would still be impossible). -- Henning Makholm What has it got in its pocketses?
Re: LCC and blobs
Michael Poole wrote: Josh Triplett writes: If the ICQ server were packaged in the Debian non-free section, would you make ICQ clients Depends: or Recommends: on the ICQ server? If not, then if the ICQ server were packaged, the ICQ client would still be in main. Therefore, the ICQ client can be in main. A, ergo B, ergo A. Please explain why you think my argument is circular. I have argued that: (1) If the ICQ server were packaged in non-free, we still wouldn't make the client Depends:, Recommends:, or Build-Depends: on the server, and therefore in that situation the ICQ client could be in main. (2) For the purposes of deciding if software can be in main in the presence of possible unexpressed dependencies on external too free for non-free software, we should take the same actions we would if the non-free software were packaged in non-free and the dependencies were expressed. (3) As a concrete instance of (2), for the purposes of deciding if an ICQ client can be in main in the presence of possible unexpressed dependencies on an ICQ server, we should take the actions we would if the server were packaged in non-free. By (1), that action would be to leave the ICQ client in main. Therefore we should leave the ICQ client in main. In general, Debian doesn't make clients for a network protocol depend on servers for that protocol. I think that's a perfectly reasonable policy, given that you could run the server elsewhere, not on the local machine. How can I run an ICQ server? Until the answer is install this package from Debian, I believe that the only way to interpret the DFSG consistent with your argument is to move the ICQ client to contrib. Right now, we don't require clients to Depends:, Recommends:, or Build-Depends: on servers. Similarly, consider if the firmware were packaged in non-free. If the device didn't require the driver to load firmware, the driver would at most Suggests: firmware, and could go to main. If the driver must load the firmware, the driver Depends: or Recommends: firmware, so the driver can't be in main. This establishes at most an indirect dependency on the firmware: The driver depends on the device which depends on the firmware. Since Debian cannot express the second dependency, you insist that it express driver depends on firmware. You inconvenience the owner of the device simply because their device has a certain characteristic. Not at all. The driver uses the request_firmware interface to make hotplug supply the firmware, and the driver won't work unless the firmware exists. The hardware is designed to require the driver to load the firmware. It is the task of the driver to load this firmware, and the driver cannot perform this task with out the firmware. I don't believe there is any indirection there; the driver should Depends: firmware, and it only doesn't because the firmware isn't packaged. Are you disagreeing with my argument that the driver would Depends: firmware if the firmware were packaged, or are you disagreeing with the idea that we should treat the firmware too non-free for non-free case the same as the firmware packaged in non-free case for the purposes of deciding if the driver goes in main? This is identical to the ICQ case: The client depends on the server (service) which depends on the server (software). Debian cannot express the second dependency, so following your approach, we must insist client software depends on server software. Except that Debian doesn't express the first dependency either, even when it would be possible to do so. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Non-free files in source packages?
On Fri, Jan 07, 2005 at 12:10:18AM +0100, Florian Weimer wrote: * Lewis Jardine: In the case of data tables, in many jurisdictions, a mere collection of facts is not copyrightable; the classic example is a telephone directory (everything in it is an uncreative fact; that there are thousands of them, which may have taken a lot of effort to gather, is immaterial). Databases are already copyrighted in many jurisdictions. AFAIK, this is also on the agenda of U.S. lawmakers. As I understand it, Databases are protected by a separate EU directive, which provides different (although to some degree similar) protections to that afforded by copyright. Databases are *not* copyrightable in the same sense as a computer program or artistic work. - Matt signature.asc Description: Digital signature
Re: Hypothetical situation to chew on
Andrew Suffield wrote (in response to me): You imply that protecting intangible assets is an improvement, and that this was not done before, but neither of those are particularly accurate. No, I imply that an asset is a property right, and that the previous regimes didn't create property rights in abstract property -- at least as a matter of law, reasonably reliably and impartially. I consider that an improvement over anarchy and despotism, but YMMV. ... and was enacted in an environment where previously no property right in ideas or expression was widely recognized That's not accurate. You're dismissing the previous widely recognized property rights because they don't fit your notion of fair. That doesn't change the fact that they existed. They were just held by the publishers. No, I'm relying on legal historians' assessments of the regime prior to the Statute of Anne, in which the Stationers' Company (a cartel authorized by the Crown) exercised monopoly power and settled internecine squabbles via the Star Chamber. That's not my idea of widely recognized property rights, and was rejected as precedent by the Donaldson court. I refer you again to Lord Camden's eloquent summary in that case; he observes that the Statute of Anne was immediately preceded by some fourteen years of complete anarchy (or freedom if you like), and that publishers themselves brought with them their wives and children to excite compassion, and induce parliament to grant them a statutory security. (A real lawyer and historian's view may be found in William F. Patry's _Copyright_Law_and_Practice_; excerpt at http://digital-law-online.info/patry/patry2.html .) That just doesn't fit the history. The Statute of Anne created a legal foundation for an automatic exclusive right of publication, something that was previously subject to the whim of royal ministers. It did not do so in a vacuum. It replaced an existing system. It replaced anarchy following the lapse of the Stationers' Company's royal charter in 1694, which was preceded by royal prerogative and the 1681 bye-law of the Stationers' Company, preceded in turn by the Licensing Act of 1662 (focused on censorship rather than property rights). As Lord Camden pointed out with regard to the records of the Stationers' Company, Every man who printed a book no matter how he obtained it, entered his name in their books, and became a member of their company: then he was complete owner of the book. Owner was the term applied to every holder of copies; and the word 'author' does not occur once in all their entries. That's not a legal foundation, that's a cartel created at despotic whim. Ironically enough, trade secret is the only form of intellectual property that I cited which doesn't create an asset, in the sense that it doesn't create any tradable right like copyright or patent. Trade secrets are routinely traded in the US, by means of contracts and NDAs. No, the secrecy of trade secrets is maintained by means of these mechanisms. Like any other thing of value, unpublished knowledge may form part of a contractual exchange; but a tradable right in publicly disclosed knowledge, as created by copyright, patent, and trademark law, is a creature of statute, and trade secret law doesn't create such a thing. Personally, I find it sobering to realize that my livelihood depends on the continuation of these frail legal fictions, especially as I dislike some of the uses to which they are put. But you can always spot a legal fiction that is sufficiently well established to be taken for granted; people start calling it an inalienable right while it erodes all around them. (Does an indirect reference to Thomas Jefferson's slaveholding invoke a corollary to Godwin's Law?) Cheers, - Michael
Re: LCC and blobs
On Thu, 6 Jan 2005, Josh Triplett wrote: If the firmware we have packaged in non-free comes standard on the device, then the driver does not need a copy of the firmware, so it does not have a dependency on it. Hm? The driver does need a copy of the firmware. It needs a copy that is present on the device. Otherwise, we end up in the absurd situation in which if the non-free item becomes distributable (slightly less non-free) and someone packages it in non-free, such that the driver can then properly express its dependencies, the driver suddenly needs to go to contrib. And of course there's the absurd situation where a manufacturer decides to move firmware from a device from a ROM to a CD and Debian suddenly cannot provide a driver for it
Re: AROS License DFSG ok?
Scripsit Josh Triplett [EMAIL PROTECTED] (b) any software, hardware, or device, other than such Participant's Contributor Version, directly or indirectly infringes any patent, then any rights granted to You by such Participant under Sections 2.1(b) and 2.2(b) are revoked effective as of the date You first made, used, sold, distributed, or had made, Modifications made by that Participant. This clause does indeed seem to terminate your patent license from that one participant if you sue that participant over any patent, which is far stronger than the previous clause, and possibly problematic (though still better than clauses that terminate the copyright license). I think (a) is not a problem at all, but (b) might be. I tentatively think (b) is a DFSG problem if and only if the code in question is covered by a patent that we would otherwise worry about. -- Henning Makholm The Board views the endemic use of PowerPoint briefing slides instead of technical papers as an illustration of the problematic methods of technical communicaion at NASA.
Re: LCC and blobs
On Thu, 6 Jan 2005, Josh Triplett wrote: If the firmware we have packaged in non-free comes standard on the device, then the driver does not need a copy of the firmware, so it does not have a dependency on it. On Thu, Jan 06, 2005 at 06:21:52PM -0800, Ken Arromdee wrote: Hm? The driver does need a copy of the firmware. It needs a copy that is present on the device. The driver doesn't need the firmware .deb file. The driver doesn't even need to know whether any such file exists. For that matter, the driver doesn't need to know whether or not there are devices which have different firmware, no firmware or whatever. And of course there's the absurd situation where a manufacturer decides to move firmware from a device from a ROM to a CD and Debian suddenly cannot provide a driver for it Huh? Manufacturer releases some new piece of hardware (which doesn't work like the old hardware, even though it shares some hardware elements), and it's absurd that Debian can't provide a driver for it? How is this absurd? For that matter, how is that even the situation? Most likely, Debian IS able to provide a driver for it. Well, unless we can't figure out how to pull the firmware off that cd and feed it to the hardware. Most likely it's the new driver isn't exactly the same as the previous driver (because now the driver has to support downloading the firmware, and it didn't have to do that before). There's a significant chance that the new driver is in contrib (because it's your hypothetical example, so I'm presuming that that's what you're trying to make happen). But the only thing that's absurd is claiming that it's the same piece of hardware. If it was the same piece of hardware, the old driver would continue to work, and Debian would have no problem providing that driver. -- Raul
Re: LCC and blobs
Josh Triplett [EMAIL PROTECTED] writes: Michael Poole wrote: Josh Triplett writes: If the ICQ server were packaged in the Debian non-free section, would you make ICQ clients Depends: or Recommends: on the ICQ server? If not, then if the ICQ server were packaged, the ICQ client would still be in main. Therefore, the ICQ client can be in main. A, ergo B, ergo A. Please explain why you think my argument is circular. I have argued that: (1) If the ICQ server were packaged in non-free, we still wouldn't make the client Depends:, Recommends:, or Build-Depends: on the server, and therefore in that situation the ICQ client could be in main. (2) For the purposes of deciding if software can be in main in the presence of possible unexpressed dependencies on external too free for non-free software, we should take the same actions we would if the non-free software were packaged in non-free and the dependencies were expressed. Depends and Build-Depends are not necessarily the entirety of the Social Contract's idea of dependency. (3) As a concrete instance of (2), for the purposes of deciding if an ICQ client can be in main in the presence of possible unexpressed dependencies on an ICQ server, we should take the actions we would if the server were packaged in non-free. By (1), that action would be to leave the ICQ client in main. Therefore we should leave the ICQ client in main. Your argument is that the ICQ client does not depend on the ICQ server; therefore it is free and can go into main; therefore it does not depend on the ICQ server. In general, Debian doesn't make clients for a network protocol depend on servers for that protocol. I think that's a perfectly reasonable policy, given that you could run the server elsewhere, not on the local machine. How can I run an ICQ server? Until the answer is install this package from Debian, I believe that the only way to interpret the DFSG consistent with your argument is to move the ICQ client to contrib. Right now, we don't require clients to Depends:, Recommends:, or Build-Depends: on servers. We don't require drivers to Depends:, Recommends: or Build-Depends: on hardware, either. Similarly, consider if the firmware were packaged in non-free. If the device didn't require the driver to load firmware, the driver would at most Suggests: firmware, and could go to main. If the driver must load the firmware, the driver Depends: or Recommends: firmware, so the driver can't be in main. This establishes at most an indirect dependency on the firmware: The driver depends on the device which depends on the firmware. Since Debian cannot express the second dependency, you insist that it express driver depends on firmware. You inconvenience the owner of the device simply because their device has a certain characteristic. Not at all. The driver uses the request_firmware interface to make hotplug supply the firmware, and the driver won't work unless the firmware exists. The hardware is designed to require the driver to load the firmware. It is the task of the driver to load this firmware, and the driver cannot perform this task with out the firmware. I don't believe there is any indirection there; the driver should Depends: firmware, and it only doesn't because the firmware isn't packaged. Are you disagreeing with my argument that the driver would Depends: firmware if the firmware were packaged, or are you disagreeing with the idea that we should treat the firmware too non-free for non-free case the same as the firmware packaged in non-free case for the purposes of deciding if the driver goes in main? I disagree that the driver would Depends: on the firmware. This is identical to the ICQ case: The client depends on the server (service) which depends on the server (software). Debian cannot express the second dependency, so following your approach, we must insist client software depends on server software. Except that Debian doesn't express the first dependency either, even when it would be possible to do so. We evidently agree on this point: Debian can express neither the dependency of the driver/client on the device/service nor the dependency of the device/service on the non-free software. As web applications and other distributed programs become more common, we will run into more and more problematic divisions between the two endpoints. I believe they should be treated consistently regardless of the communication bus between the Debian software and what it talks to. Michael Poole
Re: mozilla thunderbird trademark restrictions / still dfsg free?
Matthew Garrett [EMAIL PROTECTED] wrote: But we're also distributing files that the user can't modify without renaming, so I'm not entirely sure what the issue is. If Mozilla's /copyright/ license said You may not modify this without renaming it, unless you have a separate agreement with us, would you object to Debian having permission to call the code Mozilla? Would you object if we then distributed it under that name, even if our users didn't have permission to do so? Probably not. Is freedom to modify (or not) the software's name as essential as the freedom to modify (or not) the software itself? The problem here isn't a forced filename change or even a forced change: it's some restriction on edits allowed by a licence.
Re: mozilla thunderbird trademark restrictions / still dfsg free?
Gervase Markham [EMAIL PROTECTED] wrote: MJ Ray wrote: Are you sure? The graphics seem to have the words Firefox in them, which doesn't seem a permitted use of the trademark to me. The default build removes the trademarked logos (the fox-on-globe or the bird-on-envelope) but not the trademarked words. Just to be clear: are you saying that the logo graphic with a blue world (no fox) and the word Firefox is OK to use for any purpose? mozilla/dist is the built version of Mozilla. mozilla/other-licenses/branding shouldn't be pulled or built unless you've set MOZ_USE_OFFICIAL_BRANDING: [...] mozilla/other-licenses/branding is in the source tarball. I've no compelling reason to track mozilla CVS, as far as I know. If mozilla/dist/.../branding is the built version, where is it built from? Amusingly, the About FireWWW box says it is copyright contributors, but pressing the credits button displays a box empty apart from FireWWW \n The browser, reloaded. [...] If you wait, it scrolls - or it should do. There are also more contributors at about:credits. Oh yes, so it does. The mozilla compile must have been slowing that machine down a bit...
