Re: Debian-approved creative/content license?
Ken Arromdee wrote: On Sun, 11 Mar 2007, Francesco Poli wrote: In order to release the audio/video recording in a DFSG-free manner, they should release the source as well, as defined in the GNU GPL v2. Wonderful! That is a feature of the GPL, not a bug! Recipients should not be in a position of disadvantage with respect to original authors, or otherwise it's not really Free Software. It's a bug. If the original author puts a video under GPL and doesn't release the source, you can't demand it. He's not bound by the GPL since he can't violate the copyright on his own work, so he has no obligation to give you anything. So the result is that you can't demand source and can't distribute the work either. That doesn't give free software the least bit of benefit. The problem with source for audio or video files is that the source is much larger and much more awkward to distribute than the final result. It's plausible that the author doesn't care what you do with his work, but doesn't want to give you these files simply because it's a lot of trouble. If he then puts his work under GPL, he may not even realize that he's given you no permission to redistribute at all. Also, it's very possible that stuff no longer exists. I know that when I do an audio project (quite infrequently), once I'm satisfied with the result, I toss away all the intermediate stuff (audacity project files and the like) and only keep the finished (wav/mp3/whatever). signature.asc Description: OpenPGP digital signature
Re: [RFC]: firmware-ipw2200, acceptable for non-free?
Francesco Poli wrote: On Thu, 08 Mar 2007 15:34:32 -0500 Benjamin Seidenberg wrote: Francesco Poli wrote: [...] We would really love to be more permissive, but we cannot, 'cause that other evil guy forbids us. As I keep reading answers like this, I'm less and less convinced of their good faith... [...] For some companies I would agree, but as has been said, intel has been opensourcing a lot lately, And is getting good publicity for this: as a consequence, I think they should act likewise on other fronts... [...] For a lot of wifi cards (dunno about Intel's) it's regulatory - they can't sell cards that can be easily modified to exceed FCC limits, so they limit it in a binary firmware. If they gave away the source, people could easily modify the card to exceed the legal output power, and thus they can't give away source. This sounds like another cheap excuse: I cannot believe that the law really says that *Intel* is responsible if *I* modify an Intel WiFi card so that it exceeds regulatory limits... If there indeed is a law like this in some jurisdiction, well, the law should be changed ASAP. Intel should be able to sell easily-reprogrammable WiFi cards: if *I* modify one card and exceed regulatory limits, I should be seen as the *sole* responsible. Rules for transmitting devices certified under FCC part 15: FCC Rules, Part 15 section 15(b): (b) Except as follows, an intentional or unintentional radiator must be constructed such that the adjustments of any control that is readily accessible by or intended to be accessible to the user will not cause operation of the device in violation of the regulations. [...] A firmware setting in an open-source firmware would be considered to be readily accessible. Some other points to consider: Section 202: [...] Master devices marketed within the United States must be limited to operation on permissible Part 15 frequencies. Client devices that can also act as master devices must meet the requirements of a master device. For the purposes of this section, a master device is defined as a device operating in a mode in which it has the capability to transmit without receiving an enabling signal. [...] Which limits frequencies, but it's similar Section 203 specifically forbids allowing the user to change antennas (by saying it should be permanently attached or use a non-standard connector. This is for the same reasons. 204(a) says that [...] no person shall use, manufacture, sell or lease, offer for sale or lease (including advertising for sale or lease), or import, ship, or distribute for the purpose of selling or leasing, any external radio frequency power amplifier or amplifier kit intended for use with a Part 15 intentional radiator. I would think a firmware that boosts power beyond the part 15 limits would count as an amplifier kit, but I could be wrong. - Now, the reason why this is good: Imagine if someone could boost the power of their device at the click of a button. You'd get better performance, so anyone who is aware of it is likely to do it. (The likelihood of being caught is extremely low). So what happens? a.) Anyone who isn't using boosted wifi power is likely to lose the ability to use wifi as their signals are drowned out b.) The same happens for other part 15 devices on nearby frequencies (cordless phones, wireless mice, etc, etc) c.) The likelihood of exceeding RF radiation safty limits is increased, both for users and for people nearby. Remember, the airwaves are a public resource. While I agree with you that you should have the right to do with your equipment as you see fit in general, this conflict with my rights to enjoy a public resource and to use equipment I purchased legally. Since it is illegal to boost the power on these devices (or even use a higher-gain antenna), I think it's fully reasonable for the FCC to say something that is basically You can't put a switch on there between legal and illegal. HTH, Benjamin signature.asc Description: OpenPGP digital signature
Re: [RFC]: firmware-ipw2200, acceptable for non-free?
Francesco Poli wrote: On Thu, 8 Mar 2007 09:46:05 +1000 Kel Modderman wrote: On Thursday 08 March 2007 04:23, Francesco Poli wrote: [...] However, the license does not meet the DFSG (it's not even close to meeting them...): has Intel been contacted and asked to provide the firmware (with source code) in a DFSG-free manner (for instance, under the terms of the GNU GPL v2, or of the Expat/MIT license)? Intel has recently had some press coverage about their Free Software drivers for integrated graphics chips: I appreciated that move, maybe they are willing to get some more good publicity by freeing this firmware... Quoting from: http://intellinuxwireless.org/index.php?n=FAQs=license [quote] Q. The license for the binaries needed with the newer projects (ipw3945 and iwlwifi) seems much cleaner than the license for the ipw2100 and ipw2200. Can you change the terms of the older license? [ ipw2100 and ipw2200 specific ] A. Unfortunately, no. Those binaries contain intellectual property licensed from third parties, and Intel must follow certain contractual obligations in licensing for those components. The ipw3945 and iwlwifi related binaries are all Intel-developed, and we are able to use a simplified license for that product. [/quote] We would really love to be more permissive, but we cannot, 'cause that other evil guy forbids us. As I keep reading answers like this, I'm less and less convinced of their good faith... All this pointing fingers to unspecified third parties and passing the buck to them seems like a cheap excuse: if they managed to get permission to use the intellectual property (whatever that means) of some third parties, they are probably also able to get permission to disclose source code in a DFSG-free manner, as long as they really want to. After all, Intel has deep pockets, they could even pay enough money to obtain copyright transfer, if necessary... Disappointed. For some companies I would agree, but as has been said, intel has been opensourcing a lot lately, and as that FAQ says, later versions are free, which shows they must have some concern. For a lot of wifi cards (dunno about Intel's) it's regulatory - they can't sell cards that can be easily modified to exceed FCC limits, so they limit it in a binary firmware. If they gave away the source, people could easily modify the card to exceed the legal output power, and thus they can't give away source. signature.asc Description: OpenPGP digital signature
Re: BCFG Public License
Henning Makholm wrote: Scripsit Benjamin Seidenberg [EMAIL PROTECTED] Henning Makholm wrote: What does it even mean then? Which legal consequences does it have for me to acknowledge that law? Why would the licensor want me to do so - he must have _some_ purpose in requiring such an acknowledgement, which indicates that a laywerbomb must be present somewhere. I would be wary of using the software, because it is completely opaque what the catch is. It's to cover UChicago's ass. They want to make sure if someone distributes their software in a way that violates US export laws they can point at that license and say See! We warned them! It's not our fault Thay would be able to cover their asses just fine by simply informing the licensee that those laws exist. Lots of fine licenses do that. However, this clause does not simply inform about a fact. It requires the _licensee_ to do something, namely to agree. Some people in this threa claim that the action being required is not that of holding the same opinion as that of the export law, but one of acknowledging it. I don't even _know_ how to perform that action to the satisfaction of the court. If I am to communicate acknowledgement to the licensor, the software becomes postcardware and therefore non-free. By using the rights given to you by the license. Your use of the rights is contingent on acceptance of the terms of the license, thus by exercising those rights, your are demonstrating your acknowledgment. Think of the GPL. By distributing software under the GPL, you are acknowledging the terms of the GPL (SCO excluded) and you are then bound by them. This license just explicitly requires you to acknowledge a fact of US law, which you do by the act of distribution/modification. What I am saying is that if the author sues me with a claim that my copying was unautorized becaus I have not performed the act of agreeing that bla bla bla that was a condition of getting the license, how would I go about convincing the court that he is wrong and I did in fact do what the licensor wanted me to. (Assume here that I _know_ what it is that the licensor wanted me to, which I don't). At least I know what opinions I have. If Licensee agrees does not mean that I in fact agree, then I don't know how to tell whether I have acknowledged the law in a proper manner that allows me to use the license, or what it would mean for me to do so. Would you agree that there are bugs present in the Debian operating system? You may not like the fact (I know I don't), and you may not agree that they should be there, but I hope you can agree that they exist. It is true that there are bugs in Debian. That does not mean that a free license can require me to tell the licensor that. This was an example of the difference between the two types of 'agree', not saying a license should say that. Benjamin signature.asc Description: OpenPGP digital signature
Re: BCFG Public License
George Danchev wrote: On Sunday 30 July 2006 00:01, Stephen Gran wrote: --cut-- Lets refer back to the license for a little clarity, perhaps: 7. LICENSEE AGREES THAT THE EXPORT OF GOODS AND/OR TECHNICAL DATA FROM THE UNITED STATES MAY REQUIRE SOME FORM OF EXPORT CONTROL LICENSE FROM THE U.S. GOVERNMENT AND THAT FAILURE TO OBTAIN SUCH EXPORT CONTROL LICENSE MAY RESULT IN CRIMINAL LIABILITY UNDER U.S. LAWS. Can you tell me which part of this clause you think asks you to agree with the law? Can you tell me which part of this clause you think is stronger than a 'may' statement? I am at a loss here, frankly. I think mjg59 and myself have done a reasonably good job explaining a sentence in our native tongue, but I see that we are still failing to communicate. If you don't see what we're saying now, can you be more explicit about what phraseology you are seeing that supports your interpretation? It would be helpful in trying to explain it. Ok, the above `MAY REQUIRE' implies a possibility of eventual requirement to bla bla bla ... What happens when that possibility becomes true and one does not agree with that law and has never accepted it before. Agree can have two (actually more) meanings. In the context of this license, you don't have to agree that the law is right or just (agree with it), merely that it exists, as a statement of fact (Agree that the the facts stated are true). The facts that are stated are that the law declares x, y, and z. signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
Re: BCFG Public License
Henning Makholm wrote: Scripsit Matthew Garrett [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Matthew Garrett [EMAIL PROTECTED] Please quote the section of the license that states that. # LICENSEE AGREES THAT THE EXPORT OF GOODS AND/OR TECHNICAL DATA FROM # THE UNITED STATES MAY REQUIRE SOME FORM OF EXPORT CONTROL LICENSE FROM # THE U.S. GOVERNMENT AND THAT FAILURE TO OBTAIN SUCH EXPORT CONTROL # LICENSE MAY RESULT IN CRIMINAL LIABILITY UNDER U.S. LAWS. In this sense, AGREES is synonymous with ACKNOWLEDGES. If you read it like that, are you happier? What does it even mean then? Which legal consequences does it have for me to acknowledge that law? Why would the licensor want me to do so - he must have _some_ purpose in requiring such an acknowledgement, which indicates that a laywerbomb must be present somewhere. I would be wary of using the software, because it is completely opaque what the catch is. It's to cover UChicago's ass. They want to make sure if someone distributes their software in a way that violates US export laws they can point at that license and say See! We warned them! It's not our fault They don't want to get sued by someone claiming that it's their responsibility for not informing that person of the legal risk. At least I know what opinions I have. If Licensee agrees does not mean that I in fact agree, then I don't know how to tell whether I have acknowledged the law in a proper manner that allows me to use the license, or what it would mean for me to do so. Would you agree that there are bugs present in the Debian operating system? You may not like the fact (I know I don't), and you may not agree that they should be there, but I hope you can agree that they exist. HTH, Benjamin signature.asc Description: OpenPGP digital signature
Re: Help Selecting License for Bacula Documentation
Kern Sibbald wrote: Benjamin Seidenberg wrote: Kern Sibbald wrote: John Goerzen wrote: I'm forwarding, with permission, parts of a message from Kern Sibbald, author of Bacula and its manual. The current manual, which has a license listed at http://www.bacula.org/rel-manual/index.html, is not DFSG-free. However, Kern has indicated a willingness to consider other license arrangements. Kern's main concern (correct me if I'm wrong, Kern) is that he doesn't want someone to be able to publish and sell paper versions of the manual. Yes, this is correct, but with the nuance, that I would be very happy to see the manual published in physical form provided there is an agreement for a reasonable financial contribution to the project, which should take into account normal royalties and how much work the publisher (or whoever transforms it) has to do to get it in a publishable form. In my other email, I attempt to explain my reasoning behind this. While this is an understandable viewpoint, and one that I can sympathize with, any license that would provide protection such as you describe would most definitely be in violation of the DFSG, and as such, not distributable by debian, at least in the main section (though possibly in non-free). On the other hand, note that the GPL requires that distributors notify recipients about the Free Software status of the work, which would allow people to know hey, I could get this for free online; this might achieve a similar effect to what you desire. Furthermore, I don't know for sure, but a carefully worded license *might* manage to require a specific notice as to the unofficial, non-endorsed status of the manual, while still remaining DFSG-free. You could then specifically grant distributors the rights to call themselves an official and/or endorsed manual in exchange for whatever auxiliary licensing terms you want. Hmmm. Possibly having an invariant section (or whatever it is called) stating the unofficial, non-endorsed status of any commercially printed version of the manual would do what you suggest. Well, Debian doesn't allow invariant sections, but I would think that requiring a prominent notice on any derived work stating it is an unofficial and endorsed work would be ok. I'm going to try to come up with some such wording over the next week, but if you or someone else could suggest such a carefully worded license for the Bacula manual that would be acceptable to Debian, it would for me be a good solution, and I would very likely accept it Sadly, that's really not my forte - could someone who spends more time on -legal help Kern out? -- obviously, I would like to see the wording before making a firm commitment ... Of course. Best regards, Kern Cheers! Benjamin signature.asc Description: OpenPGP digital signature
Re: UC license and debian
kris wrote: We are releasing some software and would like to make sure it is compatible with debian. We have been told that this is the current license to use for UC produced works. http://www.ucop.edu/ott/permissn.html I searched the archives to no avail. I notice that it no longer includes the advertising clause, so it looks pretty good to me. Any ideas whether this is compatible with debian or not? Thanks, kris No, it's not. It doesn't grant the right to be used in commercial products, and thus fails the DFSG. Sorry, Benjamin signature.asc Description: OpenPGP digital signature
Re: UC license and debian
kris wrote: On Wed, 2006-05-17 at 19:06 -0400, Benjamin Seidenberg wrote: [[snipped]] No, it's not. It doesn't grant the right to be used in commercial products, and thus fails the DFSG. I guess you mean that it does allow commercial licensing and therefore is not compatible with debian.. Is that correct? No, it doesn't allow commercial licensing. See Bill's post on the list. In brief: DFSG 6: 6. No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. The UC License prevents it from being used in commercial software. OK.. now I am really confused. No problem ;-). Let me try to help... Below is the relevant text. I read this as free for non-commercial use Yes. and non-free for commercial use. Correct. GNU GPL can't be used in commercial software Incorrect. Here is where the error lies. The GPL allows you to sell copies of the software - you just have to provide the source code with it, and whoever you sell it to could then give it away. For more information see: http://www.gnu.org/philosophy/selling.html and by the above reasoning, therefore is not DFSG free? (Obviously by removing the claim on which this is based, we show this as false) I hope this helps! Benjamin signature.asc Description: OpenPGP digital signature
Re: Help Selecting License for Bacula Documentation
Kern Sibbald wrote: Hello debian-legal, I'm forwarding, with permission, parts of a message from Kern Sibbald, author of Bacula and its manual. The current manual, which has a license listed at http://www.bacula.org/rel-manual/index.html, is not DFSG-free. However, Kern has indicated a willingness to consider other license arrangements. Kern's main concern (correct me if I'm wrong, Kern) is that he doesn't want someone to be able to publish and sell paper versions of the manual. Yes, this is correct, but with the nuance, that I would be very happy to see the manual published in physical form provided there is an agreement for a reasonable financial contribution to the project, which should take into account normal royalties and how much work the publisher (or whoever transforms it) has to do to get it in a publishable form. In my other email, I attempt to explain my reasoning behind this. While this is an understandable viewpoint, and one that I can sympathize with, any license that would provide protection such as you describe would most definitely be in violation of the DFSG, and as such, not distributable by debian, at least in the main section (though possibly in non-free). I also wanted to clear something up. When you said I consider this a really minor point that has virtually a zero probability of discriminating against someone. (in your other mail), I took it to mean that you felt Debian was accusing you of being discriminatory. While that it one test of the DFSG, it is not the only one. Even though the documentation's license is not discriminatory, it violates other core principles of the DFSG, those of allowing the user to sell the work, and to change the form it is in. Best regards, Kern Cheers! Benjamin signature.asc Description: OpenPGP digital signature
Re: License Licenses (again)....
Joe Smith wrote: Nathanael Nerode [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Javier wrote: The last proposed licensed I sent is *not* a new license. It is simply this license: http://www.freebsd.org/copyright/freebsd-doc-license.html ... The Debian Documentation License Copyright 1997-2006 Software in the Public Interest, Inc. All rights reserved. ... You can't do this. You just took a copyrighted work (the FreeBSD Documentation License), put a different organization's copyright notice on it, stripped off the original copyright notice, and renamed it. That's copyright infringement. It's also plagarism, because you don't credit the origin of the work. License texts may be literary works, subject to copyright, too. Remember that. Dammit, I keep having to bring this topic up. People seem to have a blind spot about license licensing. True, but even laywers have the nasty habit of reusing other licence text without permision, and usually do not attribute at all. It looks to be a tolerated practice, although that does not make it any less illegal. Out of curiosity, are you aware of any legal cases involving infringing the copyright of a legalese document? Out of curiosity, since IANAL, could this be used to prevent a lawsuit? If the side that created the contract was violating them, could they claim copyright status and prevent the injured party from citing the contract when filing a lawsuit? signature.asc Description: OpenPGP digital signature
Re: cdrtools - GPL code with CDDL build system
Måns Rullgård wrote: Don Armstrong [EMAIL PROTECTED] writes: On Sun, 19 Mar 2006, Måns Rullgård wrote: Don Armstrong [EMAIL PROTECTED] writes: Not just linking; it's the creation of a derivative work of a GPLed work. Frankly, I don't see how you can argue that cdrecord is not a derivative work of the GPLed part of cdrecord and the build system. I disagree. The final executable is no more a derivative of the build system than it is of the compiler. After all, no parts of the makefiles end up inside the executable. The makefiles direct the assembly of the executable, just like the source code directs the operation of the compiler. [And indeed, some question as to whether some part of the executable is a dirived work of the compiler exists as well; luckily there are exceptions in the licences of gcc to deal with this case.] There are multiple different ways that the compiler and assembler can be directed by the makefile; quite a large number of them will produce an operational executable. Given only the source files, writing a makefile that will produce a working executable is fairly simple. I see makefiles as more of a convenience than a necessity to build a program. You might as well argue that every program in Debian is a derivative of apt and the package descriptions, since the former uses rules in the latter to decide what to install. Again, I say this is just a convenience that saves users the time to find out and install the dependencies manually. If that is the case, wouldn't the simplest course of action be simply to strip the build system from the tarball and replace it with a free one written by the maintainer? signature.asc Description: OpenPGP digital signature
Re: cdrtools - GPL code with CDDL build system
Benjamin Seidenberg wrote: If that is the case, wouldn't the simplest course of action be simply to strip the build system from the tarball and replace it with a free one written by the maintainer? Oops, missed where Don mentioned this earlier in thread. Sorry! Benjamin signature.asc Description: OpenPGP digital signature
Re: data on the consultants page
Andrew Donnellan wrote: The site seems legit, but that doesn't make spamming legal. To be spam, however, it must be automated. It looks like a site for 'open source' programmers, and Debian clearly qualifies as an 'open source' project (in fact the OSD was based on the DFSG), so it may have been manually sent. I would just ignore it. Andrew I thought spam was unsolicited email, automatic or not? Cheers, Benjamin signature.asc Description: OpenPGP digital signature
