Re: Non-free IETF RFC/I-Ds in source packages
On Mon, 16 Oct 2006 11:49:48 +0200 Simon Josefsson wrote: Francesco Poli [EMAIL PROTECTED] writes: [...] I don't know whether I'll have enough time to do it personally. Let's do as follows: I see if I can modify the wiki page on Sunday; you look at the wiki page on Monday and, if it's not already updated, you do the changes. OK? I've updated it, thanks! You're welcome! :) Btw, one variant of the MIT License is described at: http://www.opensource.org/licenses/mit-license.php That is the Expat license, word for word identical. I used that link instead of the one above, this one seems more authorative. That seems to be a valid choice[1], taking into account that http://www.jclark.com/xml/copying.txt recently began to refuse connections on TCP port 80... We are really beginning to have a problem with vanishing URLs for widespread non-copyleft licenses. :-( I'm more and more convinced that my wishlist bug #284340 is a good suggestion... :-| [1] except for the minor drawback of (mis)leading people to consult the OSI list of approved licenses, as if it were anything meaningful... :-( [...] The fact is that it's *one* of the licenses historically used by MIT. But MIT used many other licenses as well, so referring to it as the MIT license is a bit vague. Moreover the X11 license is also known as the MIT license as well; hence the name MIT license is an ambiguous label. As already explained, X11 license is also vague... It's a mess, agreed. I can't think of a better name than Expat/MIT though, and since the URL is present, the risk of confusion seems small. The clearest and least ambiguous name for that license, is Expat license, AFAICT. It has the only drawback of being less widespread and known than MIT license, which, on the other hand, is ambiguous, as already explained. Using the compound name Expat/MIT license or Expat a.k.a. MIT license is, IMHO, the best way to be clear and understandable, while disambiguating the reference to MIT... P.S.: Please do not Cc: my personal address when replying to the list, as I didn't ask to be copied. Thanks. Sorry, I'm reading this list through gmane.org and pressed 'F' in Gnus, which apparently ended up being the wrong thing. Don't worry, nothing serious happened! :) I changed the headers manually this time. It worked! -- But it is also tradition that times *must* and always do change, my friend. -- from _Coming to America_ . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpYyyaXzVGf3.pgp Description: PGP signature
Re: Why TPM+Parallel Distribution is non-free
Terry Hancock [EMAIL PROTECTED] wrote: Okay, fine. Let's consider the case in which TPM is hard to apply: Then isn't it an effective barrier to further modification and redistribution (i.e. non-free)? It's a practical problem, not necessarily something non-free. [...] I stand by my opinion that TPM is intrinsically simpler than binary compilation. [...] After all, there is a standing assumption that programs are written by expert developers who are not regarded as being in the same class as mere users. [...] But content creation is not a technical specialty. [...] The above assumptions are flawed, in my experience (I've used TPM more complex than compilation; I was no expert when I started writing programs; and putting out a radio magazine show is surely a technical specialty - well, if you want to do it right). [...] It creates an incentive to keep the TPM simple to apply. While noble, that is not necessarily any more free than requiring distribution to always be in a shar. [...] So the anti-TPM clause is necessary to preserve copyleft, and Debian really needs to recognize that in order to remain the flagship free software distribution that it is. Yeah, and Debian really needs to recognise patent-poison-pill clauses, anti-commercial clauses and distributing Netscape in main(!) -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why TPM+Parallel Distribution is non-free
Terry Hancock [EMAIL PROTECTED] wrote: [...] It's very frustrating to have to repeat the same points over and over again, because some people don't apparently read them before replying. Amen. I can appreciate of course, that Debian legal folk, having discussed this already, and having amongst themselves already reached a consensus, find it difficult to have to revisit the same question. [...] Please check the prejudice in at the door. On the other hand, some of the responses on this list have been very rude, which does make it difficult to have an intelligent conversation. I don't find that hurling insults or airing conspiracy theories is particularly helpful. FWIW, I don't find the finger-jabbing, confrontational style of this: However, in respect for your request, I've eliminated all stylistic emphasis from this post. IMHO, this makes it harder to read, but I trust you are prepared to make the extra effort. [...] this: (Once again, here's the binary/source to TPM/non-TPM analogy that MJ Ray insists isn't being used to support parallel distribution... being used to support parallel distribution!) [...] and this: Okay, but what part did you not understand? [...] at all helpful. What responses were rude? -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why TPM+Parallel Distribution is non-free
I spent far too long crafting a reply to this, then a pair of ISP/SMTP errors sent it to /dev/null - this is a rushed rewrite. If you are in a rush, points 17.1, 17.8, 17.13, 17.15 and 17.18 are most repeated and you can get the gist from them. Terry Hancock [EMAIL PROTECTED] wrote MJ Ray wrote: Since when has CC-By been a copyleft anyway? CC-By is a separate issue and whether it is or is not a copyleft isn't relevant. 17.1 One cannot argue that allowing being non-copyleft is a problem for CC-By. The terms in question ARE DFSG free, as they exist in CCPL3.0, for By and By-SA. 17.2 That seems circular reasoning: the terms follow DFSG, as they exist in CCPL 3.0; and CCPL 3.0 follows DFSG, as the terms follow DFSG. FWIW, Mia Garlick notes that, unlike copyright, TPMs are not limited by fair use or fair dealing. Thus TPMs have the capacity to render a work even less free than all rights reserved. 17.3 That is a problem that I am working on, but as far as I can see from the treaties, there's no assurance that fair use or fair dealing exists in any meaningful form everywhere. The platform monopoly issue creates a problem for the original work, as well as derivatives, so it is still a problem for CC-By licensors. More importantly, from my PoV, the provision *is* DFSG free, so it doesn't matter. 17.4 Either it is a problem or it doesn't matter. Pick one. Not only is this untrue, but it is in fact reversed. Allowing TPM distribution allows a platform-owner to obstruct redistribution of the work. It is true. Also, allowing TPM distribution while prohibiting a platform-owner to obstruct redistribution of the work would not allow a platform-owner to obstruct redistribution of the work. Now, who's using the confusing phrasing? ;-) TPM is such an obstruction. Hence allowing TPM distribution while prohibiting a platform-owner from obstructing redistribution of the work is contradictory. 17.5 Only if one assumes that TPM must be such an obstruction. That assumption may be wrong. The legislative definitions of TPM are not great and there's not much case law yet. the restrictions of a licence that permits parallel distribution need not be non-copyleft; The anti-TPM clause is part of the copyleft. It is essential to preserve the freedom of the work, hence it is essential to copyleft. However, blanket anti-TPM is not the only way to preserve that freedom and arguing about copyleft does little to argue for why it's in CC-By. There is no blanket anti-TPM. There is a requirement that distribution not occur in TPM'd form. All free licenses have some kind of distribution requirement. Many (including the GPL) make requirements about the form of distribution of derivatives (e.g. you must include the license). 17.6 The existance of some acceptable restrictions does not make all restrictions acceptable. Some discriminate against fields or groups. I've already pointed out that it is technically possible to design a TPM that triggers on the presence of GPL license statements, thus rendering the GPL non-free by your argument. 17.7 I do not see how it is possible to twist my argument into that conclusion. Has it been misunderstood? [...] BTW, this is NOT a new freedom of the CC-By-SA, as you keep suggesting. The wording has been improved, but CC-By-SA 2.5 provided this freedom as well (and it may go back further). Mia Garlick addresses this point in #6 of her responses document: http://lists.ibiblio.org/pipermail/cc-licenses/attachments/20060908/da9db6a3/attachment-0001.pdf 17.8 I am not online, I do not have that URL cached and IIRC it doesn't convert neatly anyway. As with other URLs, I neither accept nor reject their arguments - it is merely citing inaccessible material. If it is important, please quote relevant excerpts or summarise the substance, and give an unambiguous reference. This isn't rocket science - it's research. 1. one particular problem with TPMs overruling all other arguments; It's not so much one particular problem as it is THE problem. Really? Fantastic! So prohibit THE problem instead of carpet-bombing whole fields of endeavour. The only field of endeavour being restricted is the same one that ALL free licenses restrict: namely, the process of distribution. As with ALL free licenses, requirements are set on the form and methods of distribution. 17.9 If the TPM field of endeavour were restricted, that might be fine. It's not: any public use of TPM is prohibited, if I believe the claims. The entire purpose of TPMs is to preserve monopolies. I thought the entire purpose of copyright was to grant monopolies, even if that's not what we use it for today. I wonder whether TPMs will be subject to such legal judo in future. No clue what you're getting at here, MJR. We both know that TPMs were invented because their users thought that
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
The answer to the question in the subject is simple: NO. This is a matter of copyright law. If we do not have permission to distribute, it is illegal to distribute. GPL grants permission to distribute *only* if we distribute source. So, GPLed sourceless == NO PERMISSON. I will list the usual caveats so that nobody else brings them up. (1) Obviously if we have an alternate license (dual-licensing) which doesn't require source we can use that license. (2) If the material is so trivial it is uncopyrightable we can obviously distribute it. (The classic example is CRC tables, which contain no creative content beyond the CRC polynomial which is generally public domain.) Likewise if it was published prior to 1988 in the US without copyright notices, or is in the public domain for some other reason. (3) If the copyright holder for the firmware donated the firmware to Linux with the understanding that it would be redistributed by Debian and other distributors, this may constitute an implicit license to distribute. This would be a case of dual-licensing, but an unpleasant one because we'd be relying on an *implied* license. This requires tracing down the donation of the material to the Linux kernel and ascertaining the state of mind of the donor (perhaps by reading press releases). This clearly applies only to some of the firmware; other pieces have no such 'paper trail'. Also, this implicit license *does not* include a license to modify, because I've never seen any indication that any firmware donor intended that their firmware be modified. (4) If the hex lumps really are the preferred form for modification, then we have the source and this is not a case of 'sourceless firmware'. I have not yet seen a case where there is any evidence that this is true. It is, however, theoretically possible. If the firmware author came forward and said Yes, that's the form in which we modify the firmware, this would be the case. Sven Luther wrote: Hi debian-legal, ... It seems the firmware kernel issue has reached a deadpoint, as there is some widely different interpretation of the meaning of the GPL over sourceless code. For some background, the kernel/firmware wiki page includes both a proposed GR, the draft position statement by the kernel team, as well as an analysis of how we stand : http://wiki.debian.org/KernelFirmwareLicensing. But this is beside the point. The real problem is that there are a certain amount of firmware in the kernel, embedded in the drivers, which have no license notice whatsoever, and as thus fall implicitly under the common GPL license of the linux kernel. The audit from Larry lists some 40+ such firmware blobs. Actually, I have to split this into two categories: * hex lumps explicitly licensed under the GPL by the copyright holder (e100 for instance) * hex lumps with no license notice - these may be implicitly under the common GPL license for the kernel - but they may also be present inappropriately, with stripped copyright notices and no license at all, if they were inserted into the kernel by someone other than the copyright holder. This has happened at least once already. There is some claims that some of those blobs represent just register dumps, but even then one could argue that the hex blobs doesn't in any way represent the prefered form of modification, but rather some kind of register name/number and value pair. (Well, perhaps the registers are numbered 0,1,2,3,4,5... and the values are listed in that order) So, the RMs are making claims that those sourceless GPLed drivers don't cause any kind of distribution problem, This is a case of the RMs not thinking clearly, perhaps. while i strongly believe that the GPL clause saying that all the distribution rights under the GPL are lost if you cannot abide by all points, including the requirement for sources. Yep. Since i am seen as not trusthy to analyze such problems, i think to deblock this situation, it would be best to have a statement from debian-legal to back those claims (or to claim i am wrong in the above). Friendly, Sven Luther -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote: The answer to the question in the subject is simple: NO. This is a matter of copyright law. If we do not have permission to distribute, it is illegal to distribute. GPL grants permission to distribute *only* if we distribute source. So, GPLed sourceless == NO PERMISSON. I will list the usual caveats so that nobody else brings them up. (1) Obviously if we have an alternate license (dual-licensing) which doesn't require source we can use that license. (2) If the material is so trivial it is uncopyrightable we can obviously distribute it. (The classic example is CRC tables, which contain no creative content beyond the CRC polynomial which is generally public domain.) Likewise if it was published prior to 1988 in the US without copyright notices, or is in the public domain for some other reason. (3) If the copyright holder for the firmware donated the firmware to Linux with the understanding that it would be redistributed by Debian and other distributors, this may constitute an implicit license to distribute. This would be a case of dual-licensing, but an unpleasant one because we'd be relying on an *implied* license. This requires tracing down the donation of the material to the Linux kernel and ascertaining the state of mind of the donor (perhaps by reading press releases). This clearly applies only to some of the firmware; other pieces have no such 'paper trail'. Also, this implicit license *does not* include a license to modify, because I've never seen any indication that any firmware donor intended that their firmware be modified. (4) If the hex lumps really are the preferred form for modification, then we have the source and this is not a case of 'sourceless firmware'. I have not yet seen a case where there is any evidence that this is true. It is, however, theoretically possible. If the firmware author came forward and said Yes, that's the form in which we modify the firmware, this would be the case. Thanks Nerode for this complete reply. It seems thay 3) is probably the best way we have to be able to distribute sourceless de-facto GPLed firmwares, but as you say, it will be a mess. I suppose the firmwares resolutions, both the one voted, and the one i proposed, both allow to include those firmwares into main under these conditions, for etch only, altough the resolution voted upon is probably much less clear in its wording. It is regretable that Manoj losed patience suddenly after more than a month an a half of discussing the issues. But we will see. I think we all now await impatiently the statement of the RMs on what will happend with the tg3 and acenic firmwares, and if we need a new vote or not. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why TPM+Parallel Distribution is non-free
Terry Hancock wrote: I have been a Debian user for several years now, an occasional free software developer, and a user of the Creative Commons By-SA license, so I have been following the effort to make the CCPL3.0 comply with the Debian Free Software Guidelines with some interest. I used to post here on debian-legal occasionally, and I've rejoined to discuss this issue. I am not a lawyer. I apologize for the length of this post, but it is summarizing the conclusions of quite a large discussion (which I promised to the Debian folks who joined the conversation there that I would provide here). The case has been made that CCPL3.0 is DFSG-non-free because it does not allow the distribution of content in TPM'd format[0]. I assert that not only is this argument false, it is actually reversed: allowing TPM distribution, even with parallel distribution of non-TPM versions of the same content actually permits a violation of the DFSG, specifically item 3: *Derived Works* The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. [1] I interpret this to be an alternate wording of the same rule described as Freedom 1 of the Free Software Definition: The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this. [2] Debian's determination that parallel distribution of non-TPM files alongside TPM files will solve this problem is based on the FALSE idea that binary/source distribution is analogous to TPM/non-TPM distribution. This analogy has been cited multiple times in the discussion on debian-legal, but I am not able to find much serious analysis of this assumption. It is a seductive idea, and I have to admit that I was sold on it myself for quite some time. However it misses the most critical point about TPM systems, which is that they acquire their force not from technology (despite the name), but from law. It is not truly the fact that TPM is difficult to reverse that is the problem, but rather that it is ILLEGAL to do so. The point here is that parallel distribution obviates any need for the recipient to reverse the TPM. If parallel distribution does not do that, then it is not the sort of parallel distribution we are trying to allow. :-) Moreover, it turns out that the most serious problem occurs not because it is difficult/illegal to *remove* TPM, but because it is difficult/illegal to *apply* TPM (counter-intuitive as that may seem). That is an important point which has not been brought up before. I'm not sure how relevant it is though. *Prohibiting applying a TPM system to a work* is something which can be done by someone controlling the rights to use the TPM system, regardless of the work. Nothing in the work's license can prevent this, ever. It's difficult to put a copy of my favorite perl one-liner on the side of a blimp. However, under a free license I am allowed to do so. The fact that it will be very difficult for anyone to put their modified version on the side of the blimp is rather irrelevant. The fact that I, or anyone else, need special permission from the blimp owner to do so is also irrelevant. Even if the blimp owner is evil and using the blimp for his own nefarious purposes, the license for my one-liner would be non-free if it prohibited distribution by means of blimp. A system which applies encryption, but is not enforced under law is NOT a TPM in the legal sense of the word, and is therefore not being used to restrict a work (legally). This is why we want to be very specific. If a system is genuinely being used to restrict the rights given to work's recipient, we want that to be disallowed. If it is not actually restricting rights, we want it to be allowed. The CC-Scotland licenses were written to allow exactly that. The actual current text of the proposed CC license is likewise fine, provided it's interpreted straightforwardly. For example, any TPM system licensed under the new GPLv3 (d2), will not actually be a TPM in the legal sense, because the license expressly declares that it is not. This *technically identical* software is nevertheless *legally distinct*. We might call this a Non Legal Technological Protection Measure or NL-TPM system. OK. This is exactly what we're looking to allow. So this is just a matter of terminology. For such an NL-TPM, Debian's parallel distribution idea *might* apply (there is still a subtle problem, but it is much less severe), but this is not what TPM is under law. TPM is something that has the force of law backing it up. In the United States, this means that circumventing the TPM is a violation of the DMCA. Other countries are adopting similar rules, which is, of course, the basis for so much concern over TPM. Right. Now, if I distribute a TPMed copy and an identical unTPMed
Re: compatibility of bsd and gpl
And people can copypaste that code out of your project and reuse it elsewhere under the original (BSD) terms. Doesn't section 2b say that projects reusing BSD code from a GPL'd project have to be GPL'd? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Releasing a software implementation of a board game as Free Software
posted mailed Ben Finney wrote: Dr. ERDI Gergo [EMAIL PROTECTED] writes: [Please CC replies to [EMAIL PROTECTED] Done. I have no idea where I could get questions like this answered, so I thought Debian-Legal would be a good place. You should definitely seek experienced legal opinion in your jurisdiction before doing what you propose. It might be polite to ask the holder of any trademark, copyright, or patent in the board game what their attitude is toward this kind of derivative. I'm a European software developer and I'd like to release a GNOME software implementation of a commercial board game. Whether it's commercial (traded for money) or not, doesn't really matter. What matters is any rights held to concepts in the board game. The game in question is Gobblet (http://www.blueorangegames.com/gobblet.php). Can I release the game as Free Software (if I don't use the trademark Gobblet anywhere in its description)? If some party holds any trademark to the game's name or image, you can't legally use that name or image (or anything confusingly similar) for your game without license. If some party holds any copyright in any of the game's creative content (rules, images, text, etc.), you can't legally base your work on that content without license. You can, though, generate entirely new content of your own, or from work for which you do have license to derive. If some party holds any patent in the game's mechanics, you can't legally implement those mechanics in your game without license. I don't know how far this extends to abstract mechanics; European legislations have historically been to be relatively sensible on the topic of patenting abstract methods and algorithms, though this is certainly a disputed topic. Yes, unfortunately board games can be restricted by all three of these disparate bodies of law. This may be part of why it's so expensive to produce a board game. Not really -- board game producers pretty much always use custom artwork, and new names (so no trademark issues), and game mechanics patents are generally construed very narrowly as far as I can tell (so it's hard to violate them by accident). The expense in producing a board game is mostly in parts, it turns out: pawns and dice cost money, color printing costs money, box assembly costs money, cardstock costs money, board stock costs money, etc. Cheapass Games is an example of a company which avoids most of these costs. For sufficiently old games intellectual property law is rarely a serious problem: (1) patents on game mechanics have usually expired, since they last 20 years or less in most jurisdictions. (2) trademarks can be handled by renaming. A reference to the trademark of the form This game has similar rules to the game X is always allowed. In some cases the commercial manufacturer used a preexisting generic name for a game which they didn't invent: 'monopoly' and 'parcheesi' are very weak trademarks for this reason, and quite a lot of uses of them are permitted. (3) copyright issues can be avoided by writing a clean-room description of the rules and making entirely fresh artwork; usually there isn't enough material for this to be difficult. You will almost certainly want to do this for a computer implementation of *any* board game, unless you can get the author of the rules or artwork to license the rules/artwork as free software. Game mechanics patents are the most common method of protecting games from 'cloning', in the jurisdictions which allow them (the US does). This generally affects games invented within the last 20 years. On the other hand, many board game companies are aware of the fact that fan-based derivative works only serve to drive up interest in their games, so you may find the company quite helpful. Right. It's considered best practice to talk to the game's creator *anyway*, even if he holds no copyright, patent, or trademark claims (which he probably does). -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: public domain, take ∞
Daniel Gimpelevich wrote: Greetings! I'm fully aware that the opinions stated on this list have no bearing on anything, but I would still like to ask whether anyone here might have any ideas for improving the wording of the following license header: #!bin/bash # # Let this be known to all concerned: It is the specific intent of the # author of this script that any party who may have access to it always # treat it and its contents as though it were a work to which any and all # copyrights have expired. # I thought about s/author/sole author/ but decided against it as not generic enough. I can see how deciding against it may make it rather unclear as to whose intent is being expressed, but I think that would be rather moot anyway in the event of any dispute. I now cut the ribbon opening this to the free-for-all of opinions... irrevocable intent is probably better. :-/ Also, intent doesn't mean action. :-) The author of this script hereby grants irrevocable permission to any party who may have access to it to treat it as though it were a work to which any and all copyrights have expired. I think that would be an improvement. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?...
Re: public domain, take ?$B!g
posted mailed Arnoud Engelfriet wrote: Ben Finney wrote: Perhaps the statement should be granting the recipient all rights otherwise reserved to the copyright holder. Maybe it's better to reformulate it as a non-assert instead of a license. There's more than just the exclusive rights. To the extent permitted by law, the copyright holder of this work hereby declares he will not, now or at any time in the future, exercise any right under copyright, related rights or moral rights applicable to the work against any person or legal entity. This declaration shall be construed to the detriment of the copyright holder to the maximum extent permitted by law. Invalidity or unenforceability of any part of the above shall not affect any other part. Finally an actual lawyer steps in. :-) Nice draft. I think that's an excellent idea Only one quibble, but it's an important one: it doesn't waive the rights of heirs or assignees. To the extent possible, we want to do that *too*. Any ideas? (You can't waive your right to protest against mutilation of your literary work, and software is a literary work according to Berne and WIPO.) Arnoud -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Vicam driver appears to contain misappropriated code
Michael Poole wrote: Nathanael Nerode writes: Do you have any evidence to indicate that these byte streams contain any copyrightable or otherwise protected content? They look creative to me. I certainly couldn't write them independently, on my own. Under modern copyright law, everything is copyrighted by default, unless it falls in one of the standard uncopyrightable categories. It's not a fact and it's not an idea. If you show me evidence that it's a multiplication table, I'll retract that statement. It appears to be executable code based on the way it's loaded into the camera. Given the date of the camera's creation, it's not pre-1988, so it's not public domain by lack of notice. setup4[] and setup5[] could conceivably be firmware; the others are pretty clearly some other kind of device command, or alternatively are not copyrightable if they embody executable code. Where on Earth do you get this idea? This is completely contrary to everything I have ever heard about copyright law, so I'd really like to see some legal references. To my knowledge, executable code is copyrightable in general provided it is not the only possible (or only reasonable) way to express the needed execution steps. If it is the only reasonable way, then idea/expression merger makes it non-copyrightable. If it is not, then that is not the case -- it contains creative elements, and it is copyrighted material. In the absence of an indication from the manufacturer or vendor (or from inspection of the device), I tend to assume sequences of that size are configuration writes rather than small firmware. Given a particular mode of operation, configuration writes are non-creative fact. (It might be what the U.S. Copyright Act calls a useful article.) That category doesn't provide any relevant exceptions to the exclusive distribution right. (It does restrict action to 1977 law. Perhaps you know something about 1977 law.) In any case, the same exceptions do not apply worldwide. The US Copyright Office disagrees[1] about the impact of useful article status. Insofar as the device is pretty nearly useless without these programs, Copyright does not protect the mechanical or utilitarian aspects of such works of craftsmanship. It may, however, protect any pictorial, graphic, or sculptural authorship that can be identified separately from the utilitarian aspects of an object Ah. You're suggesting that the programs are *purely* utilitarian and have *no* non-utilitarian elements. I don't know about this. From what I've seen, the vast majority of programs have non-utilitarian elements even in object code form. I'm inclined to assume they have them unless there's some evidence that they don't. That's interesting. It seems like an arguable case. I am not aware of any courts which have used the useful article distinction in a software case, but you probably know something I don't. and even European governments are realizing that similar kinds of fair use are necessary for interoperability, Would be nice. Interoperability exceptions are where we should be looking here. The scope of interoperability exceptions is something about which I do not know very much. I *do* know that the reverse engineering lawsuits which were successfully defended involved Chinese wall methodology, which attempts to guarantee (and if done correctly, does guarantee) that the only replicated material is the *essential* material. This was not done by this method. I do not see a problem with treating these bits as copyright-free until someone demonstrates (or asserts under oath, such as in a legal complaint) that they are copyrightable. [1]- http://www.copyright.gov/circs/circ40.html#useful Why do you say it is non-distributable in the first place? Copyrighted material without license from the copyright holder is non-distributable unless it is fair use/fair dealing. You have made a rather large assumption to reach this conclusion, but you did not identify it earlier. Oh, the this is copyrighted material and this is not fair use assumption? Yes. Also, if you are going to exclude useful article status from consideration, why include fair use or fair dealing, which are similarly neither uniform nor universal? The parts of that status to which you are referring appear to be part of the question of what is eligible for copyright, actually. I'm happy to consider them, but it seems unlikely to cover anything not covered by the idea/expression merger doctrine. Michael Poole -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libbtctl: two questions regarding use of LGPL and GPL in source files
Øystein Gisnås wrote: I've gone through license considerations of RFP-marked package libbtctl lately, and have questions about two concerns: * 7 source files are have LGPL license in their headers, but link against bluez-libs, which is licensed under the GPL. One such file ishttp://cvs.gnome.org/viewcvs/libbtctl/src/btctlimpl.c?rev=1.20view=markup. The overall license of libbtctl is GPL. Shouldn't the license in each of the 7 source files be changed to GPL since they link against a GPL'ed library? No. LGPL is approximately equivalent to GPL+LGPL. The source files are LGPL (in case someone takes them out and uses them for some other project). The combination is GPL. Basically, whenever you add a bit of GPL to an LGPL thing, you get GPL -- but the LGPLed bits remain LGPL in case someone wants to separate them out and use them for something else. * Some source files are LGPL and some are GPL. The end-result library is GPL. My conclusion is that this is DFSG compatible. Am I right? Cheers, Øystein Gisnås -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?...
Re: License review request: LinuxMagic FSCL
Ryan Finnie wrote: Greetings, I responded to an RFP[0] for packaging magic-smtpd[1], and need some help on the legal side. I see 3 issues here: 1. The license[2], also included below, has not been reviewed by the OSI, and is not used in any existing Debian package. The company itself considers it open source, but I feel I am not qualified to make a determination. My GOD. It's EXTREMELY LONG. It has several non-free requirements: (1) Forced distribution. If you Deploy to anyone, you must make changes publicly available. Fails dissident test. (2) Choice-of-venue. Fails force people to fly to Vancouver test. (3) The notice in exhibit A is false: you do not agree to this license by using the software. Forces the display of false notices. There are several requirements, like the Wizards get the right to use all your modifications one, which are free requirements but obnoxious. Incidentally, the license text itself seems to be a copyright violation, since it lifts text from the Apple Public Software License, which IIRC isn't licensed for modification. 2. The software is designed to replace certain components of qmail, which is wholly non-free. Even if the license is clean, does this make the software part of the non-free archive as well? That would make it 'contrib', but it's non-free, so don't worry about it. I guess theoretically you could write Free software that would interface with magic-smtpd... 3. More of a technical packaging question, but as long as I'm here... Since magic-smtpd basically requires qmail, and qmail technically doesn't exist within Debian (you get the qmail-src package and run build-qmail to build your own local qmail .deb), will having a Depends: qmail (but it doesn't Build-Depends: qmail) be a problem to the Debian package system? Would I have to Recommends: qmail instead? No, you can Depends: on out-of-Debian stuff if your package is contrib or non-free. Thank you for your time, Ryan Finnie -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote: The answer to the question in the subject is simple: NO. Thankyou for your opinion. I note you seemed to neglect to mention that you're not a lawyer. Cheers, aj signature.asc Description: Digital signature
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Wed, 18 Oct 2006, Anthony Towns wrote: On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote: The answer to the question in the subject is simple: NO. Thankyou for your opinion. I note you seemed to neglect to mention that you're not a lawyer. That should be abundantly apparent to anyone who has been paying attention. Regardless, it doesn't dismiss the crux of the argument: baring competent legal advice to the contrary,[1] distributing sourceless GPLed works is not clear of legal liability. Doing otherwise may put ourselves and our mirror operators in peril. Don Armstrong 1: And frankly, I'd be suspicious of the source of any legal advice claiming that violating the letter of the GPL was something that could be done without any concern for liability. -- I now know how retro SCOs OSes are. Riotous, riotous stuff. How they had the ya-yas to declare Linux an infant OS in need of their IP is beyond me. Upcoming features? PAM. files larger than 2 gigs. NFS over TCP. The 80's called, they want their features back. -- Compactable Dave http://www3.sympatico.ca/dcarpeneto/sco.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Tue, Oct 17, 2006 at 03:35:26PM -0700, Don Armstrong wrote: On Wed, 18 Oct 2006, Anthony Towns wrote: On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote: The answer to the question in the subject is simple: NO. Thankyou for your opinion. I note you seemed to neglect to mention that you're not a lawyer. That should be abundantly apparent to anyone who has been paying attention. Regardless, it doesn't dismiss the crux of the argument: baring competent legal advice to the contrary,[1] distributing sourceless GPLed works is not clear of legal liability. Doing otherwise may put ourselves and our mirror operators in peril. So what? Distributing GPL works *with* sources is also not clear of legal liability. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: License review request: LinuxMagic FSCL
Ryan Finnie wrote: Walter, Thank you for your comments (everybody else too). Sorry for not following up sooner; please see question below. On 9/27/06, Walter Landry [EMAIL PROTECTED] wrote: MJ Ray [EMAIL PROTECTED] wrote: Ryan Finnie [EMAIL PROTECTED] asked for help with: (c) You must make Source Code of all Your Deployed Modifications publicly available under the terms of this License, including the license grants set forth in Section 3 below, for as long as you Deploy the Covered Code or twelve (12) months from the date of initial Deployment, whichever is longer. You should preferably distribute the Source Code of Your Deployed Modifications electronically (e.g. download from a web site); and This looks like forced *public* availability and a 12-month retainer, which I think is both a significant cost (so not free redistribution) and maybe a practical problem. If you need to make any modifications, then with this clause, I don't think that it can even be uploaded to non-free. Debian does not insure that every version ever distributed will be available for 12 months. How does this differ for the GPL's section 3(b) three-year clause? Debian doesn't distribute under 3(b), it distributes under 3(a). At this point, the feeling seems to be that software that uses this license cannot even be uploaded to non-free. Yes. :-( If that is the case, I will make an effort to contact LinuxMagic and ask them if they can re-license magic-smtpd under the GPL (it looks like some of their other software is GPL-licensed), and/or ask them to contact debian-legal to discuss what can be done to make it possible to include magic-smtpd with Debian. Again, thanks for the input. Ryan Finnie -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CC's responses to v3draft comments
Evan Prodromou wrote: On Sun, 2006-24-09 at 12:06 -0400, Nathanael Nerode wrote: Worse, the PDF description of the parallel distribution amendment appears to describe an amendment which is less restrictive than necessary for Debian's purposes (see comment 11). (Proper parallel distribution requires the unencumbered to be distributed to every recipient of the encumbered: though not technically with the encumbered, it's effectively the same, and that's not mentioned in the response.) Given this (mis)interpretation, I would probably oppose such an amendment too. :-/ If there is a mistake there, it is probably my fault. I'm confused as to why the unencumbered version must be _distributed_ to each recipient, rather than just _made available_ to each recipient. (I differentiate here between packaging the two versions inseparably together, versus putting the unencumbered version on a public Web site, say.) Erp, that's correct. You just stated it even better. The way the PDF description from CC stated it it seems to imply that the copies must be physically bundled. I believe it's immaterial to the DFSG-compatibility of the license, but I wonder why you think it's required for proper parallel distribution otherwise. Clarification above. Hence, it seems that CC refuses to disclose the intended meaning of the clause... I think the plaintext meaning should be assumed unless the licensor specifies otherwise (reference UW-Pine case), and we know that the plaintext meaning allows parallel distribution. (Of course, if there is a court case, we'd have to defer to that, but until there is, I'd go by the plain meaning.) My guess is that Mia's response is a political one. Their international affiliates have opposed additional parallel distribution language; we've said that the language in the 3.0 draft may be enough to allow parallel distribution anyways. Rather than getting them upset, she's given us a barely-qualified yes. I think we should take our victory as gracefully and discreetly as we can. OK. ~Evan -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CC's responses to v3draft comments
MJ Ray wrote: How can anyone discuss decisions made by a secret process for secret reasons in any useful way? If that decision is to be changed, it helps to know how and why it was made, but we simply have almost no data on it. This is the part which is really frustrating about CC, actually. Frankly, if we had some more data on it, we might well conclude Oh, they rejected a separate clause just because they wanted to keep the license simple, they have no problem with the parallel distribution concept. And then we wouldn't be discussing this. I think we have to go with the text as written at this point: any distribution method which doesn't restrict the rights granted in the license is OK. If individual licensors assert a different interpretation, we'll deal with that then. snip I remember being criticised for taking these comments to wider communities in the past, but this is why I do that: CC's discussion forums seem damped, narrow and impotent, which I think will only change when enough prominent CC supporters like Evan start to question that problem. Whereas I do it because I'm sick of being told I can't post unless I subscribe to the mailing list. :-P OK. Let's declare victory and move on. Proposed statement: We believe that the draft CC-BY and CC-BY-SA licenses appear to be Free Licenses, so that most works licensed under them will probably satisfy the DFSG. Please note that Debian evaluates the freeness of each work independently. Issues beyond copyright licensing sometimes come into play. And particular licensors may specify different interpretations of the license text. So this statement does not mean that Debian will automatically consider every work licensed under these licenses to be free. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
Anthony Towns wrote: On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote: The answer to the question in the subject is simple: NO. Thankyou for your opinion. I note you seemed to neglect to mention that you're not a lawyer. Yes, I'm not a lawyer. Do not rely on anything I say as a legal opinion. Even if I *were* a lawyer, my postings here would not constitute legal advice. Please, I don't want to be sued for practicing law without a license! I'm just describing what little I've learned, which is far more than I should have to know under a sane copyright law system. :-/ Actually, you're the frickin' DPL. Go get a real legal opinion already. Call SPI's lawyer. I will be extremely surprised if he says Yeah, sure, this stuff is totally legal to distribute, but who knows? Cheers, aj -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: compatibility of bsd and gpl
Matthew Wala wrote: The new BSD (meaning, without the forced-advertising clause) and GPL licenses are considered compatible, but how are the requirements of the BSD license satisfied when BSD licensed code is included in GPL projects (eg, the Linux kernel)? (1) Include the copyright notice, BSD license text, and disclaimer. (2) Don't use the specified names to endorse or promote products. Is clause 3 of the BSD license (The name of the author...) GPL-compatible? So the question is, is that clause an additional restriction, prohibited by the GPL? Good question. Traditionally it's considered not to be. Probably because it falls in the You already can't do that category -- it's a stupid and redundant clause prohibiting something which is illegal everywhere. Prohibiting something which is already prohibited is not *in practice* a restriction, I guess. I recommend avoiding that clause for new works -- heard of the two-clause BSD license? You have to be careful with that sort of clause because sometimes it turns out that the prohibited practice is not prohibited everywhere, and then it really is a restriction for that jurisdiction. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creative Commons 3.0 Public draft -- news and questions
MJ Ray wrote: and maybe some other bits too (CC3.0 is a long licence). The Scotland one is far briefer, especially when viewed in context, and it has the apparently crucial difference of including 'effect or intent'. I'm actually curious as to why this is apparently crucial; I haven't seen a good explanation of this. It seems to be a better formulation (applies to cases where technology effectively restricts rights by accident, and to cases where it was intended to restrict rights but doesn't), but I'm not sure why it's crucial. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conquer relicensing
The title of this thread made me think, Gee, I'd love to conquer relicensing. I'm certainly not a relicensing master yet. :-) [EMAIL PROTECTED] wrote: Hi all, I'm new dealing with licenses and I've been trying to catch up, however I need advice. Edward M Barlow wrote conquer, a middle earth multi-player curses based game, and posted it in USENET at comp.sources.games around 1987 and 1988. Later Adam Bryant contributing with code and patching the original sources. Recently I managed to contact Ed Barlow and asked him for permission to relicense conquer as free software. My concerns are around the contributed code of Adam Bryant who I didn't manage to contact. Please check the original C source code of conquer v4.11 at [1] and look that three files (navy.c, sort.c, and trade.c) specially the latter have a notice like this: /*conquer : Copyright (c) 1988 by Ed Barlow.*/ /* * The following file trade.c was written by Adam Bryant who * gives all rights to this code to Ed Barlow provided that this * message remains intact. */ Could the code be relicensed as GPL v.2 or any compatible license with this notices? Yeah, Adam Bryant's intent seems extremely clear. I'm not a lawyer and I'm not sure exactly how the clause would be interpreted, but it pretty clearly lets Ed Barlow license the code however Ed wants. Unless Adam Bryant comes back and complains, don't worry about it. Thanks, Juan [1]. http://vejeta.no-ip.org/conquerv4/ -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: compatibility of bsd and gpl
Matthew Wala wrote: And people can copypaste that code out of your project and reuse it elsewhere under the original (BSD) terms. Doesn't section 2b say that projects reusing BSD code from a GPL'd project have to be GPL'd? No. This is a matter of identifying the individual works making up a composite work; the tail end of section 2 applies: If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Yahoo! DomainKeys license
Magnus Holmgren wrote: OK, another stab at this beast! I've been in contact with Mark Delany, the Yahoo! engineer that wrote the draft and administrates the DomainKeys SourceForge project. HINAL though, AFAIK. On Saturday 17 June 2006 19:41, Joe Smith took the opportunity to say: snip Below is my initial analysis of the licence. The licence url is: http://domainkeys.sourceforge.net/license/softwarelicense1-1.html, and I have included a complete copy at the end of this message. Ok, 1.1 does not seem to grant the right to sell the code/program. Section 1.2 grants the right to sell for the sole purpose of implementing a sender verification solution in connection with e-mail.. I'm not sure if limiting the scope of Sale is allowed by the DFSG or not. But section 1.1 grants the right to modify and distribute the code. Without an explicit limitation that must mean that one can charge any consideration for it. Section 1.2 grants the right to infringe on the patents with the code (and modifications to it) insofar it's needed to implement a sender verification solution etc. But that's a patent license, and that can't be directly connected to the code. They also license their patent claims under their Patent License v 1.2, which says nothing about any particular code. Anyway, section 1.2 can't limit the ways the code can be used with respect to copyright, you can't expect them to completely waive their patents, and the impact of patents on DFSG-freeness has already been discussed at length. I'm slightly concerned that the specification is an Internet-Draft. More distubing is that the Licence give a URL for the Draft, but the URL does not work. Section 3.3 says You must create Your own product or service names or trademarks for Your Licensed Code and You agree not to use the term DomainKeys in or as part of a name or trademark for Your Licensed Code.. This may be a problem, considering the name of the package. Actually this is a weird restriction. Suppose I don't want *any* product or service names or trademarks, and I want to use the code in an anonymous fashion. Must I invent a trademark? :-/ According to Mark Delany it's OK to call the package that as long as the source code is unmodified. The DFSG specifically allows licenses that require name changes if the code is modified. Section 3.5 is a you must obey the laws section. Section 3.8 is choice of law and venue. Yes, those are the problematic ones. Instances of both have been discussed here and are disliked by many, We're all OK with choice of law if it seems to be a reasonable legal system (we'd probably be disturbed by This license shall be interpreted under the laws of the Taliban). Choice of venue is generally considered unacceptable because it allows nuisance lawsuits by the license issuer, and specifically allows the license issuer to drag the licensee to strange faraway courts to defend him/herself. but was there consensus as to whether such clauses go against the DFSG? DFSG 6 perhaps, if breaking the law is a Fields of Endeavor. civil disobedience perhaps would be a better description. I don't know whether this is DFSG-free or not. It probably is, but it's not very friendly. OK, choice of venue can be nasty, but at least one is entitled to get legal notice and a chance to respond in writing before having to physically appear before the court for oral deliberations? Is that true everywhere? I hope so but I don't know. It looks like Yahoo was indeed trying to create a a Free licence, or at least an Open-Source licence. However, it clearly fails the part 10 of the OSD (it is not technology nutral, as it is specific to e-mail), and is quite likely to be running afoul of the DFSG. It should at least be uploadable to non-free. But in that case Exim can't be linked with it unless Exim is moved to contrib, which is unacceptable. Seeing as DomainKeys is experimental and even obsolete already, but still not replaced with DKIM at Yahoo (for instance), the value of these packages can be questioned. OTOH, DKIM is still experimental too. I think it can make sense to include DomainKeys packages in Etch and drop them again for the next release. I found one more problem, a big one. 3.4. You may choose to distribute Licensed Code or modifications under this Agreement or a different agreement, provided that: (a) a copy of this Agreement or the different agreement is included with each copy of the Licensed Code or modifications along with the following prominently displayed statement: By using, reproducing, modifying, publicly displaying, publicly performing, distributing, and/or sublicensing this code as permitted, you agree to the terms and conditions of the Yahoo! DomainKeys Public License Agreement or other agreement contained herein.; and Not OK. It's not DFSG-free to have a use restriction in a copyright license (patent licenses are a different matter obviously
Re: conquer relicensing
Joe Smith wrote: Juan M. Mendez wrote in message news:[EMAIL PROTECTED] So, I have been investigating. It seems Adam Bryant developed a new version 5 of conquer: http://www.cs.bu.edu/ftp/fs/pub/adb/beta/ where all the files hold notices disallowing redistribution of the code with a notice starting with. /* conquer : Copyright (c) 1992 by Ed Barlow and Adam Bryant */ Some people managed to talk with Adam in 1997 where he said he licensed conquer to a commercial developer, saying title would revert back to him if the company didn't release anything in two years. http://members.aol.com/heiska/ecframe/future.html I would expect that the new code was completely different, which would explain this. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conquer relicensing
Juan M. Mendez wrote: On 10/9/06, Arnoud Engelfriet [EMAIL PROTECTED] wrote: Without a piece of paper with Adam's signature saying otherwise, the copyright remains with him. So Ed should ensure he does not change the copyright notice. snip So, I have been investigating. It seems Adam Bryant developed a new version 5 of conquer: http://www.cs.bu.edu/ftp/fs/pub/adb/beta/ where all the files hold notices disallowing redistribution of the code with a notice starting with. /* conquer : Copyright (c) 1992 by Ed Barlow and Adam Bryant */ Oh, great. Reading out of order sucks. It looks like Adam *didn't* make a all-new version, he made a *mess*. You do need to contact him or get rid of the Adam Bryant code. Arnoud is right in his reply -- it's not clear what Adam Bryant's statement transferring rights to Ed Barlow means in the context of this later information. Some people managed to talk with Adam in 1997 where he said he licensed conquer to a commercial developer, saying title would revert back to him if the company didn't release anything in two years. http://members.aol.com/heiska/ecframe/future.html A press release in 1997 also seems to cerfify that: http://web.archive.org/web/20020804001252/http://www.mythicentertainment.com/conquerpr.html My doubt is, how this license transfering of the Adam Bryant code could affect the old code of version 4 of conquer released in 1988 in USENET, the one that Ed allowed me to relicense as Free Software. Sorry for the sudden burdening of information, I tried to give all the information I can. -- Juan -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License review request
Arnoud Engelfriet wrote: Andrew Donnellan wrote: Of course that doesn't mean it's not required, just that the evidence given was irrelevant. I've seen most places do it and lawyers recommending it and so on, and as it is a legal disclaimer I think it would be wise to use emphasised text, at least put asterisks around it or something to draw attention. Laws like the Uniform Commercial Code do require that disclaimers of warranty be by a writing and conspicuous. http://www.law.cornell.edu/ucc/2/article2.htm#s2-316 I suppose you could be equally conspicuous with boldface or differently colored text. Hmm. I'd really think conspicuous is more about *placement* than emphasis. A warranty disclaimer in ALL CAPS subtly located on the bottom of the package is inconspicuous; one in any form of text located front and center on the package is conspicuous. Sigh. Thinking about this, this means putting your warranty disclaimer in the license, which only a small percentage of recipients even read, is probably inconspicuous by nature. The problem is, as far as the lawyers are concerned, all caps seems to work just fine. Why use something different? At best, the court will rule it's just as good as all caps. At worst, they'll say you deviated from common industry practice, which confuses consumers, and therefore your disclaimer was *not* conspicuous. Well, when someone wins a court case invalidating a disclaimer because all caps are unreadable it'll change then, I guess. :-/ So it's not just monkey-see, monkey-do, but more like monkey-worry-about-malpractice. So common industry practice is the reason -- that sort of makes sense, even though it's unutterably stupid. It seems like any disclaimer in the *MIT* license would be relatively conspicuous, seeing as how it's more text than the whole rest of the license. In contrast, I'd expect any disclaimer tucked on page nine of a ten-page-long license to be found inconspicuous. And lawyers do *THAT* all the time. :-P Arnoud -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Tue, 17 Oct 2006, Roberto C. Sanchez wrote: So what? Distributing GPL works *with* sources is also not clear of legal liability. Those liabilities occur in either case, so they're not particularly interesting to discuss. Doing something that is against the letter and spirit of a software license is just not a position that we should put ourselves in. Don Armstrong -- Miracles had become relative common-places since the advent of entheogens; it now took very unusual circumstances to attract public attention to sightings of supernatural entities. The latest miracle had raised the ante on the supernatural: the Virgin Mary had manifested herself to two children, a dog, and a Public Telepresence Point. -- Bruce Sterling, _Holy Fire_ p228 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License review request
Arnoud Engelfriet wrote: Sean Kellogg wrote: Just a quick chirp from a d-l lurker with a JD that the above is a pretty common concept in consumer protection type laws and, as referenced, the UCC. Thanks for your input. I did some focus group research for Microsoft a few years back where they were experimenting with converting their licenses to regular text and using boxes for conspicuous text. I, and the research group, felt they were pretty effective. Did you check with the Legal group? I've seen lots of common-senes solutions to this type of legal issue, and somehow it is very hard to get beyond the but everyone's been doing it for 20+ years. Probably you'd have to have a court case proving that all-caps does not make for conspicuous. :-( I once tried something like: This program is WITHOUT ANY WARRANTY and is provided AS-IS, with ALL LIABILITY to be assumed BY YOU. The other side's lawyer just put it in all caps because you're not supposed to have lowercase in disclaimers. Well, that at least takes care of their all caps is unreadable argument. Yeah, actually your version is much more conspicuous, using the ordinary meaning of the word, than the unreadable all-caps version. :-/ Huge all-caps hunks make my eyes slide right over; it looks sort of like bad ASCII art. Arnoud -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Wed, Oct 18, 2006 at 08:06:19AM +1000, Anthony Towns wrote: On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote: The answer to the question in the subject is simple: NO. Thankyou for your opinion. I note you seemed to neglect to mention that you're not a lawyer. Anthony, Could you use some of the trunkloads of money available at SPI for debian, in order to consult a lawyer on these issues, instead of making such comments ? This should have been done months ago, and would have avoided probably much dispute of no-lawyer person trying to argue stuff. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
