Re: CA certificates
* Niklas Vainio: On Tue, May 04, 2004 at 11:52:39PM -0700, Russ Allbery wrote: There's an interesting question. Is a public key copyrightable? In other words, does VeriSign have any legal grounds to restrict use of their public keys at all? My understanding is that copyright laws speak about original works with some creativity in them. Some European jurisdictions require that a work shows a certain amount of creativity before it is subject to the equivalent of copyright. At least in Germany, this rule no longer applies to computer programs, so it's quite unclear what the limits of copyright are over here. Computer-generated, seemingly random string of numbers hardly is such a work. Such random strings tend to have DMCA protection. However, certificates are not random strings, they also contain trademarks. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, di-ve.com, hotmail.com, jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com.
Re: CA certificates
* Russ Allbery: Florian Weimer [EMAIL PROTECTED] writes: I've digged a bit more, and VeriSign actually has a license governing the *use* of their certificates (including the root and intermediate certificates): https://www.verisign.com/repository/rpa.html The license seems to violate DFSG §6. It also fails the Desert Island test. There's an interesting question. Is a public key copyrightable? In other words, does VeriSign have any legal grounds to restrict use of their public keys at all? Does it matter? Why should we ignore VeriSign's wishes? They have far more lawyers than we have. 8-) -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, di-ve.com, hotmail.com, jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com.
Re: moosic package contains obfuscated code
* Henning Makholm [03:58 06/05/04 CEST]: Scripsit Nicolas =?iso-8859-15?Q?=C9vrard?= [EMAIL PROTECTED] So I was wondering, since this is problem is only with the binary package should I file a bug against moosic stating that obfuscating is an error or does it seems an acceptable policy to your eyes ? If the source package contains unobfuscate source for everything, then there is no DFSG problem. It is not worse than compiling to machine code. Indeed, that's what I tought but it is strange to obfuscate script code and I don't think that be encouraged. Someone using moosic is not running out of space. As far as I can see from a quick look at the source package, this appears to be the case. This is the case. (By the way, the comments in the Makefile indicate that the upstream author is apparently more concerned about saving space in the binary packages than about obfuscation). I don't see this comment. It's in the upstream Makefile ? ... going to check ... Ok I got it in the README.developers. Silly me. -- (° Nicolas Évrard / ) Liège - Belgique ^^
Re: Mass bug filing: Cryptographic protection against modification
On Wed, May 05, 2004 at 01:28:26PM -0600, Joel Baker wrote: The standing opinion there for some time (certainly every time I've seen this issue raised, which has been some number) is that a license text which is required solely to allow us to distributed the software under said license is Free by the DFSG, in that it is a pre-requisite to being able to establish and protect the other freedoms required by the DFSG in a world with legal systems that require such. I don't think it's so much that unmodifiable license texts are considered free, but that they're a necessary bit of non-freeness. As I've suggested, I don't think that this is necessarily completely true, considering the concepts of license terms and license texts separately. We must allow the implicit restriction you must not misrepresent the terms under which this work is licensed, which means that you can't take the GPL, modify it, and then claim that the Linux kernel is under your modified GPL. The license of the license is irrelevant--if the GPL was freely modifiable, you would still have to distribute the unmodified text, in order to accurately represent the licensing terms of the software. So, I think Debian could require that license texts be modifiable. I don't think that would be a good thing; I do think an exception for license texts is appropriate, for lots of reasons. I'm just not sure that we *have* to do it that way, due to the nature of the legal system is correct. (I'm not claiming that such an exception needs to be laid out in the SC; I don't have an opinion on that.) -- Glenn Maynard
Re: xzx license
Niklas Vainio wrote: On Tue, May 04, 2004 at 06:10:06PM +0530, Mahesh T. Pai wrote: xzx's license forbids modification but we have a diff of over 30 kB. It looks like it's undistributable in the current form. See bug 240941. Where is the license text available? All packages have a link to their license text in the package page. Here's the text: http://packages.debian.org/changelogs/pool/non-free/x/xzx/xzx_3.0.1-2/copyright - Nikke You're absolutely right. The binaries appear to be completely undistributable, since they're derivative works of the source. The diff is probably a derivative work too and so undistributable. -- There are none so blind as those who will not see.
Re: European Directive on Copyright Law (91/EC/250) wrt open source
Luke Kenneth Casson Leighton wrote: http://europa.eu.int/eur-lex/et/dd/docs/1991/31991L0250-ET.doc I can't read this. Got it in English? this document outlines the circumstances under which copyright holders effectively forfeit their copyright ... and the sections that i wish to draw to your attention are the ones concerning interfaces and interoperability at interfaces. under 91/EC/250, interfaces are exempt from copyright law if the developers of the code and/or hardware will not grant a license for interoperability purposes. even reverse engineering is allowed and catered for - but for interoperation only, not for people to find out trade secrets such as faster implementations. This indicates the intended meaning. the reason why i am bring this up on debian-legal is because there may come a time when either one open source project approaches another, or a proprietary company approaches an open source project (controlled by debian) and requests a license from the copyright holders in order that their proprietary (or open source project with an incompatible license) project interoperate with that otherwise incompatible project. Indeed snip now, i am aware that a number of open source projects DELIBERATELY release libraries under the GPL in order to force people to release their code under the GPL, too. where such libraries could be construed to have interfaces, and where the GPL is used to force a monopoly position, then any company or open source project with an incompatible license is entitled to request a compatible license and if they do not receive one they are entitled to treat the interface - i.e. the header files and Yes... effectively the entire library - I don't think this is right. In most cases, I can't see how the 'entire library' can possibly be construed as an 'interface'. They would be able to use the library much as if it was under the LGPL, but not much more -- they would not be able to modify the internals without running into copyright. It is unlikely that interfaces are copyrightable in the first place. And there is some question as to the validity of the FSF's belief that dynamic linking creates a derivative work. snip this is _exactly_ the sort of thing that is compatible with the EU directive on copyright law, whereas the GPL most clearly is not. It looks like the directive is intended to apply narrowly. Given that, I suspect that the it would not be used to invalidate the GPL as a whole. If it simply means that it will treat certain uses along the same lines as fair use in the US or fair dealing in the UK, as not subject to the copyright monopoly, then the GPL will presumably be held to apply only to those uses subject to copyright restrictions (the GPL as much as says that that's how it should be interpreted). -- There are none so blind as those who will not see.
Re: Help on package
David Moreno Garza wrote: Hello, I am now packaging a Tetris-like game, and I have some doubts about the description. I have written the description like this: Description: Free clone of Tetris, featuring a bastard level Bastet (stands for bastard Tetris) is a free (GPL'd) clone of Tetris(r) (built on the top of petris by Peter Seidler) which is designed to be as bastard as possible: it tries to compute how useful blocks are and gives you the worst, the most bastard it can find. Playing bastet can be a painful experience, especially if you usually make canyons and wait for the long I-shaped block. As Tetris is a trademark, are the uses of this word proper? I mean, is it legal to make use of this word as I have written it on the description? IANAL, but I believe it is just fine. But perhaps 'clone of Tetris' is not the best phrase to use. Putting it very roughly, you can't use a trademark to confuse people. A Tetris-like game is certainly fine. A clone of Tetris might possibly imply that it was behavior-identical to Tetris, which apparently it isn't. :-) How about a free game very similar to Tetris? Now, the upstream author mentions his software is based on petris, a Tetris-like game on MIT/X11 license. Is it all valid to bastet use GPL? Yes. Bastet is licensed over GPL. Under the MIT/X11 license, the author of a derivative work (Bastet) can license his parts however he likes, such as the GPL. In some sense Bastet as a whole is licensed under GPL. The parts which come from petris are still copyright the petris authors, and are MIT/X11-licensed; the copyright file *must* reflect that. I only need some orientation, in order to make bastet Debian policy-compliant. Regards and thanks in advance, -- There are none so blind as those who will not see.
Re: How might I convince my school not to use this product?
Elizabeth Fong wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My school is looking into installing Stanford's Coursework application for managing online course sites: http://getcoursework.stanford.edu/index.html However, its license seems to be decidedly non-free, and I'm trying to convince my school not to use it. This is for the following reasons: 1.) It requires Sun's JRE 2.) It requires Oracle, and has limited support for Free alternatives (experimental support for Postgre only) 3.) Its license (http://getcoursework.stanford.edu/license.html) is prohibitive Open Source License CourseWork Copyright © 2004 Board of Trustees of the Leland Stanford Junior University License Agreement By obtaining and/or copying the application or source code for CourseWork, you agree that you have read, understand, and will comply with the following terms and conditions of the License. Title and copyright in CourseWork and any associated documentation will at all times remain with the Board of Trustees of the Leland Stanford Junior University (Stanford). Subject to the terms and conditions of this Agreement, Stanford hereby grants to any person obtaining a copy of CourseWork a nonexclusive, royalty-free license under only any copyright interest Stanford has in CourseWork to use, copy, modify, merge, publish, perform and/or distribute copies of CourseWork, and to permit persons to whom CourseWork is furnished to do so. Doesn't say anything about distributing derivative works - one has the right to create them, but not to distribute them. The interpretation of modify and/or distribute by most copyright holders seems to have been that it allows the distribution of modified copies. The University of Washington was the exception. Maybe it's worth asking Stanford what they mean and hanging on to the answer. In addition, doesn't specify that derivative works have the same license applied. Doesn't have to, since this is BSD-style; you can license your derivative work however you want, apparently. CourseWork may not be distributed in any form for a fee. Clearly not Free, since it doesn't allow charging for the time/media for making a copy Indeed Distributions of CourseWork in source code and/or executable form must retain all copyright notices in the Software as furnished by the Licensor, this list of conditions, and the following disclaimers in the code, documentation and/or other materials provided with the distribution. Neither the names of Stanford, nor the names of any contributors to CourseWork, nor any of their trademarks or service marks, may be used to endorse or promote products derived from this Software without express prior written permission of Stanford. I forget whether this is permissible for DFSG-free. Yes, but only because it's a no-op -- this is apparently always true, pretty much, even if it's not specified. IANAL, though. Except for the license granted you under Stanford's copyright interest in CourseWork, Stanford retains all right, title and interest in CourseWork and any intellectual property rights in CourseWork. Without limiting the foregoing, no license is granted you or any other party under any patent owned or held by Stanford. In other words, all your modifications are belong to Stanford. Wonderful. No, this is just the usual we don't grant anything not explicitly granted. COURSEWORK IS PROVIDED AS IS AND WITH ALL FAULTS. THERE IS NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. ALL WARRANTIES ARE EXPRESSLY DISCLAIMED INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR PARTICULAR PURPOSE, NONINFRINGEMENT OR ARISING OUT OF A PARTICULAR COURSE OF DEALING. YOUR USE OF THE SOFTWARE IS AT YOUR OWN RISK. IN NO EVENT SHALL ANY LICENSOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, RELATING TO, ARISING FROM OR IN CONNECTION WITH SOFTWARE OR ANY USE OF THE SOFTWARE. CourseWork is provided under the terms of this license without support, and with no commitments stated or implied, for technical assistance, modification or upgrade from the Licensor. Standard no warranty stuff Any suggestions? Alternatives I might suggest? First, ask them if you can charge for your modifications to CourseWork; if you can, that deals with the problem of 'no fee'. :-) Ideally, they would * make explicit that you may charge for derivative works * make explicit the permission to distribute derivative works * specify that the Names must not be used bit is simply a disclaimer, rather than a license condition Those changes would make the license a perfect non-copyleft license however, I'm not sure you'll be able to get all of that. -- There are none so blind as those who will not see.
RE: Fwd: reiser4 non-free?
Burnes, James wrote: It disturbs me that such a great piece of software engineering like ReiserV3 and V4 is sullied by licensing arguments about whether someone is going to plagiarize them. I imagine that nearly all software engineers would be horrified at the thought of stealing the Reiser3 and 4 code and representing them as their own. Which is quite illegal anyway, for a multitude of different reasons. l. Is it that you believe the John Q Software is going to rip off your software and represent it as their own work. That would be plagiarism and I think very very rare in the FOSS community. And it's contrary to law. And if it's done by stripping copyright notices, it's copyright violation. 2. Are you unhappy with the fact that a few of the major distros are charging money for support and representing the software itself as their own creation? Wouldn't that already be in contravention of GPL V2? Yes. Are you unhappy with the fact that some distros make *a lot* of money and fail to credit the FOSS people that made it possible? Arguably the market determines whether their support and package integration are worthy of financial support, just as the DOD determines whether V4 is worth of their support. The relative discrepancy in reward vs. effort is an economic discussion beyond the scope of this. 3. Is it that you simply want an efficient mechanism for cataloging efforts of the major contributors to a project? If that's the case why don't we just come up with some sort of credits standard to be macro embedded in the binaries? That way anyone could view the credits by running a 'credits' shell command against the binary/library/kernel etc. Obviously the macros would be viewable in source. Nice idea. I like it. It's also a good way to put the copyright notices *into* the binaries, rather than merely next to them. How about a standard ELF section for credits? :-) snip Hopefully the issue doesn't devolve into an argument about forcing people to read the credits, nagware like, during the execution of the code. That would simply not scale at all and would aggressively de-select your software free or otherwise from an open environment. I thought it already had devolved into that. :-) snip -- There are none so blind as those who will not see.
Re: Fwd: reiser4 non-free?
Hans Reiser wrote: Burnes, James wrote: Is there any way to do an MD5 of either (1) each module in a software subsystem or (2) each software version and then have a central registry where interested developers and users can go to see the credits? Credits that users must take action to see are not effective credits. No one will look at them. Well, it's definitely very non-free to try to force people to look at the credits. It's hopeless anyway. Look at how many people walk out of movies before the credits roll. It would certainly be frighteningly non-free to force them to sit through the credits. Most of them ignore the opening credits too. (I, myself, always watch the credits.) -- There are none so blind as those who will not see.
Is SystemC license compatible with the GPL ?
[ I know this is out topic here, but I've already sent this mail twice to [EMAIL PROTECTED], twice to the discussion list of the fsfeurope, another time to the SystemC mailing list, and didn't get a single answer :-( ] Hi, I've developped a piece of software using GCC as a C++ front-end and the SystemC library. The SystemC license can be found from www.systemc.org (And I've temporarily put a copy here: http://www-verimag.imag.fr/~moy/vrac/License.pdf ) I would like to know wether it is legal to distribute this software and wether it is possible to do so under a free license. The architecture of the software is as follow : ++ +-+ +-+ || | | | | | A | | B | | C | || | | | | | SystemC |--1--| My software |--2--| GCC | || | | | | ++ +-+ +-+ Where --n-- can be either a static or a dynamic link. I would like to use as permissive licenses as possible. Ideally, I would like the following : A = SystemC license B = LGPL C = GPL Is this possible ? (From what I understood, I can distribute A+B and let the user download C and compile A+B+C himself) If not, do you have a solution ? Or maybe, the following would fit : A = Dual license GPL + (L)GPL B = (L)GPL C = GPL ? Thanks a lot for your help, -- Matthieu
Re: Prefered License for forums content
Wouter Vanden Hove wrote: Josh Triplett wrote: Brian Thomas Sniffen wrote: MJ Ray [EMAIL PROTECTED] writes: Recall that the Creative Commons Attribution license was ruled to be DFSG-non-free by debian-legal (initial review request at http://lists.debian.org/debian-legal/2004/debian-legal-200403/msg00267.html , final summary at http://lists.debian.org/debian-legal/2004/debian-legal-200404/msg00031.html When any Licensor asks, all references to their name(s) must be purged from the work. This restricts modification (DFSG 3). This is an unalienable moral right in most of Europe. No, it isn't. Or, anyway, I sure as hell hope not. Let me state this simply and clearly. If I state in my work, which is a derivative of RMS's, I disagree with RMS about , or RMS founded the FSF, where does he get off demanding that I remove his name? If this is DFSG non-free, then Debian has a serious problem, because then is it logically impossible to have a license that is compatible with the DFSG and European Law at the same time. The by-sa license is likely to be non-free as well for the same reasons. If people think that, we don't they express their opinion about it on the relevant mailinglist, namely [EMAIL PROTECTED] I thought that was an alias to /dev/null, for all the responses I got from the request to change the HTML pages so that it was clear that the trademark stuff wasn't part of the license. -- There are none so blind as those who will not see.
Re: Fwd: reiser4 non-free?
Russ Allbery wrote: Lewis Jardine [EMAIL PROTECTED] writes: I find it unlikely that people intelligent enough to write software as complex as Apache, Sendmail, Linux, Thunderbird, etc. would license their software under a license they haven't fully read, or don't fully understand. I (and, in my opinion, any 'reasonable person') must assume that when an author releases under the GPL, he intends to permit any modification of the program (including the removal of run-time advertisements), as the GPL states. The GPL is actually a rather interesting case here, since it *does* require the preservation of credits, and in a way that I believe Debian finds acceptably free. | 2. You may modify your copy or copies of the Program or any portion | of it, thus forming a work based on the Program, and copy and | distribute such modifications or work under the terms of Section 1 | above, provided that you also meet all of these conditions: | | [...] | | c) If the modified program normally reads commands interactively | when run, you must cause it, when started running for such | interactive use in the most ordinary way, to print or display an | announcement including an appropriate copyright notice and a | notice that there is no warranty (or else, saying that you provide | a warranty) and that users may redistribute the program under | these conditions, and telling the user how to view a copy of this | License. (Exception: if the Program itself is interactive but | does not normally print such an announcement, your work based on | the Program is not required to print an announcement.) In fact, on first glance, I'm not sure that I understand the difference between Debian's inclusion of software which triggers GPL 2c (such as bc) and a similar clause for non-interactive programs. Maybe I'm missing some previous discussion? Well, first of all we don't really like programs which trigger 2c. Second, and much more important, non-interactive programs often have defined output. A similar credits requirement on a non-interactive program can make it outright impossible to make the code produce the necessary defined output. -- There are none so blind as those who will not see.
Re: Is SystemC license compatible with the GPL ?
On Thu, May 06, 2004 at 01:22:24PM +0200, Matthieu Moy wrote: ++ +-+ +-+ || | | | | | A | | B | | C | || | | | | | SystemC |--1--| My software |--2--| GCC | || | | | | ++ +-+ +-+ Where --n-- can be either a static or a dynamic link. I would like to use as permissive licenses as possible. Ideally, I would like the following : A = SystemC license B = LGPL C = GPL gcc is LGPL. Diego
Re: RFC: Debian License Information on www.debian.org
Jakob Bohm wrote: Another common cause of non-distributable software happen when a single program combines parts under different free licenses** that conflict with each other in some way that makes the combination null and void. s/null and void/undistributable/ Or, some way which means that there is no valid license to distribute the combination. This is the most unfortunate kind of non-free software, all the parts are free** but we cannot ship it no matter how much we would like to do that. Such conflicts can often be fixed by adding a permission notice**[link to above] modifying one of the licenses so it no longer fails the conditions imposed by the other licenses. Examples and solutions: BSD with advertising clause + GPL2** OpenSSL + GPL2 (happens a lot)** QPL + GPL2 (happened to KDE version 1)** -- There are none so blind as those who will not see.
Re: Social Contract GR's Affect on sarge
Lewis Jardine wrote: There are, however, standards that are backed by patents and/or trademarks, and not freely implementable (postscript, mp3, pdf, etc.), ^^ No, trademarks are different. Trademarks are always DFSG-free and don't cause problems except when certain companies get litigious (they generally lose when they try to overextend trademark law, but can still cause problems). Just patents. the status of which is a huge can of worms (not helped by software patent laws that very from nation to nation). To my knowledge (and this is not something I understand very well), Debian's guideline is that a program using/implementing a patent-encumbered standard is not allowed in main, unless the owner of the patent/trademark promises not to sue developers of free software. Actually, Debian's been operating sort of the opposite way: unless the owner of the patent shows some sign of enforcing it against software, Debian assumes that the patent is invalid, or at least invalid when applied to software, and that it will not be enforced. This is done because there are so many junk software patents out there (most of which are invalid on their faces for being obvious, due to prior art, or for being pure mathematics), and most of them are never enforced. On the other hand, if the owner of the patent does show some sign of enforcing it, Debian has been somewhat inconsistent, and I'm not really sure what the policy is. -- There are none so blind as those who will not see.
Re: Squeak in Debian?
Jakob Bohm wrote: snip The term under your direct control typically does not refer to physical access or knowledge of the root password etc., it usually refers to under your [licensee as legal entity] direct [legal] control, that is any computer that the licensee (which may be a person, company, organisation etc.) has the *legal* command over, typically by owning, renting, leasing, borrowing, getting as sponsorship etc. Thanks for that clarification. That cleans up that problem. :-) *happy happy joy joy* So if a DD is working with weak guest privileges on a remote computer, the use of which has been donated as a sponsorship to SPI, and the software is licensed to SPI (not the DD), then SPI may do the things in the clause without that being an act of distribution, and SPI may use the DD as a tool to do that work. In contrast if the software is licensed to the DD as a person and the computer was not donated to the DD as a person, then this clause does not apply to anything the DD does on that computer, even if the DD is standing in front of the computer logged in as root and with full access to every part of the opened up computer cabinet. But it would apply to something that the DDs friend is doing for the DD on DDs laptop, even if the DD has no physical or network access to the laptop during the exercise. Just my 2c Jakob -- There are none so blind as those who will not see.
Re: Squeak in Debian?
Henning Makholm wrote: Scripsit Jakob Bohm [EMAIL PROTECTED] The term under your direct control typically does not refer to physical access or knowledge of the root password etc., it usually refers to under your [licensee as legal entity] direct [legal] control, that is any computer that the licensee (which may be a person, company, organisation etc.) has the *legal* command over, typically by owning, renting, leasing, borrowing, getting as sponsorship etc. That's even worse. It means that the license is trying to say that I'm not allowed to install the software on my neighbour's computer, which I have no legal control over, even if my neighbourt asks me to help him. Well, if Jakob is correct that this refers to legal control, that's not correct. I've run into something like this before somewhere. Legal control is a funny concept, which is mostly about ownership, and in the context of it, funny things happen to the meaning of doing. It seems, though IANAL, that the owner is considered to be actually performing the action himself by asking someone else to do it. This is genuine legalese, which doesn't mean what it appears to, and so the opinion of a lawyer expert in the area would be a Really Good Thing. -- There are none so blind as those who will not see.
Re: Is SystemC license compatible with the GPL ?
gcc is LGPL. Diego I don't know where you got that idea, but it's wrong. Some of the libraries may be LGPL, but the compiler itself is very much GPL, to the point that RMS doesn't want people adding interfaces that might make it easier to use a GCC frontend by itself without linking to GCC. (He can't stop it, but patches for it won't be accepted into the GNU trees.) -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm
Re: Squeak in Debian?
Lex Spoon wrote: I've posted a summary of the discussion on including Squeak in non-free: http://minnow.cc.gatech.edu/squeak/3733 I'll edit it as issues come up. There are two open issues: 1. Export regs. Are our servers up to snuff for avoiding export to US embargoed countries? (It looks to me that we need to handle this anyway, even aside from Squeak's license.) 2. The computers under your direct control verbiage. I still do not understand why people object to that sentence, but I put it on the list because multiple people have claimed that it makes Squeak non-distributable. Reading it as plain English, it looks like a strong restriction. However, now Jakob Bohm has explained that it means the technical legal definition of control, and with reference to the way that's apparently normally interpreted under the law, that seems fine. I'd still love to get a lawyer to agree, though! -- There are none so blind as those who will not see.
Re: Poly/ML license
Please read this licence and click on the Accept button at the bottom if you are happy to accept it. snip Before downloading Poly/ML you must read and agree to the licence below. If you are downloading this in order to make it available to others, for example to install it on a server at your University or place of work, you agree that everyone who has use of Poly/ML will abide by this licence. Licenses requiring acceptance are not considered DFSG free. See the DFSG FAQ at http://people.debian.orb/~bap/dfsg-faq.html IMPORTANT -- READ CAREFULLY BEFORE USING THE SOFTWARE: This Licence In law, *users* are required to read something only if it imposes a burden / obligation on them. You may install a copy of the Software and may use it only in accordance with and to the extent allowed by the terms and conditions of this License Agreement. By clicking on the Accept button, installing, copying or otherwise so using the Software, you agree to be bound by the terms of this Licence Agreement. If you do not agree to the terms of this Licence Agreement, click on the Cancel button and/or do not install the Software. YOU AGREE THAT YOUR USE OF THE PROGRAM ACKNOWLEDGES THAT YOU HAVE READ THIS LICENCE, UNDERSTAND IT, AND AGREE TO BE BOUND BY ITS TERMS AND CONDITIONS. See above. 4. The copyright and other intellectual property rights of whatever nature in any improvements, enhancements or modifications to the source code of the Software or which necessitate access to the source code of the Software in order to be compiled into a functioning binary form and which are made by the Licensee (the Improvements) shall vest in and be and remain the property of the Licensee. This means, if you modify the program, the copyright in *your* modifications vests in the licensor and operates as assignment of copyright.This is void in most jurisdictions since most jurisdictions require that assignment of copyright has to be in writing. AFAIK, English law too requires assignment in writing. Was this license really written by a qualified lawyer? 5. The Licensee grants to the Licensor in good faith a non-exclusive, royalty-free licence to use any Improvements with the right to grant sub-licences to any existing or future licensees of the Software. That is the right to distribute modified and unmodified copies. Fine. 6. The Licensor shall be bound to grant sub-licenses of the Improvements on being requested so to do by any existing or future Licensee of the Software. The Improvements shall promptly be made available by the Licensee to the Licensor and by the Licensor to any sub-licensee. Such Improvements shall be made available to a degree of detail sufficient for the purposes of the license granted under clause 5 or as required by the Licensor. Fails the Desert Island test. 7. Any licence or sub-licence granted by either the Licensor or the Licensee of the Software and/or the Improvements shall contain provisions that reflect the provisions of this Agreement with any changes necessary to give the arrangements efficacy. Generally, it is a very bad idea to allow downstream to modify a license. -- +~+ Mahesh T. Pai, LL.M., 'NANDINI', S. R. M. Road, Ernakulam, Cochin-682018, Kerala, India. http://paivakil.port5.com +~+
Re: GFDL
I had a discussion with a DD friend on the GFDL; and we both felt that I should share my views with the list. What follows is slightly modified text of one of my messages on the subject. I do not agree with RMS on GFDL. It is too restrictive on But I do. transparent copies. The debian position statement, nicely sums up all the issues. And I agree with that also. Did I hear somebody say`huh?'? The point is that there are very valid arugments in favour of, and against, GFDL's (degree of) freeness. GFDL suits the way FSF wants to do things; but does not suit the Debian way. FSF stands for users' freedoms. Debian stands for users' freedoms. `Users' for the FSF are the users in general. `Users' for Debian, are people who use Debian. `Use' of Debian (the software collection), for Debian (the community), means, among other things, distribution of CDs, mirroring, and repackaging/modifying packages from Debian archives. (correct me if I am wrong). FSF has to be distro neutral, because FSF knows that its works will be used by people other than Debian, and has to strategize accordingly. Debian is a distro in itself, uses a large portion of material from others, and is not concerned with how others use its works. For the FSF, freedom is the message, and has to be conveyed. FSF's invariant clauses speak of free software and how users' rights are affected by software. FSF is not, should not (and justifiably so) concerned with, or can control what other people who use the GFDL (NOT FSF's GFDL'd work) put in their invariant clauses. FSF rarely puts technical info in invariant clauses. Its invariant clauses are very small. For Debian, the distro is the message. Debian distributes work created by others (Including the FSF). It has no control over what others people put in the invariant clauses. Or the proportion of a document declared as invariant. Debian is very much justified in what people put in invariant clauses, what exactly invariant clauses say. Several people in Debian (and outside it too) have other problems with the GFDL. Such opinion typically is that the GFDL obstructs further copying of the copies you *make*. These people think the GFDL is written in English, which is a mistake. If you read the GFDL in legalese, (and that is what a court will do, if a dispute arises), you will realise that the GFDL does not oblige me to allow people access to a copy of a GFDL'd document I made for my use. Therefore, I am justified in things like using an encrypted filesystem to store GFDL'd document. FSF has very valid points in having invariant sections, because invariant sections, as used by FSF serve a very useful purpose. (I am an example of how these invariant sections introduce - rather enlighten - people about freedom.) The FSF is happy when people are compelled to reproduce the invariant sections from works owned by the FSF, because it furthers FSF's objective - spreading the message of freedom. Invariant sections, which enable FSF to do this, are likely to be misused by others; but that is not FSF's fault. The real objection Debian has about invariant sections is that they impose a burden on people who wish to modify packages from Debian repositories. (like using a small snippet from a GFDL'd work). Imposing burdens on people wishing to modify works (or redistribute modified works) is *not* desirable for the Debian community. (I understand this aspect of Debian's arguments. Recently, I used material from some pages in HTML format to create a man page. If the HTML was GFDL'd, I would have taken a few weeks to write an entirely new manual, and the new manual still would have been substantially identical with the HTML version.) FSF sees documentation as a vehicle to carry its message. Debian sees documentation as a vehicle to carry technical information. FSF says - `freedom is important, spread the word'. Debian says `here is a free operating system, spread it, use it, modify it; there is no obligation attached to it'. My take on the whole issue is this:- FSF seeks to achieve its objectives through the GFDL. The way GFDL is written, while perfectly suits the FSF way, is contrary to way Debian does things. Obviously, the two are not likely to meet. Anyway, talks are on between FSF and Debian, a committee has been formed at the instance of Bruce Perens, a new draft of GFDL is expected by June '04. RMS informed me when he was here (in January) that (1) he is not aware of this committee, (2) he sees no problem with the GFDL. Obviously, the communication `gap' still persists. -- +~+ Mahesh T. Pai, LL.M., 'NANDINI', S. R. M. Road, Ernakulam, Cochin-682018, Kerala,
Re: Redistributing PHP Licensed code under LGPL app
Marc Fargas (TeLeNiEkO) wrote: Hi folks. I'm working on a php application that is licensed under the LGPL license but I need to include a few files from http://pear.php.net that are licensed under the PHP license. Then the question is: Can I redistribute those PHP licensed files with my LGPL application? If it's mere aggregation, you would be allowed to... But if you need to include them, it might not be. First determine whether your application is a derivative work of the files from pear.php.net. If not, you're clear. This is an annoying question, because it's factual. Then check the PHP license to see whether you can distribute the files under the terms of the LGPL. If so, you're clear. (I couldn't find the PHP license offhand, so I can't tell you.) Then check: do the files only use your application as a library? If so, you're clear. Otherwise, you can't. -- There are none so blind as those who will not see.
Re: Is SystemC license compatible with the GPL ?
On Thu, May 06, 2004 at 04:05:16AM -0800, D. Starner wrote: gcc is LGPL. Diego I don't know where you got that idea, but it's wrong. Some of the libraries may be LGPL, but the compiler itself is very much GPL, You are right, I stand corrected. Diego
Re: reiser4 non-free?
David Masover [EMAIL PROTECTED] wrote: First and foremost: Hans, this is your project. Someone willing to replace entire APIs with things that feel like files is obviously not afraid of creating something new. So at the end of the day, it shouldn't matter too much that it's in Debian Non-free, especially if (assuming I heard correctly) XFree86 is also non-free. People seem to be missing this issue, so I'll bring it up again. The problem is not so much whether the license is free or not. The problem is that it is incompatible with the GPL. That means that Debian can't distribute it _at all_. Not in main, not in non-free. Not at all. The license may be perfectly free (e.g. the IBM CPL), but if it is incompatible with the GPL, then Debian can't distribute it. Regards, Walter Landry [EMAIL PROTECTED]
Re: moosic package contains obfuscated code
On Thu, May 06, 2004 at 09:56:23AM +0200, Nicolas Évrard wrote: Indeed, that's what I tought but it is strange to obfuscate script code and I don't think that be encouraged. Someone using moosic is not running out of space. Note that reducing the amount of space required at runtime tends to improve performance -- memory is implemented in many tiers, and the less space you occupy, the greater the probability you'll have that the stuff you need is in one of the faster tiers. Mind you, efficiency can also be addressed in a variety of other ways (for example: different coding style, different language, different libraries, different feature set, ...). Anyways, I've not looked at this very closely, but I don't think the obfuscation squeezeTool does is any worse than the obfuscation gcc does. -- Raul
Re: The draft Position statement on the GFDL
Manoj Srivastava wrote: Hi, Raul miller posted this mail on debian-private, with an explicit permission to quote it elsewhere. I am doing so now. manoj On Tue, Apr 27, 2004 at 05:24:15PM -0500, Manoj Srivastava wrote: Can you refute the hard facts found on http://people.debian.org/~srivasta/Position_Statement.xhtml? I see several topics there: DRM Restriction One question here, is what does control copying mean? In a very general sense, making a copy is controlling a copy, and likewise not making a copy is controlling a copy. Therefore, any technical means of controlling copies (such as having the gnu cp command installed on your system) could be seen as violating the GFDL. However, on re-reading the license, I see that the clause in question actually reads: obstruct or control the reading or further copying of the copies you make or distribute In other words, clause isn't about copying, but about further copying. I believe this indicates that once you've given a copy to someone else, you've not placed specific technical obstacles in the way of them making copies. In other words, once distributed, the distributor has given up legal control of the copy. Make or distribute is the biggest problem here. If it said make and distribute, you might be correct. As it is actually written, it requires that you not place specific technical obstacles in the way of people reading or making copies of the copy you *make*, even if you don't distribute it at all. As it is, this does seem to prohibit chmod -r on a shared computer. Is that really OK? Frankly, if it was changed to make and distribute, this would probably evaporate as a complaint. I'm fairly confident the phrase technical measures to obstruct or control refers to the concept of having a legal right to obstruct control the reading or copying of the document after distribution. I wish it meant that. That's just not what it says though. It refers specifically to technical measures, but not to legal rights. If it said You may not use technical measures to prevent recipients from having or exercising the rights they would otherwise have..., it would be just fine. In a funny sort of mirror image, the biggest problem with the DMCA is that it prohibits circumventing technical restrictions *even* when this is done solely for otherwise legal purposes. If it prohibited circumventing technical restrictions in order to circumvent legal restrictions, that would be quite different. More specifically, since the GFDL is a legal document, the primary effect of this clause is to deny someone the right, in court, of claiming someone else has subverted the barriers they placed on copying. It denies the right to make private copies. It appears to allow the copyright holder to sue me if I make a private copy without separate permission. While the FSF may not interpret it this way, this is what it says, and we have to expect that other copyright holders will take it at its word. It appears to be legally possible to prohibit private modifications, so we can't rely on that. Although this is not explictly prohibited by the DFSG, it seems very much against the spirit of it, and would cause no end of trouble if anyone ever attempted to enforce it. I don't see that this is a problem in the context of the DFSG. If it is, could you spell it out more clearly? Alternatively, if you think I've mis-interpreted this section of the license, could you spell out the interpretation you're seeing in some fashion [which isn't self contradictory]? Yep -- see above. :-) Transparent and Opaque Copies Again, I don't see that this is a problem in the context of the DFSG. I see that the restrictions are different from GPL restrictions, but the DFSG does not require all licenses be GPL compatible. This part *may* be OK. But wasn't this discussed in detail? From Manoj's draft position statement: Section 3 (Copying in Quantity) of the GFDL states that it is not enough to just put a transparent copy of a document alongside with the opaque version when you are distributing it (which is all that you need to do for sources under the GPL, for example). Instead, the GFDL insists that you must somehow include a machine-readable Transparent copy (i.e., not allow the opaque form to be downloaded without the transparent form) or keep the transparent form available for download at a publicly accessible location for one year after the last distribution of the opaque form. This seems moderately oppressive. But assume that that's OK; there are bigger problems. From the GFDL: A Transparent copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available
Re: The draft Position statement on the GFDL
Raul Miller wrote: On Tue, May 04, 2004 at 08:40:25AM -0400, Anthony DeRobertis wrote: [you seem to have attributed my words to Manoj -- but we are different people] On May 2, 2004, at 14:25, Manoj Srivastava wrote: obstruct or control the reading or further copying of the copies you make or distribute In other words, clause isn't about copying, but about further copying. I read it as: (obstruct OR control) (the reading OR further copying) of the copies you (make OR distribute) I'll grant that my observation about further copying is moot, however, the phrase you've quoted has no verb, so you have not addressed the other aspect of my argument. I'm fairly confident the phrase technical measures to obstruct or control refers to the concept of having a legal right to obstruct control the reading or copying of the document after distribution. If they wanted to prohibit you from using legal measures --- the DMCA, for example --- why did they say technical measures instead of legal measures? Because they are specifically talking about technical measures to enforce intellectual property rights. Well, if they had been, they should have said so. But they didn't actually say that. They just said technical measures. As far as I know, that isn't restricted to less than its normal meaning in legalese. In fact, it appears to have been chosen by DMCA authors *because* of its broadness. It's an overly broad restriction. snip No, it does not prohibit bloat. I does, however, prohibit legally requiring bloat. If by bloat, you mean bloat in program binaries, this is true. Oh. Well, the GFDL with Invariant Sections requires bloat in distributed binaries. However, for example, the DFSG doesn't require that bloat be removed from program sources. snip -- There are none so blind as those who will not see.
Re: Poly/ML license
On 2004-05-16 10:41:11 +0100 Mahesh T. Pai [EMAIL PROTECTED] wrote: This is void in most jurisdictions since most jurisdictions require that assignment of copyright has to be in writing. AFAIK, English law too requires assignment in writing. That is my understanding too. I was rather surprised by this clause. Was this license really written by a qualified lawyer? Yes, but I have tried to contact him recently and failed. I've exhausted the obvious online searches. If someone wants to hunt UK lawyers for free, please email me directly. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ http://www.ttllp.co.uk/ for creative copyleft computing
Re: The draft Position statement on the GFDL
Don Armstrong wrote: snip I'm not sure if it's been raised in the context of the DFSG, but as some people have been mixing and matching GFDLed works with GPLed works, or seem to want to, this was something that came up in discussion. Since many of the affected GFDL works are documentation for GPLed programs, it came up as something people actually wanted to do, a lot. Last time I checked, nobody but the FSF could legally make modified versions of the libstdc++-v3 manual, because it combined doxygen-generated material from GPL source files with GFDL material. -- There are none so blind as those who will not see.
Re: reiser4 non-free?
Walter Landry [EMAIL PROTECTED] writes: David Masover [EMAIL PROTECTED] wrote: First and foremost: Hans, this is your project. Someone willing to replace entire APIs with things that feel like files is obviously not afraid of creating something new. So at the end of the day, it shouldn't matter too much that it's in Debian Non-free, especially if (assuming I heard correctly) XFree86 is also non-free. People seem to be missing this issue, so I'll bring it up again. The problem is not so much whether the license is free or not. The problem is that it is incompatible with the GPL. That means that Debian can't distribute it _at all_. Not in main, not in non-free. Not at all. The license may be perfectly free (e.g. the IBM CPL), but if it is incompatible with the GPL, then Debian can't distribute it. You're right, Walter, and thank you for the clarification. To clarify further, Debian can't distribute a derivative work of the Linux kernel which is not licensed under the GPL. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: GFDL
On Sun, May 16, 2004 at 04:32:46PM +0530, Mahesh T. Pai wrote: Several people in Debian (and outside it too) have other problems with the GFDL. Such opinion typically is that the GFDL obstructs further copying of the copies you *make*. These people think the GFDL is written in English, which is a mistake. If you read the GFDL in legalese, (and that is what a court will do, if a dispute arises), you will realise that the GFDL does not oblige me to allow people access to a copy of a GFDL'd document I made for my use. Therefore, I am justified in things like using an encrypted filesystem to store GFDL'd document. Are you a lawyer, and does this constitute legal advice, such that if you are proven wrong in a court of law, we can pass liability on to you? If not, you can take that assertion and stick it. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Mass bug filing: Cryptographic protection against modification
On Thu, May 06, 2004 at 04:14:31AM -0400, Glenn Maynard wrote: I don't think it's so much that unmodifiable license texts are considered free, but that they're a necessary bit of non-freeness. As I've suggested, I don't think that this is necessarily completely true, considering the concepts of license terms and license texts separately. We must allow the implicit restriction you must not misrepresent the terms under which this work is licensed, which means that you can't take the GPL, modify it, and then claim that the Linux kernel is under your modified GPL. The license of the license is irrelevant--if the GPL was freely modifiable, you would still have to distribute the unmodified text, in order to accurately represent the licensing terms of the software. Funny that, the standards communities make the exact same argument about why you can't take a standards text, modify it, and then publish it. Even if you change the name, it causes major interoperability problems --- what if there were ten different versions of the http protocol out there, all with different standards documents blessing them as legitimate? Hence, standards bodies that state that out of policy reasons, if someone wants to make a non-interoperable version of a protocol, they should start from scratch and not be able to leverage the existing work of the protocol specifications, are in many ways making the exact same argument about why it is necessary to prevent someone from using the GPL using it as a base, possibly stemming confusion in the marketplace. (Your arguement that if someone could modify the a copy of the GPL and hence modify the terms under which the kernel is distributed is laughable, by the way; just as a contract doesn't change if someone attempts to modify a paper copy of the contract, changing a copy of the GPL would not change the terms under which existing code is licensed. The only argument for why it is necesssary that license texts should be unmodifiable is to avoid confusion --- which is EXACTLY why some standards bodies don't want randoms dicking about with the definition of the http protocol, for example.) So tell me again why the GPL text should be privileged? - Ted
Re: The draft Position statement on the GFDL
Raul Miller wrote: On Sun, May 02, 2004 at 12:59:51PM -0700, Don Armstrong wrote: snip I think the phrase technical measures in the GFDL refers to the concept discussed in this article from the WIPO copyright treaty: Contracting Parties shall provide adequate legal protection and effective legal remedies against the circumvention of effective technological measures that are used by authors in connection with the exercise of their rights under this Treaty or the Berne Convention and that restrict acts, in respect of their works, which are not authorized by the authors concerned or permitted by law. Well, it might be intended to refer to this, but in the article above, it says techological measures...that are used by authors... that restrict acts Technological measures in general is obviously a broad category, since it is restricted by the two that clauses, which explain what sort of measures they're talking about. In the GFDL, it says ...technical measures to obstruct or control...[etc], which seems to be the only restriction on what sort of technical measures they're talking about. It's not clear to me why other kinds of technology (not associated with any sort of right to intellectual property) which prevent use or distribution should qualify as measures. Well, they are actions which are taken to further a purpose, which is the approximate meaning of measures. If they are taken for reasons entirely different from preventing reading or copying, perhaps the GFDL clause does not apply. Although I'm not sure whether the GFDL clause requires that these measures prevent reading or copying as their *purpose* or whether it's sufficient that they do so incidentally. Anyway, chmod -r really has no purpose *other* than to prevent reading or copying. This is why it has become the canonical example. Is it supposed to be prohibited? The contrast made by one person was that the GFDL prohibits distribution on restricted media, period. The GPL, in contrast, allows it as long as it's accompanied by distribution on unencumbered media. Anyway, we'd probably be willing to read most of this more generously if it didn't apply to private copies, which is the core problem. :-P When a user deletes a file, or ceases to provide power to the computer which holds the file, this certainly prevents reading of the file instance. However the purpose of deleting the file or turning off the power is not to prevent unauthorized people from retaining copies. Technological measures, as I understand it, means there are people who do not have the right to see copies of the material in question, which the measures are designed to prevent. Mind you, my thinking might be flawed. If so, I'd appreciate it if someone could spell out for me the relevant legal issues. snip [*] Where the requirement for encryption or control has nothing to do with digital rights management. This gets back to the question of whether or not non-rights management activities count as technological measures in the context of copyright. I would assume that they do count in the context of a license. A copyright license can put perfectly arbitrary restrictions on your right to make copies. I see no reason to assume that the meaning of technical measures in the GFDL is limited. (Of course the scope of the clause is limited by the phrase to obstruct or control the reading or further copying of the copies you make or distribute, but that doesn't really help.) I would assume, barring legal advice, that us[ing] technical measures to obstruct or control means precisely what it says. It is possible that this phrasing implies the need for intent to obstruct or control. (I'm not sure.) If so, it still prohibits 'chmod -r'. snip Invariant Sections redistribution of derived works are allowed Redistribution of derived (or modified) works of specific sections are dissallowed. We have long held that licenses which require that specific parts of the functional work be unmodifiable are non-free because they violate DFSG §3.[3] It seems to me that it's DFSG §4 which deals with the unmodifiable sections issue. DFSG §3 simply requires that derived works be redistributable and doesn't address any restrictions on the right to redistribute derived copies (such as GNU's restriction where people who don't distribute their own modificates to GPLed software under GPL compatible terms lose the right to distribute derived works). No. There are two issues: the right to create derived works and what license the derived works may be distributed under. The GFDL restricts the right to *create* derived works. Restrictions on the choice of license for the redistribution of the derived works are generally allowed, provided they satisfy DFSG 3: ...and must allow them to be distributed under the same terms as the license of the original software (and DFSG 4, and the rest of the DFSG). The GFDL does not
Re: The draft Position statement on the GFDL
On Thu, May 06, 2004 at 09:12:05AM -0400, Nathanael Nerode wrote: Make or distribute is the biggest problem here. If it said make and distribute, you might be correct. As it is actually written, it requires that you not place specific technical obstacles in the way of people reading or making copies of the copy you *make*, even if you don't distribute it at all. Except, this is a copyright, and only capable of restricting things copyrights can grant permission on. It needs to be read with that in mind. From Manoj's draft postion statement: Matthew Garrett Notes: Awkward. Even if the Microsoft Word file format was well described, it would not be modifiable in a generic text editor. The GPL requires distribution of source in The preferred format for modification - the GFDL limits what that preferred form may be. The lack of definition of copy here makes things unclear - if my only source is a formatted Word document, does a plain text output of the contents qualify as a transparent version? Without clarification, this may prevent certain types of derivative work being produced, which would be a violation of DFSG 3. I don't see the problem here -- this seems to be an objection that the GFDL shouldn't be used in some contexts where it's not being used. If you've created the document in word, don't use the GFDL to license it. If the document was created in some other format, then it wasn't created in Word. In other words: if you want to have new content, put it under a different license, and if you want the compilation as a whole to be copyrighted use a compilation copyright which also is not the GFDL. So why is this a problem? This is the serious freeness issue with Transparent and Opaque formats; the overly specified definitions mean that certain types of documents don't appear to have any transparent formats (notably word processing files, even ones for Free word processors, and sound files of any sort). Which makes it impossible to make certain kinds of derivative works. :-P Well, it's true that you can't produce DRM derived works -- that's pretty much the point. However, if you wanted to produce a word document which embedded some GFDL content, it's probably worth noting that word offers a superset of html, and html lets you put things in iframes. If your objection is that someone could create a restricted capability format which would not allow this kind of compilation, that's also true, and I think that's about as noteworthy as the content licensed under the GPL cannot be combined with content licensed under the TeX license issue. That's not a problem that we have made any consistent effort to solve. Well, it allows some derived works, but not all. Generally clause 3 has been interpreted to mean that the license must allow derived works in *general*, not merely certain derived works. But we don't really do that. Or maybe it is legal for me to combine incorporate metafont code into gcc? Interpreting it to allow licenses to contain arbitrary restrictions on what derived works are permitted would open up loopholes the size of whales. For a quick example, it would immediately allow Sun's Java into main; it would allow all those other licenses which only permit conformant implementations; it would allow licenses which permitted derivative works to be made only for purposes of porting; etc. I don't see that this needs to be that general. However, requiring that all derived works have a huge honking hunk of unmodifiable text in the middle of them, with a specific title, listed in the table of contents, untranslated, does not seem to be a reasonable restriction! A key point here is that if the works are programs, DFSG#4 is relevant. -- Raul
Re: The draft Position statement on the GFDL
Raul Miller wrote: On Sun, May 02, 2004 at 03:31:49PM -0700, Don Armstrong wrote: Not all jurisdictions have a concept of fair use, so licenses which rely upon such a concept generally are not free. Ah, this is key. I'm need to understand how it's possible to have copyright on computer programs in such a jurisdiction -- any copyright which restricts unauthorized copying, such as almost any commercial program, would seem to be unusable in that kind of jurisdiction. There may be an explicit right to to make transitory copies a program solely as part of the course of normal use of the program. Which is very narrow. Or you may need a license to copy, and your EULA may grant the right to copy solely for that purpose. snip Hmm... There seem to be two ways of reading §3: The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. In one reading, the license must allow all modifications and derived works to be distributed, and §4 is an exception. In another reading, the license must allow some modifications and derived works to be distributed, and §4 is an additional constraint. In another reading, the license must allow most modifications and derived works to be distributed, with possible exceptions. Section 4 can be an exception or a constraint; your choice. :-) There are additional implied exceptions; derived works can be required to carry accurate attribution, for instance. Since these are guidelines, and since they don't contain phrases like All and 100%, but also don't contain phrases like Some or A few, this seems like the right interpretation. This is an interesting ambiguity. Indeed. -- There are none so blind as those who will not see.
Re: The draft Position statement on the GFDL
On Thu, May 06, 2004 at 09:18:00AM -0400, Nathanael Nerode wrote: Oh. Well, the GFDL with Invariant Sections requires bloat in distributed binaries. Where the GFDL is used to license programs, it's not something that we can distribute under the DFSG. [As this could require us to not fix security problems.] -- Raul
Re: The draft Position statement on the GFDL
Raul Miller wrote: On Sun, 02 May 2004, Raul Miller wrote: Can you point me at some jurisdiction where such copying is disallowed? On Sun, May 02, 2004 at 05:05:15PM -0700, Don Armstrong wrote: I have been told that the UK is one such jurisdiction, but I'm by no means expert (or even versed) in UK law. http://lists.debian.org/debian-legal/2003/debian-legal-200309/msg00760.html talks about it a bit. Hmm... not much to go on. The only hint I see in the UK copyright law on how it deals with the routine copies which are necessary to use a file on a computer appears in Chapter VI (Presumptions). Here, it uses the term copies to refer to ownership of a computer program: http://www.hmso.gov.uk/acts/acts1988/Ukpga_19880048_en_7.htm#mdiv105 This language seems to indicate that in the UK, the owner of a computer program has a right to some set of copies. This is entirely supposition, unfortunately. The details aren't spelled out anywhere I can find, but given that multiple copies is an accurate representation of what has to be the case in the use of a computer program, I find it easy to believe. However, I haven't been able to find anything in UK copyright law which would cause a problem for the user who has a GFDL licensed document named file where they issue the command chmod 0 file and the command completes without error. Jurisdictions with Droit d' auter may be others which don't have a concept of fair use (or have a limited concept.) I think the presence or absence of Fair Use is largely irrelevant in this context. I believe all that's needed is that the country allow people to run legally owned computer programs. Really? How does that give any rights regarding the GFDL file? You may have the limited right, under copyright law, to make the copies which are necessary to run chmod, but that doesn't help you when it comes to the copyright of file. However, if there are countries which allow copyright restrictions on use -- where the owner of a program may control how a person uses a program (outside of redistribution) -- then this GFDL license might be a problem. Does anyone know of any such countries? [If we do, they could serve as significant examples in a variety of other contexts as well.] Thanks, -- There are none so blind as those who will not see.
Re: VOCAL (Vovidia Communications License)
Dan Weber wrote: I wanted to run this by you guys before I produced any packages that use this noting the sip library resiprocate which uses it. The license is attached. * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The names VOCAL, Vovida Open Communication Application Library, *and Vovida Open Communication Application Library (VOCAL) must *not be used to endorse or promote products derived from this *software without prior written permission. For written *permission,[EMAIL PROTECTED] These three are 3-clause BSD, which is fine. Although clause 3 is silly, since it's apparently a no-op. * 4. Products derived from this software may not be called VOCAL, nor This is generally considered OK, although it's rather annoying; it's a typical name-change requirement. *may VOCAL appear in their name, This is the only questionable bit, since it's really a rather broad restriction. But I think it's DFSG-free enough, especially since vocal or Vocal could still appear in the name. without prior written *permission of Vovida Networks, Inc. You must be careful; your Debian package of this will almost certainly be a derivative work (unless you don't need a diff at all, which is unlikely) and so in order to satisfy clause 4, you need to make sure it isn't called VOCAL and that VOCAL doesn't appear in its name. This is obviously an annoyance. Clause 4 is not GPL-compatible, of course, in case you were wondering. -- There are none so blind as those who will not see.
Re: Mass bug filing: Cryptographic protection against modification
Theodor Ts'o wrote: Hence, standards bodies that state that out of policy reasons, if someone wants to make a non-interoperable version of a protocol, they should start from scratch and not be able to leverage the existing work of the protocol specifications, are in many ways making the exact same argument about why it is necessary to prevent someone from using the GPL using it as a base, possibly stemming confusion in the marketplace. But the GPL is modifiable. The preamble isn't. Yes, it would be nice if the preamble was. So tell me again why the GPL text should be privileged? Because without us distributing it, we can distribute no GPLed works. This would make providing a Linux distribution rather difficult. Yes, this is hypocrisy. We arguably should alter the social contract to say Debian will remain entirely free (except for two or three text files that we're required to distribute in order to actually be able to distribute any software whatsoever), but it's not entirely clear how that would actually benefit anyone. Reality currently requires that we distribute around 1K of unmodifiable GPL preamble in order to be useful. That 1K buys us a lot. 1K gives us a modifiable kernel and a modifiable basic userland. We could relax our principles a little further and get a bunch of unmodifiable text files, but the payoff is much smaller. I think the line's in the right place now. In the end, even Debian is occasionally forced to bow to pragmatism, and I think the GPL case is one where we have no choice. In contrast, I don't think the GFDL/firmware/whatever cases are. -- Matthew Garrett | [EMAIL PROTECTED]
Re: VOCAL (Vovidia Communications License)
Don Armstrong wrote: On Tue, 04 May 2004, Branden Robinson wrote: Does anyone know if the latest version of the Apache Software License still retains these terms? No, thankfully Apache Source License v 2.0 ditched them for the more sane (and more to the point) §6: 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.[1] Which is probably what the license should have said in the beginning. Heh. :-) [We probably should really review Apache Source License v 2.0 sometime... §3 (patent reciprocity) and §4d (acknowledgements in the NOTICE file) are two clauses that are near the border, and while I think they're free, I'm interested in others opinions of them.[2]] Don Armstrong 1: http://www.apache.org/licenses/LICENSE-2.0 2: I know we discussed §3 when it was proposed, but it's interesting... §4d may also be important to discuss, especially in the context of droit d' auter and in the context of free documentation licenses. I remember giving the Apache Foundation detailed amendments to 4d (which they adopted) so as to make it non-objectionable. I think it's sufficiently free. It's *very* narrowly tailored to forestall a lot of problems, unlike similar clauses in other licenses. Similarly for section 3; sentence 1 is a permission grant, while sentence 2 is very narrowly tailored to protect the freedom of the Work itself, rather than just to attack software patents in general -- it prevents a particular scheme which could otherwise be successfully used by a patent-holder to make other people's work proprietary to the patent-holder. -- There are none so blind as those who will not see.
Re: VOCAL (Vovidia Communications License)
Josh Triplett wrote: Glenn Maynard wrote: On Sun, May 02, 2004 at 09:26:10AM -0700, Josh Triplett wrote: * 4. Products derived from this software may not be called VOCAL, nor *may VOCAL appear in their name, without prior written *permission of Vovida Networks, Inc. This license appears to be identical to the Apache License, version 1.1, with the names changed and clause 3 (an advertising clause) removed. It looks to be a DFSG-Free license. Clause 4 makes it GPL-incompatible, so be sure it doesn't link to any GPLed software. I wonder why we considered clause #4 to be free; it seems a little overreaching. It prohibits code reuse with any projects with names like Vocal Minority or Vocalize. (This isn't an objection; just curiosity.) The DFSG justification is based on DFSG 4, which states that The license may require derived works to carry a different name or version number from the original software. Right. That allows the requirement of not calling it VOCAL -- but not including VOCAL in the name at all? As for _why_ we allow that, I think it is based on the idea of avoiding misrepresentation: anyone should be free to create a forked version of a piece of Free Software, but attempting to pass it off as the original is misrepresentation. Users should always know what they are getting, and be able to make a reasoned choice as to where they get their software from. That said, I think putting such a _specific_ requirement about misrepresentation in the license, while still Free, is not a particularly good idea. I am a big fan of licenses that state intent rather than mechanism. I think all of debian-legal is. Actually, it might be worth making a page of advice for license designers, explaining basic principles like this, with examples. (And examples of why mechanism specification causes unintended trouble.) For example, contrast the GPL's preferred form for modification with the GFDL's Transparent and Opaque: the former states intent, while the latter states mechanism. In this particular case, a condition that stated intent would be something like this (taken from the zlib license): Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. Damn, that's a good one. - Josh Triplett -- There are none so blind as those who will not see.
Re: Squeak in Debian?
Walter Landry wrote: Lex Spoon [EMAIL PROTECTED] wrote: snip The permission that matters to us comes two sentences later: You may distribute and sublicense such Modified Software only under the terms of a valid, binding license that makes no representations or warranties on behalf of Apple, and is no less protective of Apple and Apple's rights than this License. That's an only. I read that as a restriction on the permissions granted earlier, not as a separate grant of permission. If it's a separate grant of permission, it doesn't need the 'only'. Then there's the question of what a binding license is; who is it supposed to bind? Shall we assume that it binds those who distribute only, in which case it's all good? This suggests that we could distribute Squeak under any more restrictive license. But it is rather vague. Regards, Walter Landry [EMAIL PROTECTED] -- There are none so blind as those who will not see.
Re: VOCAL (Vovidia Communications License)
Glenn Maynard wrote: On Sun, May 02, 2004 at 09:26:10AM -0700, Josh Triplett wrote: * 4. Products derived from this software may not be called VOCAL, nor *may VOCAL appear in their name, without prior written *permission of Vovida Networks, Inc. This license appears to be identical to the Apache License, version 1.1, with the names changed and clause 3 (an advertising clause) removed. It looks to be a DFSG-Free license. Clause 4 makes it GPL-incompatible, so be sure it doesn't link to any GPLed software. I wonder why we considered clause #4 to be free; it seems a little overreaching. It prohibits code reuse with any projects with names like Vocal Minority or Vocalize. (This isn't an objection; just curiosity.) Well, I figured that it only applied to VOCAL with that capitalization, which isn't as bad. It's still an annoying and stupid clause, and they should be asked if they'd be willing to remove the 'nor may VOCAL appear in their name' part. -- There are none so blind as those who will not see.
Re: Repost of the DRAFT d-l summary of the OSL v2.0
Thanks for your answer. GPL-compatibility would be an interesting point, but the problem that we encounter is the GPL copyleft, which is very strong, due to the interpretation of the FSF concerning derivative works. Moreover this will be probably be enforced in GPL v3. It is annoying as soon as we would like to link our projects with free/open-source, but GPL-incompatible modules, for instance some libraries in CPL, for instance at http://www.coin-or.org. Therefore I would prefer to use a less-restrictive license, while ensuring some copyleft in the project, as does the LGPL. The OSL seems a good alternative (but again GPL-incompatible), since L. Rosen interprets derivative works in a more convenient way at my opinion. Unfortunately, we know the Debian position about OSL. I could try to write a new license, but I think also that there are currently to many licenses, so I would prefer to use an existing one. Fabian Jeremy Hankins wrote: Fabian Bastin [EMAIL PROTECTED] writes: Just a little question. If you want a copyleft license for your work debian-legal recommends the GPL v2.0. What is the recommendation if you want a copyleft license, but no as strong as the GPL, in particular if you consider that simply linking a module does not produce a derivative work? The LGPL has an annonying point since it allows anybody to distribute the product in GPL instead of LGPL. I don't know of a license that does specifically what you want, though I don't think it would be hard to come up with one. I think the reason there isn't one is that there's little reason for such a license. If you want to give extra permissions, just use the LGPL. Why is it important for your works to be GPL-incompatible?
Re: reiser4 non-free?
On Thu, May 06, 2004 at 09:44:01AM -0400, Brian Thomas Sniffen wrote: Walter Landry [EMAIL PROTECTED] writes: David Masover [EMAIL PROTECTED] wrote: First and foremost: Hans, this is your project. Someone willing to replace entire APIs with things that feel like files is obviously not afraid of creating something new. So at the end of the day, it shouldn't matter too much that it's in Debian Non-free, especially if (assuming I heard correctly) XFree86 is also non-free. People seem to be missing this issue, so I'll bring it up again. The problem is not so much whether the license is free or not. The problem is that it is incompatible with the GPL. That means that Debian can't distribute it _at all_. Not in main, not in non-free. Not at all. The license may be perfectly free (e.g. the IBM CPL), but if it is incompatible with the GPL, then Debian can't distribute it. You're right, Walter, and thank you for the clarification. To clarify further, Debian can't distribute a derivative work of the Linux kernel which is not licensed under the GPL. if linux kernel distributes itself such a derivative work why debian can't? -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: Fwd: reiser4 non-free?
Nathanael Nerode [EMAIL PROTECTED] writes: Burnes, James wrote: 3. Is it that you simply want an efficient mechanism for cataloging efforts of the major contributors to a project? If that's the case why don't we just come up with some sort of credits standard to be macro embedded in the binaries? That way anyone could view the credits by running a 'credits' shell command against the binary/library/kernel etc. Obviously the macros would be viewable in source. Nice idea. I like it. It's also a good way to put the copyright notices *into* the binaries, rather than merely next to them. How about a standard ELF section for credits? :-) I like the idea as well. FWIW, as an experimental implementation attempt, I have just modified my own little program (jpegpixi, of which I'm the upstream author; I'm not a DD) to put the copyright and license information (i.e. the text which is normally output in reaction to the --version command line option) in a separate ELF section .license. The objcopy command can be used to dump and/or extract the contents of this section. Martin
Re: The draft Position statement on the GFDL
On Thu, May 06, 2004 at 10:06:37AM -0400, Nathanael Nerode wrote: Really? How does that give any rights regarding the GFDL file? You may have the limited right, under copyright law, to make the copies which are necessary to run chmod, but that doesn't help you when it comes to the copyright of file. I'm trying to envision the scenario you're concerned about. I suspect this is because we have wildly different ideas about what it is that we're talking about. From my point of view: GFDL grants a number of rights, and retracts them under certain circumstances. I believe the circumstances it retracts them is when someone providing a GFDL document attempts to control how someone else uses the copy. From this point of view, complete and utter refusal to distribute a copy (chmod -r) does not constitute control. I appreciate that you think that chmod -r is control, but since (from a user point of view) it's equivalent to not making the file available for download I don't think that this is a meaningful point of view. You might as well claim that deleting text from a region which is not immutable constitutes control, that turning off the power to the machine is control, that deleting the file is control or that compressing the file is control. Despite the fact that the copyright notices use the phrase technical measures it is still a legal document. That said -- I'm not trying to convince people that the GFDL as it currently stands should be considered DFSG free. I'm ambivalent about that. What I am trying to say is that some significant arguments against the GFDL don't really make sense. -- Raul
Re: reiser4 non-free?
On Thu, 06 May 2004 16:36:43 +0200, Domenico Andreoli said: if linux kernel distributes itself such a derivative work why debian can't? What non-GPL derivative works ship with the kernel? Even having facilities to load *non-derivative* non-GPL microcode into adapters is frowned on pgpYBZEdxe7F2.pgp Description: PGP signature
Re: reiser4 non-free?
Domenico Andreoli [EMAIL PROTECTED] writes: On Thu, May 06, 2004 at 09:44:01AM -0400, Brian Thomas Sniffen wrote: Walter Landry [EMAIL PROTECTED] writes: David Masover [EMAIL PROTECTED] wrote: First and foremost: Hans, this is your project. Someone willing to replace entire APIs with things that feel like files is obviously not afraid of creating something new. So at the end of the day, it shouldn't matter too much that it's in Debian Non-free, especially if (assuming I heard correctly) XFree86 is also non-free. People seem to be missing this issue, so I'll bring it up again. The problem is not so much whether the license is free or not. The problem is that it is incompatible with the GPL. That means that Debian can't distribute it _at all_. Not in main, not in non-free. Not at all. The license may be perfectly free (e.g. the IBM CPL), but if it is incompatible with the GPL, then Debian can't distribute it. You're right, Walter, and thank you for the clarification. To clarify further, Debian can't distribute a derivative work of the Linux kernel which is not licensed under the GPL. if linux kernel distributes itself such a derivative work why debian can't? Someone who is the sole copyright holder of the Linux Kernel can distribute it linked with some other program which is not under a GPL-compatible license. But nobody is in that position. It is not Debian's business to attempt to control what the kernel folks do -- we're all grateful for shier contributions, and that's about that. Reiser can distribute his filesystem and tools, because they depend only on components included with the OS, and others can redistribute for the same reason -- but Debian, as an OS distributor, can't do that. It's part of why we require OpenSSL-targeted license extensions from GPL'd work which links against libcrypto. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: reiser4 non-free?
I just modified the Reiser4 license to be the following: The Anti-Plagiarism License Pre-amble: At the time of writing (2004), distros commonly remove, diminish, or obscure the credits of original authors from many programs so as to ensure that the user has brand awareness primarily of the distro. They have a strong marketing incentive to do so, and there is no shame shown by them in the act. This is a very real problem which has already affected many programs (e.g. KDE, ReiserFS, many others). Western academia has a strong tradition of opposing plagiarism, and there are good societal reasons for ensuring that persons are known for what they have done with precision. Individual users don't benefit as significantly from knowing who produced their software, and so one cannot say that there is a market demand for better credits that is sufficient to overpower the desire of the distros to be the only source users know of to turn to for all their needs. While individuals may not be well motivated to ensure prominent and full crediting, society as a whole is. Crediting is a powerful incentive to produce good works, and many have written about the power of fame as a motivator for producing free software. Society needs accuracy in its recognition of its contributors. The License: The Anti-plagiarism license is the Gnu Public License Version 2 with the following modification: you may not modify, remove, or obscure any credits in the software unless your modification causes those credits to remain equally prominent and to retain their wording. You are not required to display the credits if the computer has no effective display mechanism, or if you do not distribute the software to others. FAQ: Q: Will this license lead to ads? A: No, credits describe the contribution made to a project. Ads describe a product someone wants you to buy. Ads are not the same as credits, and their preservation is not protected by this license. Q: Can we the distro preserve the credits but send the credits to /dev/null. A: No. How can you even ask such a question? Q: Can I change the font? Can I move the credits to a different moment in the user interaction to suit my installer? A: Yes, if you make sure the credits make an equally effective/frequent impression on the user. If you have doubts about whether your changes are fair, be courteous and ask the author and you'll find that most authors are reasonable. Q: What in this license prevents persons from making their name display excessively annoyingly throughout the running of the program? Isn't that a flaw in the license? A: The shovel doesn't stop the digger from creating a pit in the road that endangers other people. The license is a tool. Whether you make an ass out of yourself using it on the software you write is up to you. No compiler makes broken programs work
Re: reiser4 non-free?
[reiserfs-list removed from Cc:] 6.05.2004 pisze (głupio) Hans Reiser ([EMAIL PROTECTED]): I just modified the Reiser4 license to be the following: The Anti-Plagiarism License [rant, irrelevant here, cut] The License: The Anti-plagiarism license is the Gnu Public License Version 2 with the following modification: you may not modify, remove, or obscure any credits in the software unless your modification causes those credits to remain equally prominent and to retain their wording. You are not required to display the credits if the computer has no effective display mechanism, or if you do not distribute the software to others. So, just in this very moment you made Reiser4 undistributable with Linux kernel by making it GPL incompatible. What an achievement! Jubal -- [ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ] [ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ] Proti mocným nikdo není dostatečně vyzbrojen. CONTRA POTENTES NEMO EST MUNITUS SATIS.
Re: reiser4 non-free?
I don't think my clarifications of what is a derivative work conflicted with the GPL, they merely make it less vague as to what is a derivative work. The notion that if something is linked determines whether it is derivative has no basis in either copyright law or the GPL. rms, correct me if you disagree. Vagueness is not a benefit to a license, but in this aspect of the GPL it is curable only in specific to a particular program being licensed. It would be nice if the GPL explicitly allowed particular instances of it to specify what are derivative works with some clarity. (Richard, please consider that.) I can see that not very clever people who view the GPL as some sort of holy writ will make more of an issue out of it than I want to deal with. So, as a result reiser4 plugins will always be compiled in and never dynamically loadable and the clarifications of what is or is not a derivative work have been removed for now. Users and I will both lose as a result, and maybe some needless lawsuit will result at some time in the future that would have been avoided with clear definitions. Hans
Re: reiser4 non-free?
Hans Reiser wrote: The License: The Anti-plagiarism license is the Gnu Public License Version 2 with the following modification: you may not modify, remove, or obscure any credits in the software unless your modification causes those credits to remain equally prominent and to retain their wording. You are not required to display the credits if the computer has no effective display mechanism, or if you do not distribute the software to others. Ok, that's a restriction that's not present in the GPL version 2 (otherwise it wouldn't be necessary). Section 6 of the GPL says: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. Which means that code under the Anti-plagiarism license is not GPL compatible, since it imposes further restrictions. This would prevent anyone from distributing it with their kernel. In order for it to be distributable at all, you'd also need to demonstrate that it isn't a derivative work of the Linux kernel. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Fwd: reiser4 non-free?
MJ Ray wrote: On 2004-05-04 18:47:02 +0100 Hans Reiser [EMAIL PROTECTED] wrote: Our licenses are free and not plagiarizable. GPL V2 is plagiarizable in the view of folks at debian who felt free to remove the credits. Can someone give a conclusive statement of what actually happened? The bug report 152547 looks like someone moved an advert into the docs accompanying, rather than removed any attribution. Now, if you call that advert the credits then I think you have a different view to many people. Show me the line in those credits where it said buy Coca-Cola cheaper here. They were credits, not advertisements. Their new condition clause 4, which says you cannot use their name, even for accurate reporting. Normally, this would just be a false statement, but this licence makes it a condition of the grant. I've not seen that mistake committed by anyone else yet. Can you supply their full verbatim phrasing so that we can discuss it accurately? I'd like to understand whether your characterization is correct. And call it a credit clause, not an advertising clause. Advertisements sell products, credits describe who made the project happen. No, it is advertising for the XFree86 Project, Inc. In addition to acknowledging their copyright (the credit), that advert may have to appear. You seem to understand the difference between credit and advertisement as advertisements are credits for those you dislike. If they are putting their name on their software or its documentation, then surely it is a credit not an advertisement.
Re: Fwd: reiser4 non-free?
Joe Wreschnig wrote: On Tue, 2004-05-04 at 12:54, Hans Reiser wrote: When you go to the opera, they don't come on stage and say buy XYZ, but they do say something prominent on the brochure like we thank the generous ABC corporation for making this evening happen. Debian should follow that model, it works and is morally right to do. This is a very good analogy. Debian will happily print your credits in our brochure (/usr/share/doc/*reiser*/copyright), which is an optional read for people who want to see the opera (use the ReiserFS software). We'll even do it prominently, all caps, whatever. But we will not walk out on stage (print messages during use of the software) to advertise your filesystem. Reiser4 prints them when you make a new filesystem, not when you use the filesystem. We are not as aggressive as you imagine. While I do personally think that boot time credits should be returned to existence, I am not asking for that. We do follow that model, it does work, and it is the right thing to do. Operas put the credits where they get seen. Where a contributor is really significant to it happening, a theater group (little league baseball game, etc.) will mention on stage sometimes.
Re: reiser4 non-free?
Matthew Garrett wrote: Hans Reiser wrote: The License: The Anti-plagiarism license is the Gnu Public License Version 2 with the following modification: you may not modify, remove, or obscure any credits in the software unless your modification causes those credits to remain equally prominent and to retain their wording. You are not required to display the credits if the computer has no effective display mechanism, or if you do not distribute the software to others. Ok, that's a restriction that's not present in the GPL version 2 (otherwise it wouldn't be necessary). Section 6 of the GPL says: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. Which means that code under the Anti-plagiarism license is not GPL compatible, since it imposes further restrictions. This would prevent anyone from distributing it with their kernel. In order for it to be distributable at all, you'd also need to demonstrate that it isn't a derivative work of the Linux kernel. The kernel portion is GPL V2, this is the progs license.
Re: Fwd: reiser4 non-free?
Hans Reiser writes: MJ Ray wrote: On 2004-05-04 18:47:02 +0100 Hans Reiser [EMAIL PROTECTED] wrote: Our licenses are free and not plagiarizable. GPL V2 is plagiarizable in the view of folks at debian who felt free to remove the credits. Can someone give a conclusive statement of what actually happened? The bug report 152547 looks like someone moved an advert into the docs accompanying, rather than removed any attribution. Now, if you call that advert the credits then I think you have a different view to many people. Show me the line in those credits where it said buy Coca-Cola cheaper here. They were credits, not advertisements. -- ... And my lawyer asked 'People pay you money for this?'. Yup. Hee Hee. Life is good. If you buy ReiserFS, you can focus on your value add rather than reinventing an entire FS. You should buy some free software too -- If these are credits, then Coca-cola is gpled. This is just _noise_, spewed on each invocation. Their new condition clause 4, which says you cannot use their name, even for accurate reporting. Normally, this would just be a false statement, but this licence makes it a condition of the grant. I've not seen that mistake committed by anyone else yet. Can you supply their full verbatim phrasing so that we can discuss it accurately? I'd like to understand whether your characterization is correct. And call it a credit clause, not an advertising clause. Advertisements sell products, credits describe who made the project happen. No, it is advertising for the XFree86 Project, Inc. In addition to acknowledging their copyright (the credit), that advert may have to appear. You seem to understand the difference between credit and advertisement as advertisements are credits for those you dislike. If they are putting their name on their software or its documentation, then surely it is a credit not an advertisement. Nikita.
Re: Fwd: reiser4 non-free?
On Thu, May 06, 2004 at 06:16:50PM +0200, Martin Dickopp wrote: Nathanael Nerode [EMAIL PROTECTED] writes: Burnes, James wrote: 3. Is it that you simply want an efficient mechanism for cataloging efforts of the major contributors to a project? If that's the case why don't we just come up with some sort of credits standard to be macro embedded in the binaries? That way anyone could view the credits by running a 'credits' shell command against the binary/library/kernel etc. Obviously the macros would be viewable in source. Nice idea. I like it. It's also a good way to put the copyright notices *into* the binaries, rather than merely next to them. How about a standard ELF section for credits? :-) I like the idea as well. FWIW, as an experimental implementation attempt, I have just modified my own little program (jpegpixi, of which I'm the upstream author; I'm not a DD) to put the copyright and license information (i.e. the text which is normally output in reaction to the --version command line option) in a separate ELF section .license. The objcopy command can be used to dump and/or extract the contents of this section. How much did this addition increase the size of the final binary? Hypothetically, would you object to this information being stripped if your binary were used on an embedded or low space device? -- Jamin W. Collins Never underestimate the power of very stupid people in large groups. -- John Kenneth Galbraith
Re: Fwd: reiser4 non-free?
A typical example: /sbin/mkreiserfs -V mkreiserfs 3.6.9 (2003 www.namesys.com) A pair of credits: Alexander Zarochentcev (zam) wrote the high low priority locking code, online resizer for V3 and V4, online repacker for V4, block allocation code, and major parts of the flush code, and maintains the transaction manager code. We give him the stuff that we know will be hard to debug, or needs to be very cleanly structured. BigStorage (www.bigstorage.com) contributes to our general fund every month, and has done so for quite a long time. Nikita Danilov wrote: Hans Reiser writes: MJ Ray wrote: On 2004-05-04 18:47:02 +0100 Hans Reiser [EMAIL PROTECTED] wrote: Our licenses are free and not plagiarizable. GPL V2 is plagiarizable in the view of folks at debian who felt free to remove the credits. Can someone give a conclusive statement of what actually happened? The bug report 152547 looks like someone moved an advert into the docs accompanying, rather than removed any attribution. Now, if you call that advert the credits then I think you have a different view to many people. Show me the line in those credits where it said buy Coca-Cola cheaper here. They were credits, not advertisements. -- ... And my lawyer asked 'People pay you money for this?'. Yup. Hee Hee. Life is good. If you buy ReiserFS, you can focus on your value add rather than reinventing an entire FS. You should buy some free software too -- If these are credits, then Coca-cola is gpled. This is just _noise_, spewed on each invocation. Hmmm. Ok, you are right, I should change the wording of that. Their new condition clause 4, which says you cannot use their name, even for accurate reporting. Normally, this would just be a false statement, but this licence makes it a condition of the grant. I've not seen that mistake committed by anyone else yet. Can you supply their full verbatim phrasing so that we can discuss it accurately? I'd like to understand whether your characterization is correct. And call it a credit clause, not an advertising clause. Advertisements sell products, credits describe who made the project happen. No, it is advertising for the XFree86 Project, Inc. In addition to acknowledging their copyright (the credit), that advert may have to appear. You seem to understand the difference between credit and advertisement as advertisements are credits for those you dislike. If they are putting their name on their software or its documentation, then surely it is a credit not an advertisement. Nikita.
Debian: reiser4 non-DFSG-free. !?!
@ 06/05/2004 15:29 : wrote Hans Reiser : I just modified the Reiser4 license to be the following: The Anti-Plagiarism License etc. Mr. Heiser, I am a software developer, a paralegal, and a Debian user. Recently, I've participated in various technical discussions in debian-devel and in various licensing discussions in -legal. While I have sent you, both by way of the lists and personally, some questions about the reasoning of your licenses, you have up to the present moment refrained to answer me. I stated in those e-mails that I am a great admirer of your work. I stated, also, that I agree with your concerns about plagiarism. I said, moreover, that I think that your work and the other reiser[34] contributors' work is important. Important to Debian. Important to the Linux community. Important to the Linux users. It's certainly important to me. What I don't understand is _why_ are you doing this in such a beligerant manner. I repeat: please, let's work our differences out. Let us reach consensus and move forward. Reading all the lists archives and bug reports, it appears to me that (at least part of) the problem is the following: some of your filesystem utilities displayed, unconditionally, a big (by some measure, but greater than 3 lines) attribution of credits. This was too much to some package maintainers, and they transferred said text to a file in the documentation directory for the package. You filed a bug, the maintainer gave you the shoulder, flames ensued, etc. I don't agree with you that this is plagiarism. I'm sorry to say, but, in my dictionary (and in the jurisdiction I live in) plagiarism would be, for instance, remove *all* the credit attributions in the packages, or substituting them for some credits crediting the wrong person or persons. In this case, here in Brasil at least, the person commiting such acts would be subject to one to four years in jail and a fine. The legal part of this remembers me of another problem, with your old clarifications over the GPL and with your new Anti-Plagiarism License: it's a GPL-incompatible license ... for a work (reiser4) which is derived from a GPL'd work (linux). This pretty much renders your product (reiser4) undistributable by any person other than yourself. And, in principle, even by yourself. And I think this is a very big loss. About the credits: if the credits attribution is too long to fit by the standards of the package's maintainer (who is the proper authority in the case, seemingly), what other solution there is? Just putting a line like: Many people contributed to this project. Please look: /usr/share/doc/reiserfsprogs/CREDITS. is not enough? I mean, instead of the 20+ lines of the current display in dispute? As someone noticed in debian-legal, many people leave the theather before the credits roll. They know it's a (for instance) George Lucas' movie, but they won't know the name of the cameramen. Isn't it the same thing? If you want to see the credits, go and see them. It's not like Debian did make them disappear. Now, I have only one question: is there a way you could back out in your opinion and return to the old licensing for your products, provided a consensus on moment and size of the credits attribution is reached? If the answer is yes, I volunteer to mediate the discussions between you and the affected package(s) maintainer(s). -- best regards, Humberto Massa
Re: Fwd: reiser4 non-free?
Vitaly, change the paragraph Nikita complained of to: Continuing core development of ReiserFS is mostly paid for by Hans Reiser from money made selling licenses in addition to the GPL to companies who don't want it known that they use ReiserFS as a foundation for their proprietary product. We thank those anonymous companies. Hans Reiser and Namesys also perform consulting to companies who miscellaneous kernel work done, and we thank those companies also. Nikita Danilov wrote: Hans Reiser writes: MJ Ray wrote: On 2004-05-04 18:47:02 +0100 Hans Reiser [EMAIL PROTECTED] wrote: Our licenses are free and not plagiarizable. GPL V2 is plagiarizable in the view of folks at debian who felt free to remove the credits. Can someone give a conclusive statement of what actually happened? The bug report 152547 looks like someone moved an advert into the docs accompanying, rather than removed any attribution. Now, if you call that advert the credits then I think you have a different view to many people. Show me the line in those credits where it said buy Coca-Cola cheaper here. They were credits, not advertisements. -- ... And my lawyer asked 'People pay you money for this?'. Yup. Hee Hee. Life is good. If you buy ReiserFS, you can focus on your value add rather than reinventing an entire FS. You should buy some free software too -- If these are credits, then Coca-cola is gpled. This is just _noise_, spewed on each invocation. Those sales make it possible every once in a long while to pay salaries Their new condition clause 4, which says you cannot use their name, even for accurate reporting. Normally, this would just be a false statement, but this licence makes it a condition of the grant. I've not seen that mistake committed by anyone else yet. Can you supply their full verbatim phrasing so that we can discuss it accurately? I'd like to understand whether your characterization is correct. And call it a credit clause, not an advertising clause. Advertisements sell products, credits describe who made the project happen. No, it is advertising for the XFree86 Project, Inc. In addition to acknowledging their copyright (the credit), that advert may have to appear. You seem to understand the difference between credit and advertisement as advertisements are credits for those you dislike. If they are putting their name on their software or its documentation, then surely it is a credit not an advertisement. Nikita.
Re: reiser4 non-free?
@ 06/05/2004 15:29 : wrote Hans Reiser : I just modified the Reiser4 license to be the following: The Anti-Plagiarism License etc. Mr. Heiser, I am a software developer, a paralegal, and a Debian user. Recently, I've participated in various technical discussions in debian-devel and in various licensing discussions in -legal. While I have sent you, both by way of the lists and personally, some questions about the reasoning of your licenses, you have up to the present moment refrained to answer me. I stated in those e-mails that I am a great admirer of your work. I stated, also, that I agree with your concerns about plagiarism. I said, moreover, that I think that your work and the other reiser[34] contributors' work is important. Important to Debian. Important to the Linux community. Important to the Linux users. It's certainly important to me. What I don't understand is _why_ are you doing this in such a beligerant manner. I repeat: please, let's work our differences out. Let us reach consensus and move forward. Reading all the lists archives and bug reports, it appears to me that (at least part of) the problem is the following: some of your filesystem utilities displayed, unconditionally, a big (by some measure, but greater than 3 lines) attribution of credits. This was too much to some package maintainers, and they transferred said text to a file in the documentation directory for the package. You filed a bug, the maintainer gave you the shoulder, flames ensued, etc. I don't agree with you that this is plagiarism. I'm sorry to say, but, in my dictionary (and in the jurisdiction I live in) plagiarism would be, for instance, remove *all* the credit attributions in the packages, or substituting them for some credits crediting the wrong person or persons. In this case, here in Brasil at least, the person commiting such acts would be subject to one to four years in jail and a fine. The legal part of this remembers me of another problem, with your old clarifications over the GPL and with your new Anti-Plagiarism License: it's a GPL-incompatible license ... for a work (reiser4) which is derived from a GPL'd work (linux). This pretty much renders your product (reiser4) undistributable by any person other than yourself. And, in principle, even by yourself. And I think this is a very big loss. About the credits: if the credits attribution is too long to fit by the standards of the package's maintainer (who is the proper authority in the case, seemingly), what other solution there is? Just putting a line like: Many people contributed to this project. Please look: /usr/share/doc/reiserfsprogs/CREDITS. is not enough? I mean, instead of the 20+ lines of the current display in dispute? As someone noticed in debian-legal, many people leave the theather before the credits roll. They know it's a (for instance) George Lucas' movie, but they won't know the name of the cameramen. Isn't it the same thing? If you want to see the credits, go and see them. It's not like Debian did make them disappear. Now, I have only one question: is there a way you could back out in your opinion and return to the old licensing for your products, provided a consensus on moment and size of the credits attribution is reached? If the answer is yes, I volunteer to mediate the discussions between you and the affected package(s) maintainer(s). -- best regards, Humberto Massa
Wholesale Prices on Vicodin
Buy your drug of choice, NO prescription required Today's special: Free overnight Fedex delivery Vicodin.$2.55/dose Hydrocodone$2.16/dose Xanax...$2.56/dose Valium..$2.68/dose Phentermine..$0.86/dose Stock is limited and selling fast, so hurry Buy them here
Re: Debian: reiser4 non-DFSG-free. !?!
Another example: [EMAIL PROTECTED]:~/reiser4progs-0.5.3 /sbin/mkreiserfs -V mkreiserfs 3.6.9 (2003 www.namesys.com) A pair of credits: Edward Shushkin wrote the encryption and compression file plugins, and the V3 journal relocation code. Vladimir Demidov wrote the parser for sys_reiser4(), the V3 alpha port, part of the V3 journal relocation code, and helped Hans keep the business side of things running. Humberto Massa wrote: @ 06/05/2004 15:29 : wrote Hans Reiser : I just modified the Reiser4 license to be the following: The Anti-Plagiarism License etc. Mr. Heiser, I am a software developer, a paralegal, and a Debian user. Recently, I've participated in various technical discussions in debian-devel and in various licensing discussions in -legal. While I have sent you, both by way of the lists and personally, some questions about the reasoning of your licenses, you have up to the present moment refrained to answer me. I stated in those e-mails that I am a great admirer of your work. I stated, also, that I agree with your concerns about plagiarism. I said, moreover, that I think that your work and the other reiser[34] contributors' work is important. Important to Debian. Important to the Linux community. Important to the Linux users. It's certainly important to me. What I don't understand is _why_ are you doing this in such a beligerant manner. I repeat: please, let's work our differences out. Let us reach consensus and move forward. Reading all the lists archives and bug reports, it appears to me that (at least part of) the problem is the following: some of your filesystem utilities displayed, unconditionally, a big (by some measure, but greater than 3 lines) attribution of credits. This was too much to some package maintainers, and they transferred said text to a file in the documentation directory for the package. You filed a bug, the maintainer gave you the shoulder, flames ensued, etc. I don't agree with you that this is plagiarism. I'm sorry to say, but, in my dictionary (and in the jurisdiction I live in) plagiarism would be, for instance, remove *all* the credit attributions in the packages, or substituting them for some credits crediting the wrong person or persons. In this case, here in Brasil at least, the person commiting such acts would be subject to one to four years in jail and a fine. The legal part of this remembers me of another problem, with your old clarifications over the GPL and with your new Anti-Plagiarism License: it's a GPL-incompatible license ... for a work (reiser4) which is derived from a GPL'd work (linux). This pretty much renders your product (reiser4) undistributable by any person other than yourself. And, in principle, even by yourself. And I think this is a very big loss. About the credits: if the credits attribution is too long to fit by the standards of the package's maintainer (who is the proper authority in the case, seemingly), what other solution there is? Just putting a line like: Many people contributed to this project. Please look: /usr/share/doc/reiserfsprogs/CREDITS. is not enough? I mean, instead of the 20+ lines of the current display in dispute? As someone noticed in debian-legal, many people leave the theather before the credits roll. They know it's a (for instance) George Lucas' movie, but they won't know the name of the cameramen. Isn't it the same thing? If you want to see the credits, go and see them. It's not like Debian did make them disappear. Now, I have only one question: is there a way you could back out in your opinion and return to the old licensing for your products, provided a consensus on moment and size of the credits attribution is reached? If the answer is yes, I volunteer to mediate the discussions between you and the affected package(s) maintainer(s). Try running mkreiserfs and seeing if it really is all that bad, ok? Thanks for caring. Hans
Re: Fwd: reiser4 non-free?
Jeremy Hankins wrote: A couple comments (that I may not be remembering properly) seemed to imply that these credits are part of a revenue generating model. Folks who wish to require users to see their name in conjunction with ReiserFS may purchase this control over what ReiserFS users see (i.e., they can purchase an ad -- the first TV ads worked exactly like this, that's why the word sponsor is used to refer to ad purchasers). If this is the case, and you are using the license to implement this control (i.e., option three above), then I think it's clear that you intend your license to work exactly as it appears to, and restrict users' freedom. If this is your goal (or perhaps some other variant on item 3 above) I don't think you're going to have much luck convincing folks on d-l that your license is Free. Please consider my distinction between a credit (public television in the USA has them), and an ad (for profit broadcast television has them). I don't find the credits annoying, I don't like the ads. Maybe the broadcasters could make more effort to make the ads less annoying and more informative, but their sense of civic duty is too lacking. I do like well funded television shows.
Re: reiser4 non-free?
On Thu, 06 May 2004 16:56:23 -0300, Humberto Massa said: It's the same case as Windows NDIS drivers loading on linux. They were created in a different environment, and would exist as they are even if linux did not exist. Provided GPL'd glue code, you can load them in the linux kernel, and they are _not_ derivative works. And in fact, the fact that the NDIS or NVidia drivers *did* start off as Windows code and have a properly GPL'ed glue layer is the only reason why they're tolerated at all by the kernel community. Linus has said on several occasions words to the effect that if NVidia hadn't convinced him that all of the closed .o files were basically of Windows/other heritage, they'd have heard from a lawyer... pgplmu10N0Osa.pgp Description: PGP signature
Re: reiser4 non-free?
On Thu, May 06, 2004 at 11:41:02AM -0700, Hans Reiser wrote: I don't think my clarifications of what is a derivative work conflicted with the GPL, they merely make it less vague as to what is a derivative clearifications are modifications to the license and thereof not relevant and incompatible to GPL. -- ciao - Stefan
Re: Fwd: reiser4 non-free?
On Thu, May 06, 2004 at 12:34:46PM -0700, Hans Reiser wrote: Please consider my distinction between a credit (public television in the USA has them), and an ad (for profit broadcast television has them). Both are ads. One just makes a poor attempt at failing to mention an actual product making a credit on PBS nearly indistinguishable from most pharmeceutical commercials. I don't find the credits annoying, I don't like the ads. Maybe the broadcasters could make more effort to make the ads less annoying and more informative, but their sense of civic duty is too lacking. I do like well funded television shows. Maybe if you'd watch more television instead of trying to be a lawyer this thread could have died long ago. I'll be blunt. Your current shenanigans, including the misuse of the term plagiarism, discourage me from recommending reiserfs and to strongly contemplate removing it from systems I am responsible for. I suspect that others have well, they just haven't bothered to tell you. Your desire to advertise, advertise, and advertise runs contrary to the Unix philosophy of Don't output a damn thing if it ran right, and frequently don't output a damn thing if it failed miserably. I don't want to see your parp. Your desire to tinker with the license flies in the face of the GPL. If you're so damned sure that your desire to put advertising in the code is right and won't alienate your users, get a lawyer that does software licenses to draw up one to your specifications and kindly shut up until you 1) Get the license drafted 2) Get all of the reiserfs copyright holders to sign off on using the license. As an alternative, perhaps you could talk with Theo DeRaadt about porting Reiserfs to OpenBSD. -- Chris Dukes Been there, done that, got the slightly-charred t-shirt. -- Crowder
Re: Mass bug filing: Cryptographic protection against modification
On Thu, May 06, 2004 at 09:33:23AM -0400, Theodore Ts'o wrote: Hence, standards bodies that state that out of policy reasons, if someone wants to make a non-interoperable version of a protocol, they should start from scratch and not be able to leverage the existing work of the protocol specifications, are in many ways making the exact same argument about why it is necessary to prevent someone from using the GPL using it as a base, possibly stemming confusion in the marketplace. I don't quite understand how you're disagreeing with me. I'm arguing that license texts *can* be placed under freely modifiable metalicenses. The result is that you still have to include the original, unmodified text when distributing other people's software, but you can use the modified text for your own software. For example, I can modify the GPL[1], and distribute my own software under that license. If I distribute the Linux kernel, however, I must include the original GPL with it, or I may be misrepresenting the terms of the license. I'm arguing that unmodifiable license texts *are* DFSG-unfree, and that we don't necessarily have to make an exception for them to be consistent with the nature of the legal system. We *do* make an exception for them, and I don't think this is a problem; I just don't think the we have no choice due to the legal system's design is correct rationale. (An alternative rationale is beyond the scope of this argument, of course.) (Confusion isn't an element in my argument; if you want to prevent confusion, you can say if you modify the GPL, rename it--which the FSF does say, in fact--just as you can say if you modify RFC 12345, don't call it RFC 12345.) (Your arguement that if someone could modify the a copy of the GPL and hence modify the terms under which the kernel is distributed is laughable, by the way; just as a contract doesn't change if someone I didn't claim that you'd be modifying the terms under which the kernel is distributed. (That'd be stupid.) I'm saying that if you modify the GPL, replace the text of the GPL inside the kernel source with your modified copy, and distribute the result, you're *misrepresenting* the actual terms of the software. I think this is analogous to taking the kernel source, changing all of the names inside it to your own, and distributing it. You'd be misrepresenting the authorship of the work. [1] ignoring any arguments about the actual modifiability of the GPL for the sake of discussion -- Glenn Maynard
Re: Fwd: reiser4 non-free?
Chris Dukes wrote: 2) Get all of the reiserfs copyright holders to sign off on using the license. I have licensing rights to all of reiserfs in all versions.
Re: reiser4 non-free?
@ 06/05/2004 15:56 : wrote Hans Reiser :
I don't think my clarifications of what is a derivative work conflicted
with the GPL, they merely make it less vague as to what is a derivative
work. The notion that if something is linked determines whether it is
derivative has no basis in either copyright law or the GPL. rms,
correct me if you disagree.
In Brazilian copyright law, a derivative work has a simple definition:
the work achieved by some transformation of the original work, but is a
novel intellectual creation in itself.
Even the GPL is excessively verbose about what a derivative work is, and
some of it contradicts the various copyright laws in a lot of
jurisdictions. What I'm trying to say is: please don't. Solve the
credits problem in any other way. I would be glad to help you. I care.
Really.
Vagueness is not a benefit to a license, but in this aspect of the GPL
it is curable only in specific to a particular program being licensed.
It would be nice if the GPL explicitly allowed particular instances of
it to specify what are derivative works with some clarity. (Richard,
please consider that.)
But, it currently does not. It currently (and, in the case of the linux
kernel, forever -- the linux kernel is licensed by GPL V2 only, not
later) forbids aditional restrictions. It already places some
restrictions, even on what is to be considered a derived work, which is
a little bit out of its reach. If your work is a derived work (and I'm
assuming reiser4, for instance, is a derived work of the linux kernel),
Debian could only distribute it if it's licensed under the GPL V2 -- and
no aditional restrictions, as per the GPL text itself.
Here is the text of the GPL, section 6, with my coments between {{}}:
*6.* Each time you redistribute the Program (or {{ in this case, reiser4
}} any work based on the Program {{ linux }} ), the recipient
automatically receives a license from the original licensor to copy,
distribute or modify the Program subject to these terms and conditions.
{{ important part: }} You may not impose any further restrictions on the
recipients' exercise of the rights granted herein {{ which include, for
example, moving printf-credits to some-file-credits }}. You are not
responsible for enforcing compliance by third parties to this License.
I can see that not very clever people who view the GPL as some sort of
holy writ will make more of an issue out of it than I want to deal
with. So, as a result reiser4 plugins will always be compiled in and
never dynamically loadable and the clarifications of what is or is not a
derivative work have been removed for now. Users and I will both lose
as a result, and maybe some needless lawsuit will result at some time in
the future that would have been avoided with clear definitions.
This seems to be unnecessary: in this case, specifically, if reiser4
plugins were or not derived works of reiser4, is settled even without
the clarifications -- they are. Rule of thumb to derived works: could
them (plugins) be created (as they are, not in a different way) if the
original work (reiser4) was not created? Yes = derived; no = original.
Likewise, could reiser4 be created as it is now, had linux not been
created? Yes = reiser4 is a derived work on linux; no = it's an original
work.
It's the same case as Windows NDIS drivers loading on linux. They were
created in a different environment, and would exist as they are even if
linux did not exist. Provided GPL'd glue code, you can load them in the
linux kernel, and they are _not_ derivative works. This wouldn't happen
with reiser4 plugins... unless, of course, someone took, for instance,
NTFS plugins (if those ever come to existence) and put some (GPL'd) glue
code to load them as reiser4 plugins (this would not render the
previously-non-derived NTFS plugins in derived code from reiser4.)
Hans
I renew my plea for a peaceful and consensual resolution of these
matters. Thank you, and please keep up the good work in the filesystems.
--
best regards,
Humberto Massa
Re: Fwd: reiser4 non-free?
On Thu, May 06, 2004 at 12:54:22PM -0700, Hans Reiser wrote: Chris Dukes wrote: 2) Get all of the reiserfs copyright holders to sign off on using the license. I have licensing rights to all of reiserfs in all versions. You do not have copyright on code contributions that came from outside of namesys, unless the copyright was released to you by the author. You currently have licensing rights under GPL2 over all of that code. As I said, shutup and talk with a lawyer. -- Chris Dukes Been there, done that, got the slightly-charred t-shirt. -- Crowder
Re: VOCAL (Vovidia Communications License)
On Thu, May 06, 2004 at 10:20:38AM -0400, Nathanael Nerode wrote: Well, I figured that it only applied to VOCAL with that capitalization, which isn't as bad. Well, I don't claim to know whether this clause means grep -i, grep -w, or both ... :) (Which, incidentally, is why I included the Vocal Minority example, though I didn't think about capitalization.) (I suspect the original author might have problems with people renaming the software to Vocal and claiming that's distinct from VOCAL, though.) -- Glenn Maynard
Re: reiser4 non-free?
Humberto Massa wrote: (and I'm assuming reiser4, for instance, is a derived work of the linux kernel), ReiserFS is not, it was created with the intent to port to other operating systems, and at least one of our customers has done so for V3, and I hope/expect others and I will do so for V4. While I agree that Reiser4 plugins would be considered derived works legally, I think that unless the language is clear people will attempt to apply the linker rule to them (which has no legal basis but is what people act on). Lawsuits against persons who had different interpretations waste money. I renew my plea for a peaceful and consensual resolution of these matters. Thank you, and please keep up the good work in the filesystems. I hope you get your wishes in the matter.
Re: Fwd: reiser4 non-free?
Chris Dukes wrote: On Thu, May 06, 2004 at 12:54:22PM -0700, Hans Reiser wrote: Chris Dukes wrote: 2) Get all of the reiserfs copyright holders to sign off on using the license. I have licensing rights to all of reiserfs in all versions. You do not have copyright on code contributions that came from outside of namesys, unless the copyright was released to you by the author. It was. Lawyer wrote the agreements. Please go away. You currently have licensing rights under GPL2 over all of that code. As I said, shutup and talk with a lawyer.
Re: reiser4 non-free?
Humberto Massa wrote: Rule of thumb to derived works: could them (plugins) be created (as they are, not in a different way) if the original work (reiser4) was not created? Yes = derived; no = original. I believe that is incorrect. It should be: yes = original; no = derived. Likewise, could reiser4 be created as it is now, had linux not been created? Yes = reiser4 is a derived work on linux; no = it's an original work. Again, that should be: yes = it's an original work; no = reiser4 is a derived work on linux. __ Post your free ad now! http://personals.yahoo.ca
Re: reiser4 non-free?
@ 06/05/2004 17:03 : wrote Narcoleptic Electron : Humberto Massa wrote: Rule of thumb to derived works: could them (plugins) be created (as they are, not in a different way) if the original work (reiser4) was not created? Yes = derived; no = original. I believe that is incorrect. It should be: yes = original; no = derived. Likewise, could reiser4 be created as it is now, had linux not been created? Yes = reiser4 is a derived work on linux; no = it's an original work. Again, that should be: yes = it's an original work; no = reiser4 is a derived work on linux. You're right in both accounts. It's 5:15 pm, I'm tired and I want to go home. :-) -- br,M
Re: Mass bug filing: Cryptographic protection against modification
On Thu, May 06, 2004 at 05:42:45PM +0200, Eike zyro Sauer wrote: This makes it as unfree or free as GFDLed documents. We allow non-modifiable license texts, so we should allow other texts to be unmodifiable, too! Stop trying to use license texts as a wedge to get other non-free software into the archive. It's tiresome and unconvincing. PS: Sorry, gmane doesn't allow me to crosspost. Then stop using gmane. Maintaining crossposting is fundamental. My mailer is broken is not an excuse for breaking conversations. -- Glenn Maynard
Re: Fwd: reiser4 non-free?
Jamin W. Collins [EMAIL PROTECTED] writes: On Thu, May 06, 2004 at 06:16:50PM +0200, Martin Dickopp wrote: Nathanael Nerode [EMAIL PROTECTED] writes: Burnes, James wrote: 3. Is it that you simply want an efficient mechanism for cataloging efforts of the major contributors to a project? If that's the case why don't we just come up with some sort of credits standard to be macro embedded in the binaries? That way anyone could view the credits by running a 'credits' shell command against the binary/library/kernel etc. Obviously the macros would be viewable in source. Nice idea. I like it. It's also a good way to put the copyright notices *into* the binaries, rather than merely next to them. How about a standard ELF section for credits? :-) I like the idea as well. FWIW, as an experimental implementation attempt, I have just modified my own little program (jpegpixi, of which I'm the upstream author; I'm not a DD) to put the copyright and license information (i.e. the text which is normally output in reaction to the --version command line option) in a separate ELF section .license. The objcopy command can be used to dump and/or extract the contents of this section. How much did this addition increase the size of the final binary? It is not really an addition, because the text was there before, just not in a separate section. The --version command line option still displays the same text, although it is now in a separate section. The main benefit of the current experimental implementation is that a shell script (e.g. a one line objcopy wrapper) could also access the text (given only the binary file). To answer your question, the new section increases the binary file size by 48 bytes, which is probably due to the additional ELF header. Hypothetically, would you object to this information being stripped if your binary were used on an embedded or low space device? No, I wouldn't. Frankly, I don't see how I could without introducing additional restrictions to the GPL. The result of stripping the section is no different from removing the text from the source and recompiling. Technically, if stripping the section is an option, IMHO the program should be changed to react sensibly if it is invoked with the --version command line option and the section is absent. Martin PS: If people are interested in exploring this further, should the discussion be moved to a technical list (e.g. -devel)?
Re: Debian: reiser4 non-DFSG-free. !?!
@ 06/05/2004 16:52 : wrote Hans Reiser : Another example: snikt Try running mkreiserfs and seeing if it really is all that bad, ok? While I _don't_ think it is all that bad, as I told you, the proper authority in this case is the package maintainer(s). I'll try to contact him/her/them and come with some solution. Thanks for caring. Hans -- best regards, Massa
Re: Fwd: reiser4 non-free?
On 2004-05-06 19:53:10 +0100 Hans Reiser [EMAIL PROTECTED] wrote: Show me the line in those credits where it said buy Coca-Cola cheaper here. They were credits, not advertisements. Someone else has given the most extreme example of this. I thank them. Can you supply their full verbatim phrasing so that we can discuss it accurately? I'd like to understand whether your characterization is correct. Please take it up in an XFree86 thread. It has little to do with your problems. You seem to understand the difference between credit and advertisement as advertisements are credits for those you dislike. You seem to understand the difference between modification and plagiarism as plagiarism is a modification that you dislike because it doesn't praise you enough. If they are putting their name on their software or its documentation, then surely it is a credit not an advertisement. They are putting their name in other people's software and documentation too. I thank others for continuing to point out your errors. I have a conference schedule to organise and papers to write, which are both preferable to a seemingly endless debate with an extremely hostile opponent of debian contributors. I really hope that other filesystems replace yours if you won't get clue. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ http://www.ttllp.co.uk/ for creative copyleft computing
Re: GFDL
On 2004-05-16 12:02:46 +0100 Mahesh T. Pai [EMAIL PROTECTED] wrote: FSF has very valid points in having invariant sections, because invariant sections, as used by FSF serve a very useful purpose. (I am an example of how these invariant sections introduce - rather enlighten - people about freedom.) What did you read? Did you obtain it directly from FSF? Would it have been less or more enlightening if you had the freedom to edit it? Maybe their aim is noble, but I believe their method is wrong. This seems to be a frequent problem, not just in free software, but in many walks of life. It is similar to the arguments over whether nuclear weapon proliferation causes peace (because everyone is too scared to attack each other) or danger (because there is more chance of a mistake). How far should we restrict people's freedom in order to promote freedom? I am not sure this question is ever going to reach consensus, but I feel that the FSF does not currently represent my view on software in general. At least we seem to agree on programs, which is still something to be happy with. I think your sees and says often misrepresent positions. It is better not to put too many words in people's mouths. It detracts from your generally thoughtful message. RMS informed me when he was here (in January) that (1) he is not aware of this committee, (2) he sees no problem with the GFDL. Obviously, the communication `gap' still persists. This is worrying, but not insurmountable. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ http://www.ttllp.co.uk/ for creative copyleft computing
Re: RFC: Debian License Information on www.debian.org
On Fri, 30 Apr 2004 10:44:46 +0200 Andreas Barth wrote: I'm just preparing a summary of the three example licenses GPL, BSD and artistic, so that we can add these also on this page. Also, Frank is about to summarize older discussions. Good job! I think that having clear statements even on well-known licenses (such as the GNU GPL) is very important and useful. Summaries of other non-recent d-l discussions are very much appreciated, as well. -- | GnuPG Key ID = DD6DFCF4 | You're compiling a program Francesco |Key fingerprint = | and, all of a sudden, boom! Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO, | 31B5 78F4 279B DD6D FCF4 | version 1.8.0 pgp6z4J3rKhss.pgp Description: PGP signature
Re: RFC: Debian License Information on www.debian.org
On Sun, 2 May 2004 02:38:13 +0200 Frank Lichtenheld wrote: Further license summaries will be included soon, Great! Your job is really appreciated! We Debian enthusiasts have our own list of licenses, at last! :-) -- | GnuPG Key ID = DD6DFCF4 | You're compiling a program Francesco |Key fingerprint = | and, all of a sudden, boom! Poli| C979 F34B 27CE 5CD8 DC12 | -- from APT HOWTO, | 31B5 78F4 279B DD6D FCF4 | version 1.8.0 pgpmzJPb8eFoe.pgp Description: PGP signature
Re: reiser4 non-free?
Hans Reiser [EMAIL PROTECTED] writes: I just modified the Reiser4 license to be the following: The License: The Anti-plagiarism license is the Gnu Public License Version 2 with the following modification: you may not modify, remove, or obscure any credits in the software unless your modification causes those credits to remain equally prominent and to retain their wording. You are not required to display the credits if the computer has no effective display mechanism, or if you do not distribute the software to others. You do realize that this is not GPL compatible, and so works derivative of the Linux kernel cannot be meaningfully licensed under it, and works licensed under it cannot be shipped linked to any GPL'd works, right? That's not the end of the world, but it's worth making clear. There are a couple of other problems with this license. For example, what if there is a display mechanism but I must pay an exorbitant amount to use it? Say, I'm doing mkreiserfs on the London Stock Exchange ticker's main display. Sure, that's a ridiculous case, but a teletype where the user pays by the byte is not. Can you restrict this to works used interactively? That's an intentionally different phrasing than the GPLv2's -- and intentionally captures programs like mkfs, which are not themselves interactive, but which are used in an interactive way. Also, as written the license prohibits me from stripping the credits out of my own copy if I also, separately, distribute the unmodified code. I don't think that's what you meant -- is it? Also, I may not, as written, translate the credits into another language, since that changes their wording. With those serious questions about the license out of the way, I descend to the Faq, which obscures more than it clarifies: FAQ: Q: Will this license lead to ads? A: No, credits describe the contribution made to a project. Ads describe a product someone wants you to buy. Ads are not the same as credits, and their preservation is not protected by this license. Debian's going to have to look really, really closely at every release of every piece of software under this license, then, and risk an argument -- in a courtroom -- with a copyright holder who considers some line to be a credit, or insufficiently prominent in its modified form. For example, moving a credit from mkfs to an installer reduces its frequency, as at least one fs is made per install, but other filesystems may be made. Q: Can we the distro preserve the credits but send the credits to /dev/null. A: No. How can you even ask such a question? How about e-mailing them to root? How about providing a --no-credits switch? How about making it on by default? I expect the answers to be Yes, Yes, No, but I certainly can't read your mind. This license is very, very vague about what is allowed and what is not -- normally not so bad, since there's a big clear zone of what's allowed, but the line of what's Free and what's not is right through the middle of the murky zone. Whether this is a Free license, then, depends very heavily on the licensor. That's awfully inconvenient, from a distributor's point of view. Q: Can I change the font? Can I move the credits to a different moment in the user interaction to suit my installer? A: Yes, if you make sure the credits make an equally effective/frequent impression on the user. If you have doubts about whether your changes are fair, be courteous and ask the author and you'll find that most authors are reasonable. Q: What in this license prevents persons from making their name display excessively annoyingly throughout the running of the program? Isn't that a flaw in the license? A: The shovel doesn't stop the digger from creating a pit in the road that endangers other people. The license is a tool. Whether you make an ass out of yourself using it on the software you write is up to you. No compiler makes broken programs work In other words, some works under this license are free (for example, one containing no credits but the copyright notice) and others are non-free. -- Brian Sniffen [EMAIL PROTECTED]
Re: reiser4 non-free?
On Thu, May 06, 2004 at 11:59:23AM -0700, Hans Reiser wrote: The License: The Anti-plagiarism license is the Gnu Public License Version 2 with the following modification: you may not modify, remove, or obscure any credits in the software unless your modification causes those credits to remain equally prominent and to retain their wording. You are not required to display the credits if the computer has no effective display mechanism, or if you do not distribute the software to others. Ok, that's a restriction that's not present in the GPL version 2 (otherwise it wouldn't be necessary). Section 6 of the GPL says: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. Which means that code under the Anti-plagiarism license is not GPL compatible, since it imposes further restrictions. This would prevent anyone from distributing it with their kernel. In order for it to be distributable at all, you'd also need to demonstrate that it isn't a derivative work of the Linux kernel. The kernel portion is GPL V2, this is the progs license. Which does appear to preserve distributability of both parts. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: reiser4 non-free?
Hans Reiser [EMAIL PROTECTED] writes: The kernel portion is GPL V2, this is the progs license. Oh! That makes many things more clear. I know I've been assuming reiser4 non-free meant the filesystem, not the reference tools which manipulate it. So somebody else can reimplement them in free versions, writing from the specification. Eugh, what a pain, and what a waste, redoing all that work, but it's at least feasible. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Fwd: reiser4 non-free?
MJ Ray [EMAIL PROTECTED] writes: You seem to understand the difference between credit and advertisement as advertisements are credits for those you dislike. You seem to understand the difference between modification and plagiarism as plagiarism is a modification that you dislike because it doesn't praise you enough. To be fair, these credits really do seem to be for others. Some of them are credits *and* ads, and at least one is an ad for work for Hans Reiser and Namesys, but they are credits as well, and most of them for other people. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: reiser4 non-free?
On Thu, May 06, 2004 at 11:10:32AM -0700, Hans Reiser wrote: The Anti-Plagiarism License [...] with the following modification: you may not modify, remove, or obscure any credits in the software unless your modification causes those credits to This licence would benefit greatly from a definition of Credits. Considering that there have already been misunderstandings about Ads vs Credits (which you attempt to dispel in the FAQ, but which confuse me further), and different ideas about what exactly is a credit, you really do need to tighten that up somewhat. Yes, you can ask the author, but if this licence becomes widely used, can you imagine asking the author(s), for every new version they release, what the credits are? Do you really want N+1 distributions all e-mailing you for every release with their credits questions? You could go GFDL and define the exact wording of your desired credits in the licence, but then it would involve a licence change to change the credits -- which if you've got parts licenced by different people under a particular form of credits in the work, will require a new licence grant by them, unless you word the licence in such a way that new credits can be added to the licence without mucking up old ones. Q: Can we the distro preserve the credits but send the credits to /dev/null. A: No. How can you even ask such a question? Q: Can we the distro send the credits to another virtual console other than the one the user is currently looking at? Likely Answer: No. How can you even ask such a question? Actual answer: ??? Q: Must we then force the user to stay on the virtual console which the credits are displayed until the notice has finished displaying? Likely Answer: No. Actual Answer: ??? Q: Where is the limit between displaying the credits where the user won't necessarily see them, and forcing the user to read them? Likely Answer: Umm... Actual Answer: ??? These are all line in the sand questions which need to be answered. If distros are desiring to re-brand you (or rather, your contibutors) out of the equation, they will likely be looking for where the line is, and how far they can redraw it in their favour while you're not looking. I'd imagine that if you don't embed the line in concrete and bolt it down, it'll end up somewhere you don't expect. So you really have to tighten up your wording. I'm not against what you're trying to accomplish - I like to be attributed for my work, too. I've never noticed any instances where I've not been properly attributed in my work on an OSS project, and in fact I've been surprised several times by the prominence others have given my name for work I have done. I've relied on human kindness thus far, and it's worked pretty well for me, so perhaps my naivete is showing a little... That being said, as far as I know my work doesn't form a fairly important part of *any* distribution (Debian or otherwise). There's something I haven't seen answered in this thread or the other recurring ones on the same topic: have you ever actually made a formal request to any of the distributions which have butchered your credits to reinstate them? If so, what was the response? If not, why not, especially since you advocate distributors asking authors what is appropriate? - Matt
Re: Fwd: reiser4 non-free?
On 2004-05-07 00:21:32 +0100 Brian Thomas Sniffen [EMAIL PROTECTED] wrote: MJ Ray [EMAIL PROTECTED] writes: You seem to understand the difference between modification and plagiarism as plagiarism is a modification that you dislike because it doesn't praise you enough. To be fair, these credits really do seem to be for others. Please excuse my bad phrasing. That last you was reiserfs developers or similar. As I said, I am busy. Not an excuse, but an explanation. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ http://www.ttllp.co.uk/ for creative copyleft computing
Re: Debian: reiser4 non-DFSG-free. !?!
On Thu, May 06, 2004 at 12:26:05PM -0700, Hans Reiser wrote: Another example: [EMAIL PROTECTED]:~/reiser4progs-0.5.3 /sbin/mkreiserfs -V mkreiserfs 3.6.9 (2003 www.namesys.com) A pair of credits: Edward Shushkin wrote the encryption and compression file plugins, and the V3 journal relocation code. Vladimir Demidov wrote the parser for sys_reiser4(), the V3 alpha port, part of the V3 journal relocation code, and helped Hans keep the business side of things running. I note that you appear to have put a random selection of credits in the output on each invocation (at least, two invocations on 3.6.13 give me different credits). This makes the definition of what credits are, and giving equal prominence to all of them even harder. As a contributor, if I care that much about getting my name in lights, and part of the mandatory output of a program, the chances are I don't want to possibly miss that chance on a lot of eyeballs and place myself subject to the vagaries of a random number generator. Of course, in this case I would imagine that all of your contributors have said it's OK, but would you consider this modification OK if you hadn't made it? It certainly would be failing the letter of equal prominence to all, but you've done it yourself? A basic tenet of software freedom (IMO) is that modifications should be OK no matter who does them -- this allows everyone the power to fork if they so choose. Oh dear, I appear to have become embroiled in a long thread... - Matt
Re: reiser4 non-free?
On Thu, May 06, 2004 at 07:40:15PM -0400, Raul Miller wrote: Other things to consider: how long must they be displayed? What fonts 0 seconds. Just choose the correct locale. :) -- ciao - Stefan
Re: GFDL
On Sun, May 16, 2004 at 04:32:46PM +0530, Mahesh T. Pai wrote: For the FSF, freedom is the message, and has to be conveyed. FSF's invariant clauses speak of free software and how users' rights are affected by software. FSF is not, should not (and justifiably so) concerned with, or can control what other people who use the GFDL (NOT FSF's GFDL'd work) put in their invariant clauses. FSF rarely puts technical info in invariant clauses. Its invariant clauses are very small. If they're not concerned with other people's use of the license, then they should use it but not advocate it. However, they *are* advocating its use, and therefore to not be concerned with its misuse would be extremely irresponsible. RMS informed me when he was here (in January) that (1) he is not aware of this committee, (2) he sees no problem with the GFDL. Obviously, the communication `gap' still persists. You might want to pass that on to Benj. Mako Hill [EMAIL PROTECTED], who was a member of the committee on Debian's side. -- Glenn Maynard
Re: reiser4 non-free?
Brian Thomas Sniffen [EMAIL PROTECTED] writes: Hans Reiser [EMAIL PROTECTED] writes: A: No, credits describe the contribution made to a project. Ads describe a product someone wants you to buy. Ads are not the same as credits, and their preservation is not protected by this license. Debian's going to have to look really, really closely at every release of every piece of software under this license, then, and risk an argument -- in a courtroom -- with a copyright holder who considers some line to be a credit, or insufficiently prominent in its modified form. Fuzzy lines in a license are not a new thing. Debian isn't in the litigation business, so we're not going to be trying to push the boundaries anyway. Respecting the wishes of the author/licensor is a policy of ours -- remember the pine business. Q: What in this license prevents persons from making their name display excessively annoyingly throughout the running of the program? Isn't that a flaw in the license? A: The shovel doesn't stop the digger from creating a pit in the road that endangers other people. The license is a tool. Whether you make an ass out of yourself using it on the software you write is up to you. No compiler makes broken programs work In other words, some works under this license are free (for example, one containing no credits but the copyright notice) and others are non-free. Wouldn't such a work still be non-free? At the least, it definitely goes much farther than the analogous clause in the GPL. You can't include code (even optionally executed code) to suppress it, for example. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Mass bug filing: Cryptographic protection against modification
On Thu, May 06, 2004 at 09:33:23AM -0400, Theodore Ts'o wrote: Funny that, the standards communities make the exact same argument about why you can't take a standards text, modify it, and then publish it. Even if you change the name, it causes major interoperability problems --- what if there were ten different versions of the http protocol out there, all with different standards documents blessing them as legitimate? Hence, standards bodies that state that out of policy reasons, if someone wants to make a non-interoperable version of a protocol, they should start from scratch and not be able to leverage the existing work of the protocol specifications, are in many ways making the exact same argument about why it is necessary to prevent someone from using the GPL using it as a base, possibly stemming confusion in the marketplace. (Your arguement that if someone could modify the a copy of the GPL and hence modify the terms under which the kernel is distributed is laughable, by the way; just as a contract doesn't change if someone attempts to modify a paper copy of the contract, changing a copy of the GPL would not change the terms under which existing code is licensed. The only argument for why it is necesssary that license texts should be unmodifiable is to avoid confusion --- which is EXACTLY why some standards bodies don't want randoms dicking about with the definition of the http protocol, for example.) So tell me again why the GPL text should be privileged? It is privileged precisely because license texts are irrelevant to our goal of distributing a freely modifiable OS. We distribute programs, scripts, documentation, images, fonts, boot sectors, firmware, dictionaries, and other fine software because we want it to be useful to people; and because these things are useful to our users, our Social Contract compels us, possibly to varying degrees, to ensure that they are also freely modifiable if they are included in Debian. I have, however, never seen anyone actually argue that Debian should distribute a package of licenses -- they simply aren't useful to our users in their own right. We distribute them *solely* out of need (the need to comply with the software license in many cases, or at a minimum the need to document the licensing status of the work), so it doesn't really matter whether the license text is free or not -- even if all the license texts we had were freely modifiable, it would not make *one bit* of difference to what we actually distribute, or to what gets distributed by those who build upon the Debian system. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Is SystemC license compatible with the GPL ?
Matthieu Moy [EMAIL PROTECTED] wrote: [ I know this is out topic here, but I've already sent this mail twice to [EMAIL PROTECTED], twice to the discussion list of the fsfeurope, another time to the SystemC mailing list, and didn't get a single answer :-( ] I'm not surprised. Whoever wrote the license must have been paid by the word. In any case, to answer the subject line of this email, the SystemC license is not compatible. The one part I found that is definitely a problem is 2.6b: Recipient shall assist OSCI to the extent reasonably necessary to protect and maintain the Marks worldwide, including, but not limited to, giving prompt notice to OSCI of any known or potential infringement of the Marks, and cooperating with OSCI in preparing and executing any documents necessary to register the Marks, or as may be required by the laws or rules of any country or jurisdiction. So if you get a copy of the software, you are suddenly part of their trademark police. There may be other problems, but this one is pretty clear. Hi, I've developped a piece of software using GCC as a C++ front-end and the SystemC library. The SystemC license can be found from www.systemc.org (And I've temporarily put a copy here: http://www-verimag.imag.fr/~moy/vrac/License.pdf ) I would like to know wether it is legal to distribute this software and wether it is possible to do so under a free license. The architecture of the software is as follow : ++ +-+ +-+ || | | | | | A | | B | | C | || | | | | | SystemC |--1--| My software |--2--| GCC | || | | | | ++ +-+ +-+ Where --n-- can be either a static or a dynamic link. I would like to use as permissive licenses as possible. Ideally, I would like the following : A = SystemC license B = LGPL C = GPL Is this possible ? (From what I understood, I can distribute A+B and let the user download C and compile A+B+C himself) So you are only distributing source? AIUI, that is acceptable. You'll have problems if you distribute binaries. Regards, Walter Landry [EMAIL PROTECTED]
Re: Mass bug filing: Cryptographic protection against modification
Steve Langasek writes: I have, however, never seen anyone actually argue that Debian should distribute a package of licenses -- they simply aren't useful to our users in their own right. A package of Free model licenses from which a programmer could choose would be at least as useful as some of the document packages we distribute. Note that I am not advocating such a package. I think such things belong on Web sites, not in Debian. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: reiser4 non-free?
Jeremy Hankins [EMAIL PROTECTED] writes: Brian Thomas Sniffen [EMAIL PROTECTED] writes: Hans Reiser [EMAIL PROTECTED] writes: A: No, credits describe the contribution made to a project. Ads describe a product someone wants you to buy. Ads are not the same as credits, and their preservation is not protected by this license. Debian's going to have to look really, really closely at every release of every piece of software under this license, then, and risk an argument -- in a courtroom -- with a copyright holder who considers some line to be a credit, or insufficiently prominent in its modified form. Fuzzy lines in a license are not a new thing. Debian isn't in the litigation business, so we're not going to be trying to push the boundaries anyway. Respecting the wishes of the author/licensor is a policy of ours -- remember the pine business. Q: What in this license prevents persons from making their name display excessively annoyingly throughout the running of the program? Isn't that a flaw in the license? A: The shovel doesn't stop the digger from creating a pit in the road that endangers other people. The license is a tool. Whether you make an ass out of yourself using it on the software you write is up to you. No compiler makes broken programs work In other words, some works under this license are free (for example, one containing no credits but the copyright notice) and others are non-free. Wouldn't such a work still be non-free? At the least, it definitely goes much farther than the analogous clause in the GPL. You can't include code (even optionally executed code) to suppress it, for example. If there are no credits, the prohibition on removing credits is null. -- Brian Sniffen [EMAIL PROTECTED]
Re: GFDL
MJ Ray said on Thu, May 06, 2004 at 11:37:26PM +0100,: What did you read? The various documentation from the FSF. Did you obtain it directly from FSF? No. I found all this in a Debian Woody CD From a friend. been less or more enlightening if you had the freedom to edit it? I would have got a very different idea about freedom if this friend had changed either the FSF's `political speech', or the Debian PM or DFSG and whatever else is in doc-debian and allied packages. That this friend had the freedom to modify the latter, but did not, is a different issue altogether. Maybe their aim is noble, but I believe their method is wrong. This My point is that it is not a question of `wrong' and `right'; just a different way of solving issues. weapon proliferation causes peace (because everyone is too scared to attack each other) or danger (because there is more chance of a mistake). How far should we restrict people's freedom in order to promote freedom? You have a point here. feel that the FSF does not currently represent my view on software Which is what the whole issue is about. FSF says `documentation is not software'. Debian says `whatever we carry in our CDs is software'. The problem for experienced users and advocates of the free software philosophy, like me (I'm speaking for myself *only*, as an individual, and not as a lawyer, which is what I do for a living) is that if Debian takes out what is `free documentation' for the FSF we loose a potent tool for spreading the concept. I would never have understood the real meaning of `free software' if the FSF's messages were not carried in a *Debian* CD, and I read them side-by-side with the documents in /usr/share/doc/*debian*. Does debian really want to deny future newbies a good intro to what free software is by taking out all this political speech from the /usr/share/doc? And all this `political speech' is very different and has to be treated differently from other `do not modify' documents like RFCs. I am reading this list for about two years now, and understand why Debian does not want invariant sections, (and also other issues with the GFDL). But I also understand the FSF's perspective; and the point is that both are right, in their own way. This is worrying, but not insurmountable. Yes. And somebody tells me that there was a meeting of this committee last month. And there was some progress on this issue. -- +~+ Mahesh T. Pai, LL.M., 'NANDINI', S. R. M. Road, Ernakulam, Cochin-682018, Kerala, India. http://paivakil.port5.com +~+
