Re: debian-legal review of licenses
* Simon Law [EMAIL PROTECTED] [2004-02-11 18:01]: I'm willing to take on a position to summarize our discussions, and present them to upstream. I think I can do this diplomatically, and I have some experience with this. (I was responsible for ironing out Thanks. -- Martin Michlmayr [EMAIL PROTECTED]
Re: debian-legal review of licenses
* Matthew Palmer [EMAIL PROTECTED] [2004-02-12 09:17]: Hands up anyone who wants to take on the job of official d-legal summariser. I can think of a few people who *could* take the job, unfortunately, those qualified also tend to be those most qualified in other areas. I certainly *don't* think it should be a committee summary; we've already got one discussion group (d-legal), no need to add a second one. Oh, absolutely. Also, I don't think we need one official summarizer. Really, anyone can volunteer to summarize a particular discussion, post a summary to -legal to get the ok and then send it on. We don't necessarily need one specific person to do that - what we need are volunteers willing to do it. -- Martin Michlmayr [EMAIL PROTECTED]
Re: debian-legal review of licenses
* Henning Makholm [EMAIL PROTECTED] [2004-02-12 00:01]: Of course, perhaps the best thing for -legal to do is have people self-nominate themselves to this position, and then have a small vote. Hmm.. do we really need to have a single person charged with writing all of the summaries? No, I think we just need vounteers who step in in a particular discussion and volunteer to summarize it. If there are just 4-5 regulars who feel like me, the chances of someone volunteering for any given request would be much better than the chances of a Single Official Summarizer not being buried under Yes, which is also why I'm relucant to appoint one delegate for this right now. It would be good if a group of people would do it and after a few months we see automatically who the people are who are doing it regularly. -- Martin Michlmayr [EMAIL PROTECTED]
Re: debian-legal review of licenses
* Henning Makholm [EMAIL PROTECTED] [2004-02-13 04:09]: Hm, that would involve somebody monitoring the OSI lists, because an Are the OSI lists public (sorry, cannot check, I'm off-line at the moment waiting for my plane to Malaga)? Is anyone from -legal following them already? unsolicited approach to the licensor *after* the OSI process has finished cannot help but be interpreted as rude. I'm not sure if this is true. Say someone approaches OSI with their license, the OSI has their decision making process and announces that the license is OSI compliant. -legal reads the license and find some issues why the license is not DFSG-free. Someone then contact the author of the license, basically saying We noticed that you have just been OSI certified, but we found that it does not adhere to the DFSG because of this and that. The DFSG is about this and that, and this is why it is different to the OSI guidelines and we why feel it is important to comply with the DFSG. I don't think such a mail would be perceived as rude. Some people might ignore it and not care, but I cannot see people seeing it as rude. -- Martin Michlmayr [EMAIL PROTECTED]
Re: debian-legal review of licenses
Martin Michlmayr - Debian Project Leader wrote: * Henning Makholm [EMAIL PROTECTED] [2004-02-13 04:09]: Hm, that would involve somebody monitoring the OSI lists, because an Are the OSI lists public (sorry, cannot check, I'm off-line at the moment waiting for my plane to Malaga)? Is anyone from -legal following them already? OSI lista are public, and I read the license-discuss list. There are a lot of off-topic flames, but very costructive comments on how to improve licenses unsolicited approach to the licensor *after* the OSI process has finished cannot help but be interpreted as rude. I'm not sure if this is true. Say someone approaches OSI with their license, the OSI has their decision making process and announces that the license is OSI compliant. -legal reads the license and find some issues why the license is not DFSG-free. Someone then contact the author of the license, basically saying We noticed that you have just been OSI certified, but we found that it does not adhere to the DFSG because of this and that. The DFSG is about this and that, and this is why it is different to the OSI guidelines and we why feel it is important to comply with the DFSG. I don't think such a mail would be perceived as rude. Some people might ignore it and not care, but I cannot see people seeing it as rude. OSI guidelines are very similar to ours (they based from our DFSG). It would interessting to find the differences and see if we should update our DFSG. ciao cate
Patent issues
Hi, I wonder if it is still possible for sarge to be released before 7 July 2004 (international expiration of US4558302). If not, we could start to move GIF/LZW patent encumbered packages from non-free and contrib to main. More generally, I hope I'm not the only one aware of the fact that currently, many packages in main violate software patents. E.g. EP0394160 (the progress bar) and EP0689133 (notebooks). These two have their equivalents in US, JP and other regions and are used heavily by popular GUI based programs (e.g. using GTK+, Qt and the toolkits themselves). These are just examples (see http://webshop.ffii.org/ for others), though trivial ones, but I doubt that these and all the others will be deleted some day. I wonder what Debian considers the threshold of importance for patents that can be ignored and patents that we care about. Thanks. bye, Roland signature.asc Description: This is a digitally signed message part
Re: free licensing of TEI Guidelines
However, there seem to me to be a few obvious caveats: * I would not want to be blamed for bad advice someone else added to mine; thus I would want modifications to be indicated; This is just fine and DFSG-free. * I would not want someone else to change my biography provided in the About the Author section. This is *not* OK; it means, quite simply, that the biography is not DFSG-free. If you require that the biography be included with any derivative work, that renders the whole work not DFSG-free. (If you allow your biography to be *removed* from derivative works, then DFSG-free derivative works can be made by removing the non-DFSG-free biography.) But this isn't what you really care about, is it? Editors change author's biography texts fairly often. The author of a derivative work might want to add that you'd won the Nobel Prize (if you had done so after the original work's publication), and what's wrong with that? Really, what you want is to prevent an *inaccurate* biography from being put in, right? Or perhaps to prevent an altered version of the biography from being presented as your version? For the second purpose, that's what attribution requirements and ChangeLog requirements are for. For the first purpose, I believe a clause like the following would be just fine: As a condition of distributing a modified version of the Biography, you must in good faith believe that all your modifications are accurate, and you must prominently note that you wrote the modified version and I didn't. * The Paramedic Free Press Association would not want the colophon information that is no longer true to be retained in a modified version. (E.g., if part of the colophon says This book was written in its entirety using Emacs/psgml on a PowerMac 7100 running Debian GNU/Linux 3.0 (Woody), and is valid against the DocBook XML 3.2 DTD., but the modifications were not written on that system nor is the result valid against DocBook 3.2.) This is OK provided it's written narrowly enough -- but it usually isn't. The thing is, it should be OK to write The original book from which this was derived was written in its entirety using Emacs/psgml on a PowerMac 7100 running Debian GNU/Linux 3.0 (Woody), and is valid against the DocBook XML 3.2 DTD. That sentence is obviously a derivative of the original sentence and probably subject to its copyright. If your license prohibits writing this, you've messed up and your license is not DFSG-free. It should also be OK to use the sentence unmodified *if* it's still true. This sort of stuff is really not the domain of copyright licenses. We encourage you to avoid imposing such non-copyright-related restrictions in copyright licenses, because it's error-prone. But if you must, you need to write the restrictions *very* carefully. For instance, I believe the following is OK: As a condition of distributing this work or derivative works thereof, you must not include statements in the colophon unless you believe them to be true. Beginning to get the idea? :-)
Re: free licensing of TEI Guidelines
Branden Robinson wrote: (in http://lists.debian.org/debian-legal/2004/debian-legal-200402/msg00145.html) lots of really good stuff about endorsements I agree with Branden entirely. Uh, what he said. Sorry for the me-too-ism. --Nathanael
Re: debian-legal review of licenses
Matt Palmer wrote: Hands up anyone who wants to take on the job of official d-legal summariser. Heh. I can think of a few people who *could* take the job, unfortunately, those qualified also tend to be those most qualified in other areas. Branden would do an *excellent* job. He's probably too busy, though. With the GFDL issues, we've actually had multiple people come up with summaries. How about this: (1) Someone volunteers to summarize the discussion. If people pipe up and say No, we haven't discussed it enough, he or she waits. (1a) or, the person asking for advice says I need a summary! In which case, go to step 1. (2) The summary is posted to the list, asking if it's a good summary. (3) If consensus is that it's a good summary, it's sent on to the person asking for advice. (4) Otherwise, a revised summary is prepared, and we return to step 2. Perhaps this is too much of a formalization for a very simple process, but anyway, how does it sound.
Re: debian-legal review of licenses
On Wed, 18 Feb 2004, Giacomo A. Catenazzi wrote: OSI guidelines are very similar to ours (they based from our DFSG). It would interessting to find the differences and see if we should update our DFSG. In theory, it might be usefull, but there is a significant difference between the OSD and the DFSG: the OSD is a definition, whereas the DFSG is a guideline. This has poses interesting aspects for how we interpret licenses like the GFDL, OSL, and others. See http://people.debian.org/~terpstra/message/20030126.175505.a6b4f9aa.html for the most recent thread on OSD and DFSG convergence. Don Armstrong -- Tell me something interesting about yourself. Lie if you have to. -- hugh macleod http://www.gapingvoid.com/archives/batch20.php http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu
Re: Patent issues
* Roland Stigge ([EMAIL PROTECTED]) [040218 18:40]: I wonder if it is still possible for sarge to be released before 7 July 2004 (international expiration of US4558302). If not, we could start to move GIF/LZW patent encumbered packages from non-free and contrib to main. I think this is a good idea. Even if release would be some days before 7 July, I think it would be good to move it after that date. This would make some software free, and would solve some RC-bugs. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Patent issues
On Wed, Feb 18, 2004 at 05:22:29PM +0100, Roland Stigge wrote: I wonder if it is still possible for sarge to be released before 7 July 2004 (international expiration of US4558302). If not, we could start to move GIF/LZW patent encumbered packages from non-free and contrib to main. They will most likely not be moved until the patent expires. Packages that contain LZW code should not be in contrib; they should be in non-free because they cannot be practiced under a DFSG-free license. I wonder what Debian considers the threshold of importance for patents that can be ignored and patents that we care about. Active enforcement. Of course, if the patents are enforced, but are allowed to be practiced under a DFSG-free license, then that's different. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
