Re: GFDL and cover texts
On Tue, 2007-07-08 at 14:15 +1000, Ben Finney wrote: Those documents cover the issues you're raising; there's nothing I've said in the above that isn't already addressed by the documents Evan pointed you to. I've started a wiki page about the history of Debian and the FDL; it may be useful for assembling links and data about the relationship and about the factors that went into our decision: http://wiki.debian.org/GFDLHistory It may actually make sense to link to relevant (or just long) threads on debian-legal. -Evan -- Evan Prodromou [EMAIL PROTECTED] Debian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GFDL and cover texts
On Mon, 2007-06-08 at 08:58 -0500, Jordi Gutiérrez Hermoso wrote: Can I get an explanation of why Debian considers a GFDL manual with cover texts non-free? http://people.debian.org/~srivasta/Position_Statement.xhtml http://www.debian.org/vote/2006/vote_001 http://www.google.com/search?q=GFDL+Debian -ESP -- Evan Prodromou [EMAIL PROTECTED] Debian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Free art license, CC and DFSG
On Tue, 2007-06-03 at 10:06 +, MJ Ray wrote: In his role as DPL, that same ftp-master (or archive maintainer, if you prefer) has endorsed [2] the Debian Creative Commons Workgroup which opined [3] that the CCPL 3.0 is suitable for Debian main. [...] I think [3]'s the opinion of the Workgroup leader. My opinion is based on the contribution of debian-legal participants, of the workgroup participants, and of my own review of the licenses. I believe that the Workgroup, including yourself, considered the license draft that included the explicit parallel distribution proviso to be compatible with the DFSG. That includes the amended revocation and attribution clauses that Francesco is concerned with; we thought they were sufficiently softened that they were not an effective prevention of licensors exercising their freedom. I think the loss of that explicit parallel distribution proviso was regrettable, but I also believe that a large number of debian-legal participants have said that the DRM clause, as it stands, is free enough to allow distribution under DRM if such DRM is not effective -- that is, if steps are taken to preserve downstream users' freedom. Most considered it to be open to parallel distribution, even without an explicit proviso. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
[Fwd: Re: [cc-licenses] Comments on the latest public CC draft]
I answered Francesco on cc-licenses, and I thought it'd be useful to forward the answers here, too. ~Evan ---BeginMessage--- On Sun, 2007-25-02 at 19:16 +0100, Francesco Poli wrote: In a recent message[1] to the cc-licenses list, a new draft of CC-v3.0 licenses was announced. I don't believe this is a draft anymore; it's now a released version. Since this is the case, it probably makes sense to have at least part of this conversation on debian-legal. This is unchanged with respect to the previous drafts: I'm not yet convinced that this clause meets the DFSG. I disagree, and I think there's been some general agreement that if the request-to-remove only applies to metadata like authorship credits, it's DFSG compatible. Note that the original author cannot interfere with the contents of the work itself. This is unchanged with respect to the previous drafts: credit must be at least as prominent as the credits for the other contributing authors. Even if the licensor's contribution is not comparable to others. *IF* a credit for all contributing authors of the ... Work appears. In other words, if you're listing out everybody, list out everybody. If you don't want to list out everybody, you can just leave people out as you wish. I, and other members of the Debian CC Working Group, *don't* think that that is an onerous burden that makes it practically difficult or even impossible to exercise DFSG rights. I disagree. ~Evan -- Evan Prodromou -- http://evan.prodromou.name/ By God! I will accept nothing which all cannot have their counterpart of on the same terms. -- Walt Whitman, Song of Myself signature.asc Description: This is a digitally signed message part ___ cc-licenses mailing list [EMAIL PROTECTED] http://lists.ibiblio.org/mailman/listinfo/cc-licenses ---End Message--- signature.asc Description: This is a digitally signed message part
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
On Tue, 2007-30-01 at 03:30 -0800, Don Armstrong wrote: The bright line is actually pretty straight forward: Do you modify the file with syntactic whitespace or the file without? Is it preferable to modify the file without the keyword expansion or with? That's not a very good line at all. I don't modify source LZ-compressed, yet that is how I distribute most of my code and how most of the source in Debian is distributed. We're talking about a case where a developer has used a lossy compression algorithm (which I think we all agree is foolish and useless) that can be more-or-less reversed with tools readily available in most programmers' toolset. It's not run through an obfuscator, nor is it object code or virtual machine code, nor is it code generated from a higher-level language. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
On Tue, 2007-30-01 at 11:54 -0800, Don Armstrong wrote: This refrain keeps getting repeated, but still no one has explained how distributing a form of the work which is _not_ the prefered form for modification satisfies section 3 of the GPL: So, I think we all readily admit that _some_ transformations on the original source (like compression) are acceptable. The distributed source code does not need to be bitwise identical with the source edited by the developer to be the preferred form. I think we'd all be pretty comfortable with some other transforms, like \r\n - \n line ending conversion or character set changes. I think that, instead of hewing to the line that any transforms on the code are unacceptable -- clearly unsupportable -- we should probably deal with this particular case and whether this particular transform is acceptable. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
On Mon, 2007-29-01 at 14:06 -0500, Yaroslav Halchenko wrote: I've ran into a problem: given firefox extension released under GPL as shipped (.xpi files) has obscured .js files -- all formatting was removed. So, if I read your comments correctly, the .js files aren't intentionally obfuscated. Whitespace has just been removed in order to speed up download. It may be misguided, but it's also pretty common among JavaScript programmers. I was able to run the JavaScript code through GNU indent (http://www.gnu.org/software/indent/ ) and get readable and modifiable output. I think there are some special-purpose JavaScript beautifiers out there that could give even better formatting. I don't think that this is a case where the user gets unmodifiable source. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: GPLed software with no true source. Was: Bug#402650: ITP: mozilla-foxyproxy
On Tue, 2007-30-01 at 08:59 +1100, Ben Finney wrote: The point is that the recipient isn't getting the preferred form of the work for making modifications to it and can't therefore fulfil the terms of the GPL when distributing the work. It's obvious that some transformations are acceptable for distributing source code. I assume that lossless compression like zip or gzip is OK, right? As well as conversion of character codes (ASCII - Unicode)? DOS line endings to Mac- or Unix-style line endings? I know that stripping whitespace from the source code is a step beyond this -- it _is_ lossy -- but it's not _too_ far off. The re-indented code isn't fun to edit, but it's definitely possible to do. I think if someone was being extra-careful, they'd avoid re-distributing, but if it were me I'd avoid loaded statements like no true source or accusations that upstream was distributing spyware. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: Elive requires donation to download
On Fri, 2006-24-11 at 07:08 -0800, Ottavio Caruso wrote: Elive http://www.elivecd.org/gb/Download/Stable/, based on Debian, requires a donation, however small, to allow downloading the stable version. I wonder if this legally sound. Is that just wondering out loud, or a particular question? I think it should be fine license-wise, except if they've included any non-commercial hoohaw from non-free. Probably the only potential sticking point is making source code available, for those packages that have licenses that require source code availability at no cost. I think that if you don't have to pay an additional fee, on top of the first donation, to get the source code, they should probably be in the clear. -Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: What is the most restrictive DFSG approved Commercialism prohibited
On Wed, 2006-22-11 at 00:06 +0200, Jari Aalto wrote: I need to talk to upstrem that wants to prohibit commercial use of the software. What Licence I should suggest to him? The current hand written license permits the software to be used in GPL programs -- except the ssoftware cannot be used for commercial purposes. Prohibiting commercial use is incompatible with the DFSG. 6. No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. Typically people who are opposed to commercial use are really opposed to commercial _exploitation_. They don't want their work to be used unfairly or selfishly. A copyleft license like the GPL can prevent some of the more egregious misuses of a piece of software, but not all. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Owner will be laid off
Hi, Would you like to make 1.5K to 3.5K per day just for returning phone calls? If you have a telephone and can return calls you are fully qualified. Call us - 800-391-9084 Goodbye, Evan Donne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Public discussion time for Creative Commons 3.0 license draft coming to a close
Hi, everyone. Pardon the wide distribution, but I wanted to make sure I didn't miss anyone. As some of you know [1], a workgroup within Debian cooperating with Creative Commons [2] to make some of their licenses compatible with the Debian Free Software Guidelines [3] so that CC-licensed works (images, video, sounds, documentation, help text) can be part of the Debian operating system. [4] We reached some good conclusions, which resulted in the current Creative Commons 3.0 license but unfortunately some of the people in the Creative Commons community -- a diverse one, just like Debian's -- have managed to knock the process off track. [5] The license draft now available leaves out some key clauses that the workgroup thought necessary to make the license DFSG-compatible. The draft has been subject to public review for more than a month now, and the discussion period is drawing to a close. Creative Commons general counsel has said that they'll consider public opinion when it comes to making a final decision about this license. So, for those of you who want to see Creative Commons licenses that meet our standard of Freedom, this is the time to act. Please, if you haven't already, take a few minutes to send an email message to the Creative Commons public review mailing list [6] letting CC know that you support a Debian-compatible version of the license. I want a Debian-compatible Creative Commons license, signed John Q. Hacker is probably plenty. Complaining to each other 6 months from now won't do any good; the time to complain is now, when it can make a difference. We've got a narrow window in which to let CC know that the Free Software guidelines matter. Please spread the word to other Debian users and supporters as well as into the rest of the Free Software community. Thanks for your time, ~Evan [1] http://evan.prodromou.name/Debian_Creative_Commons_Workgroup_report [2] http://creativecommons.org/ [3] http://www.debian.org/social_contract#guidelines [4] http://people.debian.org/~evan/ccsummary [5] http://creativecommons.org/weblog/entry/6017 [6] http://lists.ibiblio.org/pipermail/cc-licenses/ -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: License review request
On Sun, 2006-01-10 at 10:54 +0900, Sanghyeon Seo wrote: I am intending to some of my codes licensed under MIT license to the new license of my devising. I would like to have it reviewed. Will this code be going into Debian? I am deadly serious. No, you're not. The license itself says that it's a parody. Anyways, I don't see any reason that that license wouldn't be compatible with the DFSG. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: CC's responses to v3draft comments
On Tue, 2006-26-09 at 09:42 +0100, MJ Ray wrote: So, CC's leadership suggests that the workgroup's presented view is not debian's view, which effectively kills the workgroup because its lead starts arguing CC's point in public. What point is that? You're simply wrong on this, and if you go back to the email discussions on the debian-cc list you'll see that you're wrong. Mia talked to us about the Rio decision as if we had no options; *I* was the one who pointed out the results of the GFDL GR to her. You insist on a conspiracy theorist's view of the situation: that the CC leadership subverted parallel distribution for some reason mostly to do with humiliating Debian and that international affiliates didn't oppose parallel distribution. Your theory is internally inconsistent. Why would Garlick and Lessig give us a draft license with a parallel distribution proviso in it, just to take it away again? What about posts to the cc-licenses list by international affiliates saying, I opposed this proviso at Rio? Most importantly, who cares? Whether or not there's a conspiracy, the same task is needed: to make the case to the public, on cc-licenses and elsewhere, that rigid anti-DRM clauses inhibit freedom and and that parallel distribution at a minimum is needed for users and for developers. There is a strong emotional knee-jerk reaction against parallel distribution, since it allows DRM. It takes some work to overcome that reaction. As a member, I share common responsibility for the workgroup's failure on this, but it is not my fault alone. Your failure is in not making a convincing argument to the public on the cc-licenses list about parallel distribution. You are very intelligent, well-versed in this subject, and you convey ideas clearly. You have some experience talking with at least a few of the people opposing parallel distribution on the list. You could make a difference, but you're not. However, there is still hope: CC's leadership decision is not CC users' view. Joe CC Public seems to have no input into it, or oversight of it. cc-licenses. Fixating on the mechanics of CC's decision about parallel distribution has done little good, and demonizing Creative Commons over it has done less. How can anyone discuss decisions made by a secret process for secret reasons in any useful way? If that decision is to be changed, it helps to know how and why it was made, but we simply have almost no data on it. There's a clear process for changing the decision: get public opposition against it, primarily on the CC's principle public conduit, the cc-licenses list. I have seen it work in the past; for instance, with the proposed changes to the 2.0 ShareAlike clause to allow any ShareAlike license to be compatible with any other. I'm disappointed that anyone would think starting with 'you may feel' excuses posting personal attacks to an open list. I'm sad to see that when presented with a difficult situation you've resorted to ineffectual smear tactics. I'm sad to see someone who could be doing useful work for Debian and for Free Software obsessing about minutiae. I know you can do better. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: Creative Commons 3.0 Public draft -- news and questions
On Sun, 2006-24-09 at 11:47 -0400, Nathanael Nerode wrote: If they wanted to prevent license complication why didn't they base CC3.0 on CC-Scotland's plain and simple English that already allows parallel distribution, rather than the CC2.5-generic that IIRC doesn't? 'Cause they're not that bright. ;-) Basing 3.0 on CC-Scotland probably seemed too radical and basing it on CC2.5-generic seemed more conservative. People make stupid decisions like that. Most of them probably never even read CC-Scotland, despite our suggestions. Are you talking about this license? http://creativecommons.org/licenses/by/2.5/scotland/legalcode It doesn't seem to be a shining example of simplicity to me. Here's the relevant section from CC Scotland: 2.2 However, this Licence does not allow you to: 1. impose any terms or any technological measures on the Work, or a Derivative Work, that alter or restrict the terms of this Licence or any rights granted under it or have the effect or intent of restricting the ability of any person to exercise those rights; ...and from CC 3.0 generic draft: You may not impose any technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to them under the License. The Scottish one has a nice brevity in that it combines concerns about DRM and extra license terms, and restrictions on verbatim and modified copies, in one sentence. Otherwise, I don't see an order-of-magnitude difference in the simplicity of the text. ~Evan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CC's responses to v3draft comments
On Wed, 2006-27-09 at 09:30 +1000, Nic Suzor wrote: One thing that I am getting from Mia's argument is that CC is having difficulty actually identifying people who would benefit from a parallel distribution clause. She has stated that she is not aware of a substantial segment of developers who would incorporate CC-licensed material into products which require DRM (e.g., free software console game developers). Can we get some examples, or at least a plausible use case which we can put forward to CC? If we keep talking about hypotheticals, I think we're less likely to be heard. I know that there are some Free Software games that use CC data elements (interstitial images, music, etc.) I wonder if any also use a game engine that has been ported to e.g. the PS/2? That's an interesting thought. ~Evan -- Evan Prodromou -- http://evan.prodromou.name/ By God! I will accept nothing which all cannot have their counterpart of on the same terms. -- Walt Whitman, Song of Myself signature.asc Description: This is a digitally signed message part
Re: CC's responses to v3draft comments
On Mon, 2006-25-09 at 09:47 +0100, MJ Ray wrote: Indeed. I can't see how I can discuss things with Creative Commons when their official line is that they've decided I'm wrong for reasons they won't tell me. Classic Star Chamber politics. We have no documentation on how parallel distribution is absolutely necessary to satisfy the DFSG, nor do we have much of a mechanism short of a GR to determine if this is the consensus of Debian as a whole. Fixating on the mechanics of CC's decision about parallel distribution has done little good, and demonizing Creative Commons over it has done less. You may feel that if you can denigrate CC enough, you've excused yourself for failing at the job that Debian developers and users have asked you to do and that you have accepted. I hope not, since it's sloppy reasoning and it's unbecoming of you. I'd be disappointed if someone with as fine a mind as yours gave up so easily and comforted himself with name-calling. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: CC's responses to v3draft comments
On Sun, 2006-24-09 at 12:06 -0400, Nathanael Nerode wrote: Worse, the PDF description of the parallel distribution amendment appears to describe an amendment which is less restrictive than necessary for Debian's purposes (see comment 11). (Proper parallel distribution requires the unencumbered to be distributed to every recipient of the encumbered: though not technically with the encumbered, it's effectively the same, and that's not mentioned in the response.) Given this (mis)interpretation, I would probably oppose such an amendment too. :-/ If there is a mistake there, it is probably my fault. I'm confused as to why the unencumbered version must be _distributed_ to each recipient, rather than just _made available_ to each recipient. (I differentiate here between packaging the two versions inseparably together, versus putting the unencumbered version on a public Web site, say.) I believe it's immaterial to the DFSG-compatibility of the license, but I wonder why you think it's required for proper parallel distribution otherwise. Hence, it seems that CC refuses to disclose the intended meaning of the clause... I think the plaintext meaning should be assumed unless the licensor specifies otherwise (reference UW-Pine case), and we know that the plaintext meaning allows parallel distribution. (Of course, if there is a court case, we'd have to defer to that, but until there is, I'd go by the plain meaning.) My guess is that Mia's response is a political one. Their international affiliates have opposed additional parallel distribution language; we've said that the language in the 3.0 draft may be enough to allow parallel distribution anyways. Rather than getting them upset, she's given us a barely-qualified yes. I think we should take our victory as gracefully and discreetly as we can. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: Creative Commons 3.0 Public draft -- news and questions
Marco d'Itri wrote: [EMAIL PROTECTED] wrote: Well, it prohibits an entire class of derivative works: the ones that (accurately) credit the author of the original work! As I said elsewhere: I can release an annotate version of a CC-licensed novel, but I could be forbidden to accurately acknowledge the authorship of the novel I comment on! Don't you feel it's awkward? No. I feel that it is very reasonable for the author of a work to be able to request to not be credited if for some reason he does not want to be associated with some derivative works. Creative Commons did what we recommended here: http://people.debian.org/~evan/ccsummary That is, they limited the removal requirements only to authorship credits. I think the general consensus was that it's OK to request reasonable modifications to metadata like authorship credits, but not to request modifications to the work itself. Considering that we think it's OK for the author to request to be /added/ to the authorship credits, it seems strange to say that it's incompatible for them to request to be /removed /from the authorship credits. --Evan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creative Commons 3.0 Public draft -- news and questions
Francesco Poli wrote: Well, it prohibits an entire class of derivative works: the ones that (accurately) credit the author of the original work! As I said elsewhere: I can release an annotate version of a CC-licensed novel, but I could be forbidden to accurately acknowledge the authorship of the novel I comment on! No, that's specifically something that you can do. We recommended that they only allow requesting a removal from authorship credits, not from anywhere in the book. So, if you took a novel I wrote and published an annotation called: Wuthering Heights, from a neo-nazi Perspective, and put by Francesco Poli and Evan Prodromou, I could reasonably ask to be removed from the authorship credits. However, within the book you could say, What Evan means here is... and When Evan wrote this book... and so on. Don't you feel it's awkward? I don't care about awkward. I care about DFSG-compatible. I think that forcing modifiers to hide the origin of the work is non-free. I have to ask: you read the summary that we sent to CC several times and gave many helpful comments and suggestions. Did you not see the recommendation in the summary on this issue, or has your opinion changed since the summary came out? Moreover, there's another aspect that concerns me: I'm compelled to credit the author of the original work (see clause 4(d) of CC-by-sa-nc-v3draft0808060) until I receive a request to purge such credit. Does this mean that I must take action upon request, even after the derivative work has been released, and re-release a revised version? What if I do not have enough time to do that? My understanding is that to the extent practicable means that you don't have to do anything if it's going to be an extreme pain in the can. So, changing the author credit on a Web page, say, is practicable, but changing the credit on a broadcast TV show that already aired is not. -Evan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creative Commons 3.0 Public draft -- news and questions
On Mon, 2006-14-08 at 01:43 -0400, Nathanael Nerode wrote: As usual, please feel free to forward any of my words to CC. I'm very busy and probably won't manage to do so myself. Saying it yourself is a huge benefit. Reviewing the license, everything we were originally worried about appears to have been fixed (with the possible exception of the DRM business), and no new problems seem to have been introduced. It all looks DFSG-free to me, with the exception of keep intact, noted below. Yes. The keep intact phraseology is still present, and still mildly troublesome: You must keep intact all notices that refer to this License and to the disclaimer of warranties. Don Armstrong noticed this too, and we made a note of it, but it was pretty mild. The wording is almost directly lifted from the GPLv2, section 1: You may copy and distribute verbatim copies [...], provided that you [...] keep intact all the notices that refer to this License and to the absence of any warranty; [...] It's hard to say that some particular wording is incompatible with the DFSG if it's in other accepted licenses. I hate to bring this up at the last minute, but it would be a definite improvement to replace notices with legal notices in this clause, or to do something similar to clarify it. Feel free to bring it up. The changes from the 2.x version are largely due to an effort to make the licenses compatible with the DFSG. Congrats folks! Congrats yourself! Your analysis and suggestions on the 2.0 licenses were extremely important in getting us to this point, and they're greatly appreciated. Commented in another post if it really prohibited parallel distribution, I would think it's non-free -- but I think it does *not* prohibit parallel distribution. So I think it *is* free. Yeah, I'd like to believe that. Now, here's the funny part: if the board and the international affiliates of CC vigorously opposed the idea of parallel distribution and had a clause explicitly permitting it removed from the license, can we reasonably assume that the license as it stands still allows parallel distribution? ~Evan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creative Commons 3.0 Public draft -- news and questions
On Mon, 2006-14-08 at 21:28 +0200, Francesco Poli wrote: I understand your point: you have already expressed your standpoint repeatedly with CC folks, but they decided to listen to other parties and removed the parallel distribution proviso. At least, I imagine you have done so... Yes, both as my own opinion and on behalf of Debian. However, apparently there's been some firm resistance. Now you think that maybe other people talking about the issue could help more than the n-th reiteration from you, right? Exactly. Also, other people will probably also have fresher arguments and a better perspective than I do. In any case, consider pointing cc-licenses subscribers to single debian-legal messages and/or threads that you think express our concerns well... A good idea, but people usually reply better to conversations going on around them. ~Evan -- Evan Prodromou [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creative Commons 3.0 Public draft -- news and questions
On Sat, 2006-12-08 at 23:05 +0200, Francesco Poli wrote: Not a good start. :-( Let me take this opportunity to repeat my plea that people who have feelings about this issue join the cc-licenses mailing list and post messages on the topic. http://lists.ibiblio.org/mailman/listinfo/cc-licenses I've been trying to convey ideas from Debian, but it really helps if you can state your ideas in your own voice. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creative Commons 3.0 Public draft -- news and questions
On Fri, 2006-11-08 at 09:34 +0100, MJ Ray wrote: How does CC make decisions? They know how we make decisions and seem to be hoping the debian project backs down when pushed to a general resolution. If they were going to play the heavy with us, why would they bother making all the other changes we asked for? What would be the point? It's pretty clear that the Debian Project is not militantly united against anti-TPM clauses. I'm not sure, if we have a GR on the matter, whether this is backing down or not. Can we try to make CC put this issue out to a general resolution? You can, if you want. I don't think that's Debian's place, though. Who are CC's members? I know some CC supporters who are sympathetic, but I don't think I've met any with established voting power yet. Get those people to post on cc-licenses. 1. Was GR 2006-01 an exception to the DFSG, or a clarification of our principles? Neither. It was a single-point compromise interpretation. So, the other two questions asked are irrelevant. It's not clear to me what that means. Does that mean that the anti-TPM clause in the FDL is compatible with the DFSG, or not? [...] I'd love to hear some opinions on the matter, and I'd be happy to collect them and present them to Creative Commons. It's not clear how long the public comments period is, so there is a time factor here. Thank you! I am not allowed to post to cc-licenses at this time. Why not? I have discussed other aspects, including some downsides of TPM-bans, at http://lists.okfn.org/pipermail/fc-uk-discuss/2006-August/001173.html which is a more public list than cc-, as far as I know. So, you're complaining to a third party? What good does that do? Maybe it'd be better to make this more direct. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Creative Commons 3.0 Public draft -- news and questions
So, I have big news and a big question. Big news Creative Commons has announced the public draft of the next version of their license suite: http://creativecommons.org/weblog/entry/6017 The changes from the 2.x version are largely due to an effort to make the licenses compatible with the DFSG. Over the last year, the Debian Creative Commons Workgroup has worked with Creative Commons to smooth out the rough edges of license. DDs have already seen it, but there's a report here on the work: http://evan.prodromou.name/Debian_Creative_Commons_Workgroup_report Big question The main question I want to ask debian-legal is this: Does the anti-DRM requirement in the CCPL 3.0 draft, without a parallel distribution proviso, make it incompatible with the DFSG? That question needs some clarification, though. The big question for debian-legal is whether the new license draft is compatible with the DFSG. I hope that debian-legal subscribers will look over the new license carefully and post opinions here or on the cc-licenses mailing list. Creative Commons met almost all of the Workgroup's recommendations, and after a lot of review we've agreed that the works licensed solely under the CCPL 3.0 draft would be Free... with one exception. The exception is that the CCPL 3.0 has an anti-DRM (or anti-TPM) provision that doesn't allow distribution with copy protection features. The traditional wisdom is that prohibiting use of TPM puts an undue restriction on developers and doesn't let them experiment with TPM-required platforms. (Some console game systems, for example, require TPM for a program to run on the system.) Restricting the systems that a program can be ported to is incompatible with DFSG#3. One way to make anti-TPM clauses compatible with the DFSG is to allow parallel distribution -- that is, a developer can create a TPM'd version of a work as long as they also make available a cleartext one that people can modify, copy, etc. This lets developers experiment, but also lets downstream users exercise their rights, too. We'd originally negotiated a parallel distribution proviso, but the extra clause was later removed. So, the CCPL 3.0 license draft has this language for DRM restrictions: You may not impose any technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to them under the License. Since we negotiated the license changes, Debian has had a GR to allow works licensed under the GFDL into main. The GFDL has the following anti-DRM clause: You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. GR 2006-01 says, in part, Similarly, we do not think that GFDL covered documentation is non-free because of the measures taken in the license against misuse of DRM-protected media. The Debian Creative Commons Workgroup couldn't come to a clear conclusion on the matter, and it's not 100% clear what the effect of GR 2006-01 is on Debian as a whole. In my personal opinion, the question boils down to these points: 1. Was GR 2006-01 an exception to the DFSG, or a clarification of our principles? 2. If it was a clarification, does this mean that anti-DRM clauses like the one in the FDL are compatible with the DFSG? 3. If so, is the anti-DRM clause in the CCPL 3.0 draft similar enough to the FDL's anti-DRM clause for us to consider it compatible with the DFSG? My personal opinion is that in light of GR 2006-01 this kind of restriction is compatible with the DFSG. (I also personally think that anti-DRM clauses are really bad for Free Content; see http://evan.prodromou.name/Free_content_and_DRM ...for more. I voted against this part of GR 2006-01, for the record.) I'd love to hear some opinions on the matter, and I'd be happy to collect them and present them to Creative Commons. It's not clear how long the public comments period is, so there is a time factor here. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: Creative Commons 3.0 Public draft -- news and questions
On Thu, 2006-10-08 at 11:26 -0400, Evan Prodromou wrote: GR 2006-01 says, in part, I accidentally quoted a section from an option of the GR that didn't pass. Sorry about that. I don't think the mistake invalidates the discussion, but I wanted to point it out. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: Against DRM 2.0
Max Brown wrote: The problem is that there isn't a lawyer here: this is the problem! You seem to be mistaking the Debian Free Software Guidelines and the Social Contract as principally legal documents. They are not; they are moral, technical, and societal documents. This is a mailing list for people involved with Debian to consider legal issues. In many places in the world, it's expected that citizens can understand the law and make decisions based on it. In fact, some people see it as a citizen's obligation. It's unlikely that you're going to get legal advice from an attorney over a mailing list. If you're seeking legal advice for a particular problem, you should contact a lawyer in your area who's familiar with your country's and region's civil code and copyright, patent, and trademark laws. Finally, if your intention is to stimulate interest by Debian project members and other Debian participants in the Against DRM 2.0 license, lashing out is the worst way to do that. You catch more flies with honey than with vinegar. Good luck, ~Evan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Against DRM 2.0
On Fri, 2006-19-05 at 02:24 -0700, Max Brown wrote: This is very interesting: http://people.debian.org/~evan/ccsummary.html Yes it is. And thank you for proving the point I made earlier! You may not have noticed, but that summary and general opinion on debian-legal state that anti-DRM clauses inhibit more freedoms than they protect. I think that Against DRM 2.0 is better than Creative Commons licenses. That's an interesting opinion. Of course you know that the anti-DRM clause makes the license incompatible with the DFSG, right? There are many platforms that _require_ DRM -- notably Sony game consoles and some palmtop computers. The Against DRM license (which might win the contest for the license with the clumsiest name ever) would prevent me from porting any software to those platforms -- even if I made clear-text, modifiable and/or source versions available. Preventing me from making derivative works and porting them to different platforms, even if I take steps to ensure recipients' rights to use the works, is not DFSG-free. In the end, Against DRM is a single-issue license that's blunt and unnecessary. ~Evan P.S. The Creative Commons 3.0 licenses will allow parallel distribution -- both a DRM'd version and modifiable, clear-text version. They also make specific which kinds of technologies are covered. -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Creative Commons 3.0 Licenses
I wanted to draw the attention of the debian-legal list to the upcoming release of the public draft of the Creative Commons 3.0 licence suite: http://lists.ibiblio.org/pipermail/cc-licenses/2006-May/003557.html The main changes to these licenses has been to bring them in line with the DFSG and make at least the Attribution and Attribution-ShareAlike 3.0 licenses compatible with the DFSG and acceptable for Debian. For those of you who haven't seen it, there is a debian-legal summary of the 2.0 licenses here: http://people.debian.org/~evan/ccsummary Once the public draft is available, I'm going to try to coordinate a response from the Debian Creative Commons Workgroup, but I'd also love to see some open discussion on debian-legal. I think everyone's goal is to have these licenses work with Debian, and if we fumble it in this last phase, it'd be a real shame. After the licenses are released, I'd like to put up a summary of the 3.0 licenses similar to the 2.0 summary. If it's decided that (some) licenses are compatible with the DFSG, I'd like to make that public. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creative Commons negotiations
Benj. Mako Hill wrote: quote who=Frank Küster date=Tue, Jan 24, 2006 at 08:50:04PM +0100 Thank you for the report; it sounds promising, but on the other hand it sounds as if talking upstream authors[1] into relicensing their documentation with a CC license will not be an option for etch. That depends on when 3.0 goes out CC's door. Personally, I'd hoped to see them already and still hope to see them very soon. Then again, we can't dictate their release schedule any more than they can dictate ours. You have to admit that our working group took the process at a leisurely pace. Hell, it took about 6 months before we even had a group together ready to talk. I don't think we have much grounds to criticize CC for taking it slow; if there's been any slowdown in this process, it's been on our side. ~Evan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creative Commons negotiations
On Tue, 2006-24-01 at 19:40 +0100, Frank Kster wrote: is there any public information about the progress in the talks with CC about clarification/amelioration/whatever of their licenses? No, but that's just because I've been lazy and haven't done a proper report to d-d-a. Here's the poop, in a nutshell: after a few months of back-and-forths, we worked out a draft license that the working group felt was compatible with the DFSG. CC hopes to apply the changes to the upcoming CC 3.0 license suite draft, and that version will be available for public review. Unless there are other changes that make the licenses non-free (they're dealing with other groups besides Debian, of course), the 3.0 Attribution and Attribution-ShareAlike licenses should be DFSG-compatible and we should allow works available under those licenses in main. Works under CC licenses with the NoDerivs or NonCommercial elements will still be incompatible with the DFSG, of course, and works under 1.0, 2.0, and 2.5 versions of the Attribution and Attribution-ShareAlike licenses will still be incompatible. But for upstream projects that use earlier versions of by or by-sa, there should be a clear upgrade path. I don't have an idea of when the 3.0 license draft will be available, what other changes there may be, or pretty much where things go from here. But I do know that CC seems to take DFSG-compatibility seriously and that they're going to be open to our input. I've been putting off doing a detailed report for a while, but that's the gist. ~Evan -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/)
Re: Ubuntu CDs contain no sources
On Tue, 2005-08-11 at 11:57 -0200, [EMAIL PROTECTED] wrote: What do you people in debian-legal think about people who distribute ISO images on their websites but no ISO with sources nor a written promise? Should we consider there is an implicit offer and just ask for the sources? What does this have to do with Debian? ~ESP -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/)
Re: Ubuntu CDs contain no sources
On Tue, 2005-08-11 at 11:03 -0500, Joey Hess wrote: (Just IMHO, but I think reasonable people would agree.) Isn't that the definition of your opinion? ~ESP -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/)
Re: Releasing software sponsored by an employer
On Wed, 2005-02-11 at 10:55 -0500, John Morrissey wrote: As part of my day job, I'm working on a piece of Debian-specific software. I would like to release it under the GPL and the company is receptive [...] Good for them and good for you. Obviously, since it was written using their time and resources, they hold copyright on it. That's not the reason that they hold copyright on it, though; it's because you have an employment relationship. If I lived in my parents' basement and wrote software on their computer, I'd still have copyright on the work I'd created. If you write a novel on a stolen typewriter, you still hold copyright on the novel. They would like to retain ownership, so copyright assignment or a quit claim isn't feasible. (In other words, we don't want to follow the GPL's fictitious Yoyodyne example where the company disclaims copyright.) Yeah, that Yoyodyne example sure is a relic of a different time, isn't it? Version 69! HYUK HYUK HYUK! I'm wondering what kind of documentation we should have that explicitly authorizes me to release this software (copyright still held by the company) to the public under a DFSG compliant license. A standard GPL copyright notice, with the company's name (preferably full legal name) in the name of author slot. (No, the company is not the author; that's the slot where the copyright-holder's name goes, and the GPL assumes that the author and rightsholder are one and the same.) You'll probably want to give your own name and contact info somewhere else in the source code and documentation. ~ESP -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/)
Re: Rules for submitting licenses for review
On Thu, 2005-18-08 at 12:10 +0100, Ricardo Gladwell wrote: Could I submit a license for review just for my own personal interest and even though it is unlikely said license will ever be used in debian free or non-free? Please don't. ~Evan -- Evan Prodromou [EMAIL PROTECTED] By God! I will accept nothing which all cannot have their counterpart of on the same terms. -- Walt Whitman, Song of Myself -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is an upgrade to the Open Publication License possible?
On Sun, 2005-07-24 at 03:37 -0400, Nathanael Nerode wrote: Well, these are the problems with it: Lemme see if I can condense these down. I had a hard time reading your response. Add explicit permission to make and distribute modified versions. Remove or soften requirements for author publisher names on book covers, esp. for modified versions. Add explicit allowance of pseudonyms for identifying contributors to modified versions. Modify requirement to provide location of original document. These sound more like collateral damage than that the license was designed to be non-free. That is, I think that a salvaged license would be reasonably in the spirit of the original. The controlling body, if such a body exists, wouldn't be betraying the copyright holders' intentions by making these changes, as far as I can tell. I'm going to join the OPL authors' list and see what I can do to get these changes effected. ~Evan -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Is an upgrade to the Open Publication License possible?
I was surprised to see in this list of non-free documentation packages soon to be moved out of main so many works licensed under the Open Publication License (OPL): http://packages.debian.net/non-free-docs.html I note that the recommended boilerplate used for the OPL is as follows: Copyright (c) year by author's name or designee. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, vX.Y or later (the latest version is presently available at http://www.opencontent.org/openpub/). I think that documentation currently in main that uses the OPL could be salvaged if we can convince the controlling body for the OPL to upgrade to a version that's compatible with the DFSG. I have not, however, examined the OPL carefully enough to determine if this is possible without fundamentally changing the license. I realize the OPL is mostly defunct, but are there any ideas about who still has the power to change it? I think the OPL author eventually ended up at Creative Commons... ~Evan -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Is this license DFSG free?
On Sat, 2005-11-06 at 19:12 -0700, Sean Kellogg wrote: The Initial Developer will be acting as the maintainer of the Source Code. You must notify the Initial Developer of any modification which You create or to which You contribute, [...] This goes against the Freedom 3 of the FSF's free software defination, and the 3rd clause of the Debian Free software Guidelines. How? Leaving FSF's Freedom 3 out of the picture (unless Debian adopted them at some time), I don't see how requiring the contribution of the modification back to source violates Clause 3 of the DFSG: The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. The license allows modification and derived works, and it allows them to be distributed under the same terms as the license. It doesn't say anything about not requiring contribution. The key problem is that if Initial Developer becomes unreachable for any reason, downstream developers will be unable to submit changes, and thus disallowed from exercising the rights granted under the license. Considering the half-life of most software projects, software companies, and email addresses, it can become impossible to contact upstream developers in just 1-2 years. When there's a send-patches requirement, nobody else can pick up the mantle and continue developing the program. I think the suggestion from debian-legal, while the licensor is accessible and is willing to consider revising the license, is to change sending patches back to the Initial Developer to a _request_ rather than a license _requirement_. ~Evan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is this license DFSG free?
On Sat, 2005-11-06 at 14:09 -0700, Sean Kellogg wrote: Debian-legal, a self-appointed group of various legal, political, an philosophical stripes, is making substantive policy decisions based on thin air? Pretty much, yes. The decision-making power eventually lies with ftp-masters, but AFAIK they generally accept the consensus on d-l. I think the key point to remember is that there are two ways a license can prohibit exercising the rights required by the DFSG: either implicitly, or explicitly. Explicitly, a license could say: You MAY NOT make or distribute Derivative Works. That's clearly non-free. But a license could also _allow_ making and distributing Derivative Works, but put such a high burden on the licensee as to make the freedom effectively impossible to exercise: You MAY make and distribute Derivative Works provided that You square the circle. You MAY make and distribute Derivative Works provided that You travel faster than the speed of light. You MAY make and distribute Derivative Works provided that You light a cigar with a million-dollar bill. Dot dot dot. It's probably fair, albeit simplistic, to think of requirements in a license as a spectrum between total lack of restriction and total prohibition: |---+| Without Unacceptably Entirely restriction burdensome prohibited The point at which requirements are unacceptably burdensome -- where they effectively prevent exercise of the rights required by the DFSG for some or all people -- is admittedly vague. This is where the tests in the DFSG FAQ come in. They provide a good mnemonic for determining where in the spectrum a requirement lies. If a requirement fails the Dissident Test, for example, that means that it's probably too burdensome to be considered truly free. Note that the tests are for on-the-edge cases; that's the area of the spectrum where we need some help in license analysis, after all. Hope that helps, ~Evan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Draft summary of Creative Commons 2.0 licenses (version 3)
On Mon, 2005-04-25 at 17:32 -0400, Glenn Maynard wrote: ... and the fact that they refuse to fix such a simple thing bodes very ill for getting more serious problems fixed ... The Debian Creative Commons Workgroup has been talking to CC for about a month now. We've had some pretty successful interchanges, and I think we're moving forward nicely. So: don't count out the possibility of DFSG-compatible CC licenses in the near future. ~Evan -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: (DRAFT) FAQ on documentation licensing
On Thu, Apr 14, 2005 at 02:15:06PM +0200, Jacobo Tarrio wrote: O Xoves, 14 de Abril de 2005 ás 07:39:30 -0400, Evan Prodromou escribía: Probably another point worth making is that being in Debian or being DFSG-free is not equivalent to being good or being righteous. [...] Yes, that's worthy of an entry in the DFSG FAQ, only not in the documentation licensing FAQ part I'm drafting :-) How about this, more to the point? If the author or standards organization is unconvinced by this argument, and does not want to allow modifications, it's not a tragedy. Standards documents are useful for programmers but are by no means indispensable for Debian. Users who absolutely need a standards document can get it elsewhere, or they can conveniently get it through apt from the non-free companion distribution. I think if the only answer we have for the idea of unmodifiable documents is oh, but _all_ docs should be modifiable, we miss an important point. Docs that aren't modifiable don't _have_ to be in Debian is another important answer. It's _nice_ having verbatim distribution RFCs available in an apt archive, but it's not worth changing our policies. ~Evan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT) FAQ on documentation licensing
On Wed, 2005-04-13 at 16:14 +0200, Jacobo Tarrio wrote: Q: The ability to keep certain parts of a document is essential for some kinds of document. For example, RFC or other standards documents should not be modifiable. Or a piece may contain the author's opinion on something, and nobody should be allowed to represent the author's position by modifying that piece. A: First, standards documents should be modifiable: that's how old standards are improved and new standards are made. Modifying a copy of a standards document, such as a RFC, does not modify the RFC itself. Probably another point worth making is that being in Debian or being DFSG-free is not equivalent to being good or being righteous. Being Free doesn't automatically make things good. You can make Free Software computer viruses that are pretty evil, and you can make Open Content kiddie porn and racist propaganda.* The converse is true, too. Plenty of authors have unmodifiable programs and non-program works for whatever reason. There's nothing _wrong_ with that. There's nothing _wrong_ or _bad_ about not wanting your works distributed or distributed in modified form. I don't want love letters distributed to the world in Debian, nor do I want my will modifiable by anyone. Everyone has their reasons and their comfort level with how they send their brainchildren into the world. We'd love it if every author of digitally distributable works would seriously consider releasing their works under a Free license. But if they don't, well, that's their decision. BUT... if works don't meet our standards for Freedom, they can't be in Debian. That's OUR decision. Debian is not a public library where all the world gets to put its works; it's OUR operating system, and we make it how we like it. And: we like it Free. Folks who want us to respect their reasons for not making their works DFSG-free should respect our deeply-held beliefs in freedom, enshrined in our Social Contract. We have a special distribution, non-free, for works that can be distributed but for some reason or another can't be in Debian. This lets Debian users get at non-free works as easily as they get at packages in Debian. This is our compromise and show of good faith with the world. Standards documents are an example of works that a) may need to stay unmodified (depending on the authors' wishes) and b) are useful for Debian users. They're a great candidate for non-free packages. We haven't yet seen the package that was so absolutely indispensable that we had to give up our principles to include it in Debian. The chances that some bit of documentation or a desktop background is going to be worth compromising what we believe in are _extremely_ slim. ~Evan * Most of this stuff wouldn't get into Debian, either, though. -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: On the debian-legal Summary of Creative Commons 2.0
On Thu, Apr 14, 2005 at 12:47:36PM +, MJ Ray wrote: [...] I would also find non-opensource.org editions of the BSD and MIT licences. s/find/prefer/ One thing we can do is that I can amass as many links as I can to the BSD and MIT licenses, and then hold them up to you one at a time like an optometrist. How's this? No, that's still no good. This one? Mmmm... no. How about this? Still no. This? Almost, but not quite. Or, y'know, you could just go out and find the URL that works for you, and send it to me. Personally, I prefer option 2. ~Evan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On the debian-legal Summary of Creative Commons 2.0
On Thu, Apr 14, 2005 at 12:12:44PM +, MJ Ray wrote: About Creative Commons: I feel this needs a paragraph on CC's decision-making, but I do not feel qualified to write it. I have no way of finding that out, and I don't see why it's necessary. If you can dig up some information, I'll include it. Removing References - I think this also may conflict with No Discrimination Against Fields of Endeavour if exercised. How so? Can you make that clearer? Is it worth including in the summary? Any Other Comparable Authorship Credit - I consider this unclear rather than outright breaking guidelines, so I suggest making the last paragraph would be not is. Fair enough. How about external clarification could make this free, but could also make it not free, and fixing the text is the best solution? (Except more careful wording, esp. w/r/t free.) I need to think up something similar for the trademark requirements issue. Trademark Restrictions - In the final paragraph, this should appeal to Web Content Accessibility Guideline 2 http://www.w3.org/TR/WCAG/#gl-color to support it. Maybe this section should also note that there have been uses of the licence which included this section, so it is definitely ambiguous. I think it says that already. Some instances of the license found in the wild include the trademark restrictions. New wording welcome. Add WCAG, the debian policy manual and constitution. I apologise for the late arrival of this comment. No sweat. It's probably worth noting at this point that Creative Commons did their major review of version 3, and although they're aware of version 4, they probably are going to respond to 3. I'm going to do a version 5 after we hear their response. According to Dr. Lessig, they're meeting to go over their response today. Thanks for your response. ~Evan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creative Commons update and steps forward
On Sun, Apr 03, 2005 at 11:51:56AM -0400, Evan Prodromou wrote: I got email from Lawrence Lessig this week that their new general counsel, Mia Garlick, has been reviewing the debian-legal summary and will have a response for us by 8 April. So, another update: I got email from LL on Friday. He said that the general counsel had produced a response, but that he (Lessig) hadn't managed to read and revise before then. He was going to spend his weekend doing that to get us the doc by Monday, but I told him it'd be OK to get it to use by Tue or Wed. So: we can expect a Creative Commons response by Tu or W next week. ~Evan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creative Commons license summary (version 4)
On Thu, Apr 07, 2005 at 11:47:27AM +0100, Matthew Garrett wrote: Evan Prodromou [EMAIL PROTECTED] wrote: http://people.debian.org/~evan/ccsummary.html http://people.debian.org/~evan/ccsummary.txt Would it be possible to put a copy somewhere else while gluck is down? Argh. Gluck seems to be back in business, but there's a copy here, too: http://bad.dynu.ca/~evan/ccsummary/ccsummary.html http://bad.dynu.ca/~evan/ccsummary/ccsummary.txt Probably worth pointing out that 8 April is tomorrow. We should be getting a response from Creative Commons then, and I'd like to get the rest of the machinery in motion afterwards. I think the two big sticking points right now are: * _Trademark_. I think we all consider it worth correcting, but there are some folks who think that the problems aren't sufficient to consider the CC licenses non-free. I'd appreciate if we can come to some kind of compromise text. Maybe something along the lines of, We realize that this is not part of the license, but we are concerned whether any of this language is binding on the licensee or licensor. If so, we can't consider the license + license use restrictions free. * _Recommendation for new anti-DRM section_. I've put in a suggestion for having an anti-DRM clause that meets our requirements (free to choose who receives, free to use whatever format as long as parallel format available), but I'm not sure it meets everyone's approval. It would be good to close this off. Otherwise, I think we're doing well. Thanks to everyone who's commented. ~Evan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Draft summary of Creative Commons 2.0 licenses (version 3)
On Sun, 2005-04-03 at 03:27 +0100, Andrew Suffield wrote: So in summary, I think that 10 million is pure fiction. Does it really matter? We don't have access to the Creative Commons Web logs nor their referrer count for the Some Rights Reserved image (which is what they use for counting), so we can't audit this number. I don't see why we have to. I'm going to modify the cc summary to say many. Can we all agree to many? I know that we have more than 5000 articles and images on Wikitravel alone, and I'd say that's more than enough to call them many. ~Evan -- Evan Prodromou [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: Draft summary of Creative Commons 2.0 licenses (version 3)
On Sat, 2005-04-02 at 11:52 +0100, Matthew Garrett wrote: You're just wrong here. The fact that a license /can/ be interpreted in a way that would result in it being non-free does not mean that all material under that license should be considered non-free. I think that there is a spectrum of interpretation here. At one extreme is assuming that even obviously non-free wording (You may not make modifications or distribute copies) could somehow be considered free (They wouldn't mind if /we/ did it, I'm sure). At the other end is the assumption that even obviously free wording is non-free. I think we need to stay focused somewhere in the middle. A good metric is to be suspicious of any language that appears non-free, absent other information. In other words, err on the conservative side. I think that leaning the other way is unfair to Debian users. Especially where licenses have not been crafted to be DFSG-free, we can't make the assumption that unclear language is free. Down to brass tacks: if you think that there are parts of the Creative Commons summary where we are leaning over backwards to see a problem where none exists, please let me know. We _do_ need to bring it into a final form sooner rather than later. ~Evan -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Creative Commons license summary (version 4)
I've made a new version of the Creative Commons license summary available here: http://people.debian.org/~evan/ccsummary.html http://people.debian.org/~evan/ccsummary.txt This version has the following changes since version 3: * Changed definition to criteria per Francesco Poli. * Changed 1 million works to many works, and note that estimates range from tens of thousands to tens of millions. * Tried to modify the language for explaining why the anti-DRM clause and the trademark restrictions make it hard to call works available under this license Free. This is in response to Mako's critique, who should probably review. * Gave a reference for a CC representative stating that the trademark restrictions are not part of the license. This is one mailing-list post from July 2004; I'd be interested in seeing more. * Modified the recommendation for the anti-DRM clause per Henning Makholm. I used the language I posted, not Henri Sivonen's, in that I thought the one I used was closer to the original language of the license. This still doesn't address Henning's concerns about making personal archive copies, but I think that falls out of scope of distribution. I did not do any of these things: * Drop any of the objections. * Rank any of the objections, or mark any optional or non-normative or something like that. * Add any clarifying reference stating which technologies would be acceptable and which unacceptable for the anti-DRM clause. I haven't been able to find any such clarification on the Web. If someone else can find such a clarification, I'd appreciate it. Comments are welcome. Barring major objections, I would like to see this version posted at http://www.debian.org/legal/licenses/ . ~Evan -- Evan Prodromou [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Creative Commons update and steps forward
So, as most people here know, we've been contacted by Creative Commons to work out the issues over their licenses. I got email from Lawrence Lessig this week that their new general counsel, Mia Garlick, has been reviewing the debian-legal summary and will have a response for us by 8 April. We'd like to have a telephone conference between Debian representatives and Creative Commons to discuss our problems, their responses, and see where we go from there. The DPL has tapped me to be the Debian official for this process. The following people have agreed to participate as part of a Debian workgroup for the discussions: * Don Armstrong * Matthew Garrett * Branden Robinson * Benjamin Mako Hill * Evan Me Prodromou The following people have been proposed but haven't given a definitive yes or no: * MJ Ray * Andrew Suffield I'd like to hear from them before the end of the week, please. Also, I'd like to hear from Marco that this group is sufficiently balanced for his tastes. It's a bit too big for an efficient meeting, but I think all the people asked are necessary. Goals and Criteria -- My goal for this workgroup is to make works licensed under Attribution or Attribution-ShareAlike licenses acceptable for inclusion in Debian. A secondary but less optimal goal would be to clarify definitively that Creative Commons does not intend work available under these licenses to be free. As far as I can see, approving these CC licenses would require: * ...written clarifications for ambiguous terms in the licenses, e.g., some statement saying that any reference in the revocation clause is specifically for authorship credit and not other references. * ...changes to the license itself to make these terms more clear. I'm not confident that external clarification for all of our objections would be sufficient to make works under the 2.0 licenses DFSG-free. There are some objections that are not based on unclear terms; for example, distributing DRM'd works in parallel with cleartext version does not seem acceptable under any interpretation of the current license. I definitely think license text changes would be optimal for all of the recommendations, if possible. I think we could come to a conclusion that the licenses are decisively _not_ free if: * CC says that, yes, they mean any reference in the revocation clause. * CC says that parallel distribution of DRM'd and cleartext works is not acceptable (possible), or that other access-controlled, encrypted or private distribution is unacceptable (less likely). * CC says that the trademark restrictions are binding on licensor and licensee. There may be other sticking points that would ensure that these licenses are not free, and will not be. Finally, I think it's possible that CC leaves some terms undefined, and that we reject or approve the licenses regardless. I'd prefer that that didn't happen, though. Steps Forward - Here's what I think our steps forward should be: 1. Review the summary document and get to a final version before 8 April. I would like to make sure that we have our story straight amongst ourselves before conveying it to others. In particular, I'd like to have signoff from the members of the workgroup on the summary and the above goals. 2. Review the Creative Commons response when it's available. 3. In a telephone conference, explain the summary, give context, and make suggestions for making the licenses acceptable for Debian. 4. Based on clarifications and/or modifications that result from these discussions, re-evaluate the 2.0 licenses and/or evaluate modified 2.x or 3.x licenses when they become available. Comments or suggestions welcome. As a final note, I'd like to make the point that opportunities like this don't come along often. We have the chance now to make CC-licensed works available in Debian, or at least make it clear that such works definitely should _not_ be available in Debian. Anyone here can easily sabotage this effort. If you get this discussion off-track so we don't keep our eyes on our goals, we will fail. If there is something I can do to get your buy-in on this process and keep it going, let me know so I can do it. If there's _nothing_ I can do and you're going to stand in the way no matter what, please let me know now so we all stop wasting our time. Thanks to everyone who's participated so far. Let's hope this work has some fruitful results. ~Evan -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Draft summary of Creative Commons 2.0 licenses (version 3)
On Wed, 2005-03-23 at 19:50 +0100, francois schnell wrote: As both a Debian-Ubuntu and Creative Commons (CC) supporter, I really hope that what you're doing here will work ! Me too! It looks like there are at least 10 millions works realeased under Creative Commons (according to Yahoo a month ago). There was some confusion on this question, so I just said there are many works. It's not really crucial to the summary document to determine exactly or even approximately how many CC-licensed works there are, so I think it's OK to just punt on this issue. Thanks a lot, ~Evan -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Draft summary of Creative Commons 2.0 licenses (version 3)
On Sun, 2005-03-27 at 15:31 -0500, Benj. Mako Hill wrote: I haven't talked to Greg Pomerantz (SPI's lawyer) yet (he's on vacation) but I'd like to bring him in and probably onto the group that talks to Lessig. I think this sounds excellent but might be complicated. If you can pass along a request to review the summary and/or participate in the workgroup, that'd be great. Or if you give me his contact info, I can ask, too. I figure commentary, conference, and consequence is probably going to be about 4-8 hours of work for him at the outside. I don't know if there's a formal way to request this kind of expense from SPI; advice requested. I also don't think his participation is a make-or-break thing. It'd be nice, but not 100% necessary. ~Evan -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Creative Commons update and steps forward
On Sun, 2005-04-03 at 18:40 +, MJ Ray wrote: I'm happy to be part of the group, but I am not sure what resources I am being asked to commit. So there will be a phone conference at some random time? I've no idea whether I can make that or not. Me either. Let's just say participation in phone conference if possible, and consultation for other effort. I will review the latest summary before 8 April. Should we comment directly to you or is this list sufficient? The list is fine. ~Evan -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Draft summary of Creative Commons 2.0 licenses (version 3)
On Sun, 2005-03-20 at 12:21 +0200, Henri Sivonen wrote: I think it is in the spirit of the Creative Commons licenses not to require a transparent copy for editing. That's true. However, for a work to be DFSG-free, source code must be supplied. Therefore, I think it would be wrong to fix the Creative Commons licenses by smuggling in a requirement for transparent copy in a license update. I think in general I'd prefer we go with the minimal changes necessary to make the licenses DFSG-free. ~Evan -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Draft summary of Creative Commons 2.0 licenses (version 3)
Hi, everyone. At long last, I've made some final revisions to the draft summary of the Creative Commons 2.0 licenses. The main changes have been: * Additional phrasing changes due to MJ Ray * Additional phrasing changes due to Francesco Poli * Clear textual recommendations for Creative Commons * Recommendations for trademark restrictions The summary is also available here: http://people.debian.org/~evan/ccsummary.txt http://people.debian.org/~evan/ccsummary.html Creative Commons has expressed interest in discussing these recommendations with Debian representatives, with (I believe) the intention to make the licenses DFSG-free. I'd like to leave this draft up for a few days, and then put together a workgroup of ~5 people (including, hopefully, the DPL or some other official Debian representative, at least in an advisory role) to discuss these licenses with Creative Commons. I'm thinking this work would consist of one or two telephone conference calls of less than an hour each, with possibly some email discussions. ~Evan = debian-legal Summary of Creative Commons 2.0 Licenses = :Author: Evan Prodromou [EMAIL PROTECTED] :Date: 18 Mar 2005 :Version: 3 :Contact: debian-legal mailing list debian-legal@lists.debian.org :Copyright: This document is dedicated by the author to the public domain. This document gives a summary of the opinion of debian-legal members on the six licenses that make up the Creative Commons license suite. About debian-legal == Debian [DEBIAN]_ is an operating system consisting entirely of Free Software. Our definition of Free Software is specified in the Debian Free Software Guidelines [DFSG]_. debian-legal [LEGAL]_ is a mailing list whose members provide guidance for the Debian project on, among other things, the acceptability of software and other content for inclusion in the Debian operating system. This includes comparing software against the DFSG to determine if the packages are Free Software. From time to time the debian-legal list provides a review of a well-known software license to express a rough consensus opinion on whether software released solely under the license would be Free Software. Although these summaries are not binding, they do provide some basis for the Debian project to make decisions about individual packages. About Creative Commons == Creative Commons [CC]_ is an organization devoted to expanding the range of creative work available for others to build upon and share. The organization has created a suite of licenses [LICENSES]_ that content creators can use to specify certain rights that the public can exercise with respect to a particular work. The licenses were released in December of 2002 and revised in May of 2004; there are already over 1 million works released under a Creative Commons license. Although Creative Commons explicitly recommends that their licenses not be used for programs [1]_, works licensed under the Creative Commons licenses are still of interest to the Debian project. Debian includes documentation for programs, and many programs included in Debian use digital data such as images, sounds, video, or text that are included with the programs in Debian. The Creative Commons licenses are based on a common framework, but have a varied number of license elements that can be included to grant or revoke particular rights. Because of the similarity between the licenses, this document covers all six of the revised (version 2.0) licenses. License summaries = Attribution 2.0 --- debian-legal contributors think that works licensed solely under the Creative Commons Attribution 2.0 license [BY]_ are not free according to the DFSG and should not be included in Debian. We see the following problems with the license. Removing References ~~~ Section 4a of the license states, in part, If You create a Collective Work, upon notice from any Licensor You must, to the extent practicable, remove from the Collective Work any reference to such Licensor or the Original Author, as requested. If You create a Derivative Work, upon notice from any Licensor You must, to the extent practicable, remove from the Derivative Work any reference to such Licensor or the Original Author, as requested. Per DFSG 3, any licensee should be allowed to make and distribute modified versions of a work. The above clause allows a licensor to prohibit modified versions that mention them or reference them. For example, an author who made a novel available under an Attribution 2.0 license could give notice to disallow an annotated version that mentions the author by name or simply as the author. A more specific example for Debian would be a programmer who creates documentation licensed under
Debian License Summaries
So, this page: http://www.debian.org/legal/licenses/ ...lists some license summaries and makes some statements about whether the licenses are free or not. It's not clear to me how these summaries become official, or at least posted on that page. Any suggestions? I'll like to get the CC 2.0 licenses summary listed. ~Evan -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Draft summary of Creative Commons 2.0 licenses (version 2)
On Fri, 2004-24-12 at 04:12 -0500, Branden Robinson wrote: What is required to move forward on this? Do we *need* to move forward on this? Sorry it's taken me so long to respond to this email; I've been on my honeymoon in remote places. I had a few wording fixes suggested in off-list email by various -legal members. In addition, there were some very good suggestions for making the licenses acceptable for Debian. I've been contacted by people at Creative Commons who'd like to have a telephone conference to go over the draft. I think they're open to our suggestions, if we can stay focused on particulars. Right now, I think this is going to have to happen in late Jan. I'm running behind on a lot of things. I'm not even sure how we'd set up a debian-legal telecon. I *will* try to send out a final version of the summary this wknd. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Bug#283976: ITP: simnazi -- historical city simulation game, clone of Sim City
On Fri, 2004-03-12 at 17:05 +, Andrew Suffield wrote: The whole reason why we have armies is to protect us from these oppresive powers. Therefore there's no reason to think they are somehow a threat to the project. Yes. One of the reasons we have hundreds of developers in Debian is for just this kind of situation. If we ever need to execute military manoeuvres against a sovereign state, we have the manpower to do so. The question now becomes whether or not to make a preemptive strike against Austria. If so, do we commit ground troops, or just make surgical air strikes on Vienna and environs? All this is stunningly irrelevant though, given that Austria is a member of the EU these days, and this law is a blatant breach of Article 10 of the European Convention on Human Rights. Yeah, whatever. Blah blah blah. Please tell us more about the composition of the atmosphere on Planet Libertaria. For those of us discussing issues on Earth: our experience as a project with silly national laws has been fairly pragmatic (cf. non-US mirrors). I don't think it's feasible for us to create separate non-at, non-cn, non-za, etc. package repositories. It'd just be ridiculous for users in one country to assemble a sources.list from lists of packages that may or may not be illegal in the 189 other sovereign nations. BUT... I wonder if there's a way to invert that process, and allow mirror operators to (automatically) exclude packages they feel put them in legal jeopardy. I'm not particularly familiar with our mirroring tools; can mirror operators define a blacklist of packages to ignore and not redistribute? ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: non-free firmware: driver in main or contrib?
On Thu, 2004-14-10 at 12:47 +0200, Marco d'Itri wrote: Firmwares do not run on the host CPU (they are /data/ for the host system) Ah. You seem to be labouring under the misconception that non-program data files aren't subject to the same rules for inclusion in main as executable programs. That's an incorrect assumption. A program that requires a non-free data file to run -- be it a firmware blob, a graphics image, or some other beast altogether -- depends on that file and thus belongs in contrib. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: non-free firmware: driver in main or contrib?
On Mon, 2004-11-10 at 10:27 +0200, Marco d'Itri wrote: I think it's a question of what dependence means for contrib. If the driver absolutely _depends_ on using the non-free firmware, it should be in contrib. If the non-free firmware is optional, it should go into main. Again, please explain which part of the policy defines this criteria. http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib Of course, there's shades of gray, here. If all the driver does is emit a message CAN'T FIND NON-FREE FIRMWARE, ABORTING without the firmware, it's hard to say that it doesn't depend on the firmware. But if the This applies to almost every driver in the Linux kernel. Are you ready to move most of the kernel to non-free too? I'd probably dispute whether it's _every_ driver in the kernel, and it's not my decision, but as I understand it that's exactly what we're doing. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: non-free firmware: driver in main or contrib?
On Mon, 2004-11-10 at 20:14 +0200, Marco d'Itri wrote: On Oct 11, Evan Prodromou [EMAIL PROTECTED] wrote: I think it's a question of what dependence means for contrib. If the driver absolutely _depends_ on using the non-free firmware, it should be in contrib. If the non-free firmware is optional, it should go into main. I still cannot see anything in policy which would support the above statement. Can you make your reasoning explicit? Are we having an argument, or are you asking for information? Don't forget that the Socratic method is so annoying the Greeks poisoned Socrates for it. Anyways, here's the relevant quote: Examples of packages which would be included in contrib or non-US/contrib are: [...] free packages which require contrib, non-free packages or packages which are not in our archive at all for compilation or execution, As I said, there's some wiggle room on what require... for compilation or execution means. But not a lot. I think you'd like to make the point that kernel drivers that depend on firmware flashed to an eeprom are functionally equivalent to kernel drivers that depend on firmware blobs that are uploaded at runtime. I don't have much opinion on this. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: non-free firmware: driver in main or contrib?
On Mon, 2004-11-10 at 01:50 +0200, Marco d'Itri wrote: Probably the right question to ask is: is there any chance to use the driver without touching the non-free firmware (nor any other non-free stuff, for that matters)? Can you quote which part of the policy describes this criteria? I think it's a question of what dependence means for contrib. If the driver absolutely _depends_ on using the non-free firmware, it should be in contrib. If the non-free firmware is optional, it should go into main. Of course, there's shades of gray, here. If all the driver does is emit a message CAN'T FIND NON-FREE FIRMWARE, ABORTING without the firmware, it's hard to say that it doesn't depend on the firmware. But if the mainline functionality works without the non-free part, and the firmware's just needed for extra stuff, then it might be a candidate for main. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
No restrictions on use (was Re: JRockit in non-free, part II)
On Fri, 2004-08-10 at 14:33 +0100, Henning Makholm wrote: In fact, the consensus interpretation of the DFSG is that a license that requires users to agree legally to *anything* just for being allowed to *use* the software, is not DFSG-free. I think you mean that the consensus definition of freedom includes no restrictions on use. I _don't_ think that no restrictions on use follows directly or indirectly from the DFSG as stated -- at least, I haven't seen an argument to that effect. I _believe_ that our policy on restrictions on use comes from the fact that a copyright holder has limited rights to control other people's use of the work. Except for redistribution, replication, and creation of derivative works, it's not up to the copyright holder to say what I can do with a book, a painting, or a piece of software. So, any license that claims to have authority over other uses is non-free. Now, that all said: I wonder if there's a good reason _not_ to add a no restrictions on use clause to the DFSG. Yes, I realize that the DFSG are not the be-all and end-all of freedom; I also realize that the DFSG should not be modified unnecessarily. But this issue comes up often enough that it would be worthwhile to make the policy explicit. At the very least, it would save a lot of explanation. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: No restrictions on use (was Re: JRockit in non-free, part II)
On Fri, 2004-08-10 at 17:48 -0400, Raul Miller wrote: restrictions on use. I _don't_ think that no restrictions on use follows directly or indirectly from the DFSG as stated -- at least, I haven't seen an argument to that effect. ... except where that use falls within some field of endeavor. Ah. I guess you really can't do anything without pursuing _some_ field of endeavor. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: GFDL and Debian Logo
On 09/22/04 01:57:40, Hendrik Brummermann wrote: there is a discussion in the German Wikipedia whether the Debian Open Use Logo http://de.wikipedia.org/wiki/Bild:Debian_logo.png may be subjected to the GFDL. I'm not a lawyer and I don't speak for Debian, but I don't think that you can re-license the Open Use Logo under the GFDL. As I read it, the Open Use Logo license requires that you use the logo and derivatives _to_refer_to_the_Debian_project_. The GFDL doesn't preserve this requirement. If the logo were put under the GFDL, someone could use it to refer to an ice cream shop, an electrical component, or an astrological sign. What does Debian care if someone does that? Because under American (and I think some other) trademark regimes, if we allow people to use our trademark image to refer to just anything, it dilutes our trademark and makes it difficult for us to enforce. If someone put the Debian logo on, say, a Linux distribution without any Debian components inside, we would have a hard time making them stop. That logo can mean anything you want, they could say. This actually matters in US courts. So, my inexpert answer: NO. As a Wikipedian, I'd recommend removing the logo from German Wikipedia (although en: is a lot less rigorous about information freedom -- bravo to de:!). ~ESP
Re: W3 software license
On Sun, Aug 08, 2004 at 05:36:29PM -0700, Josh Triplett wrote: The license looks OK to me, with the possible exception that it says obtaining, using and/or copying this work implies acceptance of the license. I think it sets a bad precedent to wave such language into a list of licenses we accept as DFSG-free without at least asking the upstream authors to remove this wording. Why don't we do this: I'll write up a summary of the license, and note that we think that works released under the license would, barring complications, be free. I'll also add a suggestion to drop the use language. How does that sound? ~ESP
Helix Player under GPL (was Re: RPSL and DFSG-compliance)
So, this is a side-note about the Helix Player, not fully concerned with the RPSL per se. As I understand it, the Helix player (client side) has recently been dual-licensed under the GPL. There doesn't appear to be any way that the dual-licensing prevents users from exercising freedoms protected by the GPL, so barring any of the multitude of problems that can make GPL'd software non-free, it seems to me that at least the Helix player is Free Software, and should be included in either main or contrib. I don't know what the dependencies are, or if there are any dependencies that would prevent it from being in main. Thomas, is enough of the helix player code GPL'd that we can include it in main, regardless of what we conclude about the RPSL? ~ESP
W3 software license
I'm interested in adding cwm to Debian: http://www.w3.org/2000/10/swap/doc/cwm.html It's available under the W3 software license, appended to this message and also available at this URL: http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231 The license looks OK to me, with the possible exception that it says obtaining, using and/or copying this work implies acceptance of the license. Any opinions? ~ESP ---8--- W3C® SOFTWARE NOTICE AND LICENSE http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231 This work (and included software, documentation such as READMEs, or other related items) is being provided by the copyright holders under the following license. By obtaining, using and/or copying this work, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions. Permission to copy, modify, and distribute this software and its documentation, with or without modification, for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the software and documentation or portions thereof, including modifications: 1. The full text of this NOTICE in a location viewable to users of the redistributed or derivative work. 2. Any pre-existing intellectual property disclaimers, notices, or terms and conditions. If none exist, the W3C Software Short Notice should be included (hypertext is preferred, text is permitted) within the body of any redistributed or derivative code. 3. Notice of any changes or modifications to the files, including the date changes were made. (We recommend you provide URIs to the location from which the code is derived.) THIS SOFTWARE AND DOCUMENTATION IS PROVIDED AS IS, AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE OR DOCUMENTATION WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE SOFTWARE OR DOCUMENTATION. The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to the software without specific, written prior permission. Title to copyright in this software and any associated documentation will at all times remain with copyright holders. ---8--- The mentioned 'W3C Software Short Notice' is: ---8--- $name_of_software: $distribution_URI Copyright © [$date-of-software] World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University). All Rights Reserved. This work is distributed under the W3C® Software License [1] in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [1] http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231 ---8--- signature.asc Description: OpenPGP digital signature
Re: RPSL and DFSG-compliance
Rob Lanphier wrote: I would really like someone to map one of the cited problems with the RPSL to a stated requirement in the DFSG. It's understandably frustrating to come into a debian-legal discussion about a license without having been on the list for a while, since in fact we don't usually reference DFS guidelines by name. Most problems with licenses map either to DFSG 1 (distribution) or DFSG 3 (modified versions). A key part of discussions here is deciding whether restrictions imposed on licensees raise the bar too high for them to realistically exercise the freedom to distribute and modify. When a license says, You can distribute as long as you do X, Y, and Z, we need to evaluate whether X, Y and Z are too heavy a restriction to be acceptable under DFSG 1. That just makes everyone here believe that there will be an endless stream of manufactured excuses as to why future versions of the RPSL will also not be considered Debian-free. I don't think our project has any interest in keeping RPSL-licensed packages out of Debian. We don't usually like new licenses, not least because they make us slog through a lot of legalese and have long boring discussions about various minutiae. But if a package is Free Software, it's usually accepted into Debian. It's also probably worth waiting until there's at least a draft summary of the license before responding or making changes to the license. Discussions like this take time. ~ESP signature.asc Description: OpenPGP digital signature
Re: GPL-compatible, copyleft documentation license
Andrew Suffield wrote: This is a non-issue. It's also silly. There is no infrastructure for distributing things that aren't machine-readable in Debian. Well, sometimes we do that T-shirt thing. We *sell* those :P /me starts drafting a GR ~ESP signature.asc Description: OpenPGP digital signature
Re: Draft summary of Creative Commons 2.0 licenses (version 2)
Sean Kellogg wrote: reading this Draft Summary really set me off. I'm sincerely sorry about that. Let me point out that I was originally extremely hostile to most of the objections posited to the Attribution 1.0 license, most of which are replicated in this draft summary: http://lists.ibiblio.org/pipermail/cc-licenses/2004-June/000913.html But I really think debian-legal needs to rethink some of the absolutest positions it takes and recognize the law is not like software... it will never be perfect... it is an art of compromise. I advise against letting the perfect become the enemy of the good. I think the key problem here is that we're taking the most pessimistic possible view where there are ambiguities in the license text or where the text is vague and unclear. Personally, I believe that the people who work on Creative Commons are good, smart, and dedicated people. I think that folks who use CC licenses are generous and express great good will by sharing their creative fruits with the world. But in evaluating licenses, we have to assume that the Licensor is not good, generous, or rational. If we can convince ourselves that the license grants the licensees freedom _even_when_ the Licensor is possessed by Captain Howdy and starts spewing green goo out of their eye sockets, then we can be reasonably certain that works released under the license are really Free. Unfortunately, taking this tack makes us look like mean and vituperative a-holes. We treat Licensors -- people who are unselfishly sharing their work with the world -- like insane megalomaniacs. It's sucky, but it's a necessary part of the process. A more specific example for Debian would be a programmer who creates documentation licensed under Attribution 2.0. He could require that references in derived versions to design or implementation decisions he made for the program be removed. Are you saying the Attribution License is non-DSFG because the original author can say take my name out of the derived work??? Yes. If the Licensor can severely limit the content of modified versions, then the work isn't free, per DFSG 3. If you design a program and then say, this was designed by Programmer Joe, and Programmer Joe, embarressed by the program, says he wants his name taken out, the court will order you to take away the attribution. It is against the law to say someone did something if they did not. Yes. It's illegal to defame someone by saying something untrue about them. However, the clause doesn't say that the licensor can request that you take out untrue references. It says that the licensor can request that you take out _any_ references to them, true or not. So, if Programmer Joe really wrote a program and made the documentation available under the by 2.0, and I created a modified version and wrote in the modified documentation: Programmer Joe's version of this algorithm ran in O(N^2) time, but our new version runs in O(NlogN) time. ...then, as the license is written now, Joe could request that I remove his name from this sentence. Now, is this earthshatteringly bad? Not really. We could obviously work around it, and program documentation that leaves out reference to the original version and its authors would probably be more or less usable. But opinion here seems to lean to the side that letting Licensors have this level of editorial control over modified versions of a document makes that document non-free. comparable authorship credit This could mean either credit for comparable authorship or comparable credit for authorship. Its amazing how adding words to a phrase changes its meaning, even more so when changing the order. Comparable Authorship Credit looks/sounds/means nothing like comparable credit for authorship... come on, the words are switched around and there is a for added. That's to make it more clear that there are two different ways to read the phrase. It might be easier to see the difference with parentheses, like in a C program: (comparable authorship) credit versus comparable (authorship credit). Read it the way that make sense. Both make syntactic sense. One way is excessively burdensome, and the other is not. We have to be pessimistic here. These restrictions make excessive demands on both licensor and licensee, and abridge their fair use rights to the Creative Commons trademarks. Cute, but untrue. A trademark is not a copyright... and Fair Use rights are significantly less with a trademark over a copyright. That's debatable. However, the key point is that I can use the name Creative Commons right now to talk about the Creative Commons organization without getting their explicit permission. According to the trademark clause, as stated, I could not, if I were a licensor or licensee. Let's be serious for just a moment... do you really believe that Prof. Lessig is going to encourage
Re: Draft summary of Creative Commons 2.0 licenses (version 2)
Evan Prodromou wrote: Below is a second version of the summary of the Creative Commons 2.0 licenses. The summary is also available here: http://people.debian.org/~evan/ccsummary.txt http://people.debian.org/~evan/ccsummary.html ~ESP
Re: GPL-compatible, copyleft documentation license
Florian Weimer wrote: In software documentation, an original author could require that changelogs or discussion of differences in design or implementation (Original Author had it this way; the new version does it this other way) be removed. Replacing Evan Prodromou with Original Author would probably be enough to honor requests under the CC license mentioned in this subthread. That's not how I read any reference. Can you explain why you read it that way? I fail to see how this is a grievous restriction because common courtesy already tells us to honor such requests.. Actually, I think the freedom to make modifications that the upstream author doesn't like or approve is a pretty key freedom. I'm also confused by the moral rights issue. Under a moral rights regime, does an author have the right to have any reference to themselves removed from works? ~ESP
Draft summary of Creative Commons 2.0 licenses (version 2)
Below is a second version of the summary of the Creative Commons 2.0 licenses. The main changes are: * I've converted it to reST to make it easy to read in plain text and convert to HTML or what have you. * The summaries by license have been changed to four sections: by 2.0, by-sa 2.0, *-nd-*, and *-nc-*. * Removed statements about licenses being non-free (thanks MJ Ray). * Added note on anti-DRM clause. * Added note on requesting removal of references and credits requirement. * Added intro about Debian and debian-legal (for non-Debian readers). * Added intro about Creative Commons and the license suite. * Added recommendations for authors. * Added recommendations for Creative Commons. * Added links to pertinent documents. * Other minor changes. Comments and criticism welcome. I intend to add in Andrew Suffield's notes about providing parallel DRM'd and non-DRM'd versions of a work, and giving clearer recommendations. ~ESP ---8--- = debian-legal Summary of Creative Commons 2.0 Licenses = :Author: Evan Prodromou [EMAIL PROTECTED] :Date: 21 Jul 2004 :Version: 2 :Contact: debian-legal mailing list debian-legal@lists.debian.org :Copyright: This document is dedicated by the author to the public domain. This document gives a summary of the opinion of debian-legal members on the six licenses that make up the Creative Commons license suite. About debian-legal == Debian [DEBIAN]_ is an operating system consisting entirely of Free Software. Our definition of Free Software is specified in the Debian Free Software Guidelines [DFSG]_. debian-legal [LEGAL]_ is a mailing list whose members provide guidance for the Debian project on, among other things, the acceptability of software and other content for inclusion in the Debian operating system. This includes comparing the license terms of packages against the DFSG to determine if the packages are Free Software. From time to time the debian-legal list provides a review of a well-known software license to express a rough consensus opinion on whether software released solely under the license would be Free Software. Although these summaries are not binding, they do provide some basis for the Debian project to make decisions about individual packages. About Creative Commons == Creative Commons [CC]_ is an organization devoted to expanding the range of creative work available for others to build upon and share. The organization has created a suite of licenses [LICENSES]_ that content creators can use to specify certain rights that the public can exercise with respect to a particular work. The licenses were released at the end of 2003; there are already over 1 million works released under a Creative Commons license. Although Creative Commons explicitly recommends that their licenses not be used for programs [1]_, works licensed under the Creative Commons licenses are still of interest to the Debian project. Debian includes documentation for programs, and many programs included in Debian use digital data such as images, video, or text, that are not normally considered software. The Creative Commons licenses are based on a common framework, but have a varied number of license elements that can be included to grant or revoke particular rights. Because of the similarity between the licenses, this document covers all six licenses. License summaries = Attribution 2.0 --- debian-legal contributors think that works licensed solely under the Creative Commons Attribution 2.0 license [BY]_ are not free according to the DFSG and should not be included in Debian. We see the following problems with the license. Removing References ~~~ Section 4a of the license states, in part, If You create a Collective Work, upon notice from any Licensor You must, to the extent practicable, remove from the Collective Work any reference to such Licensor or the Original Author, as requested. If You create a Derivative Work, upon notice from any Licensor You must, to the extent practicable, remove from the Derivative Work any reference to such Licensor or the Original Author, as requested. Per DFSG 3, any licensor should be allowed to make and distribute modified versions of a work. The above clause allows a licensor to prohibit modified versions that mention them or reference them. For example, an author who made a novel available under an Attribution 2.0 license could give notice to disallow an annotated version that mentions the author by name or simply as the author. A more specific example for Debian would be a programmer who creates documentation licensed under Attribution 2.0. He could require that references in derived versions to design or implementation decisions he made for the program be removed. In addition, Section 4b of the license requires
Re: GPL-compatible, copyleft documentation license
Florian Weimer wrote: How? As MJ said, it's clearly practical to remove the author's name in places where it would nevertheless be a grievous restriction. So you suggest that if someone approaches Debian and asks his name to be removed, Debian would ignore this request even if it can be honored, practically speaking? I think this clause mainly deals with something Debian does anyway, as a mrere courtesy. I believe that was the intent. As stated, though, it could be abused; it doesn't restrict the erasing to just authorship credit. The classic example here is an autobiographical work. The author could ask that all references to herself be removed from a derivative work critical of her. In software documentation, an original author could require that changelogs or discussion of differences in design or implementation (Original Author had it this way; the new version does it this other way) be removed. ~ESP
Re: Visualboy Advance question.
Branden Robinson wrote: I know it may be a fine point, but I'd contrast that with an emulator that is free and self-sufficient, but for which there is no DFSG-free software to run. A *lot* of old home computer emulators won't be self-sufficient without the ROM, because the environments were so constrained that ROM-based service routines were very heavily used. That's interesting, but I think in the case under discussion, a system ROM isn't necessary to run the software. You just need particular game ROMs. ~ESP
Re: historical question about fceu in contrib
Branden Robinson wrote: Evan was fishing for support for his position in a recent thread entitled Visualboy Advance question.[1]. Some other debian-legal people appears to refer to Humberto Massa, in one message.[2] To be clear: I was soliciting information, not hustling for votes. No one seemed to have the full history on the emulator issue, so I was trying to get the background on it. There was some confusion on the matter; see, for example, this post: http://lists.debian.org/debian-legal/2004/06/msg00472.html Evan did at one point moderate his thinking a bit[3]. It's probably not a good idea to take every discussion on debian-legal as an argument. My theory at the time was that the old PC emulators' dependence on non-free system OS ROMs (like the atari800 package) had been fossilized into a policy that _all_ emulators depend on non-free software and thus go in contrib. It seems that that's not the case. We actually don't allow packages into main if there's not publicly-available, DFSG-free data for them to work with. Like, we wouldn't let a new word-processor into main without at least one Free document in the word processor's format, and we wouldn't let a new programming-language interpreter into main without at least one Free script that uses the language. That strikes me as odd, as it reverses the direction of dependency we normally use in Depends:. But discussion here seems to show that that's actually the case, and I accept it even if I find it weird. ~ESP
Re: Visualboy Advance question.
Francesco Poli wrote: On Wed, 7 Jul 2004 14:00:47 -0400 Glenn Maynard wrote: I think there's a fairly significant difference between an emulator that will load and display an insert ROM image (eg. NES, SNES), and one that requires a specific non-free image in order to be able to do anything at all (eg. PSX BIOS images). The first is analogous to requiring media; you see what the console displays if a cartridge isn't inserted. The second is the same as requiring a non-free library for which there is no free replacement. (I'm not aware of any free replacement PSX BIOSes.) Agreed, fully. I'd agree with that, too. Very succintly put. ~ESP
Re: Visualboy Advance question.
Branden Robinson wrote: I know it may be a fine point, but I'd contrast that with an emulator that is free and self-sufficient, but for which there is no DFSG-free software to run. A *lot* of old home computer emulators won't be self-sufficient without the ROM, because the environments were so constrained that ROM-based service routines were very heavily used. That's interesting and true. But a lot is not all. I think in the case under discussion, an OS system ROM isn't necessary to run the software. You just need particular game ROMs. ~ESP
Re: CC-based proposal (was FDL: no news?)
On Tue, 2004-07-06 at 09:23, tom wrote: My doubt is: dfsg should cover the 4 freedom of fsf. I think this is a non-issue. The DFSG is the DFSG, nothing more or less. How does CC respect the availability of source code? The licenses neither enforce nor prevent a licensee's distribution of source code. Enforcing distribution of source code is not part of the DFSG, though, and we consider works under licenses that don't enforce source code distribution (e.g., 3-clause BSD) to be Free. Of course, our project's experience shows that just having a source-available license on some software doesn't necessarily make the source available. I believe availability of source code (the first half of DFSG #2) is an attribute of the package, and distributability of source code (the second half) is an attribute of the license. And I think that the CC licenses make redistribution of source code OK. Can we consider dfsg-free a song which can be playd just in MSplayer, or a text readable just whit adobe reader? Absolutely. The problem with secret and/or obfuscated file formats is not that you can't read or use them on some player or another; it's that they're hard or impossible to modify. I'd think, though, that if there were no Free player for a work, it couldn't go into main. It'd be pretty fair to say that a work depends, in the Debian sense, on some kind of player. ~ESP P.S. Tom, I CC'd you on this since I'm not sure if you're on debian-legal. If you are, sorry for the double-post. -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Creative Commons license draft summary
On Mon, 2004-07-05 at 19:15, Evan Prodromou wrote: So, I'd like to write a draft summary for the 6 Creative Commons 2.0 licenses: So, I've started this summary, http://people.debian.org/~evan/ccsummary.sxw (and, yes, I'll convert it to HTML and plain text ASAP), and I've included the three main arguments why Attribution 2.0 is non-free (revocation, any other comparable authorship credit, trademark restrictions). I'd like to make sure that I catch anything else up-front, if possible. One question I had was about the anti-DRM clauses in section 4a). You may not distribute, publicly display, publicly perform, or publicly digitally perform the Work with any technological measures that control access or use of the Work in a manner inconsistent with the terms of this License Agreement. I know that the anti-DRM clause in the GFDL was a cause of problems. I'm worried that this loosely-phrased clause may be one, too. As stated, it seems that distribution on a file server in a firewalled LAN, in a shared directory on a shell server, or in a password-protected members area of a Web site, would be prohibited. Unless, of course, those distribution mechanisms are consistent with the terms of the license agreement. It's not clear, though, who decides what is consistent and what is not. Am I sparring with ghosts here, or is this a real issue? Does the publicly part of the sentence mean that it only applies to technological restrictions on _public_ distributions of the work? ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Creative Commons license draft summary
On Tue, 2004-07-06 at 15:47, MJ Ray wrote: On 2004-07-06 20:15:25 +0100 Evan Prodromou [EMAIL PROTECTED] wrote: included the three main arguments why Attribution 2.0 is non-free At least in this context, we should say instead that software released under it alone will not be free software. A good point, and one I understand clearly. I may have been sloppy in the summary, but I'll make sure it's clear in the final version. As keeps getting claimed in cc-licenses, the trademark restrictions usually included as the end of a CC licence are not supposed to be part of the licence. I put a note about that in the summary. I know that the anti-DRM clause in the GFDL was a cause of problems. I'm worried that this loosely-phrased clause may be one, too. Looks like a lawyerbomb to me. Without more information on its meaning, I wouldn't say anything other than could be clearer unless pushed. If pushed, I'd probably say that software covered by this term isn't free software. Thanks. OK, I gotta nuther one. Section 4a) allows the author to forbid reference to the user. Section 4b) requires authorship credit. If the author uses the revocation clause, it's not explicitly stated that the licensee is absolved of the requirements in 4b). In other words: ~Attribution - ~Distribution RevocationRequest - ~Attribution Thus, RevocationRequest - ~Distribution There are some hedges in 4b) -- the author's name only has to be give if supplied. But it's not explicit, and I think having a licensor able to effectively revoke the license at will would make it non-free. Am I nuts? ~ESP -- Evan Prodromou [EMAIL PROTECTED] Wikitravel (http://wikitravel.org/) signature.asc Description: This is a digitally signed message part
Re: Creative Commons license draft summary
On Tue, 2004-07-06 at 17:18, Evan Prodromou wrote: Section 4a) allows the author to forbid reference to the user. Section 4b) requires authorship credit. s/the user/themselves/ ~ESP -- Evan Prodromou [EMAIL PROTECTED] Wikitravel (http://wikitravel.org/) signature.asc Description: This is a digitally signed message part
Re: CC-based proposal (was FDL: no news?)
On Mon, 2004-07-05 at 19:08, MJ Ray wrote: Numerous people have tried many angles. More are welcome, as we clearly haven't found the correct approach yet. So, I'd like to write a draft summary for the 6 Creative Commons 2.0 licenses: http://creativecommons.org/licenses/ Four of them (with NonCommercial or NoDerivatives elements) are clearly not intended to be DSFG-free. It seems to the untrained eye that the other two (Attribution and Attribution-ShareAlike) are. The problems we have with these licenses are more or less ones of clarity and wording rather than intention. We could hand this over to Creative Commons with some suggested changes, as well as some information about our project and why having works be DFSG-free is important. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Apple's APSL 2.0 Debian Free Software Guidelines-compliant?
On Sat, 2004-06-26 at 17:23, Andrew Suffield wrote: Where You are located in the province of Quebec, Canada, the following clause applies: The parties hereby confirm that they have requested that this License and all related documents be drafted in English. Les parties ont exige que le present contrat et tous les documents connexes soient rediges en anglais. This seems a discrimination betwwen people and thus to violate DFSG#5 (No Discrimination Against Persons or Groups). Nah, this is just a reference to a particularly stupid tenet of their law. It's not particularly stupid to expect that, if you sign a contract, it should be in a language you understand. Being an anglophone in Quebec, I've been happy for this provision many times. My French is OK, but I feel a lot more comfortable reading legalese in English. Whether a software license requires the same level of _contractual_ understanding is an open question, though. And it makes my preferences and desires part of the license. I never requested an English version from Apple; does that invalidate my license? If I were to ask Apple for a French or Mikmak or Cree version instead, would _that_ invalidate my license? I once saw some film or other that satirised it rather well: That's unrelated, except for the fact that it has to do with French. There's no requirement that contracts have to be bilingual nor in the dominant language; just that both parties understand the language of the contract. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Visualboy Advance question.
On Mon, 2004-06-21 at 19:55, Matthew Palmer wrote: To re-quote policy, The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. Usefulness is a function of functionality. No functionality, no utility (usefulness). For an emulator, no ROM, no functionality, no utility. If there's no free ROM, then we go through the chain again, ending at not in main. That is nice sophistry, but I don't think it holds water. The order of dependence that you're describing is quite backwards. It's unusual (although not unheard-of) for a Debian package for an interpreter or emulator to Depends on programs that run under than interpreter, rather than the other way around. I don't think that many of us would be pleased if the 'perl' package Depends-depended on, say, 'prcs-utils' or 'mp32ogg'. 'perl' needs SOME data -- even console-entered data -- to be useful, but it doesn't need any PARTICULAR data to be useful. perl is still quite useful even if I don't have mp32ogg installed. Not only that, but we fully expect users to provide their OWN data for that software -- whether free or not. An MP3 player doesn't depend on the Free Software Song to operate. An image viewer doesn't depend the Tux image. It's OK to use non-free data with a free program in main. That's not a violation of our guidelines. Yes, we all need to be needed, in a hippy-squishy way -- Debian packages inclusive. (Have you hugged your packages today?) But saying that a Debian package Depends on packages that Depends on it is taking a mushy truism to an absurd technical conclusion. In closing: I think it's a mistake to leave out Free Software just because there's not Free Data for that software to work with. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: How long is it acceptable to leave *undistributable* files in
On Sun, 2004-06-20 at 10:32, Francesco Poli wrote: On Sun, 20 Jun 2004 10:16:53 -0400 Raul Miller wrote: Consider, for example, building emacs against a third party supplied proprietary libc. That would possibly require modifying Emacs source code and that's the creative act (it would create a derivative work, no doubt about that). OTOH, when you issue the classical $ ./configure $ make commands, you are not performing any creative act. Do you agree? I think the point is that a statically-linked program would contain code from the proprietary library. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Visualboy Advance question.
On Sun, 2004-06-20 at 11:50, Benjamin Cutler wrote: I think that it's a mistake to say that an interpreter or emulator depends on the data blobs it interprets, in the Debian sense of dependence. That's all well and good, but obviously somebody (presumably somebody important) somewhere disagrees, or it wouldn't have happened in the first place. Hmm. I wonder if other emulators have the same problems as the atari800 emulator. From the description: The Atari Operating System ROMs are not available with this package, due to copyright. You'll have to either make copies of them from an old Atari computer, or see README.Debian for other ways to obtain them. I'd say that this was a valid reason to put atari800 into contrib. My understanding is that this emulator *just won't work* without these ROMs. No matter what data ROM you want to run, you need the OS ROMs to do so. I know it may be a fine point, but I'd contrast that with an emulator that is free and self-sufficient, but for which there is no DFSG-free software to run. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
historical question about fceu in contrib
Joe, Just a quick note to ask you about the fceu Debian package, as its story kind of relates to some existing software in contrib. In this message to debian-legal: http://lists.debian.org/debian-legal/2004/01/msg00128.html you said: I currently maintain an NES (Nintendo Entertainment System) emulator for Debian called fceu (FCE Ultra). Although it is licensed under the GPLit is currently in contrib since it is mainly useful to play non-free ROMs (eg. Super Mario Brothers, Legend of Zelda, etc...). I would like to do what I can to move it into main. It seems kind of strange to me and some other debian-legal people that a package was kept out of main because the data files it uses are non-free. Even for emulators and interpreters, this is kind of unusual. Can you explain, for my benefit, why fceu wasn't in main in the first place? Was it your decision, or did you get advice on the matter from others? Was it just because the game ROMs are usually non-free, or was there other software (such as an operating-system ROM) that was required? Thanks for your help. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Visualboy Advance question.
On Sat, 2004-06-19 at 17:09, Benjamin Cutler wrote: Please, could someone explain me why visualboyadvance package is in 'contrib' section of Debian? It's free itself, it depends on free libs, looks like it doesn't require any non-free stuff at all. There's also free (as in freedom) roms for GBA in the net. The same reason fceu was in contrib until 'efp' was packaged, because the requires at least one piece of software that's not in Debian in order to be useful. That doesn't make sense to me. An image viewer isn't useful without images, an interpreter isn't useful without scripts, nor is a library useful without some program that links to it. But we don't keep those kinds of packages out of main just because there aren't images, scripts, nor linking programs in main. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Visualboy Advance question.
On Sat, 2004-06-19 at 18:17, Benjamin Cutler wrote: Perhaps my choice of words was poor, but I think that emulators fall into their own class of software because they rely on what is generally commercial, non-free (and honestly, quite probably illegal) software in order to run, which is why they fall into contrib. I guess I'm just not sure I buy that an emulator is materially different from a script interpreter, DFSG-wise. A quick 'apt-cache search emulator' turns up quite a few emulators in main. I can find a few that don't have supported programs in main -- mixal would be one. B-) ~ESP signature.asc Description: This is a digitally signed message part
Re: gens License Check - Non-free
BTS == Brian Thomas Sniffen [EMAIL PROTECTED] writes: BTS Yes. And this picture of a Gnu is not a derivative work of BTS Emacs. But if I package it with Emacs as the Emacs icon, the BTS combination IconEmacs is a derivative work of Emacs -- and of BTS my iconic gnu. This is counterintuitive. There's a connection here between collection and derivation that's somewhat difficult to wrap my head around, though. If I write a short story Evan's Story, that is an independent work, on its own. If I submit that story to Atlantic Monthly, the story becomes part of the collective work Atlantic Monthly, June 2004 issue. If I then make the short story into a play Evan's Play, it doesn't make much intuitive sense to say that Evan's Play is derived from Atlantic Monthly, June 2004 issue. And it seems even stranger to say that Evan's Play is a derivative work of Atlantic Monthly, April 1961 or Atlantic Monthly, December 2018. ~ESP -- Evan Prodromou Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED]
Re: Creative Commons Attribution license element
NN == Nathanael Nerode [EMAIL PROTECTED] writes: NN Actually, I think most of clause 4b is fine; it's only one NN little bit of it which is troublesome. Thanks for your close attention. This is really helpful. 4b to the extent reasonably practicable, the Uniform Resource 4b Identifier, if any, that Licensor specifies to be associated 4b with the Work, unless such URI does not refer to the copyright 4b notice or licensing information for the Work; NN Well, I think this is barely free, though it's a little silly. It's probably less silly in light of the mechanism Creative Commons suggests for embedding license info into artifacts with tight space for metadata: http://creativecommons.org/technology/embedding For file formats like MP3/ID3, there's only so much space for rights info. So, CC recommends storing an URL to the full info. One thing that bothers me, though, is how this becomes 'barely free'. I realize that it may be *annoying* or *stupid*, but how is it *non-free*? I understand how *excessive* conditions on modifications may make something non-free, but requiring that a verbatim URL be included with the Work doesn't seem excessive to me. I also am having a problem with understanding how putting limits on the modification of metadata (info about the Work) makes something non-free. This seems to be standard issue with most free licenses (you have to keep copyright notices, you have to distribute the license with the work, you have to keep a change history, yadda yadda). I see where restrictions on the content (can't change function names, can't change the ending of the short story) are non-free, but I'm not sure I grok why metadata invariance is. I really need some help getting this straight in my head. What am I missing, here? 4b provided, however, that in the case of a Derivative Work or 4b Collective Work, at a minimum such credit will appear where any 4b other comparable authorship credit appears and in a manner at 4b least as prominent as such other comparable authorship credit. NN *This* is the problem clause. It's unclear to most of us NN exactly what any other comparable authorship credit means. Yes, I see that. Is it credit for comparable authorship, or comparable credit for authorship? A failure of the appositive! The any other ... part is kind of difficult, too. Does it mean some other ... (credit has to be somewhere), or every other ... (anytime there's credit, this one has to be there, too)? NN With this ambiguity, the at least as prominent requirement NN is then a potential interpretation nightmare. Suppose, for a NN silly and extreme example, you wanted to use a huge hunk of NN material under this license in a version of ReiserFS, so that NN the code under this license needed a comparable authorship NN credit to Reiser's. Would that mean that the credit would NN have to appear in the FS name, so as to be in the same NN location and at least as prominent as Reiser's credit? Yeech. Yeech, yes. Possibly a more appropriate example would be when I include an Attribution-licensed quote from you (beyond the extent of fair use) in my book, The Autobiography of Evan Prodromou. Would I have to change the title to The Autobiography of Evan Prodromou and Nathanael Nerode? Again, though, I wonder about the non-free aspects of this. Clumsy and inaccurate, yes. Non-free...? Would it be non-free because it's not possible for the licensee to comply because the license is vague? NN This isn't supposed to be an actual part of the license, NN according to the source code for the web page; this should be NN fixed so that this is clear when *viewing* the web page (it is NN *not* clear now). That doesn't require changing the license. NN It does require someone at Creative Commons noticing and NN dealing with the issue. :-P Probably something as simple as: Creative Commons, the Creative Commons logo, and the Some Rights Reserved logo are trademarks of Creative Commons. Their use is restricted by Creative Commons trademark policy to the extent of applicable law. ...would work better. ~ESP -- Evan Prodromou Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED]
Re: Creative Commons Attribution license element
AS == Andrew Suffield [EMAIL PROTECTED] writes: Me One thing that bothers me, though, is how this becomes 'barely Me free'. AS Freedom is a binary test; a work is either free, or it is AS not. There is no partially free or semi-free. So barely AS free is free, but very close to the line; make this any AS stronger and it will be non-free. I understood that part. The part I don't understand is, what line does the URL requirement get close to? What is the line between acceptable modification restrictions and unacceptable ones? I'll try to present one dimension of modification restrictions, being what type of content those restrictions require to remain in the modified version: 1. No restrictions on modifications whatsoever. 2. Restrictions to make sure that downstream users get the following 4 things: copyright notices, license notification, changelogs, warranty disclaimers. 3. Restrictions to make sure that downstream users get general information about the work (metadata), including the above 4 things, but maybe perhaps some others. Examples: original author name, original work title, original metadata URL, bug-reporting site or address, main download site URL. 4. Restrictions that protect certain parts of the work itself (e.g., invariant sections). 5. Restrictions that prevent any modification of the work whatsoever. I'd posit that our line for free-vs.-non-free is between 3 and 4 here. Me Would it be non-free because it's not possible for the licensee Me to comply because the license is vague? AS Licenses which are vague are particularly nasty, because you AS can go with the obvious interpretation, and then get sued by AS the copyright holder who turns out to have a different AS one. Certainly we've had some copyright holders applying AS strange interpretations to apparently free licenses before AS now. To provide reasonable assurance to our users that AS everything in main is free, we have to take the most AS pessimistic interpretation, and see if that is free. Cool. So, if I can redirect back to the Attribution license, we have a worst-case interpretation with the Attribution license, where the author's credits have to be listed in _every_ place other credits are given, even if those places are possibly inconvenient (file name, work title). Even though it's vague (could mean some places, could mean all places), our New Math set theory teaches us that if we give credit in all places, we will have also have given credit in some places. So, by giving credit in _all_ places, we can comply. Now, given the all places idea: is that non-free? It may suck, but is it non-free? ~ESP -- Evan Prodromou Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED]
Re: Creative Commons Attribution license element
NN == Nathanael Nerode [EMAIL PROTECTED] writes: Me On the Creative Commons side, I'd wonder what opportunity there Me is to get Debian's very tardy comments and critiques applied to Me new versions of the CC licenses. NN Perhaps if they read their own mailing list?... That's a good point; I didn't see any followup on your message to that list. Here's a pointer to your message, BTW, for reference: http://lists.ibiblio.org/pipermail/cc-licenses/2004-January/000320.html NN The trademark issue appears to be an issue solely with the web NN page presentation of the license, which should simply be NN fixed; the trademark clause is not supposed to be part of the NN license at all, but the web page does not make that clear. As far as I can tell, no. NN I sent a message regarding this to them some time ago, but it NN seems to have fallen into a black hole. Perhaps you know NN someone who could actually get something done on this NN point?... I can try to bring the subject up on the cc-licenses list again. ~ESP -- Evan Prodromou Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED]
Creative Commons Attribution license element
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm writing because I've just been made aware of this summary of the Creative Commons Attribution 1.0 license: http://lists.debian.org/debian-legal/2004/04/msg00031.html Let me first note that Creative Commons uses a suite of licenses, with a number of mix-and-match license elements (Attribution, ShareAlike, NonCommercial, NoDerivatives). So any CC license that would require Attribution would also fall under this analysis. Second, let me note how poorly timed the analysis is. Creative Commons revised their suite of licenses this year (from 1.0 to 2.0), and this list was asked to provide comment: http://lists.debian.org/debian-legal/2004/01/msg00241.html Making our organization's ideas known to Creative Commons could have meant a better suite of licenses for the 2.0 release. Instead, the opportunity was missed. As far as I know, the above-mentioned analysis wasn't forwarded to Creative Commons before today. Thirdly, let me say that I disagree with most of the summary. I'll try and cover the points in detail below: 1) Many DFSG-free licenses require that small portions of text be kept intact or added to the source code or output of the program. The most notable examples would be copyright notices, license notification, warranty disclaimer, and notice of modifications made; the BSD license(s) and the GPL come to mind immediately. Putting conditions on modification does not make a license non-free. We even codify this in DFSG point 4. Patch-only modification is a condition on modification that we consider acceptable if not ideal. Conditions on modification are, of course, a matter of degree. If conditions are _so_ burdensome as to make modification and redistribution _impracticable_ -- You may distribute modified versions if you square the circle, jump Snake River Canyon on a motorcycle, travel faster than light -- then the right to modify is for all practical purposes not granted. But requiring attribution to the original author does not appear to me to be that kind of burden. In particular, the license makes it clear that you must give the Original Author credit reasonable to the medium or means You are utilizing. A Licensor could not abuse this requirement by making Attribution impractical -- say, by providing a 5-terabyte name or title. Licensees are only required to give Attribution in a reasonable way. Let me note here that, although the Open Source Definition is not identical to the DFSG, the OSI has approved a few licenses that have equivalent or greater attribution requirements. Most notable is the Attribution Assurance License template: http://www.opensource.org/licenses/attribution.php This is not, of course, canonical for Debian, but it does provide some suggestion that a group following guidelines similar to ours don't see a serious problem with requiring attribution. Apache 2.0 also requires attribution (in the NOTICE file). 2) I agree with this one. The intention appears to be to allow copyright holders to avoid having their name used in advertisement, a la the BSD, but in an opt-out rather than opt-in fashion. However, as stated, it would indeed allow a license holder to prevent _any_ mention of themselves in derivative works. This could severely limit the licensee's freedom. An example would be an annotated version of a work that critiques the writer, or an autobiography that is revised to include critical comments or facts about the writer. It would probably be useful to modify the license to show that the licensor can revoke the Attribution requirements, but not prevent other mention of their name. 3) As for the trademark clause, I agree that the trademark requirement is burdensome. HOWEVER, considering that Creative Commons is _not_ a party to the license, no action by that organization to overstep trademark bounds could invalidate the license. If A grants B the rights outlined in Attribution 1.0, no increase in trademark restrictions by the third-party Creative Commons could revoke those rights. So, that's my feedback. I'd like to know what can be done to amend the analysis and re-open this license (as well as Attribution 2.0, ShareAlike 1.0, and Attribution-ShareAlike 1.0 and 2.0) for consideration. On the Creative Commons side, I'd wonder what opportunity there is to get Debian's very tardy comments and critiques applied to new versions of the CC licenses. ~ESP - -- Evan Prodromou [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAxeP/ozwefHAKBVERAmHxAJ9Qna+IwzXTEXnGJm+pJD3vPdeQ7ACeNOCC 4FMc8pCK4bDxmzyefv6wlN4= =xyLh -END PGP SIGNATURE-
Re: Creative Commons Attribution license element
AS == Andrew Suffield [EMAIL PROTECTED] writes: AS Beyond that I'm not personally inclined to analyse a license AS which is clearly non-free for other reasons; it's AS time-consuming. No problem; I'm sure someone else will chime in. Thanks for your help so far. ~ESP -- Evan Prodromou Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED]
Re: Creative Commons Attribution license element
MR == MJ Ray [EMAIL PROTECTED] writes: Me Second, let me note how poorly timed the analysis is. MR It may be poorly timed but at least a debian user helped to MR make it happen. Please praise Ben Francis and give him due MR credit for getting your attention with MR http://lists.ibiblio.org/pipermail/cc-licenses/2004-June/000909.html Ben deserves some praise. Nice job, Ben! MR Equally, let us note that a debian *developer* subscribed to MR cc-discuss solicited the views of debian-legal, but did not MR make sure our views were clearly known to them. Yes, indeed. My grouchiness was unmerited, and I should have been doing a better job as a conduit between the two groups. I'm now subscribed to debian-legal and I'll try to keep the lines of communication open better. I'm sorry to have been harsh for something that was more or less my own responsibility. ~ESP -- Evan Prodromou Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED]
Public review period for Creative Commons 2.0 license draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Creative Commons (http://www.creativecommons.org/) has begun a public comment period for the draft of the next version of their open content (-ish) licenses. Creative Commons has 11+ licenses with a variety of mixins -- requiring attribution, preventing derivative works, allowing derivative works under a copyleft-like ShareAlike provision, and preventing commercial use of works. The draft 2.0 version of the Attribution-NonCommercial-ShareAlike license -- which contains all the stipulations in the other licenses mixed in -- is available here: http://creativecommons.org/drafts/license2.0 Comment is welcome on the cc-licenses mailing list: http://lists.ibiblio.org/mailman/listinfo/cc-licenses What does this have to do with Debian? Well, I figured that an opportunity to give input on new versions of content licenses would be useful for Debianistas, especially considering recent dustups around the GFDL. ~ESP - -- Evan Prodromou [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAFp2/ozwefHAKBVERArgeAKCZmM//H7HqS7769588FExpqaNabACgjAJn K8nBbIiU3GhtilnYFRmNR88= =c+J4 -END PGP SIGNATURE-
Public review period for Creative Commons 2.0 license draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Creative Commons (http://www.creativecommons.org/) has begun a public comment period for the draft of the next version of their open content (-ish) licenses. Creative Commons has 11+ licenses with a variety of mixins -- requiring attribution, preventing derivative works, allowing derivative works under a copyleft-like ShareAlike provision, and preventing commercial use of works. The draft 2.0 version of the Attribution-NonCommercial-ShareAlike license -- which contains all the stipulations in the other licenses mixed in -- is available here: http://creativecommons.org/drafts/license2.0 Comment is welcome on the cc-licenses mailing list: http://lists.ibiblio.org/mailman/listinfo/cc-licenses What does this have to do with Debian? Well, I figured that an opportunity to give input on new versions of content licenses would be useful for Debianistas, especially considering recent dustups around the GFDL. ~ESP P.S. I sent a copy of this email from my @d.o account, but that's super-busted, so I figured I'd try again from one that works. - -- Evan Prodromou [EMAIL PROTECTED] Wikitravel - http://www.wikitravel.org/ The free, complete, up-to-date and reliable world-wide travel guide -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAFqyVozwefHAKBVERAnPzAKC283h9gqhFua64/gP6JCJyRnPM3QCeJEzB kyefBVv+bvkNkSyX1hY4loA= =hoSY -END PGP SIGNATURE-
