Re: Request for IPR review
Quoting Branden Robinson [EMAIL PROTECTED]: On Tue, Nov 23, 2004 at 03:38:01PM -0500, Mark Johnson wrote: I've been asked to get some sort of review from the free software world of the new OASIS[1] IPR draft. I tried to review it myself, but the legalese is a bit on the opaque side for me. [...] Can anyone who is interested in reviewing the document please contact me? I'll send you the document for a quick review. Did anyone get in touch with you about this? Hi Branden, Yes, I did get a an initial response from MJRay and sent him the document. But am still waiting for some follow-up feedback on the document itself. Thanks, Mark -- G. Branden Robinson|It may be difficult to to determine Debian GNU/Linux |where religious beliefs end and [EMAIL PROTECTED] |mental illness begins. http://people.debian.org/~branden/ |-- Elaine Cassel Mark Johnson [EMAIL PROTECTED] Debian XML/SGML: http://debian-xml-sgml.alioth.debian.org Home Page:http://dulug.duke.edu/~mark/ GPG fp: DBEA FA3C C46A 70B5 F120 568B 89D5 4F61 C07D E242
Re: LCC and blobs
Hamish Moffatt [EMAIL PROTECTED] writes: On Thu, Dec 23, 2004 at 10:55:04PM -0500, Brian Thomas Sniffen wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: Great. Then the driver operates differently depending on the presence of additional software -- it needs a Linux kernel and the firmware. But then drivers also depend on additional softwares stored in flash EEPROMs in devices. That's not software. That's firmware, at best -- you can look at it as software, but then you don't get to distribute any drivers. It is also internally consistent to think of chips as hardware and distribute drivers appropriately. It is never consistent to think of files on disk as anything but software. Eh? The contents of EEPROMs are software just as much as the contents of CD-ROMs and hard disks. They are just different media for storing digital information. So if EEPROMs contain software, why don't [you] get to distribute any drivers? I don't understand. You can get software out of an firmware-EEPROM on a hardware device. I don't think it's appropriate to call that software as is, or in general. This line *could* be drawn in lots of places, but if you say that the contents of an EEPROM are software, then how about a one-shot PROM? How about a book with a print-out of the source code? The only reasonable place to draw the line, for Debian, is this: can Debian physically ship it in a useful way? For files on disk, the answer is yes. We are constrained only by the license. For the book or the PROM, the answer is no. For an EEPROM, in general, the answer is no. For any such correctly operating device, the firmware is already there. Debian can't usefully ship it. It would be interesting to try supporting an architecture to run on those devices instead of Wind River or whatever, but there isn't one now. Without either of those, it does not operate. This is a dependency. But then ICQ clients depend on non-free ICQ servers... Which might be software or hardware or undistributed or all sorts of things. The ICQ server isn't distributed in Debian, so why aren't the clients in contrib? This is an excellent parallel to the firmware situation. The ICQ clients don't depend on the ICQ server software. They depend on a compliant server. It might be a general-purpose computer running non-free software. It might be a specific hardware device. It might be a very fast monkey with a set of switches on an Ethernet cord. It could be anything. This is an abstraction barrier. It would be *nice* to have a free ICQ server-software in Debian. Similarly, we can treat a device with on-board firmware as an abstract device. It could be implemented in any way. But we can abstract over that and treat it as a device, and write a driver for it, and it works fine. It would be nice to have free firmware-software, and free HDL specs, and free board art, and a patent-free interface spec, and a pony. But none of these are dependencies. When the firmware has to be uploaded, it's a dependency. If it were just a magic initialization sequence, that would be OK -- such a sequence is presumably too short to copyright. But this is long and non-free, clearly software, and clearly a dependency. Perhaps if you could challenge the ICQ situation more clearly, I might believe a parallel challenge to on-board firmware. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Is the xdebug's non-free license necessary?
So can you say why it is a problem with my license, and not with Apache's and PHP's? Nobody is going to say that, because we think it's a problem with all those licenses. It was a problem with Apache's license. It was not noticed for a long time. Eventually it was noticed, and it was *fixed* in the Apache License 2.0. Debian-legal folks had a fair amount of input into that license, and it's certainly DFSG-free. Actually, you might be interested in it, particularly clause 6: 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. The PHP must not occur in the name business is still a problem with PHP, and I certainly think they should change their license for the same reason. sudo has the same unacceptable license. I think most of us have just been too tired to deal with *all* the badly-licensed stuff which is already in Debian at once; we hope to get to it eventually. Feel free to help! -- Now, this might make you feel better: In the US and all common-law countries, you have a trademark regardless of whether you register it; you get a trademark by using it in a trade. So Xdebug *is* your trademark already. Therefore people in common law countries aren't normally allowed to make products with confusingly similar names (like RealXdebug) -- *regardless* of what you put in your copyright license. :-) (On the other hand, products can legally use names like TeXDebug, UnofficialAddonsForXDebug, etc., which are *not* going to cause confusion.) Unfortunately, trademarks apparently don't work that way in civil law countries, and only arise through registration (with certain exceptions such as your own name). Even if registered, though, non-confusing uses (TeXDebug, UnofficialAddonsForXDebug) appear to be allowed in most countries. So this difference is probably why people in civil law countries want to write pseudo-trademarks into their copyright agreements often. However, it's still important to do this correctly: prohibiting *any* name containing Xdebug is significantly broader than any trademark (that I've heard of) allows, and that's why we don't like it. If the restrictions were equivalent to or less than ordinary trademark restrictions, I would consider them Free; but they're stronger. The other problem is that Debian packages routinely *are* derived works, since Debian maintainers often need to add patches; this sort of license doesn't allow them to use the same name as upstream without getting extra permission (or breaking the license, which is what the PHP packages are presumably doing; bugs should be filed). Hence my suggested alternative: require that any derived work make clear that it wasn't the original XDebug. I think that would effectively prohibit RealXDebug. XDebugPlus would be allowed but would have to have large prominent notices saying THIS IS NOT XDEBUG.
Re: LCC and blobs
Anthony DeRobertis [EMAIL PROTECTED] writes: Brian Thomas Sniffen wrote: That's not software. That's firmware, at best -- you can look at it as software, but then you don't get to distribute any drivers. It is also internally consistent to think of chips as hardware and distribute drivers appropriately. It is never consistent to think of files on disk as anything but software. Hmmm, I have a CF card. Upon it are files, and in every meaningful way it is a disk. Therefor, that data is software. Yet, CF is actually chips --- often the same chips as used to hold firmware distributed with hardware. Thus, it's all hardware. Sure. It's on a medium for software exchange, thus it's software. If it were an integral component of a device, it'd be hardware. I've never been confused when looking at such things; the closest case I've found to confusing is the MP3 player, which has its OS on disk. I'm inclined to say that it's software to the MP3 player, an architecture which Debian does not support. It's hardware, a drive, to the (Intel?) Debian-supported PC to which it's connected. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Draft summary of Creative Commons 2.0 licenses (version 2)
On Sat, 25 Dec 2004 17:09:38 -0500 Nathanael Nerode wrote: Consider adding the following to the summary under trademark restrictions: Debian-legal has contacted Creative Commons about this issue, since it seems to be trivial to fix, but has unfortunately received no response. Perhaps also add the following to the summary: We would really like to work with Creative Commons to make these two licenses DFSG-free; we hope that Creative Commons will be willing to work with us. Assuming you are referring to CC-by and CC-by-sa, aren't you? After that, I think we should declare it official. And send a copy to Creative Commons! Anyone disagree? I agree entirely. We should really do something about this odd situation. -- 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 pgpbWSllcpzSD.pgp Description: PGP signature
