Re: OSD DFSG convergence
On Mon, Jan 27, 2003 at 12:27:49AM -0500, Russell Nelson wrote: It's not a matter of being able to remove objectionable terms from the license; it's a matter of any license that contains such a term already failing to meet the requirements of the DFSG as we understand them, because the license must not unnecessarily restrict the creation of derived works. How does agreeing to a license restrict the creation of derived works? If you don't agree to the terms of the license, then you HAVE no freedom to create derived works. There's a lot of licenses that don't require a manifestation of assent. And yet the current case law says that you can't enforce a license unless you've actually formed a contract. The user has to realize that they're agreeing to a contract, and they have to do something which indicates that they agree with the contract. Hmm, I think there are two separate issues here: there's the EULA itself, which almost certainly violates the FSF's freedom zero (the freedom to use the software, even if the user doesn't agree with the license for redistribution and modification); and there's the license one must agree to in order to modify/distribute the software. There's no reason to assume that the two licenses are the same; indeed, it's a fair bet that, if click-wrap licenses of any kind are allowed, sooner or later someone will try to embed in their distribution license a requirement to present the user with a truly heinous EULA -- and they'll probably still try to call it free (or Open). It may have been an oversight that the DFSG never directly addressed freedom zero (it talks about non-discrimination against classes of users, but that doesn't mean the license can't be equally *bad* for all users). However, it does require that *developers* be free to modify the software; requiring developers to preserve the code that displays the clickwrap dialog box conflicts with this freedom. The net result is that freedom zero is protected by the DFSG so long as there are programmers who believe in protecting it. -- Steve Langasek postmodern programmer pgpZQyIvEVGGc.pgp Description: PGP signature
Problems in Open Source Licensing
Here is a paper that I presented at Linux.conf.au 2003, which a lot of people seemed to appreciate, and which is on-topic for this list: http://www.ilaw.com.au/public/licencearticle.html -- JEREMY MALCOLM [EMAIL PROTECTED] Personal: http://www.malcolm.id.au Providing online networks of Australian lawyers (http://www.ilaw.com.au) and Linux experts (http://www.linuxconsultants.com.au) for instant help! Disclaimer: http://www.terminus.net.au/disclaimer.html. GPG key: finger.
Re: Copyright(s) for roundup DFSG free?
On Sat, Jan 25, 2003 at 11:49:56AM +0100, Bastian Kleineidam wrote: Copyright (c) 2001 Bizar Software Pty Ltd (http://www.bizarsoftware.com.au/) This module is free software, and you may redistribute it and/or modify under the same terms as Python, so long as this copyright message and disclaimer are retained in their original form. What does under the same terms as Python mean? Different versions of Python have been published under different licenses. Is it the user's choice? Most restrictive? Least restrictive? Most recent? Most recent in 2001? I think this should be clarified. Richard Braakman
Re: [Discussioni] OSD DFSG convergence
[EMAIL PROTECTED], Nelson nelson@crynwr.com : and yet the DFSG does not admit the possibility of public-domain unlicensed software. strange, because the game Abuse is public domain and is part of Debian... + [EMAIL PROTECTED]:~€ cat /usr/share/doc/abuse-frabs/copyright This package was debianized by Arto Jantunen [EMAIL PROTECTED] on 20 Apr 2001 15:56:17 +0300. It was downloaded from http://www.cs.uidaho.edu/~cass0664/fRaBs Upstream Author: Justin Cassidy [EMAIL PROTECTED] Copyright: Public Domain + -- All the computers wait at the same speed . /\ ° Real Name: Lorenzo Petrone* WEB!!! http://lano.webhop.net \/ ·
Re: OSD DFSG convergence
On Mon, Jan 27, 2003 at 11:16:56AM +0100, Lo'oRiS il Kabukimono wrote: and yet the DFSG does not admit the possibility of public-domain unlicensed software. strange, because the game Abuse is public domain and is part of Debian... There's lots of public domain software in Debian; this was never in question. He's questioning whether the DFSG, as written, allows it. It seems to be a question based on the false idea that the DFSG is intended to be taken literally and without interpretation, though. The DFSG is fairly useless without being augmented by human judgement. -- Glenn Maynard
Re: acceptable restrictions on modification
On Sun, 26 Jan 2003 19:56:44 -0500, Branden Robinson [EMAIL PROTECTED] wrote: On Wed, Jan 22, 2003 at 02:12:49PM -0500, David Turner wrote: The GPL forbids removing code from interactive programs which displays copyright notices. Yes, and in my opinion this is a defect in the license. You mean this? | If the program is interactive, make it output a short notice like this | when it starts in an interactive mode: | | Gnomovision version 69, Copyright (C) year name of author | Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. | This is free software, and you are welcome to redistribute it | under certain conditions; type `show c' for details. This is not a part of GPL terms. -- Oohara Yuuma [EMAIL PROTECTED] Debian developer PGP key (key ID F464A695) http://www.interq.or.jp/libra/oohara/pub-key.txt Key fingerprint = 6142 8D07 9C5B 159B C170 1F4A 40D6 F42E F464 A695 Do not assume users will be motivated to read manuals --- The GNU Privacy Handbook
Re: [Discussioni] OSD DFSG convergence
Lo'oRiS il Kabukimono writes: [EMAIL PROTECTED], Nelson nelson@crynwr.com : and yet the DFSG does not admit the possibility of public-domain unlicensed software. strange, because the game Abuse is public domain and is part of Debian... I've no doubt. Still, where in the DFSG does it say that you can have unlicensed software (even if it's public-domain) in Debian? I'm not trying to be obstreperous, or cause trouble. I'm trying to point out that you're applying the DFSG in an arbitrary manner. We can't do that at OSI, so we need the OSD to cover these cases. If there is to be one document describing free and open software, it has to cover those cases. -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
Re: [Discussioni] OSD DFSG convergence
Scripsit Russell Nelson [EMAIL PROTECTED] Still, where in the DFSG does it say that you can have unlicensed software (even if it's public-domain) in Debian? It says so everywhere: The only thing that DFSG speaks about is what one *can't* have in Debain. Since none of those apply to public-domain software, the latter can be in Debian. Simple, eh? Another way of saying the same: The DFSG decribes which freedoms users and redistibutors must have in order for the software to be in Debian. Users and redistributors of public-domain software do have all those freedoms. I'm not trying to be obstreperous, or cause trouble. I'm trying to point out that you're applying the DFSG in an arbitrary manner. If you want to believe it's arbitrary, go right ahead. We can't do that at OSI, so we need the OSD to cover these cases. That's good for you, I suppose. Do you want Debian to do something about that? -- Henning Makholm Nemo enim fere saltat sobrius, nisi forte insanit.
Re: [Discussioni] OSD DFSG convergence
Henning Makholm writes: Scripsit Russell Nelson [EMAIL PROTECTED] Still, where in the DFSG does it say that you can have unlicensed software (even if it's public-domain) in Debian? It says so everywhere: The only thing that DFSG speaks about is what one *can't* have in Debain. Since none of those apply to public-domain software, the latter can be in Debian. Simple, eh? Foo on that. The DFSG says The license must allow modifications and derived works... If it's public domain, there *is* no license. The DFSG has a problem. It fails to admit that there is unlicensed software which belongs in Debian. Rather than amend it, you're interpreting its ambiguity to mean what you want. That's fine, but what do you do when someone comes along and interprets its ambiguity to mean what *they* want? And then they insist that their software MUST go into Debian. If you refuse, they will sue you for reliance (they created this software for this express purpose of putting it into Debian, relying on the DFSG to mean what it says, not what you say it says. You will harm their business if you refuse to go by the plain meaning of the DFSG). Maybe this hasn't happened yet. Maybe Debian isn't popular enough in the business community for it to happen. Maybe it will NEVER be popular enough in that community. Maybe it would be better to head them off at the pass and revise the DFSG. I'm not in any way saying that you must or should adopt the OSD's changes. I'm saying that you should fix problems in the DFSG rather than saying Well, if you interpret section X to mean that you can't rely on a GUI, therefore no license can use click-wrap. Another way of saying the same: The DFSG decribes which freedoms users and redistibutors must have in order for the software to be in Debian. Users and redistributors of public-domain software do have all those freedoms. The DFSG talks about licenses, not freedoms. If you want it to talk about freedoms, then it should talk about freedoms. We can't do that at OSI, so we need the OSD to cover these cases. That's good for you, I suppose. Do you want Debian to do something about that? Yes. I want there to be one and only one definition and set of guidelines. Why do you want two? What purpose can be served by having a difference? -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
Re: OSD DFSG convergence
Steve Langasek writes: Hmm, I think there are two separate issues here: there's the EULA itself, which almost certainly violates the FSF's freedom zero (the freedom to use the software, even if the user doesn't agree with the license for redistribution and modification); But the user does indeed have the freedom to use the software. They have a license that says so. It even includes a patent grant, which they don't have if they don't agree with the license. And agreeing with the license requires a manifestation of assent. And that manifestation of assent is click-wrap. What term of the DFSG *clearly* says that a license cannot require click-wrap? fair bet that, if click-wrap licenses of any kind are allowed, sooner or later someone will try to embed in their distribution license a requirement to present the user with a truly heinous EULA -- and they'll probably still try to call it free (or Open). And indeed, the DFSG allows click-wrap licenses. It may have been an oversight that the DFSG never directly addressed freedom zero Yup. Yet another thing that needs to be fixed -- in the OSD as well. the software; requiring developers to preserve the code that displays the clickwrap dialog box conflicts with this freedom. You already have to preserve code that displays the GPL's license notice. To misquote G.B. Shaw, we have established that Debian developers are willing to have their freedom restricted; Now we are trying to establish the limits. http://www-hoover.stanford.edu/main/uncommon/fall98/301.html -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
Re: [Discussioni] OSD DFSG convergence
On Mon, Jan 27, 2003 at 09:56:00AM -0500, Russell Nelson wrote: The DFSG has a problem. It fails to admit that there is unlicensed software which belongs in Debian. Rather than amend it, you're interpreting its ambiguity to mean what you want. That's fine, but what do you do when someone comes along and interprets its ambiguity to mean what *they* want? And then they insist that their software MUST go into Debian. If you refuse, they will sue you for reliance (they created this software for this express purpose of putting it into Debian, relying on the DFSG to mean what it says, not what you say it says. You will harm their business if you refuse to go by the plain meaning of the DFSG). ... Which would be complete and utter bullshit, because Debian has never represented, *anywhere*, that it will package all software someone releases under a DFSG-compliant license. Anyone who would sue Debian for such a reason is, prima facie, a litigious idiot who does not warrant consideration when evaluating whether Debian is exposing itself to lawsuits. -- Steve Langasek postmodern programmer pgpga1VqAnHBP.pgp Description: PGP signature
Re: OSD DFSG - different purposes
It seems to be a question based on the false idea that the DFSG is intended to be taken literally and without interpretation, though. The DFSG is fairly useless without being augmented by human judgement. This is the defining difference, to me, between the two documents. OSD is a definition, and is expected to be applied as literally as possible. DFSG are guidelines, and requre judgement to be applied. It could even be counterproductive to use the same document in different ways, as it might increase the number of people who say my software meets all your guidelines as I see them, you have to prove otherwise or distribute my software. Are there specific divides among the community you seek to address? It might be advantageous to examine some software that is OSD-free but not Debian-free, or vice versa, or to talk more generally about the motivation for amending differences in the documents. The answer may be to simply maintain a FAQ somewhere about the differences. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: [Discussioni] OSD DFSG convergence
Scripsit Russell Nelson [EMAIL PROTECTED] Foo on that. The DFSG says The license must allow modifications and derived works... If it's public domain, there *is* no license. If it's public domain, the license is anyone can do whatever he wants to it. The DFSG has a problem. I think you have an understanding problem. It fails to admit that there is unlicensed software which belongs in Debian. No it doesn't. That's fine, but what do you do when someone comes along and interprets its ambiguity to mean what *they* want? We tell them that they are free to interpret the DFSG whatever way they mean, but the interpretation that is going to be used for deciding to reject a package on license grounds is the one of the debian-legal consensus (or, failing to reach such a consensus, the ftpmasters and eventually the project leader). And then they insist that their software MUST go into Debian. Then we're going to get a good laugh. If you refuse, they will sue you for reliance And once more. I'm saying that you should fix problems in the DFSG You're inventing problems that aren't there. There are plenty of other, real, problems to fix if anybody cares enough about them to carry them through the flamefest any proposal to change so much as a comma will cause. Yes. I want there to be one and only one definition and set of guidelines. Why do you want two? We don't want two, we have only one. -- Henning Makholm Hører I. Kald dem sammen. Så mange som overhovedet muligt. Jeg siger jer det her er ikke bare stort. Det er Stortstortstort. Det er allerhelvedes stort. Det er historiEN.
Re: OSD DFSG - different purposes
Mark Rafn writes: Are there specific divides among the community you seek to address? Mostly the fact that some people get grumpy when we change the OSD. They express the concern that our community not be split -- and that everything which is open source is free software and vice-versa. That's my concern as well. It might be advantageous to examine some software that is OSD-free but not Debian-free, or vice versa, Does anybody know of any such software? -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
Re: OSD DFSG convergence
Scripsit Russell Nelson [EMAIL PROTECTED] What term of the DFSG *clearly* says that a license cannot require click-wrap? It doesn't say so clearly, but anyone who asks nicely (and sometimes also people who ask not-so-nicely) will get explained to them how click-wrap requirements are incompatible with the DFSG. And indeed, the DFSG allows click-wrap licenses. No it doesn't. A licence that enforces a click-wrap fails to grant the freedom of redistibution and modification that is explicitly required by the DFSG. The only point that is not spelled out explicitly is that the freedoms that are required must be available unconditionally - i.e., not on condition that one jumps through click-wrap hoops. -- Henning Makholm Den nyttige hjemmedatamat er og forbliver en myte. Generelt kan der ikke peges på databehandlingsopgaver af en sådan størrelsesorden og af en karaktér, som berettiger forestillingerne om den nye hjemme- og husholdningsteknologi.
Re: [Discussioni] OSD DFSG convergence
Henning Makholm writes: Yes. I want there to be one and only one definition and set of guidelines. Why do you want two? We don't want two, we have only one. You seem uninterested in compromise. I hope you do not carry the day. -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
Re: OSD DFSG convergence
Henning Makholm writes: A licence that enforces a click-wrap fails to grant the freedom of redistibution and modification that is explicitly required by the DFSG. What term of the DFSG says this? Should we go through the DFSG point by point? Free Redistribution The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale. Nothing in this prevents a license from requiring click-wrap. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. Nothing in this prevents a license from requiring click-wrap. Derived Works 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. Nothing in this prevents a license from requiring click-wrap. You can modify the software as much as you want. When you distribute the software, the terms of the license require that you acquire affirmative agreement with the license. Same terms. Integrity of The Author's Source Code The license may restrict source-code from being distributed in modified form _only_ if the license allows the distribution of patch files with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. (This is a compromise. The Debian group encourages all authors not to restrict any files, source or binary, from being modified.) Nothing in this prevents a license from requiring click-wrap. No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. Nothing in this prevents a license from requiring click-wrap. You could stretch this, as one peson suggested. If you do that, then you can say that the GPL discriminates against companies trying to sell software. No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. Nothing in this prevents a license from requiring click-wrap. No field of endeavor prevents someone from executing a license by clicking I agree. Distribution of License The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. Nothing in this prevents a license from requiring click-wrap. You're executing the license itself, not an additional license. License Must Not Be Specific to Debian The rights attached to the program must not depend on the program's being part of a Debian system. If the program is extracted from Debian and used or distributed without Debian but otherwise within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the Debian system. Nothing in this prevents a license from requiring click-wrap. License Must Not Contaminate Other Software The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be free software. Nothing in this prevents a license from requiring click-wrap. -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
Re: Bug#176267: ITP: mplayer -- Mplayer is a full-featured audioand video player for UN*X like systems
On Mon, Jan 27, 2003 at 05:41:00PM +0100, Gabucino wrote: I think it is unfortunate to disable media playing by default in one of the biggest Linux distributions in 2003, just because maybe some patent holder _may_ come and sue. I do understand your viewpoint. I just don't agree with it. There is no reason why this software cannot be used on Debian systems by Debian users, but it is unreasonable to expect Debian to assume the legal risk of distributing this software. In this case, 'Debian' includes CD vendors, mirror archive operators, and a lot of other intermediaries who may not even be aware of the legal situation. Surely you realize that we are not the only distribution taking this stance. For example: http://www.redhat.com/advice/speaks_80mm.html This is not idealism; it is self-preservation. With some other software packages, this problem is addressed by taking measures to only distribute such software from countries which do not honor software patents (the now-less-aptly-named non-US archive). However, this issue is generally unclear (at least to me) with regard to what can legally be used or distributed in which countries. afford a lawyer that can estimate the danger, but it is then still _risk_. Life is risky. Indeed, and individuals and organizations must manage their own risk. You cannot expect to coerce anyone else into taking a risk that they are not willing to accept. If you are willing to assume the risk, why not distribute Debian packages on the mplayer site? There are plenty of Debian developers willing to maintain such packages. -- - mdz
Re: OSD DFSG - different purposes
Scripsit Russell Nelson [EMAIL PROTECTED] Mark Rafn writes: It might be advantageous to examine some software that is OSD-free but not Debian-free, or vice versa, Does anybody know of any such software? If I remember correctly, there used to be a case with the Apple Public Source License, which the OSI certified as Open Source tm, whereas Debian didn't deem it DFSG-free. Yup, here it is. The APSL copy currently on opensource.org contains: | 2.2 You may use, reproduce, display, perform, modify and Deploy | Covered Code, provided that in each instance: ... | (c) You must make Source Code of all Your Deployed Modifications | publicly available under the terms of this License, including | the license grants set forth in Section 3 below, for as long as | you Deploy the Covered Code or twelve (12) months from the date | of initial Deployment, whichever is longer. You should | preferably distribute the Source Code of Your Deployed | Modifications electronically (e.g. download from a web site); This denies a user the right to make modifications and distribute the modified software (with source code) to his neighbour *without* also distributing it to the public at large. The consensus on debian-legal that this right is a sine qua non for DFSG-freedom is strong and well established. It also says | 12. Termination. | 12.1 Termination. This License and the rights granted hereunder will | terminate: ... | (c) automatically without notice from Apple if You, at any time | during the term of this License, commence an action for patent | infringement against Apple. which I take to mean that one who accepts the license must effectively give Apple a royalty-free license to use each an every patent he controls. This would be fair with us if it was restricted to patens related to the Covered Code, (and with some disagreement perhaps even if restricted to software patents) but no such restriction is in the language quoted. It even covers plain old honest-to-your-favorite-deity patents on mechanical or chemical devices. Furthermore, | 12.2 Effect of Termination. Upon termination, You agree to |immediately stop any further use, reproduction, modification, |sublicensing and distribution of the Covered Code and to destroy |all copies of the Covered Code that are in your possession or |control. which mentions stopping *use*. We object to the notion that one needs to to comply with specific terms simply to use the software (as opposed to modifying or distributing it). I seem to remember that there were also originally a you-must-follow-US-export-laws clause in the license originally certified by OSI, but that must have been removed since. [std.disclaimer: The above reflects my recollection of the case and my interpretation of the DFSG and the cited clauses. There are probably those on the list who disagree with me on specific points, and it's even conceivable that there's an actual consensus against my arguments that I've somehow overlooked or forgotten about]. -- Henning Makholm En tapper tinsoldat. En dame i spagat. Du er en lykkelig mand ...
Re: [Discussioni] OSD DFSG convergence
Steve Langasek writes: On Mon, Jan 27, 2003 at 09:56:00AM -0500, Russell Nelson wrote: what do you do when someone comes along and interprets its ambiguity to mean what *they* want? ... Which would be complete and utter bullshit, because Debian has never represented, *anywhere*, that it will package all software someone releases under a DFSG-compliant license. Has Debian ever rejected software which complies with the DFSG? If you do something in practice, other parties could rely on that. It's just like the private road which is never closed to the public. In time, it *becomes* public. Anyone who would sue Debian for such a reason is, prima facie, a litigious idiot who does not warrant consideration when evaluating whether Debian is exposing itself to lawsuits. I won't name names, but we (OSI) have been threatened with exactly that scenario. It is as I feared: the DFSG and OSD, although originally the same documents, and nearly identical now, are being used for two different and incompatible purposes. So, are you totally against the idea of changing the DFSG even though you probably can't find a single .deb on your machine that hasn't been touched in five years? There seems to be a firm resistance to the idea of changing the DFSG to reflect changing times. -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
Re: OSD DFSG - different purposes
Henning Makholm writes: This denies a user the right to make modifications and distribute the modified software (with source code) to his neighbour *without* also distributing it to the public at large. The consensus on debian-legal that this right is a sine qua non for DFSG-freedom is strong and well established. Where does it say this in the DFSG? which I take to mean that one who accepts the license must effectively give Apple a royalty-free license to use each an every patent he controls. Where does it say this in the DFSG? which mentions stopping *use*. We object to the notion that one needs to to comply with specific terms simply to use the software (as opposed to modifying or distributing it). Where does it say this in the DFSG? My point being that these requirements *should* be in the DFSG, not that you shouldn't come to that conclusion. I seem to remember that there were also originally a you-must-follow-US-export-laws clause in the license originally certified by OSI, but that must have been removed since. Yup, that was a major screw-up on our part. It's since been repaired by the replacement of it by the license you see now. -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
Re: OSD DFSG - different purposes
Different topic, differently reply. Henning Makholm writes: which mentions stopping *use*. We object to the notion that one needs to to comply with specific terms simply to use the software (as opposed to modifying or distributing it). A warranty disclaimer applies to users of the software. Every license with a warranty disclaimer (and that's all of them, AFAICS) is binding on the user. If you don't agree with the warranty disclaimer, you must stop using the software. Not only that, but you can't disclaim warranty without a contract. So, what meaning does the warranty disclaimer on the GPL have? Probably none. Does this translate into anything in reality? Probably not. It would be quite hard to enforce a warranty on someone giving away free software. On the other hand, wouldn't you really rather someone ELSE establish that precedent? -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
Re: OSD DFSG convergence
On Sun, Jan 26, 2003 at 12:55:05PM -0500, Russell Nelson wrote: Hi. I'm the vice-president of the Open Source Initiative, and I'm writing to you today in that stead. In another message, you asked if there were some substantive differences between the OSD and the DFSG. I can say, yes there are, even if not immediately visible at the surface. For one, I would point to clause 12.1(c) of the APSL. It states that your license to use any and all APSL code terminates if you ever commence an action for patent infringement against Apple. This, to me, is an onerous requirement -- if Apple has violated your patent, even in a completely unrelated matter, the fact that you exercise your legal right to defend your patent shouldn't impact your right to use Open Source software. Another example is the RealNetworks Public Source license, which discriminates based on personal use.
Re: OSD DFSG - different purposes
On Mon, Jan 27, 2003 at 01:26:39PM -0500, Russell Nelson wrote: Mark Rafn writes: It might be advantageous to examine some software that is OSD-free but not Debian-free, or vice versa, Does anybody know of any such software? Any software under this license[0] is non-free but is OSI Certified Open Source Software. I don't particularly remember why; you can search the archives, but the consensus was that it was non-free. We've found other such software, I think, but this was the most glaring, because several people were hoping that the license would be free (myself included). IANAL, IANADD. [0] http://www.opensource.org/licenses/real.php -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgpgOLj184Mv8.pgp Description: PGP signature
Re: OSD DFSG convergence
John Goerzen writes: On Sun, Jan 26, 2003 at 12:55:05PM -0500, Russell Nelson wrote: Hi. I'm the vice-president of the Open Source Initiative, and I'm writing to you today in that stead. In another message, you asked if there were some substantive differences between the OSD and the DFSG. I can say, yes there are, even if not immediately visible at the surface. For one, I would point to clause 12.1(c) of the APSL. It states that your license to use any and all APSL code terminates if you ever commence an action for patent infringement against Apple. This, to me, is an onerous requirement -- if Apple has violated your patent, even in a completely unrelated matter, the fact that you exercise your legal right to defend your patent shouldn't impact your right to use Open Source software. Actually, it *should*. Our community needs to etch out a patent-free space, and this is one way in which Apple has sought to implement that idea. But even if you disagree with me, how would you change the DFSG so that it agrees with you? Because I see nothing in the DFSG which keeps APSL code out of Debian. Another example is the RealNetworks Public Source license, which discriminates based on personal use. It's perfectly okay to give more freedoms to some people, as long as everyone has the necessary freedoms. The discrimination term was added to the DFSG to ensure that there would be no licenses of the form Anyone is free to use this software except people working on nuclear bombs. -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
Re: OSD DFSG convergence
On Mon, Jan 27, 2003 at 03:55:34PM -0500, Russell Nelson wrote: John Goerzen writes: requirement -- if Apple has violated your patent, even in a completely unrelated matter, the fact that you exercise your legal right to defend your patent shouldn't impact your right to use Open Source software. Actually, it *should*. Our community needs to etch out a patent-free space, and this is one way in which Apple has sought to implement that idea. I agree that software patents are a bad idea, but consider this: Let's say I work for Better Mice Inc, and my company develops plastic mouse moldings that are ergonomically comfortable and has a patent on the manufacturing process. If Apple chooses to violate Better Mice Inc's patent on plastic mouse moldings, then Better Mice Inc's right to use/distribute/modify APSL-licensed software goes down the drain if they choose to defend their patent. So, a totally unrelated circumstance could remove their ability to use APSL-licensed software. In a nutshell, you are handing over rights to all your patents to Apple if you use the software, but the license is quite explicit that Apple is not handing over rights to all their patents in exchange. But even if you disagree with me, how would you change the DFSG so that it agrees with you? Because I see nothing in the DFSG which keeps APSL code out of Debian. Clause 1 on free redistribution: The license of a Debian component may not restrict any party from selling or giving away the software If Better Mice Inc sues Apple over their plastic molding patent violation, then that party is restricted from selling or giving away the software. Further, a case could be made that it violates clase 5 (No discrimination against persons or groups) because it discriminates against people whom choose to file legal cases against Apple. Another example is the RealNetworks Public Source license, which discriminates based on personal use. It's perfectly okay to give more freedoms to some people, as long as everyone has the necessary freedoms. The discrimination term was added to the DFSG to ensure that there would be no licenses of the form Anyone is free to use this software except people working on nuclear bombs. This violates clause 6 in DFSG -- No discrimination against fields of endeavor. It even lists restrict the program from being used in a business as an example of a restriction that is not permissible. The Real license not only has that restriction, but talks at length about RD use only, etc, etc. It fails that clause in many ways.
Re: acceptable restrictions on modification
On Mon, Jan 27, 2003 at 06:53:28PM +0900, Oohara Yuuma wrote: The GPL forbids removing code from interactive programs which displays copyright notices. Yes, and in my opinion this is a defect in the license. You mean this? | If the program is interactive, make it output a short notice like this | when it starts in an interactive mode: | | Gnomovision version 69, Copyright (C) year name of author | Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. | This is free software, and you are welcome to redistribute it | under certain conditions; type `show c' for details. This is not a part of GPL terms. Yes, it is. 2c: 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.) -- Glenn Maynard
Re: OSD DFSG - different purposes
Brian M. Carlson writes: Any software under this license[0] is non-free but is OSI Certified Open Source Software. I don't particularly remember why; you can search the archives, but the consensus was that it was non-free. Hmmm... license-discuss vetted it against the OSD, but debian-legal turned it down under the DFSG even though the language for both is nearly identical. What annoys me about this process is that we *specifically* established license-discuss to keep this from happening. Perhaps I should be sending proposed licenses to debian-legal as well as license-discuss? -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
Re: OSD DFSG - different purposes
Henning Makholm [EMAIL PROTECTED] wrote: | 12. Termination. | 12.1 Termination. This License and the rights granted hereunder will | terminate: ... | (c) automatically without notice from Apple if You, at any time | during the term of this License, commence an action for patent | infringement against Apple. which I take to mean that one who accepts the license must effectively give Apple a royalty-free license to use each an every patent he controls. This would be fair with us if it was restricted to patens related to the Covered Code, (and with some disagreement perhaps even if restricted to software patents) but no such restriction is in the language quoted. It even covers plain old honest-to-your-favorite-deity patents on mechanical or chemical devices. FYI, the IBM Common Public License [1], which has been approved for Debian, has a similar clause which reads: If Recipient institutes patent litigation against a Contributor with respect to a patent applicable to software (including a cross-claim or counterclaim in a lawsuit), then any patent licenses granted by that Contributor to such Recipient under this Agreement shall terminate as of the date such litigation is filed. In addition, If Recipient institutes patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Program itself (excluding combinations of the Program with other software or hardware) infringes such Recipient's patent(s), then such Recipient's rights granted under Section 2(b) shall terminate as of the date such litigation is filed. It restricts it only to software licenses, but otherwise is very similar. I think the real problem with the APSL is the other points you mentioned. I thought the APSL had a click-wrap as well, but I guess they got rid of it. Regards, Walter Landry [EMAIL PROTECTED] [1] http://oss.software.ibm.com/developerworks/oss/license-cpl.html
Re: OSD DFSG - different purposes
Brian M. Carlson writes: On Mon, Jan 27, 2003 at 03:24:20PM -0500, Russell Nelson wrote: Henning Makholm writes: This denies a user the right to make modifications and distribute the modified software (with source code) to his neighbour *without* also distributing it to the public at large. The consensus on debian-legal that this right is a sine qua non for DFSG-freedom is strong and well established. Where does it say this in the DFSG? Debian has a strong common law tradition with regard to the DFSG. Fair enough, but do you really expect people to study the archives? For example, Google knows nothing about debian-legal RPSL, implying that you never discussed the RPSL. A search of the Subject: headers between last July and now shows no instance of RPSL, or Real. Why not change the DFSG? -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
Re: OSD DFSG - different purposes
On Mon, Jan 27, 2003 at 03:24:20PM -0500, Russell Nelson wrote: Henning Makholm writes: This denies a user the right to make modifications and distribute the modified software (with source code) to his neighbour *without* also distributing it to the public at large. The consensus on debian-legal that this right is a sine qua non for DFSG-freedom is strong and well established. Where does it say this in the DFSG? Debian has a strong common law tradition with regard to the DFSG. We interpret it in certain ways to protect people's freedoms. You might say that this discriminates against people that are on desert islands. Note that vim's license is acceptable even though that clause is in there because it states that if it is not possible to contact the maintainer to return modifications then the requirement ceases. which I take to mean that one who accepts the license must effectively give Apple a royalty-free license to use each an every patent he controls. Where does it say this in the DFSG? I'm not sure, but it's certainly atrocious. You might want to search the archives or wait about a day or so for some of the regulars to debate with you over it. which mentions stopping *use*. We object to the notion that one needs to to comply with specific terms simply to use the software (as opposed to modifying or distributing it). Where does it say this in the DFSG? US copyright law explicitly permits use. We generally do not approve licenses that attempt to take rights that user already has. If you want to get technical, forbidding use of such software would be in conflict with US law, and therefore would discriminate against people in the US. My point being that these requirements *should* be in the DFSG, not that you shouldn't come to that conclusion. I seem to remember that there were also originally a you-must-follow-US-export-laws clause in the license originally certified by OSI, but that must have been removed since. Yup, that was a major screw-up on our part. It's since been repaired by the replacement of it by the license you see now. That discriminated against people not in the US. If I am not in the US (which I am), then why should I have to abide by its laws? -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 Let us think the unthinkable, let us do the undoable. Let us prepare to grapple with the ineffable itself, and see if we may not eff it after all. --Douglas Adams pgp6fjdrnI6El.pgp Description: PGP signature
Re: OSD DFSG convergence
John Goerzen writes: In a nutshell, you are handing over rights to all your patents to Apple if you use the software, but the license is quite explicit that Apple is not handing over rights to all their patents in exchange. I don't think it's the best defense against patents, but it's *a* defense that helps the community. A better defense is that taken by the OSL and AFL: if you sue any developer claiming that the software violates one of your patents, you lose the right to use ALL software licensed under the OSL, AFL, and any other license with a similar clause. If Better Mice Inc sues Apple over their plastic molding patent violation, then that party is restricted from selling or giving away the software. Further, a case could be made that it violates clase 5 (No discrimination against persons or groups) because it discriminates against people whom choose to file legal cases against Apple. Sorry, but that's the Constitution's commerce clause all over again. Once you start using that clause that way, the DFSG may as well say Ugh. The Real license not only has that restriction, but talks at length about RD use only, etc, etc. It fails that clause in many ways. Take out the RD and personal use grants. Does it still comply with the DFSG? Now add them back. How is it possible for more freedom to make the software DFSG-nonfree? -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
Re: OSD DFSG convergence
On Mon, 2003-01-27 at 00:27, Russell Nelson wrote: Netscape v. Specht turned on exactly that issue. Netscape lost because they didn't make it clear to Specht that he was agreeing to a contract. IIRC, Netscape v. Specht concerned rights outside the exclusive rights of the copyright holder, so it's completely irrelevant. -- -Dave Turner Stalk Me: 617 441 0668 On matters of style, swim with the current, on matters of principle, stand like a rock. -Thomas Jefferson
Re: OSD DFSG - different purposes
It seems to be a question based on the false idea that the DFSG is intended to be taken literally and without interpretation, though. The DFSG is fairly useless without being augmented by human judgement. Obviously. The question is how much augmenting is necessary. For example, if you have no limit on the amount of interpretation you wish to make of the DFSG, then the whole of the DFSG could be: ``Ogg say Ugh''. I understand the attraction behind bending the DFSG to your will. Do you understand why I think the DFSG should say what you take it to mean? Do you understand why I want the OSD to say the same thing? -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
Re: [Discussioni] OSD DFSG convergence
ma, 27-01-2003 kello 22:09, Russell Nelson kirjoitti: Has Debian ever rejected software which complies with the DFSG? If you do something in practice, other parties could rely on that. It's just like the private road which is never closed to the public. In time, it *becomes* public. I don't know of any free software that has been rejected from Debian, though my memory is what it's always been, bad. However, since every time a package is added to Debian, it requires effort on the behalf of individuals, if no individual wants to put in the effort, nothing happens. I doubt that even such a lawer-happy society as the USA can require people to put in such effort involuntarily. If I brush off the snow from the stairs in my apartment building every day, without compensation, and one day stop, no sane court is going to require me to start doing it again. (Sorry about the analogy.) Anyone who would sue Debian for such a reason is, prima facie, a litigious idiot who does not warrant consideration when evaluating whether Debian is exposing itself to lawsuits. I won't name names, but we (OSI) have been threatened with exactly that scenario. It is as I feared: the DFSG and OSD, although originally the same documents, and nearly identical now, are being used for two different and incompatible purposes. Like someone else already said, the OSD is a definition that others can use to decide whether their license makes their software open source or not. The DFSG is a set of guidelines, not quite a definition, that *Debian* uses to decide whether something is acceptable to be added to Debian or not. So, are you totally against the idea of changing the DFSG even though you probably can't find a single .deb on your machine that hasn't been touched in five years? There seems to be a firm resistance to the idea of changing the DFSG to reflect changing times. If there are any real problems in the DFSG, I'm sure Debian developers will change the DFSG to fix them. Debian is, however, governed by flame-war-cum-consensus, so expect things to be quite hot in the mean while. :) (I haven't been convinced that the potential problems you've pointed out so far are real problems, but it might be good to clarify the DFSG about them anyway.)
Re: OSD DFSG - different purposes
Mark == Mark Rafn [EMAIL PROTECTED] writes: It seems to be a question based on the false idea that the DFSG is intended to be taken literally and without interpretation, though. The DFSG is fairly useless without being augmented by human judgement. Mark It could even be counterproductive to use the same document Mark in different ways, as it might increase the number of people Mark who say my software meets all your guidelines as I see Mark them, you have to prove otherwise or distribute my Mark software. Except I can see these people's point. If I were a company that was being disadvantaged because I could not get what I believed to be DFSG-free software in Debian, I'd certainly look at options to make people who I thought were being unreasonable reinterprit DFSG. I'd start with options within the project including going up to the level of getting a GR passed if necessary. But if I thought the project was being unreasonable in interpreting its social contract, I would certainly consider action against people charged with upholding that contract.
Re: [Discussioni] OSD DFSG convergence
On Mon, Jan 27, 2003 at 09:56:00AM -0500, Russell Nelson wrote: what do you do when someone comes along and interprets its ambiguity to mean what *they* want? We patiently explain that DSFG are guidelines to Debian about what to include, not a litmus test for authors to use to skirt our requirement that Debian stays free. Sometimes this results in an improved license, often it results in a flamewar. So far it has not resulted in a lawsuit, nor do I think it likely to. On Mon, 27 Jan 2003, Russell Nelson wrote: Has Debian ever rejected software which complies with the DFSG? If you do something in practice, other parties could rely on that. It's just like the private road which is never closed to the public. In time, it *becomes* public. Debian has rejected packages which the copyright holder believed complied with the DSFG. We've rejected packages that appear to comply, but the copyright holder has an odd interpretation of its license. There's certainly software not in Debian whose freedom is unquestioned. I won't name names, but we (OSI) have been threatened with exactly that scenario. It is as I feared: the DFSG and OSD, although originally the same documents, and nearly identical now, are being used for two different and incompatible purposes. It sounds that way. I wish you well, but do not have high hopes, for you to come up with a true operational definition of free software. Heh, and then folks will ask what about non-software things like documentation and images? So, are you totally against the idea of changing the DFSG even though you probably can't find a single .deb on your machine that hasn't been touched in five years? There seems to be a firm resistance to the idea of changing the DFSG to reflect changing times. Personally, I'm not against seeing the DSFG changed to make it clearer, to remove loopholes, etc. However, it's very hard to do so, both politically within Debian (for good reason) and intellectually to come up with such verbiage. I _DO_ object to changing it's use to be a binding definition rather than a set of guidelines. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: acceptable restrictions on modification (was: proposed licence change for moodle)
On Sun, 2003-01-26 at 19:56, Branden Robinson wrote: On Wed, Jan 22, 2003 at 02:12:49PM -0500, David Turner wrote: Unfortunately, DFSG doesn't discuss what sorts of modifications can be restricted. Implicitly, no sort of restriction on modification is permitted, except those already mandated by copyright law (removing someone's copyright notices can infringe their copyright, and usually does according to the terms of most copyright licenses). All modifications are restricted by copyright law, except those which constitute fair use or are otherwise excepted. Removing copyright notices are in no way special, and in no Berne jurisdiction are copyright notices required. Restrictions on modifications that already happen to exist in the licenses that the DFSG already explicitly identifies as satisfying meeting Debian's definition of Free Software also are implicitly regarded as acceptable. This seems fundamentally arbitrary -- we've screwed up before, so let's keep screwing up. Of course, the reason for this is that rejecting restrictions on modification requires rejecting nearly all software. In my view, a compromise should be worked out based on ideology and practicality, rather than tradition. The Apache license restricts modifications that *don't* also modify the name. Yes, and in my opinion this is a defect in the license. I see it as a defect mainly because it's (a) potentially unweildy and (b) incompatible the licenses of most other Free Software. But I can see the reason for it, and indeed, have heard of people being bitten by bug reports for modified versions of their software (which I think is the main concern of the Apache people). The GPL forbids removing code from interactive programs which displays copyright notices. Yes, and in my opinion this is a defect in the license. I disagree with this. Certainly, the presence of these strings has been immeasurably helpful in finding other GPL violations (although a determined violator would simply remove them, most violators are not willful but ignorant). And many authors think that this does not go far enough -- for instance, Zach Smith recently changed the license for future versions of his Beest and UnRTF software because he didn't want them renamed. I think Smith goes too far, but I do think that a little credit is hardly out of line. I can't imagine a case where I might want to remove these credits -- there's no embedded application that cares about a few kbytes these days. So, I see it as an acceptable restriction. The AGPL forbids removing code which makes the source code available to users of the software. Yes, and in my opinion this is a defect in the license. Here, I again disagree -- and this is the key point, because the other licenses you'll accept even though you feel they're defective, because (1) Debian strongly requires the software or (2) you want to not change past decisions. Neither of these seem to be very strong reasons. The Microsoft Word EULA forbids all changes. Yes, and in my opinion this is a defect in the license. Mine too. Which of these are acceptable depends on where you want to draw the line. I would argue that any restriction on modification must serve a compelling Free Software interest unrelated to restrictions on modification, and be the least restrictive means possible of accomplishing its goal. I know that this is a rather American way of putting it, but it's hard to overcome my upbringing. The judgement of what is and is not a compelling Free software interest is quite subjective and slippery. RMS apparently feels that the Invariant Sections mentioned in the GNU FDL serve a compelling Free Software interest. RMS doesn't make decisions for Debian. You and I disagree, and have reasoned arguments for it. For instance, a less restrictive means would be to allow Invariant Sections to be removable. A slippery standard is better than an arbitrary standard or no standard at all. Debian will judge licenses on a case-by-case basis anyway, so an arbitrary standard doesn't save any work. And this standard (well, with s/Free Software/something else/) is used by another famous organization to judge compliance with a much more important standard than DFSG. As much feedback during the FSF's public comment period on GNU FDL 1.2 revealed, there are many people who disagree with his calculus. Indeed, and nobody is suggesting that Richard's word be accepted as gospel. I've written to the FSF's board about the FDL. Have you? On the other hand, I notice that the FDL'd glibc-doc, at least, is still in Debian main... Letting users of software get at the source code (which is the aim of the AGPL's (2)(d)) is certainly such a compelling interest. Certainly, but placing shackles on people's freedom to reuse the source code is perhaps not the best way to achieve such an end. The GNU GPL itself demonstrates other ways to serve this
Re: OSD DFSG convergence
Russell == Russell Nelson [EMAIL PROTECTED] writes: Russell But even if you disagree with me, how would you change Russell the DFSG so that it agrees with you? Because I see Russell nothing in the DFSG which keeps APSL code out of Debian. The standard argument seems to be that Apple's requirements to publish any modified code that is deployed violate fields of endeavor by discriminating against people without net access or who cannot make their work public. I find this argument somewhat shaky.
Re: Copyright(s) for roundup DFSG free?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Jan 27, 2003 at 10:43:14AM +0200, Richard Braakman wrote: On Sat, Jan 25, 2003 at 11:49:56AM +0100, Bastian Kleineidam wrote: Copyright (c) 2001 Bizar Software Pty Ltd (http://www.bizarsoftware.com.au/) This module is free software, and you may redistribute it and/or modify under the same terms as Python, so long as this copyright message and disclaimer are retained in their original form. What does under the same terms as Python mean? Different versions of Python have been published under different licenses. Is it the user's choice? Most restrictive? Least restrictive? Most recent? Most recent in 2001? I think this should be clarified. Richard Braakman I asked upstream about this and he will release a revised copyright replacing Python with the Python Software Foundation license (which is GPL compatible and DFSG free). Thanks for your help, Bastian - -- Bastian Kleineidam Atombombe · Plutonium · Fat Man · Do it Yourself · Tim Taylor -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+NcQaeBwlBDLsbz4RAuUuAKDJcrnAtaONDg9CDOVxbmQUy7yH1gCfTdWW wKDX5AlJV/SeBbI9uFypG44= =AzRW -END PGP SIGNATURE-
Re: OSD DFSG convergence
On Mon, Jan 27, 2003 at 05:08:15PM -0500, Russell Nelson wrote: John Goerzen writes: In a nutshell, you are handing over rights to all your patents to Apple if you use the software, but the license is quite explicit that Apple is not handing over rights to all their patents in exchange. I don't think it's the best defense against patents, but it's *a* defense that helps the community. A better defense is that taken by the OSL and AFL: if you sue any developer claiming that the software violates one of your patents, you lose the right to use ALL software licensed under the OSL, AFL, and any other license with a similar clause. I don't think this makes sense either. If you are, say, GE and you have activities ranging from software development to freight locomotive manufacturing, surely you are not asserting that it is good to force them to choose between defending their locomotive manufacturing patent or using a given set of software? Further, a case could be made that it violates clase 5 (No discrimination against persons or groups) because it discriminates against people whom choose to file legal cases against Apple. Sorry, but that's the Constitution's commerce clause all over again. Once you start using that clause that way, the DFSG may as well say Ugh. I don't follow, can you explain? The Real license not only has that restriction, but talks at length about RD use only, etc, etc. It fails that clause in many ways. Take out the RD and personal use grants. Does it still comply with the DFSG? Now add them back. How is it possible for more freedom to make the software DFSG-nonfree? Because the freedom is distributed unevenly. DFSG states that there must not be discrimination. If there is -- that is, if different people/groups get different levels of freedom -- then it is not DFSG-free. I think this is a Good Thing, too. I should be able to do one thing with software if I do it in my spare time and another if I do it with my small business. -- John
Re: OSD DFSG - different purposes
Are you reading the list? I'll CC you on this message (deviating, for the moment, from list policy of not CCing without request, and hiding from Branden); if you don't want CCs, let me know. (If you do, you should add a Mail-Followup-To header.) On Mon, Jan 27, 2003 at 04:58:01PM -0500, Russell Nelson wrote: Fair enough, but do you really expect people to study the archives? For example, Google knows nothing about debian-legal RPSL, implying that you never discussed the RPSL. The correct way of finding out if a license is DFSG-free is to ask debian-legal. People frequently do this, even for very simple, BSD-ish licenses (and cases that don't require discussion--the majority--generally get a reply very quickly). A search of the Subject: headers between last July and now shows no instance of RPSL, or Real. http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00448.html RealNetworks is in the subject, and the search on lists.debian.org doesn't find partial matches by default. I don't know why Google doesn't have that indexed. Why not change the DFSG? There have been several good reasons explained for leaving the DFSG as a set of human guidelines, rather than a word-strict block of legalese that attempts to remove all human judgement from the equation. I can't find them at the moment, though, and I'll leave the explanation to someone who can do so better than I can. Even if this was done, DFSG freeness isn't a guarantee that a package will be included in Debian. For example, a game with half a gigabyte of data, all of which is DFSG-free, would most likely not be included in Debian; and software which has no interested Debian developer is unlikely to get into the archive. DFSG-freeness is necessary, but not always sufficient. -- Glenn Maynard
Re: OSD DFSG convergence
John == John Goerzen [EMAIL PROTECTED] writes: John On Mon, Jan 27, 2003 at 05:08:15PM -0500, Russell Nelson Take out the RD and personal use grants. Does it still comply with the DFSG? Now add them back. How is it possible for more freedom to make the software DFSG-nonfree? John Because the freedom is distributed unevenly. DFSG states John that there must not be discrimination. If there is -- that John is, if different people/groups get different levels of John freedom -- then it is not DFSG-free. For the record I would like to state that I cannot be part of a consensus for this interpretation of the DFSG. I do not wish to discuss this point now but would be happy to discuss this point at any future time when a specific package comes before this list. I'm also happy to discuss now off-list; it just seems pointless to waste list traffic on a side discussion when the purpose of the list is for license review.
Re: OSD DFSG convergence
On Sun, Jan 26, 2003 at 09:54:54PM -0500, Russell Nelson wrote: Simon Law writes: Public domain software that is unlicensed does not have the protection of copyright law. Therefore, it is likely to meet all the DFSG criteria. How can it? There is no license, so how can it meet #3 Derived Works? I'm not being trivial and pointless here, I'm being careful. Ah... I see that you are being pedantic. Thankfully, the DFSG is not a legal document; so although it is a literal interpretation, any sane Debian Developer will realise that public domain software needs no license whatsoever to meet all other DFSG criteria. Notice that I was careful in not specifying that it would meet OSD criteria. Your world and ours is ever so slightly different. Simon
Re: OSD DFSG convergence
On Mon, Jan 27, 2003 at 04:53:16PM +0200, Antti-Juhani Kaijanaho wrote: On 20030126T194352-0500, Branden Robinson wrote: On Sun, Jan 26, 2003 at 10:57:01PM +0200, Antti-Juhani Kaijanaho wrote: Also, there is -- again in the U.S. -- such a thing as an uncopyrightable work, and such things can be in the public domain[1]. Sure there are uncopyrightable works. There are such things in Finland, too. I was explicitly limiting myself to software, for which I am not aware of any uncopyrightability. The Debian distribution contains things that aren't software, like word lists, and some of things are neither software nor subject to copyright law (in the U.S.). If it is not software, then it is not public-domain software. (I even remember past discussions on Debian lists, perhaps even this one, where it was debated whether the DFSG, _software_ guidelines, apply to such works.) It seems that the Debian community also attempts to shoehorn the DFSG into non-software situations. Granted that this is sub-optimal since we argue endlessly over semantics; but the end results are decent. Simon
Re: [Discussioni] OSD DFSG convergence
On Mon, Jan 27, 2003 at 03:09:40PM -0500, Russell Nelson wrote: Steve Langasek writes: On Mon, Jan 27, 2003 at 09:56:00AM -0500, Russell Nelson wrote: what do you do when someone comes along and interprets its ambiguity to mean what *they* want? ... Which would be complete and utter bullshit, because Debian has never represented, *anywhere*, that it will package all software someone releases under a DFSG-compliant license. Has Debian ever rejected software which complies with the DFSG? If you do something in practice, other parties could rely on that. Oh, absolutely. On grounds of licensing? Maybe, maybe not. Either way, there is nothing that can reasonably be construed as imposing an obligation on Debian to distribute all software that meets the DFSG. The DFSG spells out conditions that are necessary, but not sufficient, for software to enter the main archive. I won't name names, but we (OSI) have been threatened with exactly that scenario. It is as I feared: the DFSG and OSD, although originally the same documents, and nearly identical now, are being used for two different and incompatible purposes. Why is this to be feared? The ability to employ human judgement in deciding what software should be included in our archive is an *asset*, not a weakness; just as, where the mission of the OSI is concerned, being held to a position of neutrality is an asset. There's nothing wrong with the fact that the two organizations need documents that can be applied in slightly different manners; working towards a shared definition of freedom doesn't require marching in lockstep. So, are you totally against the idea of changing the DFSG even though you probably can't find a single .deb on your machine that hasn't been touched in five years? There seems to be a firm resistance to the idea of changing the DFSG to reflect changing times. I had hoped that my earlier messages conveyed that I was not opposed to changing the DFSG; but such changes are doomed to be delayed by Debian's current lack of process for revising our core documents. If we are going to start down that long road we must first be able to articulate *why* the change is necessary, or we'll never move the body of developers to action on what amounts to a purely political issue. Regards, -- Steve Langasek postmodern programmer pgp4MmRoGmxm0.pgp Description: PGP signature
Re: OSD DFSG convergence
On Mon, Jan 27, 2003 at 05:56:15PM -0600, John Goerzen wrote: The Real license not only has that restriction, but talks at length about RD use only, etc, etc. It fails that clause in many ways. Take out the RD and personal use grants. Does it still comply with the DFSG? Now add them back. How is it possible for more freedom to make the software DFSG-nonfree? Because the freedom is distributed unevenly. DFSG states that there must not be discrimination. If there is -- that is, if different people/groups get different levels of freedom -- then it is not DFSG-free. I think this is a Good Thing, too. I should be able to do one thing with software if I do it in my spare time and another if I do it with my small business. I can't bring myself to agree with this position. With almost *all* free software licenses, the copyright holder continues to enjoy preferential status; does this make them non-free? Licensed are judged to be free if they provide certain freedoms to all users. This doesn't require that they treat everyone equally in other respects. -- Steve Langasek postmodern programmer pgpYIn3oKmlT9.pgp Description: PGP signature
Re: OSD DFSG convergence
John Goerzen writes: On Mon, Jan 27, 2003 at 05:08:15PM -0500, Russell Nelson wrote: Further, a case could be made that it violates clase 5 (No discrimination against persons or groups) because it discriminates against people whom choose to file legal cases against Apple. Sorry, but that's the Constitution's commerce clause all over again. Once you start using that clause that way, the DFSG may as well say Ugh. I don't follow, can you explain? Every license that has any interesting terms discriminates. The GPL discriminates against people who don't want to give away their code. The APSL discriminates against people who don't want to give away their patents. The RPSL discriminates against people who want to keep modifications private, even though they have been distributed within their organization. The Apache License discriminates against people who want to call their modified web server Apache. The MIT license discriminates against embedded system creators. And on and on. If you use this clause in the manner you suggest, then many licenses would become DFSG-nonfree even though a reasonable person would call them free software licenses. Take out the RD and personal use grants. Does it still comply with the DFSG? Now add them back. How is it possible for more freedom to make the software DFSG-nonfree? Because the freedom is distributed unevenly. Where in the DFSG does it say THAT? Sheesh! And you guys seem to think there aren't any problems with the DFSG. Sure there aren't! That's because you've already amended the DFSG in your own minds. Well how about the rest of us who aren't mind-readers? How about putting these conclusions into the DFSG? Lemme put it to you this way: if you can't get the membership of Debian to agree to amend the DFSG so it says X, then what right do you have to interpret the DFSG as meaning X? If the Debian membership doesn't agree that the DFSG should say X, then you have no standing to say that it means X. -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
Re: OSD DFSG - different purposes
Glenn Maynard writes: http://lists.debian.org/debian-legal/2002/debian-legal-200207/msg00448.html Thanks. Why not change the DFSG? There have been several good reasons explained for leaving the DFSG as a set of human guidelines, rather than a word-strict block of legalese that attempts to remove all human judgement from the equation. I'm not saying that it's possible to remove all human judgement. If it were ever possible to do that, then we could put judges out of business. It *is* possible, though, to change the DFSG to cause it to more closely resemble the case law that debian-legal has developed. The problem with relying on human judgement is that it can be arbitrary. If Microsoft came to Debian and said Would you accept this software licensed under the Microsoft Public License? would you be able to make a judgement which is not only not arbitrary, but which could be *seen* to be non-arbitrary? If you want to make judgements on things which aren't in the DFSG, how can you not be seen as arbitrary? -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
Re: OSD DFSG convergence
Sam Hartman writes: Russell == Russell Nelson [EMAIL PROTECTED] writes: Russell But even if you disagree with me, how would you change Russell the DFSG so that it agrees with you? Because I see Russell nothing in the DFSG which keeps APSL code out of Debian. The standard argument seems to be that Apple's requirements to publish any modified code that is deployed violate fields of endeavor by discriminating against people without net access or who cannot make their work public. I find this argument somewhat shaky. Indeed. There is no reason why someone cannot publish their source code through an entity which promises to publish the code, keep secret the author of the code, AND in the case of a lawsuit, serve to identify the author as having published their code. -- -russ nelson http://russnelson.com | You get prosperity when Crynwr sells support for free software | PGPok | the government does less, 521 Pleasant Valley Rd. | +1 315 268 1925 voice | not when the government Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | does something right.
