Re: Bug#278940: ITP: socket++ -- lightweight convenience library to handle low level BSD sockets in C++
On Sat, 30 Oct 2004 21:49:42 -0400 Dan Weber wrote: The new upstream (Herbert) is placing this in the LICENSE file as of the next release which will clarify for other distributions and packagers. This is great news, indeed. Obviously, the new upstream must make sure that each copyright holder agrees on this clarification... -- 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 pgphOww0CO8q2.pgp Description: PGP signature
Re: firmware status for eagle-usb-*
[EMAIL PROTECTED] wrote: On Fri, Oct 29, 2004 at 11:07:14AM +0200, Marco d'Itri wrote: Hardware is not part of Debian, and the fact that Debian depends on non-free pieces of hardware has never been considered to violate any of the above. (And, as I've said a few times, stuff tucked away in an EPROM acts like part of the hardware.) And every time you failed to explain why software magically is not software anymore when stored on a flash EPROM. By that logic, the same piece of data stored on an involatile ROM (that the driver can't upload at all) is also to be considered software. It's non-free and we require it--I guess we should just give up! Yes, sure! If some stream of bits is considered software when stored in RAM then I can't see why it should not be software anymore when stored in some other media. I have not seen any convincing argument about why software should lose its nature if stored in ROM. If the conseguences of this are that some interpretations of the policy or social contract are inconsistent then maybe you should start considering that they may really be, after all. Looks like hardware, acts like hardware. To me, it looks like software stored in hardware. Of course, it's a boundary case--it's neither strictly hardware nor software. Really? I think it's quite clear. That's where the word firmware comes from in the first place, and that's why there's disagreement on it--for things which are unambiguously hardware (my printer) and things which are unambiguously software (/bin/ls), we have clear boundaries, but for things which are neither hardware nor software and yet both at the same time, things aren't so clear. I'm sorry, but the policy revisionists forced Debian to think that there is only software and they have been very clear about this. I can't see why this should matter. The driver implements a firmware loader, which is something useful in itself and is also the first element needed to develop a free firmware. All other functions of the driver are still available, but if the hardware is not willing to interact with it I can't see why this should impact the freeness of the driver. This isn't a question of whether the driver is free or not, it's a question of whether it goes in main or contrib. Yes, this is what I was talking about. I can't see the rationale behind this. If you agree that the hardware devices are beyond the dependency barrier then I do not understand why it matters if their firmware is provided by the manufacturer on a CD or a flash EPROM. I've already explained this. If it's on a CD, the driver depends on it to give to the device; the driver doesn't work unless you have the CD to get the firmware. In fact, if you don't have the CD, you might not be able to get the firmware at all, and you won't be able to use your device at all. The driver could upload /dev/zero as well, I don't think this is important. The firmware modifies the capabilities of the hardware device, not of the driver. I don't believe the theory about indirect dependencies has any foundament in the policy or the SC, or it would have to be applied to any kind of software interacting over any communication channel. BTW, if everything is software I can't see how that non-free data used for authentication is different from a password or SSL certificate used for authentication. This is irrelevant. Why? -- ciao, Marco
Re: mass bug filing for unmet dependencies
[EMAIL PROTECTED] wrote: On Fri, Oct 29, 2004 at 05:50:29PM +0200, Marco d'Itri wrote: So, following from this why you think that the motherboard firmware (the BIOS, which can be reflashed by users) or the CD reader firmware (which can be reflashed as well, with the right tools) and e.g. a modem firmware are different? You're asking why I think can be flashed, but works just fine without being flashed is different from won't work without being loaded? Fundamentally, the latter case forces us to not ignore it. The equipment won't work if we ignore the issue. So you say that non-free software is OK with you as long as you can pretend it's not there? Which part of the policy or SC justifies this theory? -- ciao, Marco
Re: Fwd: figlet license change from Artistic to Clarified Artistic or Artistic 2.0?
Note: lists.debian.org is refusing to allow me to subscribe: please forward this post. MJ Ray scripsit: Sublicensing means that you are still bound by the original licence, but you can offer any licence in the specified range to those you distribute to. Quite so, and I should have clarified that point. If Alice licenses a work to Bob under a sublicenseable license, and Bob sublicenses the same work or a derivative work to Charlie, then Charlie cannot receive from Bob under a license that contradicts Alice's license. In the case of the AFL, as of the MIT license, it is so permissive that it is almost impossible to contradict it. The wording in the AFL looks like the range of permitted sublicences consists of only the AFL, but maybe I misunderstood it. No, it permits sublicensing the work and derivative works under any license that doesn't contradict the AFL, since it would require particular words (as found in the OSL, the AFL's sibling license) to restrict it. The license need not even be a free license. So works under the AFL can be treated much like those under the BSD or MIT licenses. I have urged Larry to add explicit words under any license whatsoever to the next version of the AFL, to make the consequences of sublicenseability clear. By contrast, the MPL is also sublicenseable, but the Original Work and Modifications can only be sublicensed under the MPL itself. I'm surprised if the author of the AFL thinks it can be replaced by any licence, as that would seem to be a trivial way to defeat its overbroad patent termination. The AFL, being a contract, cannot and does not attempt to defend Licensor against patent lawsuits by third parties who are not licensees. I'd be interested to learn why you think the patent-termination language of the AFL 2.1 is overbroad. It says: This License shall terminate automatically and You may no longer exercise any of the rights granted to You by this License as of the date You commence an action, including a cross-claim or counterclaim, against Licensor or any licensee alleging that the Original Work infringes a patent. So it takes away Bob's right to use Alice's software if Bob claims that that very software infringes Bob's or Charlie's patent. I think you are right that it's an unusual practice for free software, though, but I'm not a lawyer. There's an awful lot of MIT-licensed and MPL-licensed software out there. Any of it can be sublicensed (with varying restrictions on the sublicense); whether it is or not, nobody knows. IANAL, TINLA. Glenn Maynard scripsit: For example, the choice of venue clause in the AFL doesn't exist in the GPL. If I receive a work under the AFL from John, integrate some code from gcc, and send the result to Bob, can Bob sue John without being bound by the choice of venue? If not, it's GPL-incompatible. How does sublicenseability help here? Of course, your distribution to Bob is under the GPL. The fact that Bob receives code that was originally licensed by John under the AFL doesn't make Bob a licensee of John. The only ways for Bob to become a licensee are to explicitly manifest his assent (in which case he is bound) or to do one of the things mentioned in AFL section 1 provided there is no other way to do those things. In fact, however, Bob can make and distribute copies and derivative works under the GPL license which he has from you. = To respond to a few points made by others: the fact that the AFL is a contract does not make it violate the Autocrat Test, since the licensee makes no promises under the AFL (it is a *unilateral* contract). The right to use, as well as all the copyright and patent rights, are explicitly granted. The only thing a licensee can't do is remove the copyright notices, which is also prohibited by many other free licenses. The OSI board definitely does analyze licenses themselves; the fact that the AFL's author has an institutional connection does not mean their judgment of his licenses is biased, any more than the fact that RMS has an institutional connection with the FSF means that the GPL and LGPL are not free licenses. All Figlet authors are within U.S. jurisdiction, or were at the time when they were authors. The claim that *all* authors must agree to a change of license must depend on some legal theory that I'm not aware of and that is not stated. We are dealing here with a single module that has been repeatedly patched, not with independently licensed modules (apart from the zip stuff, which is now out of the case). That seems to meet the U.S. statutory definition of joint authorship, by which any author can act unilaterally but is responsible to the other authors for the profits (not an issue here). -- John Cowan [EMAIL PROTECTED] www.reutershealth.com www.ccil.org/~cowan I am he that buries his friends alive and drowns them and draws them alive again from the water. I came from the end of a
Re: firmware status for eagle-usb-*
Marco d'Itri [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: On Fri, Oct 29, 2004 at 11:07:14AM +0200, Marco d'Itri wrote: Hardware is not part of Debian, and the fact that Debian depends on non-free pieces of hardware has never been considered to violate any of the above. (And, as I've said a few times, stuff tucked away in an EPROM acts like part of the hardware.) And every time you failed to explain why software magically is not software anymore when stored on a flash EPROM. By that logic, the same piece of data stored on an involatile ROM (that the driver can't upload at all) is also to be considered software. It's non-free and we require it--I guess we should just give up! Yes, sure! If some stream of bits is considered software when stored in RAM then I can't see why it should not be software anymore when stored in some other media. I have not seen any convincing argument about why software should lose its nature if stored in ROM. If the conseguences of this are that some interpretations of the policy or social contract are inconsistent then maybe you should start considering that they may really be, after all. How about when they're stored on paper? How about when they're burned into a different sort of persistent chip, like an FPGA? How about CAD/CAM instructions, once embodied in a manufactured device? Is my coffee mug still software? Looks like hardware, acts like hardware. To me, it looks like software stored in hardware. Of course, it's a boundary case--it's neither strictly hardware nor software. Really? I think it's quite clear. That's because you're not thinking about all the ramifications. That's where the word firmware comes from in the first place, and that's why there's disagreement on it--for things which are unambiguously hardware (my printer) and things which are unambiguously software (/bin/ls), we have clear boundaries, but for things which are neither hardware nor software and yet both at the same time, things aren't so clear. I'm sorry, but the policy revisionists forced Debian to think that there is only software and they have been very clear about this. No, actually. I was an active participant in those debates here, and you're completely misrepresenting both the wording and intention of those revisions. -Brian -- Brian Sniffen [EMAIL PROTECTED]
