Re: licensing issue at APT
El domingo, 9 de noviembre de 2008 a las 01:35:35 -0200, Andre Felipe Machado escribía: Please, I need legal advice about the bug report [0] in APT. Just a note that legal advice means advice given by someone acting as a lawyer. As such, very few people in this list is qualified to give legal advice, and those who are will not give it, because giving legal advice has some unwanted legal consequences. Basically, nobody wants to be sued if they happen to give wrong advice :) Some of us may give our opinions, or say what we would do in that circumstance, but the responsibility for the decision lies entirely with you. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: links to external software
El sábado, 20 de septiembre de 2008 a las 22:38:27 +0200, Ramses Rodriguez Martinez escribía: error if they are not installed). My question is: ¿is this behavior DFSG-compliant or Debian packages are supposed to be 100% self-contained? If it weren't, we wouldn't be able to have in main any software that depends on a (possibly non-free) server :) -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: source code written by monkey
El lunes, 11 de agosto de 2008 a las 14:44:14 +0200, Arnoud Engelfriet escribía: While these claims seem somewhat far-fetched, the end result is still that the author has asserted the work is public domain. Why not accept that? Because that is not possible in Germany, where (I believe) the author lives. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP: debian-backports-keyring -- GnuPG archive key of the?backports.org repository
El domingo, 22 de junio de 2008 a las 12:54:09 -0600, Wesley J. Landaker escribía: Actually, how are debian-keyring and debian-archive-keyring free-software, anyway? Do I get source code for the all GPG keys they contain? The /usr/share/doc/debian-keyring/copyright even says The keys in the keyrings don't fall under any copyright. Ops! Well, the keys are not creative works, so they cannot be covered under copyright in most jurisdictions. However, the collection of keys itself can be covered under copyright, or something similar to it, in many of them, so having a free licence is still relevant: you can add, remove and update keys in the collection freely. Note how cunningly I avoided talking specifics about one or other jurisdiction to avoid giving legal advice unadvertantly. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Could you please forward this proposed license to Teosto? (was: Re: Choosing a license for Frets on Fire songs)
El jueves, 26 de abril de 2007 a las 16:25:40 -0400, Jason Spiro escribía: I have dropped Tommi, Sami and Joonas from the Cc because I don't think they want to be bothered too much with this kind of things, and only care about the results. Feel free to correct me if that isn't the case. * Persons distributing the Work to the general public may only do so if the Work is distributed and/or bundled with game software. If the songs must be distributed and/or bundled with the game, then it is not allowed to distribute the game in main and the songs in non-free. In fact, one could say they cannot even be in different packages. If I were to draft such a license, I'd allow unlimited distribution, allow to change the storage format and/or medium of the songs but only allow use, public performance, etc., in games. Also, I'd suggest not making a non-free license look similar to a free license :-) -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question about gpl-commercial dual licencing
El sábado, 21 de abril de 2007 a las 15:10:31 +0530, Shriramana Sharma escribía: Say someone creates a library libfoo in the C language. The library is dual-licenced -- under the GPL and under a commercial licence. GPL is Now I create Python binding to that library - pyfoo. Now I would like to dual-licence it myself, under the same terms -- GPL and a commercial Now to get the right of dual-licensing, do I have to obtain a commercial licence from the author of libfoo? If yes, why? If no, why not? Please elucidate. Thanks. Basically, if a customer of yours wanted to use pyfoo to create a Python application using libfoo which is distributed under terms other than the GPL, that customer of yours would need both a license from you and a license from the author of libfoo. Now, you could enter an agreement with the libfoo author so that you can sell directly pyfoo+libfoo licenses... -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: firefox - iceweasel package is probably not legal
El miércoles, 6 de diciembre de 2006 a las 16:26:27 +0100, Arnoud Engelfriet escribía: What I don't understand is why a package for the Iceweasel software would carry the name firefox. There's no such thing as a firefox. There It is not a package for Iceweasel that is called firefox. It is an empty package called firefox that depends on iceweasel and carries a description that says that it is an empty package put together to aid on upgrades from firefox to iceweasel and that it can be safely uninstalled. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: firefox - iceweasel package is probably not legal
El martes, 5 de diciembre de 2006 a las 13:57:48 -0800, Jeff Carr escribía: I notice that recently you have complied with Mozilla's request to not use their trademarks for your browser packages. However, you can't also use their trademark to switch users to a competing product. (bait-and-switch) The same trademark issues are why there is not a package called openoffice. It must be called openoffice.org. AFAIK, the firefox package is there to allow the Debian upgrade tools to install a new version of iceweasel in place of an old version of firefox. If it didn't exist, the old version of firefox would have been kept or removed and no new version of iceweasel would have been installed. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DFSG-freeness of the CID Font Code Public Licence
El lunes, 5 de junio de 2006 a las 19:39:46 +1000, Andrew Donnellan escribía: But it doesn't say that - it says applicable laws, if that includes US export laws then there's nothing you can do about it because it would apply to you in any case. It says applicable laws, including US export laws. That's: applicable laws, and, in addition to them, US export laws. If I live in the EU, US export laws are not applicable laws to me, but per the license, I'd have to comply anyway. (BTW, I disagree with the this clause is already implied in the law so let's ignore it because it's harmless school of thought. If the clause is there it's intended to have an effect. What if laws change? What about other jurisdictions?). -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DFSG-freeness of the CID Font Code Public Licence
El lunes, 5 de junio de 2006 a las 13:14:49 +0100, Stephen Gran escribía: that don't follow the Sharia, you would be forced to? Do you think a license can ever force you to follow laws that have no jurisdiction? After seeing licenses that claim not to be affected by any laws that would make any of its clauses illegal, I'd expect anything from them. Yeah, such clauses would be void, but the best thing you could make in such a case would not to accept the license at all (and not distribute the software). Yes, exactly. This means that the sentence boils down to roughly, 'you have to not break the law for your jurisdiction'. Well, that's hardly non-free. Another[0] piece of hideous pseudopoetry: If this software you want to use, abide by laws with no excuse; for if you're ever caught speeding, this very agreement will be rescinded. [0] http://raw-output.org/20060605/decorative-clauses -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DFSG-freeness of the CID Font Code Public Licence
El lunes, 5 de junio de 2006 a las 15:39:01 +0200, Jacobo Tarrio escribía: Yes, exactly. This means that the sentence boils down to roughly, 'you have to not break the law for your jurisdiction'. Well, that's hardly non-free. Another[0] piece of hideous pseudopoetry: Sorry. What I mean is that I'm very suspicious of such clauses, because the usual claim is that they have no effect at the end. Well, if they don't, why are they there? -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A GPL-compatible license for photos and music. Which?
El domingo, 23 de abril de 2006 a las 22:25:35 +0400, olive escribía: I don't understand this. For photographs, modifications doen't really make sense (apart from some adjustement). If you want to modify a In worth1000.com you can find several examples of modified photos... -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MPL and Source Code
El lunes, 3 de abril de 2006 a las 13:02:58 +1000, Craig Southeren escribía: If Debian is not ensuring that all source code for it's distribution is publically available via it's archives, then I agree that this is not only a problem for Debian, but it is definitaly a problem for downstream repackagers who rely on this. Debian does not ensure that it will have source code for any given package one year after its initial release. For example, if package foo 3.17, which is only in unstable, is replaced by package foo 3.18, the source code for 3.17 is deleted immediately. If foo were distributed under the terms of the MPL, Debian would have to keep the source code for any version released less than one year ago, and Debian's not willing to do it. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: the new license for IBPP
El jueves, 30 de marzo de 2006 a las 16:33:59 +0300, Damyan Ivanov escribía: Permission is hereby granted, free of charge, to any person or organization (???You???) obtaining a copy of this software and associated documentation files covered by this license (the ???Software???) to use the Software as part of another work; to modify it for that purpose; It allows to modify the library if it is needed to make it work with other piece of software (for that purpose == to use the Software as part of another work), but that wording does not allow modifying it to improve its performance, for example. This is why writing licenses is tricky :-) -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MPL license
O Domingo, 26 de Marzo de 2006 ás 20:57:35 +0200, Mike Hommey escribía: The GPL does require something similar. Not exactly. The GPL requires you to provide source alongside binary; when you stop offering the binary, you may stop offering the source. However, under the MPL, you must go on offering the source after you stop offering the binary. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Flamerobin-devel] License, again
El jueves, 23 de marzo de 2006 a las 22:59:46 +0100, Milan Babuskov escribía: The GPL itself covers these points. In principle, debian-legal discourages license proliferation. GPL does cover it, but GPL requires that modifications are made public. No, it does not. It only requires that, if a modified version is published, it is distributed under the terms of the GPL. Licenses that require that modifications are published are routinely rejected by Debian. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Flamerobin-devel] License, again
El viernes, 24 de marzo de 2006 a las 10:18:14 +0100, Jacobo Tarrio escribía: Licenses that require that modifications are published are routinely rejected by Debian. More properly, Works distributed under licenses that... -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Flamerobin-devel] License, again
El jueves, 23 de marzo de 2006 a las 15:55:55 +0200, Damyan Ivanov escribía: 1. allow anyone to download, copy and redistribute FR source as it is. 2. if someone makes modifications for his own use, he is not obligated to publish them 3. if someone makes modifications and makes executable version available, he must make the modifications available to the same person he made executable version available to. 4. no warranty Alright. Please, folks on debian-legal, can you see any problem including software with such licensing in Debian? Can you recommend a license that satisfies the above points and is DFSG-free? To me it seems like Expat plus point 3 above (but I can't legal-speek-phrase it). The GPL itself covers these points. In principle, debian-legal discourages license proliferation. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: no longer a bug.
El domingo, 12 de marzo de 2006 a las 13:39:45 -0500, Mike O'Connor escribía: The only things the documentation license holds as invariant are the GPL and the GFDL themselves, and Debian already accepts those as being invariant, this documentation should no longer be considered non-free in light of GR-2006-01. But becuase of this, I'm copying debian-legal. The GPL is not the license of the document, so it is not the case. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Portaudio] Re: portaudio in Debian, license updates?
El domingo, 5 de marzo de 2006 a las 14:44:33 -0500, Joe Smith escribía: If a court is in doubt as to how the licence is to be interpreted it should look at such text. Such text, especially if included near the licence, has If the author intends it to be a request, not a requirement, nobody will end up in court over this. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL v3 Draft
El lunes, 16 de enero de 2006 a las 09:07:42 -0800, Don Armstrong escribía: The Complete Corresponding Source Code for a work in object code form means all the source code needed to understand, adapt, modify, compile, Good, now even if someone codes a piece of firmware directly in machine code, they cannot say that the preferred form for modification is this raw listing of 73894 hex codes. There's probably some comments and some documentation that was used to understand the program while it was being written, and that's now being considered part of the complete source code too... Propagation of covered works is permitted without limitation provided it does not enable parties other than you to make or receive copies. Given up on the ASP loophole yet? :-) this specific declaration of the licensor's intent. Regardless of any other provision of this License, no permission is given to distribute covered works that illegally invade users' privacy, nor for modes of This is a restriction on running the program disguised as a restriction on distribution... c) If the modified work has interactive user interfaces, each must include a convenient feature that displays an appropriate copyright notice, and tells the user that there is no warranty for No longer optional? startup--except in the case that the Program has such interactive modes and does not display this information at startup. But the message on startup is still optional. I'm not sure it's exactly what they mean... d) Distribute the Object Code by offering access to copy it from a designated place, and offer equivalent access to copy the Corresponding Source in the same way through the same place. You need not require recipients to copy the Corresponding Source along with the Object Code. It's nice that they include this because it's theoretically not permitted in GPLv2, and that's how Debian (and everyone else) distributes its stuff :) Aside from additional permissions, your terms may add limited kinds of additional requirements on your added parts, as follows: I can see now the coming 15 years of debian-legal flamewars, since some of these allowed additional requirements are non-DFSG-free (some forms of patent retaliation and of mandatory link to download the source code, for example). So some GPLv3-ed works will be non-DFSG-free because they contain components which are non-DFSG-free. And, of course, people won't say d-l says that work X under the GPLv3 which contains component Y under the license Z is non-free, but d-l says that the GPLv3 is non-free. Such is life in d-l. When others modify the work, if they modify your parts of it, they may release such parts of their versions under this License without additional permissions, by including notice to that effect, or by deleting the notice that gives specific permissions in addition to this License. Then any broader permissions granted by your terms which are not granted by this License will not apply to their modifications, or to the modified versions of your parts resulting from their modifications. However, the specific requirements of your terms will still apply to whatever was derived from your added parts. This paragraph is using permissions and requirements interchangeably, which is confusing (and incorrect). -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is libreludedb DFSG compliant?
El jueves, 29 de diciembre de 2005 a las 15:54:51 +0100, Mickael Profeta escribía: If you link LibPreludeDB against other code all of which is itself licensed under the GNU General Public License, version 2 dated June 1991 (GPL v2), then you may use Libprelude under the terms of the GPL v2, as appearing in the file COPYING. If the file COPYING is missing, you can obtain a copy of the GPL v2 from the Free Software Foundation Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA. For any other uses of LibPreludeDB, you must first obtain a commercial license from PreludeIDS Technologies SARL. Please contact [EMAIL PROTECTED] for information about commercial licensing. This wording makes it look like it is GPLed only if it is linked against a preexisting GPLed work. That is, if you want to take libPreludeDB out of Prelude and modify it, you can't because it's not GPLed. To have this fixed properly, I'd suggest using the standard This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License bit, plus an additional paragraph that states that you can make use of the library under other terms if you obtain a commercial license from PreludeIDS Technologies SARL. You can use eZPublish's licensing scheme as a guide. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rar support violates DFSG #4
El sábado, 26 de noviembre de 2005 a las 11:11:32 +0100, Robert Millan escribía: That suggests if the maintainer disagrees in, say, DFSG #1 (Debian will remain 100% free), then we don't have to treat as release-critical an inclussion of DFSG #4 states: We will be guided by the needs of our users and the free software community. Please, don't confuse the Debian Free Software Guidelines and the Social Contract :-) -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New BitTorrent License Preview
El miércoles, 5 de octubre de 2005 a las 19:12:00 -0400, Joe Smith escribía: Does this mean that I cannot sell it unless I or anyone else in the world has modified it? Isn't that stipulation a bit stupid? I read this as saying you may not sell etc. the original work unless it contains some modifications. Any modification is acceptable, be it by you or any other party. Actually, only modifications that improve the program or add to its functionality (or makes the program add to the functionality of another work) substantially. This means that the trick that has been used to circunvent other don't sell clauses (which I don't like -- the trick and the clauses) and distribute the software in main would not work anymore. Moreover: Additionally, without limitation of the foregoing and notwithstanding any provision of this License to the contrary, you cannot charge for, sell, license or sublicense for a fee, accept donations or otherwise receive compensation for the Source Code. The clause basically says that you may not charge for the source CDs, however AFAICT, this does not prevent you from charging for Binary CDs. Yes, if they contain an unmodified copy of BitTorrent. It has the effect of saying that you must not charge anything for the source alone, but you may charge for the source in conjunction with the binary. No, you cannot charge anything for the source. If you include binaries, you're charging for the binary, not the source. It may be nitpicking but always keep it in mind. This can be avoided by doing what is a good idea anyway: Always include the source CDs with debian binary cds, and don't sell the source cds seperate. Debian does not stipulate that source CDs must be sold alongside binary CDs. Anyway, I can think of another scenario where this clause is a nuisance: you live in a country where international bandwidth is scarce and expensive (so you cannot download the program) but domestic bandwidth is free (so the program is still useful to you), so you ask me to burn a copy of the source code and mail it to you. The license forbids me to have you pay me the costs of the CD and the mailing, or even to accept a drink next time we meet! The license would make you an egotistic friend, in other words ;-) -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New BitTorrent License Preview
El martes, 4 de octubre de 2005 a las 11:26:03 -0500, Michael Janssen escribía: Just a couple of comments: In clause 3: As an express condition for your use of the Licensed Product, you hereby agree that you will not, without the prior written consent of Licensor, use any trademarks, copyrights, patents, trade secrets or any other intellectual property of Licensor or any Contributor except as expressly stated herein. For the avoidance of doubt and without limiting the foregoing, you hereby agree that you will not use or display any trademark of Licensor or any Contributor in any domain name, directory filepath, advertisement, link or other reference to you in any manner or in any media. Oh, a clause dealing with trademarks in a copyright license. And very inconvenient, as well. This would forbid that the Debian package of BitTorrent were called bittorrent. We would have to call it binary-digit-violently-fast-stream-of-water or something like that. This is some piece of (not legal) advice from me: delete these (new to this version) two sentences from the license, please. From 4.g.: For the avoidance of doubt, to the extent your executable version of a Licensed Product does not contain your or another Contributor?s material Modifications or is otherwise not a material Derivative Work, in each case as contemplated herein, you may not sell, license or sublicense for a fee, accept donations or otherwise receive compensation for such executable. Does this mean that I cannot sell it unless I or anyone else in the world has modified it? Isn't that stipulation a bit stupid? Moreover: Additionally, without limitation of the foregoing and notwithstanding any provision of this License to the contrary, you cannot charge for, sell, license or sublicense for a fee, accept donations or otherwise receive compensation for the Source Code. This would mean, if a product covered under this license were included in Debian, that nobody would then be allowed to sell Debian source CDs. That would be a case of this product's license contaminating other software, which is forbidden by DFSG#9, so this clause makes the license non-free. Also, this would be a practical problem: in some places it is actually cheaper and faster and more convenient to buy a Debian CD from a bookstore or over the Internet than to download and burn it. That's why selling Debian CDs is not only allowed: it is encouraged. I love this piece in clause 13: Any law or regulation that provides that the language of a contract shall be construed against the drafter shall not apply to this License. I am speechless. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is VIGRA Artistic License licence free and GPL-compatible ?
El lunes, 26 de septiembre de 2005 a las 19:34:00 +0200, Claus Färber escribía: a. place your modifications in the Public Domain or otherwise make them Freely Available, for example by allowing the Copyright Holder to include your modifications in the Standard Version of the Library. This goes beyond copyleft and is non-free, because it violates DFSG#3, restricting the distribution of derivative works. Why? All you have to do is to make the modifications freely available. Putting them under a license that is compatible (e.g. Public Domain) seems to be enough. Because the DFSG say that the license must allow distribution of modified works under the same terms as the original one. However, this one forces modified works to be in the Public Domain, which is nowhere near the terms of the original work. Moreover, forced distribution of modified versions is considered non-free (one should be allowed to create private modifications). -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux Documentation Project License (LDPL) v2.0
El domingo, 25 de septiembre de 2005 a las 10:58:49 -0400, Joe Smith escribía: Is it just me or is it hard to sue a pseudonymous modifier, becaue their real identiy is not known? Yes, but the pseudonymous modifier would have lost the license to distribute the work, and anyone distributing that version would be distributing an unlicensed piece of software. Also is it possible for somebody to enforce the copyright to a work they published anonymously if they wish not to lose the anonimity? Yes, anonymous authors usually have their publisher enforce the license for them. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linuxsampler license
El jueves, 15 de septiembre de 2005 a las 10:50:12 +0200, Sven Luther escribía: LinuxSampler is licensed under the GNU GPL license with the exception that COMMERCIAL USE of the souce code, libraries and applications is NOT ALLOWED without prior written permission by the LinuxSampler authors. If you have questions on the subject please contact us. That is indeed non-free and fails DFSG #6, the package cannot be in main, but could be in non-free maybe. Probably not, according to some interpretations (the GPL does not allow adding restrictions. The author can distribute the work, since he/she is the author, but noone else can distribute a work licensed in this way). Also, the use of the word exception is very sneaky :-) It is more like an additional restriction :-) -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linuxsampler license
El jueves, 15 de septiembre de 2005 a las 13:07:18 +0300, George Danchev escribía: That is indeed non-free and fails DFSG #6, the package cannot be in main, but could be in non-free maybe. Probably not, according to some interpretations (the GPL does not allow Right, as explained in #12 h, i, j, k at: http://people.debian.org/~bap/dfsg-faq.html What I meant is that some believe that a piece covered by the GPL+additional restrictions, even if these restrictions were added by the author, is not distributable at all (by anyone other than the author). Of course it's non-free if it does not allow commercial usage. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Alternatives to the Affero General Public License
O Martes, 21 de Xuño de 2005 ás 20:07:36 -0700, Gregor Richards escribía: In response section 6: (So that I can reference, the full section:) 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. It seems to me that the license from the original licensor would include this new term/condition, as that is how (s)he licensed it. If you look closely, it says subject to these terms and conditions and the rights granted herein, not subject to the same terms and conditions under which you received the Program nor the rights granted to you. I of course can't make an entirely new license based on the GNU GPL without FSF's permission, so is there any way that a term could be added at all? You can, if you remove the preamble. http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL In response to the dissident problem: I don't see how this hinders said dissident at all. If said dissident has to send the entire source, (s)he as already made it available through some computer network. Made *what* available? An interface to the program, not the program itself, like in the GPL. If said dissident made it available on a public computer network, they have already incriminated themselves Not necessarily. For example, in a CMS for dissidents, the source code might include workflow code that reflects the structure of the dissident organization (for example, the text is written then sent for approval to the local coordinator, then to the regional coordinator, then it is published and a copy is sent to the pamphlet printers). The source code now contains information which is not present in the user interface but is incriminating. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [WASTE-dev-public] Do not package WASTE! UNAUTHORIZED SOFTWARE [Was: Re: Questions about waste licence and code.]
O Mércores, 18 de Maio de 2005 ás 21:46:48 -0400, Roberto C. Sanchez escribía: That is completely not possible. Once you offer (and someone accepts) code under the terms of the GPL, they are for evermore entitled to use *that* code under the GPL. About the only thing that can be done is Assuming that EU laws aren't involved, which allow the author to take all copies of their work out of circulation (but the laws, or at least Spanish law, also say that the author must pay damages, and if they decide to return the work to the market, it must be under reasonably similar conditions). -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [WASTE-dev-public] Do not package WASTE! UNAUTHORIZED SOFTWARE [Was: Re: Questions about waste licence and code.]
O Xoves, 19 de Maio de 2005 ás 19:52:28 +0200, Arnoud Engelfriet escribía: That's an aspect of EU copyright law I'm not aware of. Can you tell me which Berne provision or EU directive this is? Please, next time just say directly that's not so and it'll be easier on my health. Thanks. And that's not so, true. I hadn't gotten it right the first time, and I won't say EU now. Spanish law says (the ugly translation is mine): The following un-disclaimable and inaliable rights belong to the author: [...] 6. Retiring the work from the market, due to a change in their intellectual or moral convictions, after a payment of damages to the holders of exploitation rights. I said that the translation was ugly. So scrap my previous e-mail. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Asking for advice regarding the Sleepy Cat's dbxml license
O Xoves, 5 de Maio de 2005 ás 10:36:09 +0200, Tomas Fasth escribía: * 3. Redistributions in any form must be accompanied by information on *how to obtain complete source code for the DB software and any *accompanying software that uses the DB software. The source code *must either be included in the distribution or be available for no *more than the cost of distribution plus a nominal fee, and must be *freely redistributable under reasonable conditions. For an *executable file, complete source code means the source code for all *modules it contains. It does not include source code for modules or *files that typically accompany the major components of the operating *system on which the executable file runs. This one is problematic as it does not specify for how long the information on how to obtain complete source code must be valid. For example, if it were a requirement to have it available for one year after the download, Debian would not be able to carry it (as source code is deleted from the archive when corresponding binaries are deleted) -- plus one such requirement is considered non-free by many. If it's enough that source code is available at the same moment the binary is downloaded, it is acceptable. (The GPL has a provision for a three-year-long offer for source code, but as Debian provides source code at the same time as the binaries, Debian isn't really using it). -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT 3) FAQ on documentation licensing
O Mércores, 20 de Abril de 2005 ás 08:40:21 +0200, Jacobo Tarrio escribía: Yes, in places it is too verbose, being that I'm not used to writing in English :-) (I think that I've been reading too many American laws, lately. The provision hereunder, therefore, applies to all persons not under 17 and born not after 1950, unless they never wear pants. 'Pants' means...). -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
(DRAFT 4) FAQ on documentation licensing
After suggestions by Glenn Maynard, I rewrote most of the document to make it simpler and remove redundancies that were repeated over and over ;- I repeat my point: repeated exposure to American legal texts is bad for non-native speakers ;-))) The first two questions were merged into a single one. The question about credits was deleted as it is probably too hard to answer in a FAQ (and it is not frequent at all, anyway). The end-result is two questions shorter than the original, and much easier to read (I hope). I'm still unhappy with the length of the second question (the question itself, not the answer). The current text: http://jacobo.tarrio.org/Documentation_licensing_FAQ Full document history is available by clicking on the historial tab, in case you want to compare or recover something. If you do not understand Spanish, you can use the Wikipedia page as a reference (the software I use is Wikimedia). You cannot edit any pages; direct your comments here. Q: Why does Debian apply the DFSG to documents? A: Debian applies the same standards of freedom to all works it distributes; some of these standards are written down in the DFSG. No good reasons have been provided to use a different standard with documents than with programs. Even if we were to treat software and documentation differently, first we would need to have a clear way to tell documentation apart from software. Many works, like source code annotated with Javadoc comments or Postscript files, are software and documentation at the same time, so it is easy to see that there is no such clear division. Q: Some documents need to have some parts which must not be modified. For example, RFC or other standards documents should not be modifiable at all. Or a piece may contain the author's opinion on something, and nobody should be allowed to misrepresent the author's position by modifying that piece. Isn't this a restriction that should be allowed in documents and not in programs? A: Mainly, for three reasons: such a restriction is unnecessary, it is useless and it is not true that it would be less appropriate for software than for documentation. First, misrepresentation can be prevented without forbidding anyone to modify the work, by requiring all modified works to not claim that they are the original work or that they were written by the original work. Furthermore, a clause in a copyright license would not stop anyone from misrepresenting the work or its authors. For example, I might create a new, original document titled RFC 2821, Simple Mail Transfer Protocol with a distorted description of SMTP, and with this action I would not be contravening the license of the IETF's RFC 2821. The proper defense against this are the various laws dealing with libel, fraud and impersonation. Finally, if there were any reasons to allow such a restriction in documents, these reasons would allow it in programs too. For example, qmail's license forbids distributing modified versions of it, since its author believes that his reputation might suffer if someone distributed a version of qmail with bugs not introduced by him. If restrictions on modification of documents were allowed to save an author's reputation, they would be allowed on programs; this would make qmail free, but due to the DFSG it isn't, so these restrictions cannot be allowed. Q: I think that some Debian Free Documentation Guidelines should be created as an alternative to the DFSG for documentation. What should I do to have them adopted? A: First, you must write them; most people never manage this part. Next, for every license restriction permitted by your new guidelines that isn't allowed by the DFSG, you must give satisfactory answers to these three questions: 1. How do we distinguish between packages where this restriction should and should not be allowed? 2. Why should the restriction be allowed in for these packages? 3. Why shouldn't the restriction be allowed in for every other package? Note that the answers to (2) and (3) should not involve special pleading or otherwise be contradictory. Because it's documentation is not a valid answer, and the answer to (3) should not apply to the packages in question. You'll need to discuss your proposal on debian-legal and debian-project to work out any problems with your proposal and to gather support for it. Finally, you'll have to propose a General Resolution to amend the Social Contract, and convince a 3:1 supermajority of your fellow Debian developers to vote for it. Q: If the DFSG are to be applied to documents as well as to programs, why is the text of the GPL included in Debian, if it says that it cannot be modified at all? A: Because the verbatim text of the license must be distributed with any work licensed under its terms. This is not specific to the GPL; almost all free licenses require that their text be included verbatim with the work. As a compromise, Debian distributes copies of the GPL and
Re: (DRAFT 4) FAQ on documentation licensing
O Mércores, 20 de Abril de 2005 ás 11:20:36 -0300, Humberto Massa escribía: s/software/programs and\/or libraries/g Darn, I had managed to avoid it in the previous version :-) -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT 4) FAQ on documentation licensing
O Mércores, 20 de Abril de 2005 ás 14:53:18 +, MJ Ray escribía: Q: Shouldn't we allow documents which describe standards or personal opinions to be non-modifiable? Why should we need the same freedoms as for programs? That's a good one (although I don't like the last question very much, I'm putting it in anyway). I think a better example would be the demonstration implementation of a protocol included with a standards document. (I know it's popular (maybe even deserved) to kick qmail, but why do it here?) I suggest: Well, I wrote about qmail because it was the example I knew best. Hey, I even understood his reasons! ;-) Ok, ok, I'm leaving DJB alone... the Q now reads: Q: Shouldn't we allow documents which describe standards or personal opinions to be non-modifiable? Why should we need the same freedoms as for programs? A: Mainly, for three reasons: such a restriction is unnecessary, it is useless and it is not true that it would be less appropriate for programs than for documentation. First, misrepresentation can be prevented without forbidding anyone to modify the work, by requiring all modified works to not claim that they are the original work or that they were written by the original authors; so, the restriction is unnecessary. Furthermore, a clause in a copyright license would not stop anyone from misrepresenting the work or its authors. For example, I might create a new, original document titled RFC 2821, Simple Mail Transfer Protocol with a distorted description of SMTP, and with this action I would not be contravening the license of the IETF's RFC 2821. The proper defense against this are the various laws dealing with libel, fraud and impersonation. So, such a restriction would be useless. Finally, if there were any reasons to allow such a restriction in documents, these reasons would allow it in programs too. For example, a standards document might be accompanied by a demonstration program. One could say that the reputations of the authors of the document and the program may suffer if someone breaks either one of them. If Debian allowed any restriction on modification of the document, Debian should also allow the same restriction on modification on the program, so this kind of restrictions would not be more appropriate for documentation than for programs. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT 3) FAQ on documentation licensing
O Sábado, 16 de Abril de 2005 ás 18:49:15 +0200, Francesco Poli escribía: Here I don't know if it's me that sees it wrong or that symbol is really a question mark... I would do s/components \? the/components: the/ That's a dash (mdash;), that does not appear well because I cut-and-pasted from Firefox, and as I'm using Latin-1... I changed it to a semicolon ;) Perhaps it's clearer if you say derived license rather than derivative work. Yes, I agree. Some people are even too easily confused ;-) -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT) FAQ on documentation licensing
O Venres, 15 de Abril de 2005 ás 00:29:52 +0200, Francesco Poli escribía: Copyright ones are not the only issues that matter when we check whether a work is DFSG-free. Oh, you're right. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT) FAQ on documentation licensing
O Venres, 15 de Abril de 2005 ás 17:06:00 -0400, [EMAIL PROTECTED] escribía: How about this, more to the point? If the author or standards organization is unconvinced by this argument, and does not want to Ah, now I understand what you meant :-) I have added something to that effect. I'm sending now a message with the current version of the FAQ for any further comments; I won't send any other version until Monday at the earliest. Latest version: http://jacobo.tarrio.org/Documentation_licensing_FAQ -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT) FAQ on documentation licensing
O Xoves, 14 de Abril de 2005 ás 01:22:56 +0200, Francesco Poli escribía: A: The DFSG is a set of minimum criteria that are taken into account when deciding if a particular copyright license is free or not. I would prefer if a particular /work/ is free or not. Actually, it would be a mix of both: if a particular work, with its copyright license, is free or not. [...] the existence of different DFSG and DFDG would mean that there are some freedoms that are necessary for programs but are irrelevant for documents, and vice versa [...] I would add Nobody has yet provided a convincing rationale to explain *why* programs and documents should need a different minimum set of freedoms. The Debian project claims that the same freedoms are important for both programs and documents. Agreed; I intended to add something like this all along, but I finally forgot it. Thanks for adding it :-) 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. [...] they fail to see the difference between creating a derivative work and modifying the work itself [...] I'll add ; it just creates a new work, derivative of the original RFC to the sentence, since the derivative work bit is important :-) Perhaps it's better avoiding recommending trademarks or otherwise we should be prepared to see more and more Mozilla-like mess in the future... :-( Mmmm, you are right. I'll delete the comment about trademark laws (will leave the reference to libel), but they will eventually have to be mentioned, since I believe that they're the ones to be used for protecting the reputation of the authors/of the original works, etc., etc., not a clause in the copyright license. But while the implications of using trademark law for this are not fully explored by us and put into writing, perhaps they're best left out of this FAQ... (I was going to remove slander, since slander is speech and libel is writing, but perhaps someone would modify a voice recording just to prove me wrong, so... ;-)). [Comment] Good example. My favorite one is the following: if the license of a MUA forbade to add HTML mail support (because the authors are philosophically against HTML mail), this license would be considered non-free, even when it would be protecting the authors' own opinions. This is even a better example than mine. I'll change mine to this (the old one is kept saved in the page's [1] history). == [1] http://jacobo.tarrio.org/Documentation_licensing_FAQ -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT) FAQ on documentation licensing
O Xoves, 14 de Abril de 2005 ás 09:37:12 +0100, Andrew Suffield escribía: It could also be fraud, or (strangely enough) in some jurisdictions, copyright. Although not the part of copyright law that is related to licensing; the right to not have things misattributed to you cannot be waived, transferred, or otherwise licensed. But it is sometimes written into the copyright statute rather than anywhere else. And that's why don't use the name «apache» or don't misattribute me clauses in copyright licenses are stupid: because then I might create a completely new work called «apache» or attributed to that author without contravening the terms of these licenses. What stops me from doing these things are other laws. If I find the right wording, I'll add it to my FAQ proposal. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT) FAQ on documentation licensing
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 :-) -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT) FAQ on documentation licensing
O Xoves, 14 de Abril de 2005 ás 08:55:07 -0400, Anthony DeRobertis escribía: Append at the end: - Discuss it on -project(?). Once you've worked out any problems with - Propose a General Resolution to amend the Social Contract and convince Oh, yes. I thought it looked too easy ;-) -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
(DRAFT 2) FAQ on documentation licensing
24 hours have passed, and this is the text of the current revision. Additions, removals, rewordings, criticism, suggestions are welcomed and requested. The latest revision is always available (minus network hiccups) at http://jacobo.tarrio.org/Documentation_licensing_FAQ When the text is stable, I will submit it for inclusion in the DFSG FAQ. Q: Why does Debian apply the DFSG to the GFDL (and other licenses)? A: The DFSG is a set of minimum criteria that are taken into account when deciding if a particular work, with its copyright license, is free or not. Everything that is distributed by Debian in its main distribution must be free, so the DFSG are the criteria to be applied. Q: But the GFDL (and other licenses) are not software licenses, but documentation licenses. Software and documentation are not the same thing. A: Even if by software you mean programs, there's not always a clear-cut distinction between programs and electronic documents. For example, a Postscript file may contain the full text of the GNU Emacs manual (that is a document), but it is really a program which is interpreted by Postscript-capable printers to render that text on paper. Other examples include literate programming (a style of writing programs in which what is really written is an essay about how a program works, with code snippets) or javadoc-like documentation embedded in program source code. Of course, a copy of the GNU Emacs manual printed on dead trees is definitely not software, but Debian doesn't distribute physical goods, so this example is irrelevant to the question. Q: Why are the DFSG applied to documentation? There should be some Debian Free Documentation Guidelines (DFDG) to be applied to documents instead of the DFSG. A: See the previous question. Even if it doesn't convince you or you can live with the ambiguity described there, the existence of different DFSG and DFDG would mean that there are some freedoms that are necessary for programs but are irrelevant for documents, and vice versa. Nobody has yet provided a convincing rationale to explain *why* programs and documents should need a different minimum set of freedoms. The Debian project claims that the same freedoms are important for both programs and documents. Some examples of this are given in the following questions. 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 misrepresent 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 created. Modifying a copy of a standards document, such as a RFC, does not modify the RFC itself; it just creates a new work, derivative of the original RFC. If what's really intended is to stop someone from passing a modified document as the original, other means must be used, such as slander/libel laws already existing in most jurisdictions. Clauses in copyright licenses are completely useless for this purpose, since they can be easily worked around by creating brand new works with defaming content, which would not be contravening the clause. In other words, one should be allowed by the license to write a document derived from RFC 2822 and titled New proposed extensions to SMTP, or a document titled A layperson's comments on the GNU Manifesto which was made by modifying the GNU Manifesto itself. It is the same situation in a program. For example, if the license of an email client forbade to add HTML mail support (because the authors are philosophically against HTML mail), this license would be considered non-free, even when it would be protecting the authors' own opinions. Q: The authors of a document or a literary work deserve to be credited. They should be able to add a restriction to the license so that their names must be displayed prominently on the front cover. Shouldn't such a license be considered free? A: Debian would normally consider free a license that mandated that the name of the authors appear along with other credits or something like that. Specifying the form the credit must take, or its exact wording, or where it must appear, are restrictions that aren't generally considered free. Additionally, they have some problems of their own. For example, how do you display a name prominently on the front cover of a text file? Or what if someone makes a compilation of texts; should all names appear prominently on the front cover? Also, authors of programs deserve to be credited as well, and similar restrictions have already considered non-free. For example, a license that says that a three-screen credits text must appear on startup would be unacceptable. Q: Anyway, I think that some Debian Free Documentation Guidelines are necessary as an alternative to the DFSG for documentation.
Re: (DRAFT 2) FAQ on documentation licensing
O Xoves, 14 de Abril de 2005 ás 11:46:36 -0400, Raul Miller escribía: Another example is incorporating documentation into a program, to be displayed at run time. Included. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT 2) FAQ on documentation licensing
I have added this to the FAQ: Q: If the DFSG are to be applied to documents as well as to programs, why is the text of the GPL included in Debian, if it says that it cannot be modified at all? A: It is included because this text contains the terms under which many components of a Debian system are distributed. Debian is legally required, then, to inform of these terms to the receiver of the components ? the only way is including the text in the Debian system itself. Take into account, however, that: 1. According to the FSF (copyright holder on the text of the GPL) you're actually allowed to modify the text of the GPL and create a derivative work if you remove the preamble and you do not call the results General Public License (reference: http://www.fsf.org/licensing/licenses/gpl-faq.html#ModifyGPL) 2. Actually, if no works in Debian were covered under the GPL, Debian would not distribute the text of the GPL by itself. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT) FAQ on documentation licensing
O Mércores, 13 de Abril de 2005 ás 16:56:04 +0100, Andrew Suffield escribía: Of course, a copy of the GNU Emacs manual printed on dead trees is unequivocally documentation, ^ You mean 'not software'. It's always documentation; in softcopy form it happens to be software as well (and since it's written in info, it probably qualifies as a program). Yes, that's what I meant. I left it [1] as definitely not software :-) == [1] http://jacobo.tarrio.org/Documentation_licensing_FAQ [2] [2] It doesn't have DRAFT in the URL but it does in the text. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT) FAQ on documentation licensing
O Mércores, 13 de Abril de 2005 ás 17:56:11 +0100, Andrew Suffield escribía: I've written this four times in the past week, so it belongs in a FAQ. Something along these lines should be included: Done. Now you can start just pasting URLs [1] :-) == [1] http://jacobo.tarrio.org/Documentation_licensing_FAQ -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#296369: ITP: spin -- Powerfull model checking and software verification tool
O Martes, 22 de Febreiro de 2005 ás 13:54:18 +0100, Eike Dehling escribía: So unless someone uses it commercially no license applies. Debian itself A license is a permission grant. No license == no permission. isn't commercial, so it doesn't apply here. The first sentence even encourages redistribution/modification, i'd think? How much of a problem is the restriction on commercial use, when non-commercial use is free? Many of Debian's users are commercial entities. That's why the DFSG forbid discriminating between fields of endeavo(u)r (meaning, a license that says, for instance, noncommercial use only or not for atomic weapons testing or use in the trade of oil or oil-based products requires payment of a 0.5% royalty isn't valid for Debian). -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ReRegarding iraf
O Luns, 10 de Xaneiro de 2005 ás 18:53:52 +0100, Jacobo Tarrio escribía: What defines GPL compatibility? Modify and distribute? A license is compatible with the GPL if it does not include any restriction not present in the GPL. In my latest message I didn't really say what I really meant, so I'll explain it correctly now :-) Have a program P and a library L; one of them is distributed under the terms of the GPL and the other is distributed under the terms of another license. When you link P with L, the resulting binary B is a work that is covered by the terms of both licenses at the same time. So, when you distribute it, you must satisfy the terms of both licenses at the same time. Now, by the terms of the GPL, the binary B must be licensed as a whole under the terms of the GPL (clause 2b). Furthermore, you cannot impose any restrictions not present in the terms of the GPL (clause 6). So, a license is compatible with the GPL if: - the license does not forbid anything allowed in the GPL - there's nothing which is compulsory in the license but not in the GPL In short: a license is compatible with the GPL if distributing a work in a manner that complies with the GPL would also comply with the license. -- Jacobo Tarrío | http://jacobo.tarrio.org/
Re: Drawings similar to well known products. Copyright problems?
O Luns, 10 de Xaneiro de 2005 ás 18:51:32 -0500, Brian Thomas Sniffen escribía: I wouldn't be horribly surprised if the names hummer or rubik are Is HMMV a registered trademark? -- Jacobo Tarrío | http://jacobo.tarrio.org/
Re: ReRegarding iraf
O Luns, 10 de Xaneiro de 2005 ás 12:42:57 -0500, Justin Pryzby escribía: What defines GPL compatibility? Modify and distribute? A license is compatible with the GPL if it does not include any restriction not present in the GPL. Interpretation: when you join (by linking) a GPLed work with another work, the results is a derivative of both works. If this is distributed, it must be done so under the terms of the GPL, which forbids adding any restrictions to the terms of the GPL. Look at clauses 2, 3, 4 and 6 for more information. -- Jacobo Tarrío | http://jacobo.tarrio.org/
Re: Trademarks: what is the line?
O Venres, 31 de Decembro de 2004 ás 12:59:31 -0500, Brian Thomas Sniffen escribía: What sort of nonsense is that? What on earth are they trying to accomplish? About what Debian seeks to accomplish with the Official Logo: a seal or mark indicating quality. Yes, but the more widely known logo and name are the ones everyone can use. Mozilla, instead, restricts the use of their only logos and names. They don't say you can call your derived version of our product 'unrestrictedzilla', while we say here, use the swirl. -- Jacobo Tarrío | http://jacobo.tarrio.org/
Re: Trademarks: what is the line?
O Venres, 31 de Decembro de 2004 ás 13:12:38 -0800, Steve Langasek escribía: If we're not doing anything that requires licensing the trademark, a requirement in the trademark license to change the command names is ignorable. Well, using the trademark forces us to seek permission (a license) from its owner. But I'm not convinced that a command name would force us (or anyone) to it. -- Jacobo Tarrío | http://jacobo.tarrio.org/
Re: AbiWord, trademarks, and DFSG-freeness
O Venres, 15 de Outubro de 2004 ás 12:40:23 -0400, Raul Miller escribía: Oops, I have just thought of a case where it isn't so, at least in Spain. The Spanish trade mark law allows the owner of a trademark to prohibit its removal from a product. If we are prohibited from removing the name abiword from some derivative form of the program, then we must be allowed to have abiword on that derivative form. Alternatively, once we're not allowed to have abiword on the derivative form, we can't be prohibited from removing the name. But I was talking about whether trademark law alone would be able to make a work DFSG-unfree. Therefore, I was taking the permissions for the trademarked name in isolation, and so I said if the trademark owner forbade us from removing the trademarked name, the work would be DFSG-unfree. If the license for the trademarks and the license for the work were inconsistent... well, it's not like it never happened before :-) -- Jacobo Tarrío | http://jacobo.tarrio.org/
Re: AbiWord, trademarks, and DFSG-freeness
O Venres, 15 de Outubro de 2004 ás 02:12:41 -0500, Branden Robinson escribía: First of all, I Am Not A Lawyer, so don't sue me if your trial goes bad. It's all your fault for believing me :-) And now... I think that trademarks are irrelevant to DFSG-freeness since if the copyright license is DFSG-free, we would still be able to distribute the software even if we were asked by the trademark owner not to use its upstream name (we'd have to change the name. It would be a hassle, but the software would still be DFSG-free). IOW, nowhere in the DFSG says something like you cannot restrict the user's right to have their modified copies of the software called in the same way as the original. In fact, there's one place (DFSG #4) where it says just the opposite :-) So take the following only FYI, since I think you'd like to know about it. Or if there's interest in ever writing a trademark license for the Debian logos, which allow the maximum admissible freedoms :-) First, useful URLs: http://www.oepm.es/internet/legisla/signos/iii21lmar.htm This is the URL to the Spanish trade mark law. It's in Spanish but it's there for the record :-) http://europa.eu.int/eur-lex/en/consleg/main/1989/en_1989L0104_index.html This is the EU trade mark directive. All EU member states' trade mark laws have to comply with this. http://europa.eu.int/eur-lex/en/consleg/main/1994/en_1994R0040_index.html This is the Council Regulation on the Community trade mark. That is, EU-level trade marks. Its wording is similar to the Spanish law... 1) Do the default protections that attach to trademarks, even when unregistered and unmentioned (not even with a (TM)), infringe upon the freedoms the DFSG purports to defend? In Spain, trademark owners have no rights until they register them, or unless the trademark is notoriously known in Spain. After registering a trademark, its owner has the right to prohibit its use, but these prohibitions are not enabled by default (it's the owner who has to actively enforce the prohibitions). So there are no default protections in Spanish trademark law. I think it is the same for Community trademarks, that is, EU-level trademarks. 3) I don't know if the AbiWord developers are right about meaningful, strong, legal protections applying to potential trademarks if no notice of trademark status is made. After all, common dictionary words are frequently trademarked. In Spain, notice does not affect (in principle) the outcome of a trademark suit. Only a ceasedesist order, which would earn the trade mark holder damages in some cases. P1) Adopt a kind of don't-ask, don't-tell policy regarding implicit trademarks. Many free software developers don't give a whit about trademarks, and some don't even care how much their software is patched by third parties while retaining the name. So, if you maintain a package that doesn't assert any trademarks, don't worry about it. This is sane; if no TM is asserted, do nothing special. P2) If a package does assert a trademark, contact the mark holder and ask for a trademark license that permits usage of the marks under the same terms as the copyright license that has been attached to the corresponding work, wherever applicable. No; ask for a license that allows usage of the name for packages derived from the original and whose (behaviour, form, etc) does not deviate substantially from that of the original software. Or more than a license: prohibition of using the trade mark for any piece of software which is not derived from the original one or has had major modifications. I don't think more is needed. Look at first paragraphs to see why. -- Jacobo Tarrío | http://jacobo.tarrio.org/
Re: AbiWord, trademarks, and DFSG-freeness
O Venres, 15 de Outubro de 2004 ás 17:50:29 +0200, Jacobo Tarrio escribía: I think that trademarks are irrelevant to DFSG-freeness since if the Oops, I have just thought of a case where it isn't so, at least in Spain. The Spanish trade mark law allows the owner of a trademark to prohibit its removal from a product. I don't know what I would think of a piece of software with a name that couldn't be changed. It would make forking impossible... so now I know. Non-free. But it wouldn't be the case more often. More trade mark holders are more eager to have you NOT use their mark than the inverse ;-) Some hypothetical Debian Free Trade Mark Guidelines (DFTMG) would have this item: the trade mark license must allow removing the mark from the work. -- Jacobo Tarrío | http://jacobo.tarrio.org/
Re: JRockit in non-free, part II
O Mércores, 6 de Outubro de 2004 ás 04:24:31 -0700, Johan Walles escribía: Also, since I'm really unsure about what the requirements actually are to get into non-free, is the EULA forbidding re-distribution a show-stopper? I guessed that as long as Debian was allowed to redistribute, forbidding end-users to re-distribute was more of a nuisance to the end-users than a show-stopper for JRockit going into non-free. It is, since it's not Debian who is doing the redistribution, but the ftpmasters of the mirror sites who choose to carry non-free. -- Jacobo Tarrío | http://jacobo.tarrio.org/
Re: Real names in a football game
O Martes, 14 de Setembro de 2004 ás 22:18:46 +0200, Isaac Clerencia escribía: I think this can be illegal (also team names?). Yes, it falls under trade mark protection laws. Since team names and logos, and players' names are big assets for their teams and national leagues (put Beckam's name in a 5-euro t-shirt and now it's worth 50 euros), they're defended very aggresively. Some football (soccer) games have been released with players with names like José García and Roberto da Silva because they couldn't get the rights to the actual names. I'd remove the names (i.e. change them to other, innocuous names) even without asking as I know the answer beforehand. I already have a version without player names ready to be uploaded, removing team names should take a little more effort. Use city names. Or common prefix + city name + common suffix (Sporting Club de A Coruña, Atlético de Valencia, Madrid S.A.D., Berlin 89, etc.), but this would possibly re-create actual teams' names. Or turn the teams into national selections. Country names (or any geographical names) aren't protected by trademark laws. -- Jacobo Tarrío | http://jacobo.tarrio.org/
Re: MontyLingua license
O Martes, 24 de Agosto de 2004 ás 14:54:22 +0900, Seo Sanghyeon escribía: Since it is certainly licensed under GNU GPL, is it okay to go into Debian main? What could This is covered under GPL, but only for non-commercial use mean at all? I'd guess that it's just the usual association proprietary-commercial going on. Or it might be like Dansguardian's license [1]: GPL, but you cannot download Dansguardian from its page or an official mirror if you are going to use it for commercial purposes (you may download it from any site not associated with Dansguardian; that's how Debian distributes it). But I believe it is just the first case. Might require clarification from upstream if this piece of software were to be packaged, though. [1] http://dansguardian.org/?page=copyright2 -- Tarrío (Compostela)
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
O Xoves, 12 de Agosto de 2004 ás 11:29:50 -0400, Michael Poole escribía: * Licenses like the QPL, which compel me to give somebody more rights to my work than I had to his, are not Free. They are not compatible with DFSG 3. This is where you lose me. How is that incompatible with DFSG 3? If the license says that Entity X gets extra rights (perhaps being the author of the original software), what prevents Author Y from releasing modifications under the same license terms (Entity X gets extra rights to modifications)? You're talking about a license as a document with license terms written on it. He's talking about a license as a set of permissions the copyright holder grants. With this meaning, DFSG#3 would ask that anyone who distributes a modified work be able to give the recipient the exact same permissions she received from the copyright holder. If she gives a modified QPLed work to me, for instance, the permissions are the same, but if she distributes a copy to the original copyright holder, she would be forced to give him permissions she didn't originally receive. -- Tarrío (Compostela)
Re: compatibility of OpenSSL and GPL'ed plugins
O Venres, 16 de Xullo de 2004 ás 01:11:52 +0200, Marco d'Itri escribía: Let's consider a program, released under a MIT/X11 license and linked with OpenSSL. Some GPL'ed plugins (which are dlopen'ed at run time) are distributed with the program. Is distribution of this package a GPL violation? If they are distributed with the program (in the same tarball) and implement important features of the program, the terms of the GPL would apply to the whole package, so there would be a license incompatibility. -- Tarrío (Compostela)
Re: Desert Island Test [Re: DRAFT: debian-legal summary of the QPL]
O Martes, 13 de Xullo de 2004 ás 00:56:39 -0700, Sean Kellogg escribía: back to B due to lack of communication facilities. The duty in question will be discharged by the court under section 261 provided section 263 is 95% of the world population does not live in the US. -- Tarrío (Compostela)
Re: DRAFT: debian-legal summary of the QPL
O Martes, 13 de Xullo de 2004 ás 15:19:02 +0100, Matthew Garrett escribía: I'm also unconvinced by these examples. The first sounds like A free software license should allow for small groups to avoid lawsuits while breaking the law, and the GPL can damage a wide range of perfectly legal business plans. Well, the intent behind the dissident test is not to protect you from oppresive governments; it is to check whether the license forces you to sacrifice your privacy. I wouldn't consider a license free if it said, for example, if you modify this program you must add your name to this wiki page as soon as possible. It wouldn't fail the desert island test (as soon as possible might easily mean never) but it would fail the dissident test. Tests are only for testing, not for stretching as much as we can: but he can just ignore the license. If he's a dissident it's not like he's not breaking any law. Oh, yes, but that's what the dissident test was made for. -- Tarrío (Compostela)
Re: Copyright on 'non-creative' data?
O Domingo, 4 de Xullo de 2004 ás 20:54:48 +0100, Andrew Suffield escribía: They may be covered by database property laws in some jurisdictions. ... which are not Copyright or Intellectual Property laws, so Debian would treat them in the same way it treats, for example, patents or trademarks. -- Tarrío (Compostela)
Re: request-tracker3: license shadiness
O Xoves, 10 de Xuño de 2004 ás 16:51:06 -0400, Michael Poole escribía: Can Debian properly redistribute rt3 if rt3 alleges both distribution under the GPL and GPL-incompatible restrictions? Does the fact that the restrictions are non-enforceable (at least in the US) enter consideration? I don't think it is an incompatible restriction, just a notice. You can still redistributed a modified version of rt3 retaining your own copyrights. They only become theirs if you send them for inclusion in the official rt3. But the way it is worded is a bit... dangerous. For them. What if I submit someone else's code? :-) -- Tarrío (Compostela)
Re: Cronyx Tau-ISA obfuscated driver
O Martes, 18 de Maio de 2004 ás 09:16:25 +0200, Stephane Bortzmeyer escribía: Free/non-free? (Only an academic interest, I did not use this driver yet.) Cronyx Tau-ISA driver Well, if the source code is obfuscated, it is not really useful source code for humans to modify or learn from; so it would ultimately fail DFSG #2. Now, if the license it is distributed under allows de-obfuscation, then there would be a way around this: someone fixes and documents the source code and distributed it; this de-obfuscated source code would be DFSG#2 source code. But if they want to preserve the market value (whatever they mean by that), the license is unlikely to allow that, so it would fail DFSG #3. -- Tarrío (Compostela)
Re: The draft Position statement on the GFDL
O Martes, 11 de Maio de 2004 ás 13:09:12 -0400, Raul Miller escribía: The GPL specifically disallows creation of copies with changes -- no matter how functional -- which include restrictions on the rights of other users of derivatives. The GPL forbids distributing copies under a license placing additional restrictions on the recipient's rights. If the recipient receives a copy of GCC (for instance) in DRM-uncopiable media, it is either: 1- a binary, in which case the recipiet is entitled to GCC's source code, that is: it's preferred form for modification 2- source code, in which case it isn't its preferred form for modification, and then no proper distribution under the terms of the GPL has been made And the GPL doesn't forbid anyone to modify a CD-burning program to generate DRM-capable media, or something like that. -- Tarrío (Compostela)
Re: Question about DFSG and a THC project
O Martes, 20 de Abril de 2004 ás 13:52:19 -0700, Jake Appelbaum escribía: Let this be my first try at a license analysis in d-l :) 1. This software comes with no warrenty or promised features. If it works for you - fine. It just comes AS-IS, which means as a bunch of bits and bytes. Warranty disclaimer -- fine. 2. Anyone may use this software and pass it on to other persons or companies as long as it is not charged for! (except for a small transfer/medium fee) Forbids to sell the software even along with other works -- fails DFSG #1 3. This tool may *NOT* be used for illegal purpose. Please check the law which affects your doing. I will have got no liability for any damage etc. done with this tool legally or illegaly. Restriction on use. It could be argued that it fails DFSG #6 (fields of endeavor, if I counted correctly), but it definitely fails a variation of the dissident test (dissident wants to use bulletin board software to publish banned works, ilegally). 4. If this tool is used while providing a commercial service (e.g. as part of a penetration test) the report has to state the tools name and version, and additionally the author (van Hauser) and the distribution homepage (http://www.thc.org). Use restriction. Fails the ode to the goldfish test ;-) 5. In all other respects the GPL 2.0 applies Oh, a nonconsistent license (places additional restrictions on the GPL, fine for the original author but not for would-be distributors of the work), thus undistributable. DFSG-non-free, IMO. -- Tarrío (Compostela)
Re: Forward: Re: On the possibility of changing the license of Adobe CMap files
O Xoves, 29 de Xaneiro de 2004 ás 17:06:06 +0900, Kenshi Muto escribía: Do you have any idea to cope with this situation? Or does anyone come up with possible proposal so that Adobe can be persuaded? I appreciate your help. They claim that integrity of the CMap files is the main issue. Would it be possible for them to release an unsupported fork of the CMap files under a different, more liberal license? In this way the official, supported CMap files would be unaltered, and there would be a product with a free license that would likely be equivalent to Adobe's (though with no guarantees). -- Tarrío (Compostela)
Re: BSD Protection License
O Xoves, 23 de Outubro de 2003 ás 11:10:13 +0100, Colin Percival escribía: 1. You may do X 2. You may do Y 3. You may do Z means you may take any, all, or none, of the actions X,Y,Z; likewise, clauses 2, 3, and 4 each provide alternatives -- you may take actions permitted under any of those clauses. But IIRC what your license says is: 1. You can do X, but you must do Y 2. You can do X, but you must do Z That is interpreted by me as You can do X but you must do Y and Z. -- Tarrío (Compostela)
Re: BSD Protection License
O Xoves, 23 de Outubro de 2003 ás 15:50:38 +, Dylan Thurston escribía: clause 3 vs. clause 4 issue: such a license is a grant of permission, and if I grant you permission to do X if Y, and also grant permission to do X if Z, then if you do either Y or Z, then you can do X. If one Last time I checked, if you wanted to comply with a license, you had to comply with all of its clauses simultaneously. So unless it says explicitly that you must do Y _or_ you must do Z, you must do Y and Z simultaneously to be in compliance. -- Tarrío (Compostela)
Re: There was never a chance of a GFDL compromise
O Luns, 22 de Setembro de 2003 ás 10:57:37 -0400, Richard Stallman escribía: Not long ago, people were trying to reassure me that if invariant sections were removable, nobody would remove them. I guess not. If they were both removable and modifiable (so not invariant), they would be DFSG-free and nobody would have any reason to remove them. Even if they were removable but not modifiable, they would still not be DFSG-free, so the only way to get a DFSG-free document would be to have them removed. This reinforces my conclusion that it is essential for these sections to be unremovable as well as unmodifiable. Well, in that case they'll make the document DFSG-nonfree. If they were removable and modifiable the document would be DFSG-free (except for the DRM clause, of course). So, to summarize: Removable and modifiable - Debian would most certainly carry them Removable but unmodifiable - Debian would remove them Unremovable and unmodifiable - Debian would not carry the document at all -- Tarrío (Compostela)
Re: A possible GFDL compromise: a proposal
O Venres, 12 de Setembro de 2003 ás 11:44:34 +0200, Mathieu Roy escribía: Hum, you mean in the sense of the Debian Free _SOFTWARE_ Guidelines? Everything Debian distributes is software. After all, if it weren't, we wouldn't be able to store it in a FTP server, transmit it via the Internet or burn it in CDs. -- Tarrío (Compostela)
Re: The GPL and you
O Domingo, 31 de Agosto de 2003 ás 13:51:13 -0700, Daniel Isacc Walker escribía: [...] under the GPL . What this means is that my software is automatically GPL'd even though it has no GPL'd source in it. The GPL doesn't distinguish [...] incorporated directly into PHP that means that PHP automatically becomes GPL'd. Even if I made some kind of external module for PHP, PHP would No; that's a common misunderstanding of how the GPL's copyleft works. Linking a work with a GPL-licensed work does not make the first work GPL-licensed. What it really means is that the combination of both works, if it is distributed, it must be under the terms of both licenses simultaneously (each work retains its original license, but the combination...). Now, the GPL has a clause that says you may not impose further restrictions than those imposed by this license (my wording), so if the other work's license has any restrictions not in the GPL, the resulting license is internally inconsistent, so per the GPL, you cannot distribute the resulting work at all. Note how I wrote about distribution. Use is no problem, since the GPL universally allows use (the only restrictions would be those imposed by the other work's license). A common trick which is used to distribute such undistributable combined works consists in distributing the components separately and leaving to the user the task of combining them. -- Tarrío (Compostela)
Re: A possible GFDL compromise
O Venres, 29 de Agosto de 2003 ás 16:09:57 +0200, Mathieu Roy escribía: The DFSG itself does not meet the DFSG itself, if you think that no text can be invariant. I believe that you can make modified versions of the DFSG, as long as you do not call the resulting document The Debian Free Software Guidelines or something similar that might confuse people. Can't you? -- Tarrío (Compostela)
Re: A possible GFDL compromise
O Venres, 29 de Agosto de 2003 ás 11:17:14 +0200, Mathieu Roy escribía: And according to the Debian Social Contract #4, Debian priorities are [Debian] users and Free Software. And Debian's users expect that everything they find in main will have a license that meets certain criteria: the DFSG. -- Tarrío (Compostela)
Re: A possible GFDL compromise
O Luns, 25 de Agosto de 2003 ás 13:35:21 +0900, Fedor Zuev escribía: Documentation in not a software. There is no any one-way transformation from the source to the binary. All problems with distribution and modification of documents is a legal, not technical problems. That doesn't matter. To make a derivative of some program, you would normally need some human-readable source code. To make a derivative of a manual (for example, a translation or a summary), you only need the text. At the very least, if you can read the document, you always, technically, can OCR it. An experience shows, that, if you should not care about legal requirements (because you has the right from license, you OCR public domain or, simply, you do not care about a law), it takes no more than 24-48 man\hours to completely OCR a large 500-700pages book. And there always will bee volunteers to do that. What are you trying to rebute from my clause with it? It is more or less my reasoning: you can translate the book having only a hardcopy of it. Well, it is even standard practice. If you want to actually modify it -- well, you may either OCR it, or you may ask the publisher for a modifiable soft copy of the book. -- Tarrío (Compostela)
Re: A possible GFDL compromise
O Domingo, 24 de Agosto de 2003 ás 19:36:20 -0500, Joe Wreschnig escribía: How about the GPL v2? The source code for a work means the preferred form of the work for making modifications to it; binary or object code is anything that is not source. I don't see the problem in applying this standard all software (meaning programs and documentation). Anyway, that wasn't my point. First: why have to deal with source code or the preferred form for modification when, for some of the rights the GFDL gives, these things are not even necessary? For example, to translate a document you don't really need modifiable source code: you only need to be able to read the original document. Second: the don't use technical measures to limit further copying clause is difficult because it tries to limit a mechanism, not an intention. What is someone who uses technnical measures to limit further copying trying to do? Impede that the recipient of the work redistributes new copies. Well, then why isn't there a clause saying you must not limit the recipient's ability to make and distribute new copies of this document? Third: if we were to enumerate each and every right in the license, it would be much longer and more complex (and imagine if we started combining the rights you must not limit the recipient's ability to make and distribute new copies of excerpted versions of this document). Thus, a single, simple clause I proposed: if the format or physical medium this work is distributed in limits the recipient's ability to exercise the rights given by this license, access to a copy of this work in a format or physical medium that allows for the exercise of the rights must be provided. That would mean -- if you want to modify it and cannot because you don't use Word, you have the right to obtain from your distributor a plain text copy. -- Tarrío (Compostela)
Re: A possible GFDL compromise
O Luns, 25 de Agosto de 2003 ás 16:23:36 +0300, Richard Braakman escribía: But to make a new edition with some spelling errors fixed, you definitely need the source. Of course. (I'm not sure what you're trying to say here. Are you claiming that translations and summaries are all you'll want to do with documentation?) No, I was just proposing a way to require source code to be distributed in a free documentation license, which is (IMO) saner than the one currently in the GFDL. -- Tarrío (Compostela)
Re: A possible GFDL compromise
O Domingo, 24 de Agosto de 2003 ás 16:54:53 -0500, Branden Robinson escribía: drawn to the condition You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. If make or were stricken, and perhaps some clarification added to ensure that secure transport channels between distributor and distributee were not a problem, this particular problem might go away. Or if this condition and the transparent format stuff were changed to say something to the effect to if you distribute this work in a format that obstructs the exercise of the rights given by this license, you must provide a way for its recipient to get a full copy of the work in a format that doesn't obstruct the exercise of these rights. With more legalese and other lawyer-y words, I guess :-) -- Tarrío (Compostela)
Re: A possible GFDL compromise
O Domingo, 24 de Agosto de 2003 ás 19:36:20 -0500, Joe Wreschnig escribía: How about the GPL v2? The source code for a work means the preferred form of the work for making modifications to it; binary or object code is anything that is not source. I don't see the problem in applying this standard all software (meaning programs and documentation). Well, that has already been discussed and it is apparently quite troublesome (if I convert a HTML file into plain text, which is the preferred form for modification?). My formulation doesn't have that problem: if you can modify, translate, excerpt, etc., it's ok. Well, it has problems of its own: I'd accept no you cannot modify the file it is distributed in but you can copy'n'paste into a new file and modify it as fulfilling the requirement, while others might not. Hey, in documents it's the text what matters: if the text (and illustrations, possibly) is the same, the document's file format (or physical medium) doesn't really matter, does it? :-) -- Tarrío (Compostela)
Re: SURVEY: Is the GNU FDL a DFSG-free license?
O Xoves, 21 de Agosto de 2003 ás 00:09:54 -0500, Branden Robinson escribía: === CUT HERE === Part 1. DFSG-freeness of the GNU Free Documentation License 1.2 Please mark with an X the item that most closely approximates your opinion. Mark only one. [ X ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, is not a license compatible with the Debian Free Software Guidelines. Works under this license would require significant additional permission statements from the copyright holder(s) for a work under this license to be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, is a license compatible with the Debian Free Software Guidelines. In general, works under this license would require no additional permission statements from the copyright holder(s) for a work under this license to be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, can be a license compatible with the Debian Free Software Guidelines, but only if certain restrictions stated in the license are not exercised by the copyright holder with respect to a given work. Works under this license will have to be scrutinized on a case-by-case basis for us to determine whether the work can be be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] None of the above statements approximates my opinion. Part 2. Status of Respondent Please mark with an X the following item only if it is true. [ X ] I am a Debian Developer as described in the Debian Constitution as of the date on this survey. === CUT HERE === -- Tarrío (Compostela) pgpBlE9wmHk9K.pgp Description: PGP signature
Re: A possible approach in solving the FDL problem
O Venres, 15 de Agosto de 2003 ás 12:49:21 +0200, Wouter Verhelst escribía: we should at the very least avoid confusion by clarifying the intended meaning of the word 'software' in the context of the text of the DFSG. Well, in that context, software means everything you can store in a CD, or everything you can transmit through a computer network. -- Tarrío (Compostela)
Re: A possible approach in solving the FDL problem
O Xoves, 14 de Agosto de 2003 ás 09:05:04 +0200, Sergey V. Spiridonov escribía: That was probably the intention, but the wording makes it unclear. Sorry it was quite clear for me. The GFDL, as it is worded now, would forbid me sending you a GPG-encrypted mail containing a GFDL-licensed work, even if you could decrypt it. Or would forbid me storing a GFDL-licensed work in my encrypted home directory. -- Tarrío (Compostela)
Re: a minimal copyleft
O Luns, 4 de Agosto de 2003 ás 00:21:59 +0100, Edmund GRIMLEY EVANS escribía: (L) Public Property: You may do anything you want with this work provided that you inform all recipients that all derived works must likewise be Public Property. ... with no additional restrictions. -- Tarrío (Compostela)
Re: Are c code from www.ioccc.org free?
O Venres, 22 de Novembro de 2002 ás 10:36:20 +0100, Luca - De Whiskey's - De Vitis escribía: I'm a bit confused by the possible interpretation of All other uses must receive prior permission from the contest judges: this sentence neither deny all other possible uses, nor it explicitly allows them. It does deny all other possible uses, but you can get permission for them. Just like any other freeware license: it denies you certain rights, but you can try to get permission from the copyright holder, even if not stated in the license. -- Tarrío (Compostela)
European Directive on the legal protection of databases
To whom it may concern: The following URL displays the text of the Directive, available in all 11 official languages of the EU (so you'll have no problem reading it :-)) http://europa.eu.int/smartapi/cgi/sga_doc?smartapi!celexapi!prod!CELEXnumdoclg=ennumdoc=31996L0009model=guichett (All in one line, no spaces) -- Tarrío (Compostela)
Re: Debian registered by a trade as TM in Spain!
O Martes, 3 de Setembro de 2002 ás 10:59:45 -0500, Steve Langasek escribía: The trademark is shown as registered in class 42: After some digging, I found the applications: M2321780, M2321781, M2321782. All three were submitted within one minute, by the same person. The first one claims the trademark Debian, in category 38 SERVICIOS DE TELECOMUNICACIONES. The second, claims Debian, in category 41 SERVICIOS DE EDUCACION Y ESPARCIMIENTO. The third one claims Debian, in category 42 SERVICIOS DE PROGRAMACION PARA ORDENADORES. If someone wants the Spanish PTO's database query results, I'll be glad to send them to that someone :-) -- Tarrío (Compostela)
