Things we agree on about the GPL
I thought I'd take a different tack for a minute and write about things that Raul and I (and other current debian-legal participants) seem to agree on about the GPL, and seem to think (though most of us are not lawyers) are well founded in law. 1. GPL release is not release into the public domain. There is appellate precedent for this in the US and civil court precedent in Germany. Copyright in works offered under the GPL is retained by the author, his or her employer, or an assignee, and ultimately it is this retention of copyright that gives GPL enforcement efforts their teeth. 2. GPL release on the Internet, if done under legitimate authority in the first place, is hard to undo. Caveat: there is not really very strong language in the GPL to indicate a perpetual term, and there are jurisdictions where a contract with no explicit term may be terminated at will. However, it's going to be relatively hard for a copyright holder to claim that they did voluntarily license works under the GPL, and did seek their wide distribution via the Internet, but did not intend to create a basis for reliance on a perpetual term for the license to copy and to create derivative works. 3. There is a large category of derivative works that the GPL legitimately offers license to create and distribute, solely on the conditions of source code release discussed in Section 3; we generally agree that the Debian-packaged version of a given GPL work is such a derivative work. There is also a large category of collections containing GPL works, authorized by the mere aggregation clause or otherwise, which are not obliged to be offered exclusively under the GPL; we generally agree that distro CDs are in this category. When such a collection is offered, the GPL obligation to offer source has full force with respect to the individual GPLed components. 4. There are some moral rights of the author that are more or less universally recognized (such as the right to truthful attribution) and others that apply in some jurisdictions but not others. Wherever these rights exist, they are reserved to the author (not the copyright holder) and cannot be contracted away. They are, in a sense, outside the copyright calculus, and may provide an independent mechanism for obtaining redress for some abuses. Applying them to software is, however, a bit of a stretch, both in the EU and in the US (where they are in any case technically recognized but only quasi-implemented; see http://aic.stanford.edu/jaic/articles/jaic36-02-006_3.html ). 5. There is some cause for long-term worry about termination of license by a primary author's heirs under US copyright law. I worry about this less than some others seem to, since as I read it (for example) the only person who could obtain a valid registration of copyright on the Linux kernel in the US is Linus Torvalds; see Aalmuhammed v. Lee ( http://caselaw.lp.findlaw.com/data2/circs/9th/9955224.html ) for why. Note that this is not necessarily inconsistent with Harald Welte's success in obtaining copyright registration in Germany for the netfilter subsystem and prosecuting it successfully, as civil law countries seem to handle joint works differently, and in any case the validity of his copyright was probably not contested on degree of authorship grounds by the defendants. I hope this will help avoid misunderstandings such as MKE says that A+B+C is an uncopyrightable collection! Does that mean he thinks copyright on A, B, and C is voided by combining them? Would someone care to contribute the next few points of agreement? Cheers, - Michael
Re: DRAFT: debian-legal summary of the QPL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Garrett [EMAIL PROTECTED] wrote: QPL requirement: if you pass on binaries, you must pass on source to both the recipient and upstream. You claim this is a fee. Well, this is non-free as upstream may have died, and if you can't distribute without distributing to upstream, it makes forking impractical too. If upstream is dead then you're fully knackered though. GPL requirement: if you pass on binaries, you must pass on source to the recipient. You claim this is not a fee. Well, the recipient can't be dead, otherwise they wouldn't be a recipient :) I entirely fail to understand the difference here. In both cases I have had to pass something of value on to people I might not have wanted to pass it on to. If you don't want to pass it on, don't put it under a Free Software licence *grin*. (Or use the BSD style licences). - -- Brett Parker web: http://www.sommitrealweird.co.uk/ email: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCkYkXEh8oWxevnjQRAhEXAKC0z8k8qd/CvpZ3B3KBFt23xYkREQCgw/eM NUVpX9kAxFRiU1Yyj3UnPUI= =7lo/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DRAFT: debian-legal summary of the QPL
Brett Parker [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Garrett [EMAIL PROTECTED] wrote: QPL requirement: if you pass on binaries, you must pass on source to both the recipient and upstream. You claim this is a fee. Well, this is non-free as upstream may have died, and if you can't distribute without distributing to upstream, it makes forking impractical too. If upstream is dead then you're fully knackered though. The clause in question is: If the items are not available to the general public, and the initial developer of the Software requests a copy of the items, then you must supply one. If upstream is dead, it's a bit difficult for them to request a copy. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DRAFT: debian-legal summary of the QPL
On Mon, May 23, 2005 at 09:23:57AM +0100, Matthew Garrett wrote: Brett Parker [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Garrett [EMAIL PROTECTED] wrote: QPL requirement: if you pass on binaries, you must pass on source to both the recipient and upstream. You claim this is a fee. Well, this is non-free as upstream may have died, and if you can't distribute without distributing to upstream, it makes forking impractical too. If upstream is dead then you're fully knackered though. The clause in question is: If the items are not available to the general public, and the initial developer of the Software requests a copy of the items, then you must supply one. If upstream is dead, it's a bit difficult for them to request a copy. Consider the case where 'upstream' refers to several hundred distinct entities. It's the BSD advertising clause disaster all over again... -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: DRAFT: debian-legal summary of the QPL
Andrew Suffield [EMAIL PROTECTED] wrote: Consider the case where 'upstream' refers to several hundred distinct entities. It's the BSD advertising clause disaster all over again... I don't think anyone is claiming that it's a good license. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RES: What makes software copyrightable anyway?
On 5/23/05, Michael K. Edwards [EMAIL PROTECTED] wrote: at the time that I picked Perl and 1-2-3 as examples. But perhaps we should regroup and identify the things we agree on (see separate thread) and the extent to which other gaps have narrowed. I'll need to think about that some, but I think there are some obvious points you missed. (For example, that contract law can and will be used in resolving ownership issues in copyright cases.) However, I don't really have your flair for long description. My leanings are more towards concise statements. Anyways, I'll see if I can come up with some other points of agreement. (Many of your statements are statement I agree with if they're phrased as possibilities rather than in always applicable to everything form -- that is, if they're rephrased to assert existence rather than universality.) On 5/21/05, Raul Miller [EMAIL PROTECTED] wrote: That's certainly true of Lotus v. Borland. However, if you look at the cases from video game space, you will see lots of other permutations: game developers using fair means or foul to defeat console makers' efforts to impose onerous contract terms (Sega v. Accolade and Atari v. Nintendo), emulator developers leveraging the availability of games authored for an existing console (Sony v. Connectix and Sony v. Bleem), and one publisher distributing add-ons for another's game (Micro Star v. FormGen). One thing these cases share is that the alleged infringers were not distributing the game software which was being infringed on. If we draw an analogy between these cases and a dynamic linking case, a parallel would be cases where the dynamically linked library was not being distributed by the alleged infringer. The court didn't make a point of that here, but I think it is significant. More generally, this ties back to the concept of thin derivative works vs thick works. (Which I think is an important concept when talking about the scope of coverage by a copyright.) I'm unfamiliar with this concept. What makes a derivative work thick or thin? Consider Transwestern v. Multimedia http://caselaw.lp.findlaw.com/cgi-bin/getcase.pl?court=10thnavby=caseno=966371 The mere fact that a work is copyrighted does not mean that every element of the work may be protected. Feist , 499 U.S. at 348 . Determining whether an infringement of a compilation copyright has occurred is particularly difficult where less than the entire work is copied, BellSouth Advertising Publ'g Corp. v. Donnelley Information Publ'g, Inc. , 999 F.2d 1436, 1438 (11th Cir. 1993) (en banc), especially when a competitor can take the bulk of the factual material from a preexisting compilation without infringement. Id. at 1445. The protection available for a compilation is thin. ... Although a compilation gains copyright protection with only minimal creativity in the selection and arrangement of facts, Feist 's statement that the copyright is thin has implications when the holder sues an alleged infringer. It would seem to follow analytically that more similarity is required when less protectible matter is at issue. Thus, if substantial similarity is the normal measure required to demonstrate infringement, `supersubstantial' similarity must pertain when dealing with `thin' works. 4 Melville B. Nimmer David Nimmer, Nimmer on Copyright , § 13.03[A] at 13-28 (1997); see also Apple Computer, Inc. v. Microsoft Corp. , 35 F.3d 1435, 1439 (9th Cir. 1994) (When the range of protectible and unauthorized expression is narrow, the appropriate standard for illicit copying is virtual identity.), cert. denied , 115 S. Ct. 1176 (1995); Jane C. Ginsburg, No Sweat? Copyright and Other Protection of Works of Information After Feist v. Rural Telephone , 92 Colum. L. Rev. 338, 349 (1992) (`Even if the compilation is deemed original, what kind of copying will be held to infringe it?' The answer [after Feist ] appears to be: `Virtually none, short of extensive verbatim copying.'). Further, because the copyrightability of a factual compilation depends upon the originality in selection, coordination or arrangement of the facts as a whole work, 17 U.S.C. § 101, in an infringement action the court must compare the allegedly infringing work as a whole also. The mere aggregation clause (on the same storage volume but not a part of the Program or a work based on the Program) seems to me to contain both elements of IP law and elements of technology. Let's agree that it's a subtle point, and that there's no predicting exactly how a district court would go about construing mere aggregation, let alone what conclusion it would reach. It's not even clear to me whether an appeals court would go so far as to declare the district court's approach to construing that phrase incorrect as a matter of law even if it
Male sexual enhancement formula^
Wish you could be better? http://www.terima.net/ss/ No more penis enlarge ripoffs! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
removing the debian-legal website stuff?
Hi. As some of you might know some time ago I created a web page for listing information about licenses discussed by debian-legal at http://www.debian.org/legal/licenses/ Shortly after creation this stalled however as nobody created summaries anymore, probably because for many discussions it proved to be difficult if not imopossible to summarise many of the discussions without either reproducing the entire discussion or to have an equally lengthy discussion about the summary... Since this hasn't really worked out I propose to delete this stuff again until someone comes up with a better idea how to better present the work of debian-legal. Comments, objections? Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing the debian-legal website stuff?
On Mon, May 23, 2005 at 03:47:05PM +0200, Frank Lichtenheld wrote: As some of you might know some time ago I created a web page for listing information about licenses discussed by debian-legal at http://www.debian.org/legal/licenses/ Comments, objections? Maybe it is sufficient to refer to this page more often and to explicitly request updates on various lists and in various threads. I remember that you announced the page but never visited it before :-(( I'm sure it is quite useful. Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
36 hours of freedom.
Little magic. Perfect weekends. http://colonials.healthsolutins.info/?ImagenxtvuyPalestinianzvtspecial We offer a fast-track repeat prescription service -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing the debian-legal website stuff?
In linux.debian.legal Frank Lichtenheld [EMAIL PROTECTED] wrote: Since this hasn't really worked out I propose to delete this stuff again until someone comes up with a better idea how to better present the work of debian-legal. Seconded. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License question about regexplorer
[EMAIL PROTECTED] wrote: Wait, the QPL (with no additional permission and a choice of venue) is *not* DFSG-free (many long discussions were hold on debian-legal last summer, IIRC). This is just bullshit. A few people thinking it's not free does not make it non-free. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License question about regexplorer
On Mon, May 23, 2005 at 09:04:52PM +0200, Marco d'Itri wrote: [EMAIL PROTECTED] wrote: Wait, the QPL (with no additional permission and a choice of venue) is *not* DFSG-free (many long discussions were hold on debian-legal last summer, IIRC). This is just bullshit. A few people thinking it's not free does not make it non-free. But Marco d'Itri defending it means it probably is non-free. Funny how that works. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Trademark license compatibility with GPL and/or DFSG
[EMAIL PROTECTED] wrote: On the other hand, any trademark license would permit us to use their trademark, which we could not do otherwise. This is a misunderstanding of trademark. It is always legal to describe the driver as being a driver by author intended for use with trademark, because that can't cause confusion about the origin of the driver. You should do this. I think that naming the driver after the trademark might indeed be a trademark violation, because it might theoretically cause confusion about the origin of the driver. Now, Linux drivers often have nonobvious names which don't match the hardware's commercial name. So I think you should go ahead and name the driver with some non-trademarked name, and just describe it as intended for use with trademark everywhere it's mentioned. If it was a debian package, you would unfortunately really want to have the trademark in the package name so that users could find the package using the standrd search facilities in dselect. However, that doesn't seem to be the issue right now, so I won't try to work out a solution for that right now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Trademark license compatibility with GPL and/or DFSG
[EMAIL PROTECTED] wrote: The company in question is willing to negotiate terms for a trademark license that is agreeable to all parties. Obviously any advertising or guarantee restrictions are unacceptable to us. Well, no; some such restrictions are acceptable. We accept the required NO WARRANTY clauses in lots of licenses. I think that a restriction which required that we note that *they* aren't guaranteeing it would be fine. Unlimited use of the trademark is unacceptable to them. Well, first of all we don't want or need that. We can use the trademark in most of the ways we want to without hitting any trademark restrictions. I don't have the case reference here, but there was a case involving TSR and products labelled Compatible with Dungeons and Dragons, and it was ruled that that was *not* a trademark violation (although TSR kept threatening people who did it with lawsuits for years anyway). Basically, we can't legally use a trademark (without a license) in ways which may cause confusion about the origin of the product; we can use it in all other ways and be on safe legal ground under current law. Putting the trademark in the name of the driver might lead people to think that the driver was from the company which owns the trademark, so that would require a license. How about this license: Anyone may use the trademark trademark as part of the name of a product designed to work with the hardware; provided that the product using the trademark in its name, and any advertising for it using the trademark, prominently mentions that the product is not produced by or supported by the makers of the hardware. Using the trademark in the name is the only thing we want which would actually hit trademark restrictions as far as I can tell, so that's all we need a license for. Disclaimers are required by a lot of licenses and should be acceptable (much like NO WARRANTY requirements). With this license, the disclaimers are the only restriction, and this restriction applies solely to usage of trademarks in an otherwise-maybe-infringing manner, not to anything else. Among other things, I believe this keeps it GPL-compatible, since the product can be distributed without agreeing to the restrictions simply by changing the name (which is not part of the copyright-covered material). They want their trademarks stripped from modified code that is essentially different in intent and purpose from the original code. Well, that's fine; we don't want to use their trademarks for things which aren't designed to work with their hardware, now do we? (At least, except in a historical context, which certainly wouldn't be a trademark violation.) So what do you think they would say about the model trademark license I just proposed? (Don't use it until debian-legal has had a few days to nitpick it, of course.) I think it's a free license, although others may disagree; the key point is that it is not trying to do anything but prevent confusion, and it doesn't overreach. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Revamping the debian-legal website (was Re: removing the debian-legal website stuff?
Frank Lichtenfeld wrote: Since this hasn't really worked out I propose to delete this stuff again until someone comes up with a better idea how to better present the work of debian-legal. It would really, really, really help if things like the currently-unofficial debian-legal FAQ, some of the various FAQs about the GFDL, etc., were integrated into the debian-legal website. Information about the freeness tests we use, etc., is the sort of thing which belongs there. Also, I really like the existing essay on the three categories of software, and the comments about how our list differs from the FSF and OSI lists; I do *not* want to lose that. If you delete anything, *just* delete the summary list, and update the rest of the page to reflect that. I think the official debian-legal website should form more of an About debian-legal, what we do, and how we do it site. Maybe we can put license summaries in later, but I think they're not the most important thing there. Remember to get appropriate copyright licenses from everyone whose FAQs you integrate and to specifically put the page under those licenses (not just the default OPI for the website), with appropriate copyright notices. We should attempt to follow our own recommended best practices. (Which, incidentally, is another thing to add to the website: best practices in copyright and licensing maintenance...) Oh -- what license would debian-legal like for its own web pages? I think the main choice to make is copyleft (meaning GPL) or highly permissive (in which case I don't care which one, but it would be good to settle on one preferred one). I suggest highly permissive, because this site is going to contain memes which we want to spread, and allowing unlimited reuse would IMHO be good for that. ... OK, after making all those suggestions, it's time to put my money where my mouth is. I volunteer to do this work if nobody else wants to (or indeed to do it with someone else if they do want to). I'll even put it on high priority; I think I could get quite a lot done very quickly, since the information exists, but just has to be integrated. However, I would need website access of some sort in order to do that, which I don't have. --Nathanael Nerode -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RES: What makes software copyrightable anyway?
On 5/23/05, Michael K. Edwards [EMAIL PROTECTED] wrote: On 5/23/05, Raul Miller [EMAIL PROTECTED] wrote: I'll need to think about that some, but I think there are some obvious points you missed. (For example, that contract law can and will be used in resolving ownership issues in copyright cases.) As long as you modify copyright cases to claims of license under copyright, I'm good with that. Contract law is not used to resolve any issue other than the validity and scope of a claimed license. License as in non-exclusive copyright license, a term in a contract, not any statutory or judicially created defense such as fair use or doctrine of merger. Ok. Except, last sentence no verb. Anyways, I'll see if I can come up with some other points of agreement. (Many of your statements are statement I agree with if they're phrased as possibilities rather than in always applicable to everything form -- that is, if they're rephrased to assert existence rather than universality.) OK. But let's both be careful about mistaking, say, some copyright licenses are terms in contracts as nearly agreement with all copyright licenses are terms in contracts; the former (in law, not in math) implicitly suggests that some copyright licenses are not terms in contracts, which is diametrically opposed to the latter. To my knowledge all (or perhaps almost all -- I'm not enough of an expert to say which) U.S. case law involving copyright claims have dealt with contractual issues. Note that I haven't take time to wade back through what we've written over the last few weeks, looking for points we now agree on. It's a daunting tsk. That's certainly true of Lotus v. Borland. However, if you look at the cases from video game space, you will see lots of other permutations: game developers using fair means or foul to defeat console makers' efforts to impose onerous contract terms (Sega v. Accolade and Atari v. Nintendo), emulator developers leveraging the availability of games authored for an existing console (Sony v. Connectix and Sony v. Bleem), and one publisher distributing add-ons for another's game (Micro Star v. FormGen). One thing these cases share is that the alleged infringers were not distributing the game software which was being infringed on. I don't believe that makes any difference to the logic in these cases. There would be no additional cause of action in, say, Sony v. Connectix if Connectix had legitimately purchased Sony games for resale and bundled them with its PlayStation emulator. Not as long as it did not claim collective work copyright on the bundle (compare Palladium Music v. EatSleepMusic) or violate trademark law by implying that the emulator was a Sony-approved product. I was not referring to distribution of cloned software but distribution of the original software. If Connectix was distributing Sony software, that issue (along with any associated contracts) would have been very significant to the case. If we draw an analogy between these cases and a dynamic linking case, a parallel would be cases where the dynamically linked library was not being distributed by the alleged infringer. That simply doesn't make a bit of difference to whether a program is a derivative work of the library to which it's linked -- and all of the cases cited above are copyright (and/or trademark) infringement cases, not breach of contract. Now, if the library's license agreement contained a prohibition on distributing the two things together, then the court might have to consider whether that prohibition is a legitimate term for a contract to contain. But in the case of the GPL, I do not believe (IANAL) that it contains such a prohibition when construed according to the applicable principles of common law (irrespective of the details of the given jurisdiction's implementation of contract law). Participants from civil law countries appear to reach similar conclusions. The GPL certainly allows distribution when the source code for the program as a whole is available under an appropriate license. One of the things we're discussing in the context of Quagga is whether the source code for the program as a whole is available under an appropriate license. [We're also trying to nail down the why or why not issues.] [snip citations anchored in Feist] You do understand that Transwestern v. Multimedia, BellSouth v. Donnelley, and Feist v. Rural Telephone are discussing the thin copyright on compilations of facts (such as telephone directories)? Copyright on a collective work (a compilation whose components are themselves copyrightable works) is in some ways stronger, but it still has to meet a non-zero threshold of creative expression in selection and arrangement, and the act of combining the compiled binaries of Quagga, libsnmp5, and libssl doesn't cut it. The modifications to Quagga to support publishing routing tables
Re: removing the debian-legal website stuff?
Frank Lichtenheld wrote: Shortly after creation this stalled however as nobody created summaries anymore, probably because for many discussions it proved to be difficult if not imopossible to summarise many of the discussions without either reproducing the entire discussion or to have an equally lengthy discussion about the summary... My view is that the earlier stage of the summary drafting process was used as a stick to beat debian-legal towards firey heat death, so contributors simply stopped making them. Maybe a new and totally uncontroversial licence will come along, but anything which has DFSG-related questions left open will almost always have some supporters and some detractors, so not suit the red/green judgement. Since this hasn't really worked out I propose to delete this stuff again until someone comes up with a better idea how to better present the work of debian-legal. I support deleting the summaries. I think that page would be good for a general description of how debian-legal works, linking to unofficial documents as they are prepared and official documents on other parts of the site. I had intended to write this before, but I am still not up-to-date with wml. Here is my suggested text: pThis site presents the opinion of debian-legal contributors on how certain licenses follow the a href=$(HOME)/social_contract#guidelinesDebian Free Software Guidelines/a (DFSG). Most of these opinions were formed in discussions on the a href=http://lists.debian.org/debian-legal/;\ debian-legal mailing list/a in response to questions from potential package maintainers or licensors. We welcome enquiries from maintainers considering particular licenses, but we encourage most maintainers to use one of the common licenses: GPL, LGPL, BSD or Artistic./p pSoftware packaged for debian is normally classified into four categories. There is free software (main), non-free software (non-free), free software which depends on some non-free software (contrib) and software which cannot be redistributed (not included). a href=$(DOC)/debian-policy/ch-archive.htmlDebian Policy section 2/a explains exactly how the DFSG are applied to the archive. If in doubt, maintainers are asked to email debian-legal about licenses, including the text of any new license into the body of the email./p pdebian-legal is advisory. The actual decision-makers are the ftpmasters and the package maintainers. However, if one cannot convince most of the generally liberal debian-legal contributors, it's probably not clear that the software follows the DFSG./p pLists are maintained by the a href=http://www.gnu.org/licenses/license-list.html;Free Software Foundation/a (FSF) and the a href=http://www.opensource.org/licenses/index.html;Open Source Initiative/a (OSI). Please note however, that the Debian project decides on particular packages rather than licenses in abstract, and the lists are general explanations. It is possible to have a package containing software under a free license with some other aspect that makes it non-free. Sometimes, debian-legal comments on a license in abstract, not applied to any particular software. While these discussion can suggest possible problems, often no firm answers can be reached until some specific software is examined./p pYou may contact debian-legal if you have questions or comments about these summaries./p pLicenses currently found in debian main include:/p ul liGNU General Public License (common)/li liGNU Lesser General Public License (common)/li liGNU Library General Public License (common)/li liModified BSD License (common)/li liPerl Artistic license (common)/li liApache License/li liMIT/X11-style licenses/li lizlib-style licenses/li liLaTeX Project Public License/li liPython Software Foundation License/li liRuby's License/li liGlasgow Haskell Compiler License/li liPHP License/li liW3C Software Notice and License/li liOpenSSL License/li liSleepycat License/li liCommon UNIX Printing System License Agreement/li livhf Public License/li liNo problem Bugroff license/li lipublic domain (not a license, strictly speaking)/li /ul pIf you use one of these licenses, please try to use the latest version and edit no more than necessary, unless indicated otherwise. Licenses marked (common) can be found in /usr/share/common-licenses on a debian system./p pLicenses currently found in the non-free archive section include:/p ul liNVIDIA Software License/li liSCILAB License/li liLimited Use Software License Agreement/li liNon-Commercial License/li liFastCGI / Open Market License/li liLaTeX2HTML License/li liOpen Publication License/li liFree Document Dissemination Licence/li liATT Open Source License/li liApple Public Source License/li liAladdin Free Public License/li liGeneric amiwm License (an XV-style license)/li liDigital License Agreement/li liMoria/Angband license/li liUnarj License/li liid Software License/li liqmail terms/li /ul pPlease do not upload software under these licenses to the
