Re: License concerns regarding package lft
MJ Ray wrote: Terry Hancock [EMAIL PROTECTED] wrote: No, what I *said* is that tools are not materials, which they are not -- at least not unless you use them as such. If you build a house out of hammers, *then* the hammers are materials, otherwise, they are tools. So, to be clear: you would claim that if one says 'this house is made using these materials' then the tools are not included in 'materials'? This is not so much clear as completely different, but yes, that is the principle meaning of the word materials and the ony logical reason why the author would've used the term here. A court is going to consider what the apparent intent was -- not try to stretch the meaning beyond the obvious. Would you expect an art *materials* catalogue to... Hereafter, you are trying to stretch the meaning to something that it obviously wasn't intended to mean. You can do that, because the license is POORLY WRITTEN. Which I have already said. Miraculously, you and I appear to AGREE on that point. One consequence of this is that some lawyer might try to play the same games with the language that you are doing here. I think the court would laugh in his face, but who knows? I'm trying to understand how it is possible to claim that compilers don't fit the meaning of materials there That would be by using the *normal*, *first* definition of materials and not some alternate meaning that has come about by association. There is also the point that it wouldn't make any sense to require the meaning you are attempting to press: is there even a compiler which can be released in source format under conditions of this license? If not, then it stands to reason that the author, knowing this, cannot have intended to limit compilation to such a hypothetical compiler. This is yet more evidence for an intent which agrees with the obvious interpretation of the language. So, are you saying you honestly believe the author's intent was to block compilation of changes to his package altogether? If so, why distribute source at all? Furthermore, you believe that having this irrational intent, he then tried to hide it by using a word which *might* be interpreted to support his intent, but whose most obvious meaning contradicts it? I find that a pretty implausible theory. Your interpretation is distorts the license's original intent by using alternate meanings of words. As such it may even be semantically correct (that is, it may be within the set of possible semantic meanings of the utterance), but it is pragmatically incorrect (it is not the subset of that set that was meant by the author -- as we can tell from context). Intent is a matter of pragmatics[1] -- the study of situated utterances as evidence for meaning, not semantics[2] -- the study of isolated utterances for potential meaning. You're pounding very hard on the semantics, trying to broaden the set of possible meanings, and you're not wrong about that as far as you go, but that's missing the point. The question was not what could this sentence possibly mean, but what did this sentence mean when the author wrote it -- which is what actually matters legally. The rest of the license, the fact of using the license, the fact of releasing software with source code and the consequences of licensing choices all provide situational information which supports the pragmatic interpretation of the sentence in question. The fact that courts (or we) have to go beyond semantics to understand the license is a serious flaw of the license, which I've already pointed out, but as evidence of the author's actual intent, I think it is sufficient. Cheers, Terry IANAL, TINLA, etc. [1] http://en.wikipedia.org/wiki/Pragmatics [2] http://en.wikipedia.org/wiki/Semantics -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The GPL and soundfonts
[EMAIL PROTECTED] wrote: On Mon, Jun 04, 2007 at 09:51:11AM -0700, Walter Landry wrote: Terry Hancock [EMAIL PROTECTED] wrote: So, the soundfont license needs to be very permissive, but I don't think there should be any concern about the tool used to create it. The license of the sequencing software does matter. If the sequencing software is non-free, then the WAV files build-depend on a non-free component. It is the same as if you used a non-free compiler to create an executable. If the soundfonts are GPL compatible, that would put the WAV's in contrib. Okay, I can see that that's a practical issue for Debian, since you want everything to be buildable from the source dist on a free tool chain. While it would make sense, I notice that there does not seem to be a DFSG guideline stating this requirement. Is there a free tool chain requirement for Debian? Even if there is, though, that's NOT the same as a GPL conflict (which doesn't occur here unless there's a problem with the license on the soundfonts). Although I would agree with that, the main matter here is not whether this WAV file would be appropriate for main or contrib, but whether it is distributable at all, since the GPLv2 requires complete source code, which includes the scripts used to control compilation and installation of the executable. This is incorrect. There are many examples of GPL software compiled with non-free compilers, and it is perfectly legal to do so. The scripts you refer to do not include the compiler itself (what is intended by the text you quote are things like makefiles). The FSF's claim is that the tool used to create a work is not covered by the copyleft on the work, nor does the copyleft of the tool affect the work. Thus, you may compile free software on a non-free compiler or you may create non-free software using a free compiler without invoking copyleft requirements. A useful analogy is word processing -- wouldn't you be very, very surprised if the GPL on a word processor forced you to use the GPL on every document you create with it (this would fail DFSG as a use restriction, BTW, if it were true)? Likewise, wouldn't you be pretty surprised if you couldn't release a .doc file created in MS Word under the GPL if you wrote it yourself? Also, if the compiler were considered part of the source for programs compiled with it, you'd have to include the entire gcc package with every C program intended to be compiled with it, which would also be pretty surprising. In any case, this is made clear by the GPL FAQ. See http://www.fsf.org/licensing/licenses/gpl-faq.html: http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLOutput Is there some way that I can GPL the output people get from use of my program? For example, if my program is used to develop hardware designs, can I require that these designs must be free? In general this is legally impossible; copyright law does not give you any say in the use of the output people make from their data using your program. If the user uses your program to enter or convert his own data, the copyright on the output belongs to him, not you. More generally, when a program translates its input into some other form, the copyright status of the output inherits that of the input it was generated from. [...] AND http://www.fsf.org/licensing/licenses/gpl-faq.html#CanIUseGPLToolsForNF Can I use GPL-covered editors such as GNU Emacs to develop non-free programs? Can I use GPL-covered tools such as GCC to compile them? Yes, because the copyright on the editors and tools does not cover the code you write. Using them does not place any restrictions, legally, on the license you use for your code. [...] AND In what cases is the output of a GPL program covered by the GPL too? Only when the program copies part of itself into the output. AND I'm writing a Windows application with Microsoft Visual C++ (or Visual Basic) and I will be releasing it under the GPL. Is dynamically linking my program with the Visual C++ (or Visual Basic) run-time library permitted under the GPL? Yes, because that run-time library normally accompanies the compiler or interpreter you are using. All of these pretty firmly establish that the license on the output of the sequencer that renders the MIDI is *not* affected by the license of the sequencer, regardless of copyleft. However, input material incorporated into the end result (i.e. soundfonts) does affect it. Actually, if the soundfonts are bundled with the sequencer, the last FAQ may apply. This is the system library exception -- perhaps interpreted a little broadly. If so, then even non-free soundfonts would be accepted. (Personally, I wouldn't want to rely on this, though). Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License concerns regarding package lft
Martin Millnert wrote: 7. no permission is granted to distribute, publicly display, or publicly perform modifications to the Distribution made using proprietary materials that cannot be released in source format under conditions of this license; Section 7 seems suspicious. Isn't that just a copyleft requirement? This is effectively how the GPL works -- denying distribution rights if the work is combined with proprietary work. The wording could stand to be improved, though. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
MJ Ray wrote: I'll let the PP answer for himself, but mention that money can be seen as a trick and you can read more about that view in Robert Tressell's book The Ragged-Trousered Philanthropist, which is PD at Gutenberg; and also that local exchange trading schemes exist, but would it make something any less a fee if someone can trade their work as payment? N.B. the idea that trading agreement to copyleft is a substitute for fee payment (i.e. that the basis for copyleft licensing is a quid-pro-quo wherein the author releases their work in exchange for a promise -- or likelihood -- of contributions to their project) is a basic game theory approach to understanding the economic success of the whole free/copyleft phenomenon. An overly broad interpretation of fee to include such agreements would not only be highly constructivist, but it would also be counterproductive to the success of the whole free software movement as well as Debian within that movement. Also, by holding up copyleft licenses like the GPL as best practice examples, I believe the DFSG rules out such overly broad interpretations. So I think the whole class of can be considered as a fee arguments must be taken with a very big chunk of salt. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License concerns regarding package lft
MJ Ray wrote: Martin Millnert [EMAIL PROTECTED] wrote: [...] 7. no permission is granted to distribute, publicly display, or publicly perform modifications to the Distribution made using proprietary materials that cannot be released in source format under conditions of this license; [...] Section 7 seems suspicious. Is this saying (amongst other things) that someone cannot use any incompatibly-licensed compiler to produce binaries of it? IMHO, it does NOT mean that. I think that a compiler or other toolchain element is not a material -- materials are things that go into a structure and become part of it: lumber, paneling, roofing, etc. NOT circular saws, hammers, jigs, etc. This would be as opposed to tools: from GCIDE: Material \Ma*teri*al\, n. The substance or matter of which anything is made or may be made. [1913 Webster] Based on this license, I believe that the copyleft would extend to things that are incorporated into or linked into the work: software libraries fonts graphic resources but NOT to things that are only used in the production process: compilers editors UNFORTUNATELY, my interpretation relies on the definition and usage of the word materials. Which I think is less clear than it could be, and perhaps requires a very good grasp of English usage, which may be especially problematic internationally. So, if possible, I would encourage the original author to improve the license text (which shouldn't bother them, because I don't think they intend anything beyond DFSG). Changing using to from -- i.e. made from proprietary materials -- makes it much clearer. There are people who would object further that proprietary is poorly defined and also that stating things in the negative is pretty confusing. But I think it is usable like it is, even if no such changes can be made. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License concerns regarding package lft
MJ Ray wrote: Terry Hancock [EMAIL PROTECTED] So, in your opinion, houses are not made using tools and binary packages are not made using compilers? No, what I *said* is that tools are not materials, which they are not -- at least not unless you use them as such. If you build a house out of hammers, *then* the hammers are materials, otherwise, they are tools. And yes of course that means that hammers used to build one house and then used as materials for another are both tools and materials, but it is a foregone conclusion in a license text that definitions are relative to the work being licensed! When a license says derivative, we all understand without being told that derivative of the work being licensed is meant, and not derivative of some other, unrelated work. Hence, when we say materials, we mean used AS materials, not things that could in principle be used as materials but were in fact used as tools. Because the license does say materials, it confines the meaning of the word using (which can have multiple meanings -- a flaw in the wording, but not a flaw in the intent). The strawman you are attempting to bait me with is an assertion of the exact opposite claim: i.e. that using not only confines the meaning of materials but that it would confine the meaning of a word like tools to mean materials. This claim is obviously false. However, that has no bearing at all on what I said. In fact, it is the nature of the word using to be almost entirely defined by the noun: to use X means to do whatever you normally do with X. Thus, the meaning of use materials lies entirely in the definition of materials. Hence, the definition of the word -- which you did not refute -- is what determines the meaning of that phrase in the license. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The GPL and soundfonts
Andrew Sidwell wrote: I'm sorry, I didn't make myself clear. That last paragraph was meant to indicate WAV files which were derived from MIDI files via use of non-free soundfonts, not the original MIDI file itself. The DFSG would require that the soundfont license be DFSG free in order for the WAV to be considered DFSG free, IMHO. The issue of whether the fonts can be combined with the GPL MIDI is trickier. Conservatively, I would say that this requires the soundfont license to be GPL-compatible. This is based on the idea that the MIDI+soundfonts WAV is a derivative work of both the MIDI and the soundfonts and not merely a use of the MIDI. However, if the license on the soundfonts is DFSG free so that the resulting two entities: MIDI and soundfonts can be distributed under DFSG free terms independently, then you might want to simply ask the MIDI creator to add an exemption, just like the one GPL graphic fonts usually use to allow PS or PDF documents that embed the font without having to GPL the documents' contents. In fact you could probably lift the boilerplate for that from one of the graphic fonts already in Debian. It probably was not their intent to restrict rendering of their MIDI. IMHO, the license of the sequencing software you used is completely irrelevant. You USE a toolchain when you create with it, you don't DERIVE from it (the exception being things like libraries -- or soundfonts -- that get incorporated into the resulting work). So, the soundfont license needs to be very permissive, but I don't think there should be any concern about the tool used to create it. Of course, the sourcecode requirement would probably insist that both the MIDI and the soundfonts are provided as source for the WAV. HTH, IANAL, TINLA, etc. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CC Sampling Plus 1.0
Ben Finney wrote: 1.the Derivative Work(s) constitute a good-faith partial or recombined usage employing sampling, collage, mash-up, or other comparable artistic technique, whether now known or hereafter devised, that is highly transformative of the original, as appropriate to the medium, genre, and market niche; and Trivially non-free. The DFSG freedom to create a derived work is the freedom to create *any* derived work, not some limited subset as defined in this license. I agree. However, I do have a question about this ... If I myself have sampled from a CC sampling plus work in producing a new work, I am under the impression that I'm pretty free to re-license as I please. (In other words, we move forward one generation of derivation). So, assuming that I pick a license that is otherwise an approved DFSG free license (not wanting to open that can of worms right now), would the fact that I had used CC Sampling+ work in my project be a problem? In particular, with respect to the source of my work, I would clearly have actually worked from the original work, being somewhat constrained in what I could do, but would my collection of pre-processed samples (say, sound effects), be a sufficient source provision? (I could certainly argue that the pre-processed samples are a preferred form for modification, since it's much less work to relocate samples than to extract them from an original work -- the latter process is generally an interactive creative one that doesn't ordinarily leave an electronic record anyway -- or perhaps, the preprocessed samples *are* the electronic record). AFAIK, such a collection of samples itself (as well as my final product) meets the requirements to escape the CC Sampling+ license restrictions (sufficiently transformative). I believe that in such a case I have not only evaded the legal restrictions of the CC Sampling license, but also that (in most cases) I am outside of what the original artist was trying to control (IOW, I'm within both the letter and spirit of the license; the artist is unlikely to consider this practice unethical. So this is not merely exploiting a legal loophole, but is rather a legitimate use of the license, following the author's intent). For comparison, this would be like using samples permitted under fair use from an all rights reserved work in a free-licensed project. What the CC Sampling+ does is to make this fair use exemption larger and more clearcut than it is with all rights reserved (in which case, it might be much more legally ambiguous, and therefore riskier to use -- also, it's much less clear that the author intended to allow such uses). ISTM that none of this is different for CC Sampling than for Sampling Plus. Noncommercial Sampling Plus is a whole different matter, though, since it attempts to control the uses of the samples (meaning we're back to only fair use exemptions). BTW, sampling in the sense of the CC sampling licenses seems to be pretty broadly interpreted (much more so than allowed by fair use). So, in some ways, it may be that the Sampling licenses are actually more friendly to the free commons than is the NC or NC-SA license -- in that you can actually extract something usable in free works from them. Am I right? Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Choosing a license for Frets on Fire songs
Jason Spiro wrote: 2007/3/28, Andrew Donnellan [EMAIL PROTECTED] wrote: On 3/28/07, Matthew Johnson [EMAIL PROTECTED] wrote: Yes that's the contract you have to sign to be part of Teosto (which you have to do if you ever want to make a living in Finland as a musician). Ouch. As was indicated earlier this seems standard for all performance rights organisations. Does that include performance rights organizations in the United States? (I'm from Canada, and most of the pop music here is from U.S. artists.) I used to think not, but now we have something called SoundExchange. The more I read about it, the less I like it: http://www.soundexchange.com/ Apparently, if you *haven't* signed with any collecting agencies, these folks automatically get the right to collect royalties for you. It is apparently an untested question whether an artist can explicitly opt-out of this right. This question has been asked a few times on the cc-licenses mailing list, and I haven't yet seen a satisfactory answer. Also, how about podsafe music (music liberally-enough licensed to be included in podcasts)? Are small indie artists who haven't entered into contracts with such organizations the only ones who can release music under podsafe licensing terms such as CC-BY-SA or CC-BY-NC-SA? See above. They aren't safe either. The only thing that protects podcasters, is that they are not subject to Sound Exchange royalty collection (i.e. it's the person broadcasting, not the artist that determines that exemption). If so: Are there any interest groups who are run lobbying campaigns against such strict rules? There ought to be. I'm not sure who it is though. The idea is not totally broken -- it's the inability to opt-out (or waive fees for specific works) that makes it unethical, IMHO. As it is, though, it stinks to high heaven -- it's one of the political doublespeak moves where you create an organization ostensibly to protect small interests, but the actual effect is calculated to bury them. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-approved creative/content license?
Ben Finney wrote: It's the creativity of a work that allows it to be covered by copyright. Non-creative works -- e.g. a plain listing of the digits of a mathematical constant -- are generally deemed un-copyrightable. I don't see what distinction you're making there with creative works. Are you making some distinction between a software work which happens to be interpreted as a program and a software work which happens to be interpreted in some other way? I don't think that's a relevant distinction. The true distinction is between aesthetic works, meaning works which are valued for themselves (i.e. you sensually appreciate the work in one form or another) and utilitarian works, meaning works whose principle value is in how they are used. If the principle value of gcc were its aesthetic appeal (e.g. you like to wallpaper your room with the printout), then it's the same as an aesthetic work like a movie or a song. However, almost no one views gcc that way. It's principle value is *use*: i.e. you compile programs with it. By contrast, there are almost no such uses of a movie or a song. They are meant to be rendered to the human senses and appreciated for their own content. This is a real distinction. In licensing terms, the difference is important, because it strongly effects the model of how the software will be created and also how it affects the consumer/user of it. Furthermore, the potential for and value of reuse is quite different. For aesthetic works, re-use is always non-essential, but individual instances are irreplaceable. A parody of Mickey Mouse, for example, has no meaning if it can only exist as a parody of Rudy Rat (some off-brand character created to avoid infringing on Disney's trademarks and copyrights on Mickey). Restricting the parody of the original therefore is directly muzzling freedom of expression. This is distinct from the case of compilers, for example: any compiler than can compile C source code is roughly exchangeable with any other (yes I know there are some incompatibilities -- but the point is that they can always be fixed if there is a desire to do so). The existence of a non-free compiler does not prevent the creation of a free one to replace it. Yet, it can be argued that you do not *need* that parody in the same way that you might need a compiler (not having the aesthetic work does not restrict your abilities to act). So, you can always choose to live without aesthetic works, without being materially damaged, but you are always culturally damaged by that choice, whereas the inability to access utilitarian works only implies the need to create free ones, and has little or no cultural consequences. It's a small step from there to realizing that freedom means something different for aesthetic versus utilitarian works. In fact, free licensing is an adequate solution for utilitarian works, but in the end, only better copyright law can fully resolve the problem for aesthetic works. Nevertheless, the needs of licenses for aesthetic works are necessarily different than those for utilitarian works. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: creative commons
Francesco Poli wrote: On Wed, 10 Jan 2007 09:08:48 -0600 Terry Hancock wrote: Is this a good reason to avoid promoting such freedoms among creators? That's a strawman argument: CC promotes By and By-SA licenses as well as NC, ND and others. If there's a fault it's that they don't offer strong differentiation in that support. Is this a good reason to drive creators away from good licenses that would make their works DFSG-free? Another strawman: CC doesn't driver creators away from good licenses. They offer several different alternatives. I don't think so. Definition of strawman argument: disagree with something no one in the room agrees with instead of disputing the issues that are actually contended. Pretend you have actually addressed real cases. :-) Regrettably, many in the Debian project have become committed to the idea that there is no difference between content and code, and yet this issue has repeatedly demonstrated the falsehood of this assertion. [...] Let's consider SID tunes. AFAIK, a SID tune basically contains code that is executed by a SID chip emulator in order to play music. Are SID tunes content or executed works? I would say: both at the same time. Seems to me the author would be a completely reasonable person to make that distinction. If they wish to view their work as more content than code then they ought to be able to do that and license accordingly. Alternatively, the package maintainer could decide that when bringing it into Debian. The problem is that as things stand, Debian no longer provides distinct handling for content and code. There are a variety of problems with the upcoming version that derive from this one problem. There are many examples that show that the boundaries that are supposed to draw distinctions between various categories of software are not clear-cut: they are blurred, with many overlapping cases. I don't think that a line of reasoning which is based on such distinctions can lead to good freedom criteria. Sorry, but you're too late. Software alone has a zillion of these kinds of fuzzy distinctions (e.g. just consider all the ways a library can be called). The whole reason why there is any discussion on this list at all is to deal with the enormous fuzzy spaces around the DFSG (which as guidelines are inherently fuzzy, even beyond the fuzziness inherent in all language) and licenses (which are less fuzzy, but still fuzzy because words are subject to interpretation). None of this is news. Fuzziness happens. This is debatable. Certainly NC-licensed works are not themselves free in the same sense that we mean with free software, Jeff Carr argued otherwise in the message[1] that generated this discussion: | That's good, I'm not convinced that CC in any form isn't DFSG. :) Yes, you're right. I misinterpreted that as meaning I'm not convinced that 'no form of CC licenses is DFSG' rather than I'm not convinced that 'no form of CC licenses is not DFSG' I'm used to allowing for small errors in grammar in mailing lists, but Jeff's later posts suggest that he really did mean the latter. I agree with you that NC and ND content violates DFSG. but they do exhibit important freedoms to the people who get them (relative to commercially-sold proprietary content -- I am all too aware of the problems they present relative to free works). Some argue that this promotes the values of freedom to people who would otherwise not appreciate the point. People so introduced to the concept, will have their awareness of free media increased and will become more interested in truly free works. No, they will adopt CC-by-nc-nd-vX.Y and happily say that their work is in line with the open source philosophy (whatever this may mean). Which in their mind it may be -- perhaps for the reasons I have relayed. But do they think it is DFSG free? There may be no actual disconnect here. Believe me, I've seen this so many times, that I can now consider it a classic... :-( You can take it as read that I'm aware of the problem. I was struggling with this kind of non-commercial problem in licenses before CC was even created. There's an enormous amount of work I've had to forgo because the author wanted NC terms. Or even worse, they will publish their works stating This work is licensed under a Creative Commons License without specifying which one and without any link to a suitable URL. Great, a Creative Commons License and we do *not* know which one! :-(( Of course, the same problem exists with the expressions a type of open source license, free software, and open source software. I've found sites making all three claims for software that does not meet the Open Source Definition, the Free Software Definition, or the DFSG. CC's recommended licensing method is to link to the specific license in question, and they provide icons and abbreviations to quickly label which license is used. That artists have not availed themselves of these resources
Re: creative commons
MJ Ray wrote: Jeff Carr [EMAIL PROTECTED] wrote: [...] It seems to me the CC is written with the same kind of mentality and intentions that the DFSG was written. [...] Hardly. CC fans seem to see nothing wrong with discriminating against any field of endeavour, such as commerce or technical protection. I'm not surprised to see MJ Ray say this, since he has chosen to ignore the fallacies in his arguments. The only field of endeavour that CC licenses block is the field of endeavour of copying and distributing without honoring the license which ALL copyleft licenses (including the GPL) do (indeed all licenses -- free or otherwise -- prevent some form of copying and distributing, or they would simply be public domain). Re-interpreting copying and distribution as a form of use has NEVER been understood to be indicated by the DFSG, despite the efforts of MJR and others to force this radicalization of those Guidelines. MJ Ray and some others don't like the particular way in which this copyleft is implemented -- because it inconveniences certain kinds of distributors, and -- indirectly -- the people they want to distribute to. While I disagree with that judgement, I respect that that's their choice to make. Some people don't like any form of copyleft: I'm perfectly happy to acknowledge their right to do that. However, the assertion that it is a fundamental issue of freedom (either an abstract concept or as described by the DFSG) is nothing but a snow job. I'm not going to write yet another re-hash of this argument. There's plenty of it on this list and the cc-licenses list. It's all been said already, so go check the archives. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: creative commons
Francesco Poli wrote: The CC lawyers are trying to draft a generic, useful and good license. Useful to *whom*? Useful to end users and to the community (and hence to the society)? Or rather useful to authors that are not willing to grant important freedoms to recipients of their works? It is important to remember that, without creators, there will be no works to have such freedoms in the first place. You may not like this reality, but it is no less true because of that. Regrettably, many in the Debian project have become committed to the idea that there is no difference between content and code, and yet this issue has repeatedly demonstrated the falsehood of this assertion. The GPL, drafted before the DFSG, and used largely as a guide for creating it (along with other licenses of the time) takes special care to protect the particular needs of software developers -- namely that source code is always made available. The principle of copyleft is designed to protect the creators of free software, and therefore, the body of work created. Likewise, CC's licenses are drafted with the particular needs of content creators. On the surface, these needs appear to be the same as those of software developers. However, there are subtle differences. The issue of banned TPM-distribution versus parallel distribution methods is one such difference. It can be quite successfully argued that for utilitarian purposes, parallel distribution serves all the needs of creators, because people who write code can control the platform in necessary ways to unlock monopoly behavior. However, content creators, whose work is not executed, and cannot change the nature of the platform, lacks those kinds of tools for protecting its own freedom. Thus it's much safer to avoid obstructionist laws or technology entirely. The CC licenses recognize that distinction. Drafting and actively promoting licenses that forbid commercial use and/or modifications harms the free software movement, rather than helping it. This is debatable. Certainly NC-licensed works are not themselves free in the same sense that we mean with free software, but they do exhibit important freedoms to the people who get them (relative to commercially-sold proprietary content -- I am all too aware of the problems they present relative to free works). Some argue that this promotes the values of freedom to people who would otherwise not appreciate the point. People so introduced to the concept, will have their awareness of free media increased and will become more interested in truly free works. Ironically, this is the same argument used by proponents of parallel distribution to try to allow TPM-locked distribution of free works through proprietary channels. Which I think shows that there is in fact a great commonality of intent, even as there are difference of opinion on implementation. Stallman overstates the case against Creative Commons, in my personal opinion. What I do believe Creative Commons has done wrong is to essentially pass off NC licenses as free licenses, diluted the free brand image. Recipients of NC works may think that they've already appreciated the full depth of free content and not realize that they are experiencing a crippled version of it. Of more particular interest to me, creators who use NC licenses may not appreciate that they are not reaping the full benefits of free media, and may become disillusioned with the idea before really trying it. These problems are better served not by CC abandoning the NC licenses, however, but by promoting better brand differentiation between NC, ND, and free licenses. The false unity created by using the label Creative Commons License needs to be eliminated. But it also has to be appreciated that CC doesn't want to make moves like that too quickly, lest they create confusion and disaffection in their existing community. As I already said, forbidding commercial use is definitely *against* the spirit of free software and the intent of the DFSG. Yes it is. But AFAIK, no one is debating the DFSG-freeness of CC NC or ND licenses. They are pretty obviously non-free. Hence, I cannot imagine a reason why doing so could be important to free software. Proponents (I'm not claiming to be one -- I'm somewhat ambivalent on this subject) argue that a taste of a small amount of freedom builds a desire for greater freedom. As I say -- exactly the same argument parallel distribution proponents use for why they don't like CC licenses' prohibition of TPM distribution. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Acknowledgment clause in GPL code?
Jordi Gutierrez Hermoso wrote: I'm curious as to the status of the following code for solving a Rubik's cube: http://www.wrongway.org/work/solver.tar.gz The readme.txt file states This program is released under the GNU General Public License. It may be modified and/or redistributed under the terms of said license. The creator is not responsible for damages occuring because of this program. IT MAY NOT BE REPRODUCED OR MODIFIED WITHOUT EXPLICIT CREDIT GIVEN TO THE AUTHOR. so what does that mean? It means the author wants it to be clearly understood that GPL != Public Domain. This is not a license, it's a license grant statement. It's like a cover letter. It's like that disclaimer you are supposed to put at the top of every source file to indicate that the GPL license applies. It *is* a less-than-perfectly-written grant statement, primarily because it doesn't mention the version of the license. But given that GPLv2 has been the *ONLY* significant version of the GPL for over a decade, it's pretty obvious that that is the one which was meant. That the wording is less than legally perfect is the reason why the author has chosen to reference an existing license instead of trying to write a new one himself. That people can find so much fault with this and go on about additional restrictions is absurd. The intent is exceedingly clear. I can understand the motivation for suggesting an improved statement to the author, mentioning that it would be better to add the version number to the license reference and that the word ORIGINAL should probably be inserted before the word AUTHOR. But that's like correcting spelling and grammar: it might be useful, but did you *really* not understand what was being said? Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python Software Foundation trademark policy
Gervase Markham wrote: The Python Software Foundation trademark policy[0] says the following: # Use of the word Python when redistributing the Python programming language as part of a freely distributed application -- Allowed. If the standard version of the Python programming language is modified, this should be clearly indicated. For commercial distributions, contact the PSF for permission. BTW guys, I suspect this is an example of the commercial==proprietary fallacy. Python programs can be put under a proprietary license, and standard library modules may be included in proprietary packages. Thus it's not entirely unexpected that a proprietary developer might want to include the interpreter itself. Having done so, they may want to advertise this fact on the label of their shrinkwrap box in the CompUSA where they are selling their productized proprietary software. In that situation -- as I read this -- the PSF would like them to seek trademark use permission. They might even wish to charge a royalty for that privilege. I could be wrong, but I suspect this is what they have in mind when they say commercial distributions. The term commercial has a wide range of interpretations by many people, and I personally it should be avoided because of confusion like this. Probably this question should be propagated back to the PSF, because it is rather unclear. I suspect that debarring Debian from using the name python to label the Debian package was far from their intent, however. Note that this is a FAQ you're reading, rather than a legal document. FAQs usually don't get the fine-tooth-comb legal treatment that licenses do! Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Open Font License 1.1review2 - comments?
Gervase Markham wrote: Francesco Poli wrote: I probably missed where the license makes sure that Reserved Font Names can only become such by being names used in some ancestor version of the Font Software. Could you please elaborate and show the relevant clauses, so that my concerns go away? There is no such clause. What sort of abuse do you think this loophole enables? After all, even if there was such a clause, I could make 200 trivially different versions of the font, each one from the next and each with a name I wished to reserve. But what would be the point? It doesn't seem like a showtopper to me, but if the license is being actively reviewed, then adding a limitation to the Reserved Font Names indicating that they must have been a former name for the font, seems harmless. After all, you point out yourself that it doesn't put a hard limit on the names used (it might be regarded as a soft limit, because it requires a 'release dance' for each one added to the list, which probably presents no problem for honest applications, but might retard abuse). I am put in mind of the domain sitter example: people staking out claims on domain names. It'd be a shame to repeat that. As already pointed out by Andrew Donnellan, this is vague, as the word document is never defined and has no unambiguous meaning. Do you have a proposed definition? What sort of things do you suggest some people might consider documents and others not? I don't have one, since I think that clearly drawing lines to tell various software categories apart is really hard. This discussion has showed up many times on debian-legal, at least since the GFDL times (I think it was 2002 or 2003): I believe there are no clearcut boundaries between documents, programs, images, audio/video works, and so forth. They can be classified in most cases, but the boundaries are always blurred. Hence defining what a document is, turns out to be hard. But ISTM that it's irrelevant. Since embedding and bundling are also allowed, it really doesn't make any difference where you draw the line. If you define document in the common-sense way it is used in the publishing industry (something you can print in a hardcopy or a bit more broadly, something which can be displayed on screen), then the document exemption protects those uses, while it does not protect software which includes the font. Instead, the bundling and embedding exemption would apply. Which has the same effect. OTOH, if we adopt the sort of extremely broad definition of document that you propose, then the document exemption applies to both. Which, of course, has exactly the same effect. So who cares how narrowly document is defined? There is one particular case which the software embedding and bundling exemptions might not apply to, and that is hardcopy documents and the files that are used to make them (e.g. PDF or ODF). Adding a document exemption makes it clear that those uses are *also* exempted, in essentially the same way as software which bundles or embeds the font. I don't really see how that could be clearer. ISTM, the document exemption *closes* a loophole, rather than opening one, ensuring user freedoms that might not otherwise be covered. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Open Font License 1.1review2 - comments?
Gervase Markham wrote: But the names aren't required to be trademarked. That sentence is nonsense in legal terms: there is no such thing as trademarking a name. A name becomes a trademark when you use it as one. Putting it in a list of reserved font names is one way of doing that. I think you are confusing the idea with *registering* a trademark, which is an assurance of trademark protection (it provides a formal means of avoiding conflict and establishing precedence), but it isn't required for trademark protection. In fact, this is exactly like post-1978 US copyright law (and the Berne Convention, IIRC): copyright protection applies from the moment of creation. Registration is a formality, which may make it easier to defend a copyright, but does not change the copyright status. Trademark is similar. We have separate marks for an (unregistered) trademark TM and a registered one (R). It's definitely a restriction over and above trademark law. (I don't think it makes the license non-free, though.) So, in fact, it is NOT a restriction over and above trademark law. Of course, IANAL, but I'm pretty darned certain of this. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Open Font License 1.1review2 - comments?
PoV). Again, common-sense says the license shouldn't bind in that case, but the license makes it explicit. Sorry if I'm being obtuse. I just don't see what the problem would be. Of course, I am not a lawyer. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Open Font License 1.1review2 - comments?
Andrew Donnellan wrote: Which means you can't combine an OFL font with a GPL font to make a new font (and not much else beyond that). True. The copyleft on the font doesn't bind the program for any use I can imagine. Not because of the document exemption, but because of this: can be bundled, embedded, redistributed and/or sold with any software provided that the font names of derivative works are changed. Sorry, I'll change the example - a GPL font. Can't combine them. All copyleft licenses have this incompatibility problem, unless they provide some explicit conversion clause. Debian has never had a requirement that licenses be GPL compatible, AFAIK. I then proceed to copy it into OOo Writer. How, exactly? How do you copy a program into OOo Writer? You copy it by selecting the source code in your text editor, selecting the Copy option and switching to OOo and pressing pasting. Okay, so it's the source code of a GPL font? Doesn't matter. The point is that it's a text document, now represented with a particular font, because of the use of a word processor. The content of the document is irrelevant. No document's content is bound simply because the font is embedded in it. That's what the document exemption is all about. Does this now give me an exemption? Does that exemption last after I take the source and compile it with FontForge or similar? Of course. The resulting font is a derivative of your GPL font. After compilation, it contains none of the OFL font, so it's pretty easy to see that it isn't in any way a 'derivative' of the OFL font. In fact, of course, there's probably no legal way that it could be made binding in that circumstance. So the document exemption may not even be relevant. But even if it were possible, the exemption makes it clear that no binding to the OFL license occurs. More importantly, the OFL license makes it clear that your ODF document containing the source code isn't bound by the OFL either (even though it 'embeds' an OFL-licensed font). Of course, the OFL font *within* the ODF document *is* still under the OFL license. So far, this seems clearcut to me. Just because it's fun to argue, though, I'll throw a wild one at you: What if the programming language for the program actually uses ODF as source code (instead of plain text), and the choice of font is significant (e.g. variable names in Helvetica have integer type, while names in Times Roman have floating point type, and StayPuft variables are strings?) Forcing a name-change on the font could break the build. However, unless the language uses the primary font name as presented to the users to distinguish fonts (a very unwise design decision), the problem can be avoided. Then, of course, the document *is* the source code, not merely a combination of the source code with formatting. Even in this case, though, the font expressly says it can't affect the license of the program (because it's the document). Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Open Font License 1.1review2 - comments?
Francesco Poli wrote: On Wed, 06 Dec 2006 11:21:05 + MJ Ray wrote: This means that forbidding derived works to carry the same name as the original software is acceptable. I believe that forbidding an unlimited and arbitrary list of Reserved Font Names goes beyond and is *not* DFSG-free. Surely requiring you not to use trademarked names is par for the course with font licenses? I think this is the *same* as the DFSG allowing name-change requirements. In fact, it sounds like they are doing you a service by providing a list of trademarked names that would be infringing. 5) The Font Software, modified or unmodified, in part or in whole, must be distributed entirely under this license, and may not be distributed under any other license. Does this interfere with dual licensing? Not following this. You can't dual license unless you are the copyright holder, and then you always can (unless you are party to an exclusive rights contract). Sounds like this is simply a (somewhat weak) copyleft. The requirement for fonts to remain under this license does not apply to any document created using the Font Software. [...] As already pointed out by Andrew Donnellan, this is vague, as the word document is never defined and has no unambiguous meaning. This is a standard exemption for font software. It recognizes that including a font in a document (e.g. a PDF or Postscript) file does not cause the license to bind the document. This is why, for example, the GPL is a bad font license, because if read technically, it would force all documents written with it to be released under the GPL, too. When people do use the GPL for a font, they usually apply a similar additional exemption. For font users, I would argue that document is a well-known term. It means you can embed the font in documents that use it. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ttf-tuffy: The Tuffy Font Family
Fabian Greffrath wrote: I have placed them in the Public Domain. PD is the most free 'license' possible. This is all 100% my own work. Means he has the right to PD the work. Usage is totally unrestricted. If you want to make derivative works for any purpose, please go ahead. Has no legal effect, but explains what PD means to those who may not understand. I welcome comments constructive criticism. Friendly invitation. No legal impact. Is this explicitely free enough for inclusion in Debian's main section? May this be the content of a debian/copyright file? Absolutely, this is consistent with past practice. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#383481: Must source code be easy to understand to fall under DFSG?
Francesco Poli wrote: On Thu, 02 Nov 2006 18:12:05 -0600 Terry Hancock wrote: Yes, it seems the question here is *whose* preferred form for modifications? The GPL appears to assume there is a general consensus on this, and there may not be. IMO, whenever there's any doubt about which is the preferred form (preferred by whom?), we should follow the preferences of the last modifier: if you actually modify a work, you've shown in practice what is your preferred form for modifications (rather than simply claiming in a vacuum what *would* be your preferred form, should you make modifications that you don't actually make!). While I agree with that conceptually, it may impossible to know. The person making the call is going to be a package maintainer (subject to review by debian-legal and ultimately the ftp masters), but it may not be easy to tell whether the upstream source has included the source as they modified it, or merely source that could be modified. This is likely to bring up things like CASE tools, project files, and change control systems. How much of these things are merely tools for manipulating the source and how much are part of the source? I don't think there's a hard line that can be followed in all cases, so a judgement has to be made by somebody in deciding what to include and what not to include. That is the interpretation that allows source to change form, whenever someone needs so. Hence, if Fred Fortraner writes a program in Fortran77 and releases it under the GNU GPL v2, David Distributer must make the (unobfuscated) Fortran77 code available as source. But then, Pete Pythonhacker can take the program, translate it into Python (because he cannot stand Fortran) and go on modifying the Python derivative: at that point, the source for the derivative is Python code... And so forth. Yes, that makes sense. But in most cases we can't really tell whether a conversion was made by an automatic process or by the author. It's clearly going to be a judgement call, but I'd guess that in a standard format which will be understood by potential modifiers is more important than in the original form which may not be. I disagree: there's no standard format (whatever that may mean) requirement in the GPL definition of source code. This is not so much of an issue for program source code as it is for other types of work, but what I mean is that an SVG is probably better than an XCF (more universal editor support). Even though Larry Ewing originally drew his Tux in Corel Draw (IIRC), it's the SVG or Skencil formatted versions that are better to include in Debian (because we have free software tools to edit these formats). I guess what I'm saying is that in these cases it's more obvious which form will be of greater use to would-be modifiers who use the distribution, whereas the upstream source may be happier with Corel Draw. It's more important that the end user is empowered to exercise his freedom to modify than that the historical process of creation has been preserved (one could pick endlessly over the details of the latter, but the former is what actually gives meaning to free licensing of a work). So if there's a discrepancy between what is going to be easy for the Debian user and what happened to be easy for the upstream author, then the user's PoV ought to be the one that really matters. Of course in your specific case, I think it'd be better to have your original XML *and* the XSLT translator so that the HTML can be generated from it. The question, I would suppose though is not one of best practice but of permissable practice, and I think the HTML is good enough. I don't think so. Machine-generated HTML is not source, at least not until it becomes the form that is actually preferred for making modifications to the work... I think you have to recognize some kind of pragmatic limit to these kinds of restrictions. The HTML certainly can be modified, and a lot more people know HTML than some ad hoc XML format. It may well be the case that the HTML would be the preferred form for modification for anyone but the original author. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#383481: Must source code be easy to understand to fall under DFSG?
Arnoud Engelfriet wrote: That's what I would think. But consider this example. I write texts in a homebrewed XML format, which makes little sense for anyone but me. Obviously I prefer to use that format. I have an XSLT transformation to make it HTML, and I distribute that HTML version of the texts. Is that source? Yes, it seems the question here is *whose* preferred form for modifications? The GPL appears to assume there is a general consensus on this, and there may not be. It's clearly going to be a judgement call, but I'd guess that in a standard format which will be understood by potential modifiers is more important than in the original form which may not be. Of course in your specific case, I think it'd be better to have your original XML *and* the XSLT translator so that the HTML can be generated from it. The question, I would suppose though is not one of best practice but of permissable practice, and I think the HTML is good enough. Should a programmer who writes FORTRAN release that code, or the automated conversion to C? I'd want the Fortran. Fortran is a standard, widely available language, and my experience with automatic translators says that they don't always generate clean/readable code. I'd say the same about flex/bison (or lex/yacc) code. I guess it's similar to the old XCF versus JPEG/GIF/PNG debate. I would say it depends on the intended use of the file. If the layers and other information in the XCF is no longer relevant, the PNG is just as much the source as the XCF. If it's likely that people want to edit I think the issue with XCF was that the Gimp project didn't want to be tied to XCF as an exchange format (reserving the ability to change it -- though I find that disturbing as it means my own XCF files might be obsoleted by an upgrade, so I think they have the interchange problem anyway). But I digress. ISTM that everything XCF does can be modelled in SVG, which suggests that a better source form for an image constructed of layers would be an SVG (rather than PNG, which loses the layering information). Unfortunately, I don't know of any XCF-SVG converters, so it wouldn't be so easy on developers. This is constantly an issue with artistic works because much of the source usually gets thrown away in the process of development (otherwise there would be heaps and heaps of it -- it's a bit like asking not for the current source code of a program, but the entire version history with diffs, and while that might be nice, I don't think it's ever been considered a requirement for freeness). In general, vector formats (like SVG) are better for collaboration, but to limit exclusively to vector formats would rule out a lot of people who don't know how (or simply don't want ) to use them. After all, it's still a lot harder to make certain kinds of art in a vector editor. Cheers, Terry (Not a debian developer or a lawyer. Just a user). -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why TPM+Parallel Distribution is non-free
effectively forbidden, because it would require discarding license text and notices (which are mandatory per the GPL). I don't think that this hypothetical situation would be equivalent to platforms where TPM are mandatory. Why? It's exactly the same situation. You have a *distribution requirement* which you have to meet, by including proper attribution and licensing. You have a technological measure designed expressly to discriminate against free content. How is that different? The CC solution is to allow the user to strip out whatever they need to run the code, but retain the requirements for distribution. Your proposed solution is asking to be able to strip the GPL license notices out of the binaries and distribute those as-is. You say that denying that right is DFSG non-free, to be precise. Yet, the GPLv2 is still considered free (despite the fact that it does deny that right). And in fact, this scenario applies to all licenses, hence all of the DFSG free ones, too. In principle, it is exactly the same as the TPM-only platform case. And taken exactly in principle, your proposal denies the DFSG freedom of ALL licenses, because you are essentially denying the validity of distribution requirements, including copyleft distribution requirements which are designed to ensure end-user freedoms. IMHO, that position is flawed. The TPM distribution proposal is simply anti-copyleft. If parallel distribution eliminated that problem I would say fine. But as has been demonstrated previously, it doesn't. 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. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why TPM+Parallel Distribution is non-free
Don Armstrong wrote: NB: please avoid needlessly embolding words: it only heatens discussions that are better discussed calmly.[1] I've emboldened key words that are important not to misunderstand. This seems to be very important as responses to several of my posts indicate that these words were overlooked. 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. 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. But that's something that will naturally happen when you bring in new people with a fresh point of view on the problem. Heat is not intended, however. At least not usually. Nobody's perfect. ;-) 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. 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. On Wed, 11 Oct 2006, Terry Hancock wrote: Don Armstrong wrote: On Tue, 10 Oct 2006, Terry Hancock wrote: Prohibiting TPM *distribution* is fine under DFSG. No, it's not. Prohibiting TPM distribution is quite clearly a restriction on a field of endeavor. Since distribution is always a use, then *any* distribution requirement is a use restriction in the broadest sense of the term. Thus, by this logic, GPL, LGPL, and even BSD are restrictions on a field of endeavor. This is a classical misunderstanding, unfortunatly. What the GPL does (and other similar copyleft licenses do) is make requirements on what you must distribute (or otherwise provide). This may indirectly restrict fields of endeavor because they are no longer profitable or useful, but it doesn't directly restrict them. [It may seem like splitting hairs, but it's an important distinction.] Which was the point of what I just said. Both GPL and CCPL make distribution requirements. There are no use requirements in either. Yet it is repeated over and over again that the anti-TPM distribution rule in CCPL3 is a use restriction. CCPL3 makes this point more clear, although I have it on authority from official CC folks that this was true before. I admit I have not carefully re-read v2.5 to check this claim. But I have very carefully read the 8/9 draft of v3 to make sure that it is currently true, and it is. Hence if GPL is free, CCPL should be also. The use restrictions being objected to are in fact distribution requirements. 1) TPM-distribution is allowed, so long as there is a parallel distribution of an equal or better version of the work without TPM, and there is a publically available key and encryption tool for converting the non-TPM work to TPM in order to play on the platform If I'm parsing you correctly, this would be appropriate; it's basically what the GPLv3 is trying to go for. I can understand that this kind of arrangement might be accepted as DFSG free, but not that it should be required for it. It has a fundamental flaw, as I have already shown: http://lists.debian.org/debian-legal/2006/10/msg00113.html In brief: A hard to apply TPM is a barrier to end user freedoms, just as is one without a publically available key or a tool to apply it. If it's #1, then there is only one practical concern, which is where the application of TPM occurs. In that case, I would argue that it needs to happen at the end-user, because that's the only way to truly prove both that the non-TPM work is equal or better than the TPM work, AND it's the only way to prove that the keys and encryption tools are available. This is the very same reasoning could be applied to compiled works; the counter arguments are the same reasons why important that we be able to distribute binary works. It may not be practicable for every end user to have the equipment to apply the TPM, or it may not be legal for them to posses the TPM circumventing devices. (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!) The reason why it's so crucial to release binary distributions of programs is simply that binary compilation is an intrinsically complex process. Because there are multiple variables (differing hardware, differing operating systems, differing drivers, etc), it is impossible to make compilation completely foolproof. In fact, to be precise, it isn't really compilation that is a problem, but rather linking. Compiling bytecode for Perl or Python, for example, is routinely done on the users' machine, even in so
Re: Why TPM+Parallel Distribution is non-free
Don Armstrong wrote: On Mon, 16 Oct 2006, Henri Sivonen wrote: On Oct 16, 2006, at 10:42, Don Armstrong wrote: If you're seriously interested in discussing how to do copylefted TPM and DRM properly, I strongly suggest reading my position statement from committee D on the first discussion draft of the GPL URL please? http://svn.donarmstrong.com/don/trunk/projects/gplv3/issues/ drm_allowing_authentication/ I don't see anything in that position statement that would indicate a flaw in CC's 3.0 draft wording. Is there something specific that I missed? That position statement is basically an introduction to a set of the problems of dealing properly with TPM/DRM; it was written before CC 3.0 was published, but the issues haven't changed. [The other parts are in the meeting notes with Seth Schoen.] More precisely, it addresses the issues created by parallel distribution. GPLv3 can't avoid this because it must deal with binary/source distribution (i.e. there is already a parallel distribution system going on, so it must be managed -- adding anti-TPM provisions to the mix gums things up, but it's not avoidable in that case). CCPL3 sidesteps it entirely, using an elegant solution which causes all these issues to be dealt with implicitly. CC can get away with this elegant solution, precisely because, being designed for content, not code, it doesn't have to deal with any parallel distribution provisions. So, I think it actually serves as a supporting argument for accepting the CCPL3 as-is. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why TPM+Parallel Distribution is non-free
Don Armstrong wrote: On Tue, 10 Oct 2006, Terry Hancock wrote: Prohibiting TPM *distribution* is fine under DFSG. No, it's not. Prohibiting TPM distribution is quite clearly a restriction on a field of endeavor. Since distribution is always a use, then *any* distribution requirement is a use restriction in the broadest sense of the term. Thus, by this logic, GPL, LGPL, and even BSD are restrictions on a field of endeavor. I claim this is absurd, given that these licenses are foundational examples of DFSG freedom. So I reject the idea that limitations on form of distribution are automatically limitations on use. The user has the freedom to apply TPM to a work in order to use it. AFAIK, that's all he needs. If a TPM tool for the platform exists and the encryption key exists, then he has no problem. After this, I have to ask, which terms are you arguing *are* DFSG free? 1) TPM-distribution is allowed, so long as there is a parallel distribution of an equal or better version of the work without TPM, and there is a publically available key and encryption tool for converting the non-TPM work to TPM in order to play on the platform OR 2) TPM-distribution is allowed under all circumstances, so long as there is a parallel distribution of an equal or better version of the work ? My reply is necessarily different depending on which you are arguing for: If it's #1, then there is only one practical concern, which is where the application of TPM occurs. In that case, I would argue that it needs to happen at the end-user, because that's the only way to truly prove both that the non-TPM work is equal or better than the TPM work, AND it's the only way to prove that the keys and encryption tools are available. And when I say available, I mean at least zero-cost, and preferably free as well. The one real complaint I've seen against this scenario is based on the idea that having the end user apply TPM is too *expensive* because the key-application tool or key costs money. In my opinion, this situation is non-free to begin with, and should be rejected. This retains the platform owner's monopoly control over who is allowed to make derivatives of works. If it's #2, then you are explicitly requiring permission for the DRM Dave scenario of a platform monopoly being imposed on all derivative works. In this scenario, the platform owner essentially hijacks the author's work and sell it to a captive audience. He denies that audience the freedom that the license is explicitly there to protect. I think we can be pretty clear that CC isn't going to accept that and I certainly hope that the Debian project will show the same commitment to freedom (an ironic situation, IMHO). This is exactly what the Aug 9 draft of CCPL3.0 says: You may not impose any technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise their rights granted under the License The critical aspect here is that parallel distribution does not cause the rights of a recipient of the work to be restricted; they retain all abilities that they had originally and gain additional ones (namely, being able to run the work on a TPM-inflicted device.) No. They already have that freedom in CCPL3.0. Problem solved. Only the distributor has to think about the license terms as they exist (the quote above is strictly from the requirements to *distribute*). The requirement is needed to ensure that copyleft preserves the freedoms granted by the content's author. No, they're not. They're a lazy means of hacking in a small bit of copyleft protection into licenses by outlawing legitimate uses. Provide an example of a *use* that is restricted (there are none). Only improper distribution, specifically designed to obstruct end-user freedoms (i.e. TPM) is prohibited. Any attempt via licensing to deal properly with TPM and or DRM must necessarily address the need for free software works to be capable of running on such a device when the end user desires it. Yes. And that's been dealt with. There are two choices: You either 1) allow parallel distribution 2) require distribution of keys or information needed to deploy modified versions to the device. CCPL3.0 chooses #2. The end user loads the TPM'd content onto the device, applying the TPM at that point. This is a practical and complete way of *enforcing* the requirement that keys (and any other information or tools needed) is available to the user. Whether or choosing to do 2) has the pratical effect of not allowing the use on TPM devices is a separate issue; it in itself does not outlaw their use or distribution. [It just minimizes their effectiveness.] Fine. Still good with CCPL3.0. If you're seriously interested in discussing how to do copylefted TPM and DRM properly, I strongly suggest reading my position statement from committee D on the first discussion draft
Re: Why TPM+Parallel Distribution is non-free
be talking about the user's skills), we need to be specific in what we mean by able. But in being specific, we introduce the problem of loopholes being found. The CCPL3.0 wording is far safer and simpler. It provides, as I've already argued, a natural assurance that end-users retain their freedoms. If this makes no material difference to you, but would convince the objectors, why not support it? Maybe it looks identical to you because you are not looking at the differences, dismissing them as generally and practically immaterial. Furthermore, that small difference is sufficient to ensure that the key (and whatever means is needed to apply it) truly is publically available. If there's any problem with that, then it indicates a problem with the freeness of the content anyway. I'm not sure that general public disclosure is necessary, but I could be wrong. Strictly speaking, the key must be available to all recipients of the work. CCPL3.0 provides this naturally, because the end user will use the key to load the material onto the device. What exactly is it you want references for? TPM is no longer a TPM once the key has been published - TPM is a matter of intent Moglen expressed this in the GPLv3 draft 2's approach to defining GPLv3 systems as not being TPMs. The opinion regarding this approach is expressed further in: http://gplv3.fsf.org/rationale which addresses this point in footnote 39 on the relevant section of part 3 of the license. and more clearly the Opinion on Digital Restrictions Management: http://gplv3.fsf.org/drm-dd2.html (It does take some digging to find this, see also: http://gplv3.fsf.org/opinions-draft-2.html and http://gplv3.fsf.org/gpl3-dd2-guide.html for other documents about GPLv3). - That TPM-parallel meeting the DFSG is based on the FALSE idea that binary/source distribution is analogous to TPM/non-TPM distribution. As I've pointed out, this is an irrelevant nitpick. It actually doesn't matter *why* Debian project members acquiesced to such an idea, just that the idea itself is wrong, which I've already demonstrated through logical argument. The source/binary analogy clouded the issue for *me*, so I projected that experience onto other people, in what is, admittedly, speculation. Otherwise, it's difficult for me to understand why so many people should be so easily fooled into ignoring solid logical arguments. Also, your refutation of this suggests only that the source/binary analogy was not used to *form* the parallel distribution proposal (perhaps that's true). However, it was certainly used by adherents to *promote* the proposal, and that is where my experience comes from. IMHO, it is not a great leap of logic to suppose that what is offered in support is accepted as support. It remains the most plausible explanation as to why so many people have acquiesced to the idea, and certainly if you object to the suggestion that this rationale was ever followed, you have no grounds for objecting to my stating that it is false and shouldn't be followed, for the benefit of those of us who were snowed by it? AFAICT, at best, the above have been supported by name-drop. At worst, not at all and research suggests the opposite. Now you're just attacking. I don't think refering to CCPL3.0 or public statements by Moglen or Garlick constitutes a name drop. How terribly presumptious of me, to assume that the debian-legal readers objecting so vehemently to CCPL3.0 have actually *read* it, or that comparisons to the GPLv3 draft can be easily found, by going to http://gplv3.fsf.org. I presume people know how to find the CCPL3.0, the GPLv3, the DFSG and the other sources mentioned. I've already referenced the archive for Greg London's DRM Dave test case. As I note in http://mjr.towers.org.uk/blog/2006/debian.html#notconsult CCPL3.0 You don't actually. Maybe the link is old? is buried in a PDF in a list archive, while GPLv3 is on a web site that doesn't follow the web content accessibility guidelines, so not all data about its current state is visible to all. The DFSG are at http://www.debian.org/social_contract#guidelines - if only everything was as easy to read. The logic is all pretty obvious. The only part of your logic I object to is when TPM can cause problem X leads to the conclusion prohibit TPM instead of prohibit X. Perhaps if that's what I had said, or rather what the CCPL3.0 says, but it doesn't. It says *distributing* in TPM-locked form is disallowed. The practical result is that TPM can be *used* whenever the ability to convert a non-TPM work to TPM form suitable for playback is available to the end user. It does this in the simplest and most fool-proof way possible: it ensures the ability of the end user to apply TPM through the simple expedient of making that the way to access CC material on a TPM platform. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi
Re: Why TPM+Parallel Distribution is non-free
Francesco Poli wrote: On Sun, 08 Oct 2006 21:45:46 -0500 Terry Hancock wrote: So, are you asserting that if the CCPL3.0 included an allowance to distribute TPM'd files, so long as the key necessary to apply TPM to modified works based on the non-TPM'd version were publically available (or always available as part of the non-TPM'd distribution)? Am I asserting that if $LONG_SENTENCE, then what? I'm not sure I understand your question, since something seems to be missing in it... :-/ Yes, you're right. Obviously, I was asking that if this were true, ... you would claim the license were DFSG free. I would agree with you in that case, but I would also claim that such agreement implies the existing license is DFSG free (because there is no difference in principle between them. Both restrict certain platforms in exactly the same way -- they do not allow distribution of works already encrypted to work only on that platform). What is the basis for Debian's objection to the anti-TPM clause? Isn't it that it is considered to be discriminatory against person or fields of use because it (supposedly [1]) discriminates against users of TPM systems? AFAICT, the objection is that an anti-TPM clause (such that it forbids any TPM in any case) forbids porting to some platforms. I would agree with you in the case that all application of TPM is forbidden, but as I've mentioned, that change is already conceded. The end user can apply TPM if needed. In the case of interest (the TPM key is publically available), this already provides the user with the freedoms you ask for (he is certainly able to use the content on that platform). In the case that the key is not available, your alternative wording continues to restrict the users ability to use the platform. But of course, that is not the license, the license-writer, or the licensor's fault. It is a decision made by the owner of the platform. I think that no such porting should be disallowed, as long as it can be done without denying recipients the ability to exercise the rights granted by the license. But one of the rights granted by the license is to produce modified works that can also be used by the user on ANY platform, including the one he's currently using. Certainly if the platform is common enough for it to matter that use on it is unrestricted, then it's common enough for a restriction against making works for it to also matter? It seems paradoxical to me that Debian should take such pains to allow free works to be ported to restricted platforms, because of freedom, but then to dismiss the loss of freedom that results from doing so. Likewise, a clause that forbade porting the work to Windows systems would be considered non-free. Then the GPL is non-free if Microsoft decides to implement a system to scan the package file and refuse to unpack, install, or run the file if it finds a copy of the GPL license in it. (Strictly speaking, I think it would have to look for the GPL notices that must be retained in the binary -- harder to implement, but the same in principle). You see, I think the thing you might be missing here is that the creator of the work has no control over whether the TPM key might or might not be available: it is a property of the platform, just like the platform being TPM-only. I am well aware of this. Just as the presence of a third-party software patent that covers a piece of software is not under control of its author. Again, you are inconsistent. If *this* is not non-free, then neither is the existing anti-TPM distribution clause. Both restrict distribution of files in a format that can only be read on a certain platform. If the key is publically available, then in practice, the user will have exactly the same freedoms, because it's possible to encrypt files after receiving them. Note that in the anti-GPL platform example above, the end user can remove the GPL license for the purpose of running a program (*use*). But he still has to include it when distributing the package (*distribution*). Likewise, the existing CCPL3.0 terms require the file to be distributed in a non-TPM'd format, but the end user may apply TPM in order to play the content. The anti-TPM clause in CCPL3.0 is a *distribution* requirement. It places NO *use* requirements whatsoever. If a platform uses TPM to prevent the work from running on it, and provides no means (e.g. a publically available encryption key) to allow the work to be run on it, there's nothing we should be required to do about it. So the point is, no end-user freedom is gained by your proposal: either proposal allows the end user to install content on TPM-only platforms for which a TPM encryption key is publically available and denies it on platforms for which it is not. In fact, the only thing it gains is increased complexity of the license. The end-user freedom that is added (with respect
Re: Why TPM+Parallel Distribution is non-free
MJ Ray wrote: Terry Hancock [EMAIL PROTECTED] wrote: 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, [...] I agree that Terry Hancock asserts allowing TPM-parallel licences is a violation of the DFSG but does not support that with any evidence. No. I said it permits a violation. What a platform owner may do, is take an otherwise free+copyleft work and release it under non-free terms. He may do so in a way that obstructs competition from free+copyleft works. It is essentially the removal of the copyleft on the work. You are of course right that effective copyleft is not required by the DFSG. However, I find it highly disturbing to imagine that the Debian Project is taking a position against the support of copyleft to retain future freedoms for users. So is finding For the rest of this message, I concentrate on the argument that prohibiting all TPM is fine under the DFSG. Prohibiting TPM *distribution* is fine under DFSG. This is exactly what the Aug 9 draft of CCPL3.0 says: You may not impose any technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise their rights granted under the License The entire section refers to *distribution*, not *use* (this should be obvious from the wording -- if we aren't talking about distribution, then who is the recipient?). The requirement is needed to ensure that copyleft preserves the freedoms granted by the content's author. Note that it occurs in parallel with the standard copyleft statements which make it clear that no further restrictions may be imposed. TPM is merely being included as one such means of applying restrictions against users' freedoms. I think it is not because it hinders free redistribution and discriminates against use of some platforms. Not only is this untrue, but it is in fact reversed. Allowing TPM distribution allows a platform-owner to obstruct redistribution of the work. 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. Problems I see with this argument so far: 1. AFAICT, parallel distribution was first suggested as a TPM-countermeasure [in 2003 at least] long before the binary/source analogue was first used in explanation [in 2005] so how can it be based on it?; Oh give me a break. Like they weren't thinking of that in 2003. The analogy is obvious. That it is incorrect is less so. This has little to do with my argument, though. It just shows a plausible explanation for a mistaken consensus. But explanable or not, the consensus is mistaken. 2. 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. Saying that a work distributed for platform A is free because you can play derivatives on platform B, even though you can't play them on A, is just double-speak. Obviously, a real copyleft insists that you can modify a work and play it back on the platform the work was designed for (that you can do so on other platforms is also required). 3. Debian has not determined it - we are not at that late a stage yet; Good. Let's *not* determine it, because it's wrong. 4. Debian is a distribution - probably the above meant the debian project. That's called synecdoche. 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. As I mentioned on cc-licenses, this is incorrect. The technology is potentially problematic. But it is only when the law is coupled to it that it becomes a serious impediment. A purely technologic obstacle can always be overcome (and once the solution is available, then it can be shared legally if the solution is not itself illegal). Consider DeCSS. The technology was overcome quickly, but Debian still can't distribute the resulting library for legal reasons. Also, CC3.0draft appears to prohibit use of that technology, regardless of whether or not a bad law is active - it appears to export the DMCA to everywhere. Actually, that's a valid point. I'd be happier if it made it clear that TPM means only legally-backed TPM. I can't see that it makes any real difference with the current wording, though. 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. Moreover, it turns
Re: Why TPM+Parallel Distribution is non-free
Hi. Not that I'm necessarily conceding other points, but the one below is the most interesting one... Francesco Poli wrote: Wait, wait: if the TPM are based on public key cryptography, you could have the necessary key for applying them, but not the key that's needed to pull them off. In that case, when you receive an All Rights Reserved work with TPM, d[R], you cannot get R back and share it with your friends or modify it in any way. You can only use d[R] on Dave's platform (perhaps for a limited number of times or for a limited timeframe). On the other hand, when you receive d[A] along with A (parallel distribution) under the CC-by-sa-v3.x, you can exercise all the rights granted by the license on A and re-apply the TPM to A (or A') in order to use it on Dave's platform. I think that TPM with a published encoding key are still effective TPM (as long as the decoding key are held secret). So, are you asserting that if the CCPL3.0 included an allowance to distribute TPM'd files, so long as the key necessary to apply TPM to modified works based on the non-TPM'd version were publically available (or always available as part of the non-TPM'd distribution)? If so, I'm not sure you're wrong, but you are being inconsistent. What is the basis for Debian's objection to the anti-TPM clause? Isn't it that it is considered to be discriminatory against person or fields of use because it (supposedly [1]) discriminates against users of TPM systems? But if that's true, then your modification doesn't change things. It still restricts distribution in TPM form for platforms for which the TPM encryption key is *not* publically available. And of course, as we've shown, the TPM-only platform owner *does* have motivation to keep this key secret, because doing so protects his monopoly. You see, I think the thing you might be missing here is that the creator of the work has no control over whether the TPM key might or might not be available: it is a property of the platform, just like the platform being TPM-only. Only the TPM-only platform owner has this right or ability. And he therefore has the ability to make non-TPM works work on his platform (at worst, he must provide the ability to apply the TPM in the download process to the platform). The key freedom that we need here is NOT the freedom to distribute TPM'd files, but the ability for the user to apply TPM to his own files in the process of loading them (CC believes this has always been the case due to 'fair use'/'fair dealing', but is planning to clarify the point in the next draft). This gives him the freedom to play free content on a TPM platform -- so long as the TPM encryption software and key are made available. And if they're not, then the platform has expressly made itself non-free, and there's nothing we can do about that.[2] So the point is, no end-user freedom is gained by your proposal: either proposal allows the end user to install content on TPM-only platforms for which a TPM encryption key is publically available and denies it on platforms for which it is not. In fact, the only thing it gains is increased complexity of the license. Cheers, Terry [1] I say supposedly because the CCPL3.0 anti-TPM requirement is a *distribution requirement*, it's not a use restriction. [2] We can't escape this possibility in general: Consider a platform that scans for GPL license notices in code and refuses to run them if they are found. Retaining the notices is a requirement of the GPL, but doing so would render the programs unrunnable on this hypothetical platform. In a sense, this is exactly what a TPM-only platform is doing (except that it's easier to implement). A platform designer can always find a way to restrict use based on form of distribution, and the only defense we have on that is the defense used in the GPLv2: if you can't meet the distribution requirements, you just can't distribute it. -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
License for Standards Spec?
Hi all, This question came up in the process of drafting a definition for open file formats -- what licenses are acceptable for the specification documentation? In many cases, it is to the benefit of the community that a standards body officially approves the specification, which would seem to translate to not allowing modified versions to be distributed (I think this might even be true of some existing standards like the W3C's HTML specification). What about the RFCs? Are such documents DFSG free? It seems like they would fail, since it normally mandates modify+redistribute rights for software. Is this an example of documentation needing a different standard? Or is there a way around the official version problem that makes sense? Thanks for any comments, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Re: QPL clause 3 is not DFSG-free
On Saturday 15 March 2003 03:06 pm, Thomas Bushnell, BSG wrote: Fair Use does *not* allow you unlimited rights to create derivative works. It might suck, but it just doesn't. Copyright law restricts copying and the preparation of derivative works, even if you don't distribute the derivatives. nitpick Actually fair use *does* allow derivitive works if not copy and distributed: I can paint mustaches on all the portrait posters I buy, write notes all over my books, and cut and paste them into pastiches of themselves, type the contents into my word processor and alter it to my heart's content. So long as I don't make copies for sale or free distribution, I'm completely within fair use. Presumeably the same applies to programs. /nitpick -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Re: The Show So Far
[I screwed up and sent this to Glenn first, apologies] I'd also like to ask a clarification of scope question: Are we discussing whether: 1) The GPLv2 should be interpreted to treat RPC calls as creating a combined work? 2) The GPLv3+ should be altered to make RPC calls create a combined work explicitly? 3) Whether a license that interprets RPC calls to require release of server source is DFSG free? So far, I'm just saying that I think requiring release of server if an RPC call is made from a Free work is a Bad Thing on general principles. It's better to release the server source, but legal force has too many side effects, IMHO. Still sitting on the fence a bit, though, which is part of why I'm still talking so much. ;-) On Wednesday 12 March 2003 08:55 pm, Glenn Maynard wrote: People who develop GPL code do so with the understanding that nobody can take that code and make it proprietary. Well, yes. But it does so by restricting redistribution, not use. And use restrictions are generally viewed (and I agree) as non-free and possibly legally-impossible anyway, as a violation of copyright fair-use principles. Surely the carrot -- allowing free developers to improve the software instead of having to bear all development costs on yourself -- is adequate to encourage release, without the stick. If we believed this, then we would all be using BSD licenses, not GPL. The GPL is written with the express belief that this is not true. (Experience shows--lots of proprietary vendors, such as Microsoft, have taken BSD code, integrated it into their products, improved it and never contributed back code at all[1].) Okay, touche. But I'm *not* trying to argue against copyleft in principle. I'm saying it isn't the only reason people share code. And no, I'm using the GPL on my project. I *would* actually like to avoid the case of someone developing on my codebase without releasing it. With the GPL, no one can release (or sell) their modifications without releasing source. That means the only person who would make modifications without releasing them would be someone who wants to provide the service. And IMHO there's reason to believe that having that motivation makes it more desireable to release (they have less to lose and more to gain by it than a developer who intends to sell the application directly -- or so it seems to me). Being their own customer, they would be more sensitive to the customer need -- which is for the service to work well, and the cost -- which is development. They would typically be on a thinner margin than someone selling the software to high-end customers. Those are both strong reasons to prefer an open-source development process. The tricks that people have learned to make money from open-source software (e.g. selling services instead of software goods), it seems to me, work both ways: when you're selling the service, the open-source approach makes more business sense. I don't know, maybe that's wishful thinking, but it *seems* reasonable. I agree that the RPC loophole may either be unfixable, or it may not be possible to fix it without sacrificing too much freedom elsewhere. I'm not yet convinced, of course. I do think there's a potential problem; I'm not *quite* convinced it'll become a real one. I'm moderately convinced it won't be, which is my point. And I do think that closing the loophole would require onerous non-free-ness of the licensing. I think as long as the problem is theoretical, we shouldn't be trying to solve it this way. I'd want to see a clear and present danger before doing something like that. At present it seems to me that there's too much unknown -- both about what possible threats exist and about what would be lost in flexibility by restricting use like this. In my particular application there is one possible solution (just thought of it), using social pressure: The application is meant to be multi-homed, residing on multiple servers with varying degrees of cooperation between them. It would not be onerously non-free (IMHO) to make releasing source changes a requirement for joining such a trust group (i.e. you get to join my club if you do the right thing and release source changes for your site, even if you aren't redistributing it). There are practical advantages to this as well as philosophical ones -- keeping all the networked sites more or less in synch is liable to improve interoperability. I know that won't work as a general solution, though. Hmm. Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Re: The Show So Far
On Thursday 13 March 2003 03:45 pm, Thomas Bushnell, BSG wrote: Terry Hancock [EMAIL PROTECTED] writes: On Wednesday 12 March 2003 04:34 pm, Thomas Bushnell, BSG wrote: Right, so here's what I'll do. I'll create a non-free derivative of [...] I know you meant this as a code hijacking horror story. But I don't see wrongdoing or problems with this. By definition, you are providing the computing hardware to run the above service. That costs money and is provided as a service. You have a right to charge for that alone, IMHO. I don't think it's a horror story at all. Have you been paying attention to my recent posts? Well, actually I guess I got kind of muddled. I did notice since then that you appeared to be arguing my side. ;-) To summarize my own opinion (as of now): 1) The GPLv2 doesn't require release of a server just because it's used by a GPL client. If it's remote, then this is because it's not released. But I'm not even sure that it can be applied if it's shipped together. The GPL allows mere aggregations of software with different licenses. And the server might also fall under the major component exception (is that the right wording?) that the operating system can. Basically I find the idea that an RPC call makes a combined work to be wrong. To be honest I always thought the dynamic linking concept was already getting fuzzy, so extending to RPC and/or client-server models is going way too far. 2) The GPLv3 ought not to try to take away this freedom, because a) it shouldn't take away more freedoms in general, b) it runs afoul of fair use, c) it might seriously stifle innovation while having few practical benefits. 3) DFSG freeness of such a license I have no real opinion on. I think it's less-free, but whether it's sufficiently so to de-bar it from Debian is not something I feel qualified to address. I don't personally like it, though. 4) I would like to see ideas for incentives to encourage people to release modified server code, especially if the server is derived from GPL sources. 5) The public performance argument sounds more interesting to me than the combined work argument. Perhaps the GPLv3 should explicitly address obligations of public performance and explicit scope of what *is* public performance (i.e. formally define an Internet service). That is also abusable, but perhaps less so -- all we require is that source be made available if the *server* code is GPL. (the client's licensing needn't contaminate the server licensing or vice-versa). That seems much fairer to me, and more in the spirit of the copyleft concept. I certainly wouldn't object to it if it were me doing the service, and it would protect my application legally. And it does fall within existing copyright provisions. Yeah. I guess I think defining public performance is the right way to go -- at least I can't see what's wrong with it from here. ;-) Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Re: Barriers to an ASP loophole closure
On Thursday 13 March 2003 03:56 pm, Thomas Bushnell, BSG wrote: Jeremy Hankins [EMAIL PROTECTED] writes: My understanding (IANAL, etc) is that public performance could cover this sort of thing (the problem would be scaling it back to cover only what we want it to). Are you simply objecting to that on principle, or is there some reason people shouldn't or couldn't do that? I don't think there's any reason to think that constitutes public performance. Is there *any* case law? It does seem logical, though... Consider a DVD movie (I only specify DVD because it is more obviously a software program than a VHS movie is). If you run the program in the privacy of your own home, copyright doesn't apply, because that's fair use. But if you play it on a big screen at the park, you need further permissions and may have to pay royalties. Now, what if I played it through my web server? I don't give you the DVD and I don't let you access the menu directly, so I am not distributing the work through the web, I'm just playing a video using some streaming video format. Now that is clearly public performance, isn't it? Would anyone seriously argue that fair use lets me do that? (It might matter whether I charge you for access or not, but I don't think so. The Internet has already been likened to a broadcast medium, and playing via television transmitter is certainly considered public performance). If I did let you access the menu, that wouldn't be any better, would it? Then the program would be more interactive, and therefore more closely resemble an RPC call. As for scaling it back to what we want -- that's easy, you just include a new section to cover what sorts of public performance rights are granted and which are not. And as a condition, you include the mandatory source-offer (just as with re-distribution, but perhaps with more reasonable terms for web services. That solves the problem rather neatly, and without so many side-effects. From a pragmatic POV, anyone who's running a web service for the public at large should not be suffering from the desert island or chinese dissident question -- providing source packages should not strain their resources at all. More dangerous is probably the question of program versus data. Was the DVD movie I mentioned above a program performing or a piece of data? But if it's data, it's being distributed. If it's a program it's being performed publically. Either way it might fall under copyright terms. Hmm. Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Re: Standard non-copyleft free license?
On Tuesday 11 March 2003 04:56 pm, Glenn Maynard wrote: On Tue, Mar 11, 2003 at 03:46:05PM -0800, Terry Hancock wrote: They could, of course, sell the software to someone else, but the usual caveats about selling free software (i.e. you can be easily undersold) apply. That might be valuable to them if they wanted to build significantly on it, though. The only way you get this is if you require that the software remain free: that they not be able to add a bit of non-free code to it, and add restrictions prohibiting further redistribution. The only way you'll get that is with a copyleft, not with a BSD-ish license. No, you misunderstand me. I know they can make a competing derivative of the code I produce (but I don't particularly fear this). The problem I'm trying to solve is of specifying ownership of the actual code I deliver. If I don't say anything in the contract, it might be interpreted as work for hire, and they can sell me *verbatim* the code I give them under contract under a proprietary license. *That's* what I'm trying to avoid. I don't think they will particularly care to compete with me on the market, so I'm not especially worried about that, but in any case the fact that mine will be GPL'd is all the leverage I would need anyway. To contrast the two cases: NO LICENSE AND OWNER UNSPECIFIED * They may own the software under the work for hire concept (and it probably takes a court to decide). * They have the right to sell the code under a proprietary license. They can prevent me from distributing it under *any* license or deriving my own version from it. BSD-TYPE LICENSE * I own the software, but it is free-licensed. * They have the right to sell derived software under any license they want AND SO DO I. * I release *my* derivative version under the GPL, and no one can say I can't. That is, the caveats you're referring to are caveats of copylefted software, not of free software in general. They're caveats of both, generally speaking, at least until the other party contributes enough code to seriously compete with me. At that point, I don't care too much, though -- they'll be different products. You must remember that I will have already made my money on this when I deliver it. Thank you very much for the boiler plate version and links, David Turner and Don Armstrong. I do wish though that there were a cannonical, name-recognizable version like the GPL that one could simply refer to, or copy verbatim. Maybe I'll try to fill that niche by posting a few sample licenses with use instructions like the FSF does with the GPL. The idea is to have a sort of best practice list, since the GPL is not *always* the right choice. I like copyleft, but in this case I don't need it, and it improves the value to my client, who is going to pay me well for it. As for legal advice, yeah I know I'm on my own. ;-) I do actually have a lawyer I can ask, but it's not really her specialty. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Re: The Show So Far
On Wednesday 12 March 2003 01:12 am, Anthony Towns wrote: On Tue, Mar 11, 2003 at 12:49:19PM -0800, Thomas Bushnell, BSG wrote: The ASP loophole, it seems to me, is merely another technical means for a dynamic link, and should be subject to exactly the same requirements as for all other kinds of dynamic linking. That would imply that all GPL clients for which there are no GPL servers are undistributable. I don't believe that interpretation has any legal justification, either; there is simply no copying or modification taking place. If I may inject a utilitarian user-perspective point -- I think it would be a crushing blow to open source users if licenses started banning the ability to use GPL clients with proprietary web services and vice-versa. Which it sounds like you'd be doing if you were to define, say, XML-RPC as a dynamic linking process. In fact this is getting into the client-server model, and you're starting to say that the GPL denies you the right to look at http://www.microsoft.com with a free web browser, or http://www.fsf.org with IE. What's the difference? The distinction between a web protocol (HTTP) and an RPC API (XML-RPC) is somewhat artificial, and definitely legally fuzzy! Now suppose I create a proprietary web site on a CD (not so popular anymore, but still has uses), and I want to put Galeon, say, with sources on the disk so you can read my site. If it's a static site (I gather) you'll say this is okay, but if the site has any active content (say a binary CGI), then you're going to start saying I'm actually linking the code? What about interpreters? I was under the impression that a Free interpreter could run non-free code and vice-versa. But that is even a tighter binding than these RPC issues. I don't know about the philosophical purity of my POV, but this kind of restriction would make me *feel* very non-free in using the software -- either as the potential CD distributor or as the person who now has to download the browser from somewhere else because license restrictions forbid putting it on the CD with the data / web application. So I would hate to see such an interpretation take hold. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Re: The Show So Far
On Wednesday 12 March 2003 04:34 pm, Thomas Bushnell, BSG wrote: Right, so here's what I'll do. I'll create a non-free derivative of GNU Foo, which adds a splendid text-manipulation function that many people want. And I'll write a CGI so that people can type in text and my web site will run the modified GNU Foo. I'll charge people money for this service, and never release my changes. The original GNU Foo did make its source available over the web interface, but my modification does not. I know you meant this as a code hijacking horror story. But I don't see wrongdoing or problems with this. By definition, you are providing the computing hardware to run the above service. That costs money and is provided as a service. You have a right to charge for that alone, IMHO. Furthermore, if you made enough modifications and/or innovations to prevent being outcompeted by a free competitor derived from the same GPL sources you used, then you have committed considerable capital resources. Once again, IMHO, you have a right to charge for your work. If I don't like to pay you, I have an easy option -- just replicate from GNU Foo. The point is, if it's *easy* I don't have a problem and if it's *hard* then you earned your money. Either way though, there's a non-negligible market force pressing you to release anyway, since as your user-base grows then either your costs increase (perhaps non-linearly since web services don't scale in a completely linear way) or your service level declines. Either way, it becomes increasingly attractive to switch to multiple providers or a distributed library (for users). Unless it is extraordinarily hard to duplicate your work (or run the server), this will happen. And if it is so difficult that is a legitimate reason to keep using the service. (Think of the Google example again). I personally do not think that putting Google into the pincher is a desireable goal. Surely the carrot -- allowing free developers to improve the software instead of having to bear all development costs on yourself -- is adequate to encourage release, without the stick. David Turner thinks this should be prohibited, and therefore the GPL should be changed to prohibit it. You have said that as long as no distribution happens, it's fine. Which is it? Well, I don't know what *he* thinks, but *I* think the GPL as-is is a better thing. I think the change would cause too much collateral damage to be worth whatever it might save us from. (at least, including your example, I haven't seen a compelling reason to fear the present rules continuing). Again, this is mostly the perspective of a user. Although, I am in fact developing a web application, and for me the carrot is far and away sufficient to release the code, even though I expect there will be few actual deployments. I'm hoping users of my site will be motivated by the desire to make my site more useful to them. I do see the counter-point though: what if Microsoft adopted my code and put in 1000s of man-hours into out-competing me on the web? But I'm not convinced that's a serious threat -- there are serious reasons why their product would be inferior to mine if I am accepting free-collaboration. Maybe a more concrete example of threat would change my opinion. But the counter-threat of eliminating the flexibility of web services would stifle innovation (do *you* know the full potential of such services in 10 years? I don't). And you have to erode fair-use to impose such a restriction, which I don't like in principle. Hmm. Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Standard non-copyleft free license?
Admidst the storms of controversy, I'd just like to ask a (hopefully) simple question... ;-) The GPL is the clear winner for being a maximally standard copyleft free license. The BSD license is apparently not directly usable (mentions Berkeley explicitly, etc), so these licenses are generally called BSD-type. Or, AFAIK, anyway. Is there a *standard* boilerplate for a BSD-type or say maximally free non-copyleft license (if BSD doesn't cut it). The only requirement I want to have is that credit is given correctly and that it positively asserts that I own copyright in the work. Probably also the no warranty language. No advertising clauses are needed. ;-) I am delivering work on a contract, and this is (to be) part of the contract terms -- i.e. that they get the code with no strings, but it isn't theirs. That is, they can't turn around and charge me a license fee to use or redistribute the code I wrote! The important distinction is to prevent it from being considered a work for hire in the usual sense. I don't want to ruffle their feathers by making them consider all the license details -- I'd like to just say BSD license or some appropriate standard that they can live with. They could, of course, sell the software to someone else, but the usual caveats about selling free software (i.e. you can be easily undersold) apply. That might be valuable to them if they wanted to build significantly on it, though. Also it must be freely convertable to GPL, as, if I build anything on it *after* the contract, I'll want to have copyleft on the changes. The package is probably going to be a collection of Debian packaging scripts to install a large suite of scientific applications using apt/apt-get, so it is I think on-topic, since I will most likely want to contribute the code for use by Debian packagers (I don't think Debian will accept it directly for policy reasons, but it shouldn't be too much of a fix-up -- basically I need to use a weird prefix to keep my installation out of the way of the OS and optionally-selectable, it also has to load on Red Hat and Solaris, etc.). If no such standard boilerplate license exists -- would it be reasonable to propose publishing one with instructions, along the same lines as the FSF has done with the GPL? Thanks, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Re: Do we have trademark infringements by fonts?
On Tuesday 18 February 2003 04:28 am, Anton Zinoviev wrote: A friend of mine has pointed me that it is very likely that many fonts have problems with trademark infringement. I suppose that some (most?) of the font names are registered, I don't know what is the right legal choice, IANAL, but what Corel did with Corel Draw, which included a whole lot of look alike fonts was to give them alternate (but similar) names. They probably claimed trademark on them. So, for example, Lucida becomes Lucid or Lucy and so on. Designers using free software would just have to get used to the new names (never bothered me with Corel Draw, and I'd be fine with it in Debian). So, Debian could simply use new names and actually claim tradmark status on them to prevent any kind of grab for the names (but that's easy enough if you just call it Debian Lucid or something). You could distribute a key somewhere which says that Debian Loafer is derived from Gold Brick or some such thing. Since it doesn't represent the alternative *as* the original, that's perfectly okay -- you're just claiming the fonts are similar (and I think you can do the equivalent internally when considering font substitution rules). This is just my impression of what's been done before by companies who were faced with this issue (I'm pretty sure I've seen other examples of this, but I know Corel did it). Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Re: license =? copyright
On Monday 03 February 2003 08:21 pm, Antoine Mathys wrote: On the other hand, I found that in a package I am interested in (it 's already done BTW), Otter : http://www-unix.mcs.anl.gov/AR/otter/legal.html This software is public domain. It's funded on government grant, and the copyright holder explicitly disclaims any rights in the work. It is yours to do with as you please. The main legal force of this statement is to tell you they aren't going to be held legally responsible for it (no warranty). Which you knew anyway. The license is somewhat immaterial -- it simply describes US government policy regarding work done on government contract. You can rely on that more firmly than the actual text of the license (which is worded funny, but appears to me to mean the right thing). If I take a government contract to develop software, it is understood that I can't claim any copyright in it. Government contracts are supposed to enrich the public domain, not subsidize monopolies. Unless the contract has some special provision for allowing me to retain copyright (some of them do, but it's difficult to get those terms), then this general rule applies. Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com Some things are too important to be taken seriously
Re: academic software without licence
On Monday 03 February 2003 08:31 pm, Sean 'Shaleh' Perry wrote: On Monday 03 February 2003 20:13, Terry Hancock wrote: But available to everyone, with no restrictions does give you distribute and modify, since non-modification is clearly a restriction. available gives you the right to have it, not the right to give it to someone else. with no restrictions does. If you give me something without restrictions -- I can give it to anyone I please. It doesn't matter if it's a program or a car. I can change the engine, swap the tires, park it in my backyard to rot, or blow it up. Of course, if that breaks any laws, *I'm* liable, not you. The fact that it's software doesn't change this part, IMHO. I translate that as redistribution and/or modification. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Re: What new name means?
On Thursday 30 January 2003 03:41 am, Juhapekka Tolvanen wrote:
It seems, that some licences require, that modified versions of original
work must have new name. For example Design Science Licence is like
that
But what constitutes new name?
If I release some poem called Ode to Buffer Overflow under DSL, and
some guy called Joe Random Poet creates modified version of it, which
of these names would be acceptable for that modified version?:
- Ode to Buffer Overflow (Joe Random Poet Remix)
- Ode to Buffer Overflow (version 1.0-Random-1.0)
- Ode to Buffer Overflow revisited by Random
The important point is to correctly identify a modified version as a distinct
work. If you want changes to be folded into the original work, you should
submit them to the author or get their permission. Otherwise, you need to
release under a name which is sufficiently different so as to not confuse
potential readers/viewers/users that it is the original author's work.
The social engineering of this, is that DSL-type licenses want to have
fewer, more complete releases. That's not good for every sort of work, of
course, but it makes sense for novels or movies, for example. If I'm reading
a novel, I want to know *who wrote it* and *what the author's voice is*.
I don't want to accidentally read some fixed version, unless I know for
certain that's what it is.
Think about the sanitized versions of *Mother Goose* that became popular a
few years back. Sure, cutting off the mice's tails (three blind mice) was
gruesome, but if you're going to change it to protect sensitive little
imaginations, you should call it New Mother Goose or something, and not
bill it as the original.[1]
This is a defense of the author's moral rights in places where there is no
legally defined moral right in a work (which includes the USA, for example --
in fact it is only in the EU that I have heard of moral rights being
defined).
The DSL doesn't prevent perversions of the original work, but it can
insist that they are not labeled the same as the original, which could damage
the original author's reputation.
This is (IMHO) only sensible for creative content works which might carry
some significant political or emotional impact. (I can think of edge cases
for software, but in the main, programs are very objective, and there's
little reason to demand such protection). I think if we could think of a
legal way to define it, we'd specify that such name changes were only
important for content changes and not structure or formatting changes.
(e.g. changing a fullscreen movie to letterbox format shouldn't force the
change). Unfortunately, that's way too fuzzy to put into a license, since
opinions of what is and is not content are very subjective.
Anyway, the reason I'm rehashing the reasoning is that it ought to be
reasonably clear from this purpose what needs to happen with a name change.
I think putting a subtitle in parentheses or adding a prefix is fine:
Ode to Buffer Overflow (revisited)
New Ode to Buffer Overflow
Ode to Buffer Overflow ('03 remix)
Joe Random's Ode to Buffer Overflow
But merely appending a version number:
Ode to Buffer Overflow (1.2)
is not really okay, because mere numbering does not show you that it's a
fork. Instead, it implies that it is in the main branch.
If you think about it, people do this for GPL stuff too, it's just not
*required*. Xemacs and emacs forked a long time ago, and we need
separate names to distinguish them. Likewise ghostview and gv.
Note that we're not talking about ever single version changing -- all
versions approved by a given author may have the same name.
You could probably get this kind of protection by trademarking the name, too,
of course.
Caveat -- I didn't write this license (Michael Stutz did), but I did use it
for a project of mine. I chose the GPL for a game engine and DSL for the game
content to play on it. (Unfortunately that project's currently dead).
Artists are very dependent on (and sensitive to) reputation issues. No one
wants their work misrepresented. Nor do they want inferior hack jobs passed
off as their work. This is Joe Random's 'Mona Lisa with moustache', not Da
Vinci's original 'Mona Lisa'. ;-D The DSL is a compromise between GPL-like
complete freedom to modify and the possessive don't fool with my work
positions. Having some control over this is a good motivator for creative
types, who might well feel violated by changes that would be perfectly okay
under the GPL (and which probably wouldn't bother programmers).
Cheers,
Terry
[1]Some pedant may well note that Mother Goose is public domain, so is not
protected by any such requirement. I am of course speaking in the
subjunctive: if it *were* under the DSL this particular abuse would not be
allowed.
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com
Some things are too important to be taken seriously
Re: CLUEBAT: copyrights, infringement, violations, and legality
On Tuesday 28 January 2003 08:16 pm, Branden Robinson wrote: Okay, I'm going to a pull an RMS and plead for a change in our collective use of certain terms. [] A nice collection of arguments, but I'm really uncertain why you're posting it here. Isn't this kind of preaching to the choir? Or did I miss something so that the cluebat needs to be used on me? :-D Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Re: CLUEBAT: copyrights, infringement, violations, and legality
On Wednesday 29 January 2003 09:58 am, Henning Makholm wrote: * Because copyrights are not inherent, are not natural rights, are not granted by God, but in fact merely incentive programs instituted by governments, one does not violate the rights of anyone when one disregards or acts contrary to a person's copyright. You seem to be happy enough with speaking about infringing copyrights. Is there some kind of deep difference between infringe and violate? Well, as a native speaker of English, I would say, yes, there is a *huge* difference in the connatative value between violate and infringe. It may even be the difference you are looking for. Infringe, does not, IMHO, imply any moral weight to the act. If you build your fence two meters onto my land (by intent or accident), you are infringing my territory, but if you knock my fence over and come onto my land without permission, you are violating it. In the former case, we discuss it quietly in civil court, in the latter, I go for my shotgun. ;-D -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com Some things are too important to be taken seriously
Re: Bug#176267: ITP: mplayer -- Mplayer is a full-featured audioand video player for UN*X like systems
On Wednesday 29 January 2003 01:40 pm, Richard Braakman wrote: Does it bother anyone else that this completely subverts the point of having patents in the first place? Heh. The patent system has outlived its usefulness, yes. I believe that it actually was still useful sometime around 1900 or possibly even as late as 1950 or so. But since then, it has gradually declined to the point of undermining its precise reason for being -- to promote technological progress. I don't even distinguish between software and hardware -- I think they're both pointless obstructions. In the present era, I believe anyone who could actually afford to use the patent system to protect their inventions doesn't need patents to do so, and those who might conceiveably benefit can't afford to use it. Furthermore, it promotes a general fear of litigation -- punishment for independent innovation. It may serve to prop up existing institutions, but it does not serve the society, IMHO. But then, I also believe I will have a very hard time convincing enough people of this to get the USPO abolished. So we're just doing brinksmanship here, AFAICT. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com Some things are too important to be taken seriously
Re: [Discussioni] OSD DFSG convergence
, I *do* like the relative simplicity of the DFSG, and it *is* a guideline to be refered to in making decisions, not a contract that must be complied with. I think of it as a checklist to remind people what questions they should be asking. Whether a few things need to be added to that checklist or not, is perhaps open territory, though. But even after making changes, it doesn't seem reasonable that it should become the OSD, and even if it did, it doesn't seem reasonable to commit to keeping it in synch. You can't harness joy, you can only nurture it. Debian is all about a labor of love, and I think it needs to stay that way, or we'll lose the thing we're fighting for. IMHO, of course, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com Some things are too important to be taken seriously
EULA with GPL??
This came up in a local LUG ML I participate in ( http://www.sgvlug.org ) recently: Does the GPL as written (Vers. 2) allow a distributor of a modified software to impose a *use* restriction on users? At first, I thought, No way!, but I see the other guy's point ... Section 0, says in part: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of which means this license does NOT *grant* usage rights (it just assumes them), whereas the section I would expect to protect me on this, says: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. Note granted herein -- does that mean that the use right actually *isn't* guaranteed, so that a separate agreement could constrain use? Does section 6 guarantee that the usage right is kept, or is it somehow guaranteed in law, or is there another section which addresses this (I've looked of course, but didn't see anything that seems to do it). It occured to me that in order to have a click-through EULA, this hypothetical software would have to have it in the code, and I have to have the full sources, so I should be able to remove the EULA from the source, recompile, and not have this click through ceremony happen. If I did that, would the software then be free-and-clear? Or could they make me click through it to, say, download the software in the first place? (And the EULA be viral too, so that I have agreed to force anyone else to do the same?). As for relevance to Debian, can one assume that the GPL absolutely guarantees DFSG free? (As I'm pretty sure the DFSG *does* guarantee me this right). Has this guy found a loophole, or are we both just clueless about the law? (entirely possible). Would really love to hear a more clue-ful opinion. :-D Thanks, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com Some things are too important to be taken seriously
Re: Hardware license (status)
On Wednesday 04 December 2002 06:28 pm, Rich Walker wrote: After interesting discussion on and off debian-legal, I'm now down to a choice of one hardware license for everything except the firmware which will be GPL'd. The hardware license is probably the OHGPL http://www.opencores.org/OIPC/OHGPL.html with clause 2 modified to read You may copy, modify, distribute, and/or ... The outstanding problem (AFAICT) is the suggestion that hardware under the OHGPL might not be compatible with GPL-d hardware or software. Okay, IANAL, but I believe there's NO WAY you can make hardware that it would be incompatible to run GPL software on, no matter what license or restrictions it has (unless you have some kind of EULA that specifically binds the customer not to do it -- which, of course, you don't). The thing is, running software on a piece of hardware is USING the software, not copying, distributing, modifying, or distributing modified copies. The GPL specifically doesn't address USE at all. Secondly, the GPL specifically is not affected by the licensing of the operating system or other basic environment issues. After all, almost all PCs are proprietary, non-free designs through-and-through, so as a practical reality, the GPL would have to allow this. As a more extreme case, you are allowed to run GPL utilities on a Windows system. Likewise, I do not think the GPL can really address the problem of combining implementations of GPL'd designs with your implementation. I don't believe the GPL can be sensibly applied to the actual hardware without changing the language to specifically map the concepts over (in fact, I feel that's what the OHGPL attempts to do). So, IMHO, the only possible conflict is -- can you combine a GPL'd design with your design and redistribute the combined design? I think you ought to just cover yourself, and say explicitly that the design's license may be converted to GPL at the user's discretion. The GPL insists that whenever it is combined with another free license, the resulting product must be licensed under the GPL -- it does not acknowledge the possibility of converting to another license instead. So, the only way you *could* combine with GPL'd designs, is to convert to GPL. (Though pesonally, I think the idea of applying an unmodified GPL to a hardware design is daft to begin with, because its terms can't be applied to hardware without significant amounts of interpretation). As with the LGPL, the OHGPL is clarifying an edge case, is slightly more permissive than the GPL, and ought to be convertable to GPL. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com Python takes the pain out of programming ... ... and Zope puts it back again.
Re: Documentation licenses (GFDL discussion on debian-legal)
On Thursday 05 December 2002 02:52 pm, Joe Wreschnig wrote: Advocating a policy of don't upload every piece of data that exists is not censorship, it's common sense. Yes, I think it would be cool if I could do 'apt-get install alice-in-wonderland'. I also think it would be a waste of resources and outside of the goals of the Debian project. I agree with this, if for no other reason than that Debian is already too big (8 CDs is rather large). It's just pretty bloated from the end-user's point of view, and although there's a vague notion that the more popular packages are on the earlier disks, there's no clear separation so that the user can make an intelligent subset to meet their own needs. However it would make an awfully neat project in itself! I'd love to see a conversion of Gutenberg texts to a rich text format, packaged with an appropriate reader (and/or a filter that auto-converts Gutenberg's de facto format into a nicer reading form and/or spell-checks it, etc.), and using apt-get with debian packaging. If you did it right, such a literature distribution could just be added to your sources.list and you *could* apt-get install alice-in-wonderland without having to take up Debian resources for it or bloat the existing Debian distribution. I'm sort of occupied at the moment, but I might seriously want to take a hand in organizing something like that in the not too distant future. I'm certainly going to think about it some more. :-) Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com Python takes the pain out of programming ... ... and Zope puts it back again.
Re: Hardware license
On Monday 02 December 2002 12:04 pm, Walter Landry wrote: Rich Walker [EMAIL PROTECTED] wrote: Terry Hancock [EMAIL PROTECTED] writes: The LART license is probably required reading on this subject ;-) http://www.lart.tudelft.nl/LICENSE This is pretty much the same as the BSD license. You suggested that you wanted to copyleft your work, so it may not work for you. It is certainly DFSG-free. It is BSD-like, and you might want to modify this clause: FHL Modifications to this HARDWARE INFORMATION may be copyrighted by their FHL authors and need not follow the licensing terms described here, provided FHL that the new terms are clearly indicated on the first page of each file FHL where they apply. to reflect GPL-like terms -- i.e. that modifications of the HARDWARE INFORMATION must retain the same license, which seems like a simple change to the license. I like the distinctions made between modifications to the source files, and manufacturing and use. I think anything that places restrictions on the product after manufacturing it is sure to kill it, since, unlike a binary software, significant investment of resources is required for this step -- it seems like you would want to assure the user that they can re-coup this cost and profit from it. On the other hand, you might want to specify, much as the GPL does, that the HARDWARE INFORMATION be included, or made available to anyone who receives the DEVICES. I figure you could: 1) Require HARDWARE INFORMATION to be included with the DEVICES. 2) Require a free offer on request, or free download location for the HARDWARE INFORMATION to be included with the DEVICES. or 3) Require merely a reference or URL to where the HARDWARE INFORMATION can be obtained. I like #2 myself -- easy on the distributors, but makes them bear the costs. Yes; I'm currently looking at that and the OpenIPCore license. http://www.opencores.org/OIPC/OHGPL.shtml. I hadn't seen this one before, and I'm very interested in it myself. The OpenIPCore license is a more of a copyleft, so you'll probably be happier with it. Looking through the license, it looks mostly ok. The only thing that caught my eye is section 5 5. Any modification of this hardware design or any derivative work from it should be documented by providing list of changes, reasons behind the changes and the date of change. Requiring people to list the _reasons_ for a change is somewhere closer to the edge of DFSG-free than I'd like. It might be fine with it, but it'd be better to just change it to 5. Any modification of this hardware design or any derivative work from it should be documented by providing a list and the date of the change. This seems like an incidental change to me, but I'm not really sure how it threatens DFSG free-ness. Indeed, reviewing the DFSG again, I can't find any points that this challenges. It seems to me to be a fairly simple requirement that can be easily discharged. From an end-users' point-of-view, BTW, I really like the original wording. It's harder to run a diff against a drawing, and hardware requires an expensive manufacture and test cycle compared to compiling software, so it's very useful to have a note identifying where changes occured and why. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com Python takes the pain out of programming ... ... and Zope puts it back again.
Re: Suse Products legal?
On Sunday 01 December 2002 12:34 pm, Hanspeter Roth wrote: Suse is selling several products such as `SuSE Firewall on CD' which are based on Linux and probably other tools under Gnu-license. Their price ( 1000 Euro) is much beyond the cost of media and manual. Shouldn't they offer products based on Gnu-software by conditions based on Gnu-license? Are their products legal? Sounds perfectly legal to me from your description, though I haven't seen the CD, and I am not a lawyer. Nothing in the GPL says you can't charge whatever you want for your distribution. Furthermore, proprietary software can be distributed on the same disk as the GPL'd software. They must, however, provide source (or an easy way to get it) for all the GPL'd code included. They also can't link their proprietary code into the GPL'd code (they can do this for LGPL'd code), and they can't be selling proprietary software *derived* from the GPL'd code. (and derived does not mean calls, can be linked to, or distributed on the same disk as. It *does* include already linked to and distributed as binary. LGPL further allows distributing linked code, so long as the source for the LGPL'd part is included). The motivation for not paying SuSE in this case is market-based -- you could always get the free software from somewhere else. Of course, for corporate users, SuSE has done a service no doubt, by collecting and configuring the software for you, possibly providing tech support etc. So for some people, it might be worth it. You can, of course, copy the GPL'd stuff on the disk as much as you like -- there may be proprietary stuff on it too, though -- you'd have to read the license they give you for the distribution. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com Python takes the pain out of programming ... ... and Zope puts it back again.
Re: Hardware license
On Tuesday 26 November 2002 01:59 pm, Rich Walker wrote: We've been putting together some robot-related software and hardware. We want to release this with a DFSG-compliant license set. For the software, GPL, no problems. For the hardware we propose to include .pcb files for pcb, .sch files for gschem, and .asm files for the PIC firmware. What licenses are appropriate for hardware releases? The LART license is probably required reading on this subject ;-) http://www.lart.tudelft.nl/LICENSE and you'll probably want to look at the site in general http://www.lart.tudelft.nl/ for other information about an apparently successful open hardware project. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Re: question about leaving lzw and unknown-license code in source
On Monday 11 November 2002 11:02 am, Anthony DeRobertis wrote: Fortunately, the lzw patent expires this coming June. Is that true? That would be really nice! (Finally, I can support buggy old browsers in my web application). No sarcasm -- lots of people are still using them, and I'd like to use some GIFs to keep them happy (I'm not really going into production mode until June anyway, probably). Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
