Re: DFSG + Hack typeface license with transition to proposed new source file build in Debian package
This is very helpful Ian and I really do appreciate your feedback. I think that we are in agreement on our end that elimination of the reserved font name will be the best approach for all involved. This will likely come along with licensing of all changes that we have made to the upstream source under a MIT license. How to approach the license for our changes remains under discussion by our project authors and the community around the project but this is the direction that we are leaning. This means that you can perform source and post-compilation modifications on the fonts derived from our released source and maintain the name Hack on these fonts. Ultimately, we want the fonts to be as free as possible given the upstream licensing restrictions that are in place and the pros of the RFN removal move for us seem to outweigh the cons. A large part of our current move to release the source as UFO only with only free OS build tools is to encourage its use as an upstream for modifications and new derivatives. A number of authors have expressed an interest in using “Hack” in the name of their derivative projects, something that is not permitted under the current license (including for the authors of Hack should we choose to release a derivative!). The move is, I think, a good one for the project and the Debian community has been a large part of the push for us to better understand these licensing issues and take action. Thanks to all in this thread for your feedback and assistance. Your time is greatly appreciated! Thanks again, Chris On Aug 30, 2017, 10:33 AM -0400, wrote: > > From Debian's point of view, the licence you provide is adequate for > us to be able to include the fonts in Debian. However, the reserved > font name restriction would almost certainly mean that we would have > to rename the fonts. > > Debian has a long history of dealing with upstreams who restrict the > ability of Debian to distribute a modified version under the usual > name. For example, for many years, Debian's Firefox package was > called `iceweasel' (and all the Firefox branding was removed), because > the Mozilla Foundation (who own the trademark "Firefox") insisted on > prior approval of all changes. > > Debian is not likely to accept a restriction on modifying glyphs. We > consider that Debian (and its downstreams and users) must be free to > make changes - even changes that upstreams disapprove of. For fonts, > the need to change glyphs is not theoretical: when I was an Ubuntu > developer I personally modified a font in order to correct an > erroneous glyph in some Georgian character, in response to a bug > report from a user.) > > So, if you would like Debian to distribute your fonts under names > which advertise your project as the origin, then you should grant > Debian permission to do so. > > I hope this has been a useful perspective. > > Regards, > Ian. > > NB: I am not the person in Debian who makes these decisions. But I > think the views I have attributed above to the project as a whole will > be very uncontroversial.
Re: DFSG + Hack typeface license with transition to proposed new source file build in Debian package
We created a new thread for our license discussions for anyone who is interested in participating on the repository: https://github.com/source-foundry/Hack/issues/271 One possibility for us would be to eliminate the dual license structure and simply revert to the Bitstream Vera license with public domain contribution of our changes in the same fashion that the DejaVu group used for their modifications to Bitstream Vera Sans Mono. This sounded ‘benign' to me but Dave Crossland informed me that public domain contributions to the public domaining of these source contributions led to additional problems with distribution. My understanding is that there were legal issues that arose in some European countries and that this is (at least in part) why DejaVu Sans Mono has never been included as part of the Google Fonts collection. I am hoping not to trade one set of problems for another and would be interested in your feedback about any potential DFSG issues associated with commitment of source modifications to the public domain if we moved towards this strategy. On Aug 16, 2017, 11:02 AM -0400, Francesco Poli <invernom...@paranoici.org>, wrote: > On Wed, 16 Aug 2017 08:40:00 -0400 Chris Simpkins wrote: > > > [...] Downstream open source project font licensing from the days > > prior to SIL OFL (and to some degree even after that period) is a > > bit of a quagmire. > > Hello, > I agree that font licensing is a quagmire. > > Well, I even go further and personally think that it is a real mess: > I wish more fonts were simply released under the terms of wide-spread > and well understood licenses (such as the Expat/MIT license or the GNU > GPL v2 + font exception)... Doing so would spare a good number of > headaches to many people! > > > > > Item 2 is where the reserved font name declaration is located. > > I have been considering modification of the language here to permit > > forks to use “Hack” in the name, but not “Hack” alone for a forked > > typeface. > [...] > > Personally speaking, I would encourage you to at least relax this > restriction (or, even better, to drop it entirely). > That way, only one name (or no name) would be forbidden for derivative > fonts and everything would be simpler... > > [...] > > It is a downside in the typeface software development area that > > is in need of repair. But it is a reality that we face. > > I personally think that technical issues should not be worked around by > imposing licensing restrictions. > If typeface development tools need to be improved in order to get > better QA, then I hope they can be enhanced from a *technical* point of > view. In the meanwhile, licensing restrictions should not be introduced > to compensate for technical limitations. > This is my personal opinion. > > I hope this helps. > Bye. > > > -- > http://www.inventati.org/frx/ > There's not a second to spare! To the laboratory! > . Francesco Poli . > GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Re: DFSG + Hack typeface license with transition to proposed new source file build in Debian package
> I personally think that technical issues should not be worked around by imposing licensing restrictions. If typeface development tools need to be improved in order to get better QA, then I hope they can be enhanced from a *technical* point of view. In the meanwhile, licensing restrictions should not be introduced to compensate for technical limitations. A very valid point and well taken. On Aug 16, 2017, 11:02 AM -0400, wrote: > > I personally think that technical issues should not be worked around by > imposing licensing restrictions. > If typeface development tools need to be improved in order to get > better QA, then I hope they can be enhanced from a *technical* point of > view. In the meanwhile, licensing restrictions should not be introduced > to compensate for technical limitations.
Re: DFSG + Hack typeface license with transition to proposed new source file build in Debian package
Thank you Jeff. The Hack Open Font License was modeled on the Bitstream Vera license and SIL OFL. Downstream open source project font licensing from the days prior to SIL OFL (and to some degree even after that period) is a bit of a quagmire. Item 2 is where the reserved font name declaration is located. I have been considering modification of the language here to permit forks to use “Hack” in the name, but not “Hack” alone for a forked typeface. We have bound our own hands in this language and would like to make/release some derivative typefaces from the Hack source with names such as “Hack Ligature”, “Hack ASCII”, “Hack ZeroSlash”, etc. This will also support other project teams who would like to associate their fork with the Hack upstream source by using Hack followed by a string that distinguishes it from the upstream source. The impetus for the reserved font name issue is simply QA. We perform a great deal of manual testing prior to releases that cannot be fully automated in the current era of font development software. The exact build process that we use is the one that we have validated and want to support. One of my worries if we loosen this requirement (i.e. fully remove the reserved font name) is that we will be approached on the repository about all build issues assuming that we will be able to troubleshoot the issue for teams that elect to build with a different approach. There are numerous other ways to compile the fonts out there and the OpenType tables as well as the hinting on the fonts can, and in many cases likely will, change for those who do not appreciate these issues. It is a downside in the typeface software development area that is in need of repair. But it is a reality that we face. Will wait for more feedback and then weigh in further. On Aug 16, 2017, 8:23 AM -0400, wrote: > > This License becomes null and void to the extent applicable to Fonts or Font > Software that has been modified and is distributed under the "Bitstream Vera" > names
DFSG + Hack typeface license with transition to proposed new source file build in Debian package
Our fonts (Hack - https://github.com/source-foundry/Hack) are currently released through the Debian package manager (package maintainer Paride Legovini) from our Github repository as binaries that are compiled + hinted by the project author team. As of our upcoming v3.0 release of the fonts, we are transitioning to a new scripted compilation process that will allow redistribution of these binaries as built directly from the source files by redistribution teams. There are multiple reasons for this, but one has been a request by a number of Linux distro package maintainers to abide by guidelines that include the DFSG. Paride asked me if there will be an issue with the release of the Hack font files through this scripted source compilation process on Debian and Ubuntu distros based upon the language in our dual license structure (admittedly complex due to the fact that these fonts are a fork from Bitstream Vera Sans Mono that had a license which predates the current FLOSS licenses in use for typefaces). I believe that his concern is with the Reserved Font Name stipulation in our Hack Open Font License and whether there are conflicts for your group. I received a request from a user to contact this mailing list for further information and to clarify the language in our license against your guidelines for software redistribution. We fully support and encourage this form of redistribution of our fonts so long as the packages are compiled with the validated build tooling (including appropriate dependency versioning) that we use in the repository builds that are intended for release to the end user. If there is license language that seems to indicate otherwise or prohibits your capacity to distribute the font files in this fashion, I would greatly appreciate any feedback that you would be willing to provide about how we can modify the licensing so that this is no longer the case. Our license is available here: https://github.com/source-foundry/Hack/blob/master/LICENSE.md The original issue report thread where this was raised by Paride is here: https://github.com/source-foundry/Hack/issues/255#issuecomment-316414866 It would be ideal to have this conversation in a Github issue report on the repository (the above report or a new one if appropriate) if you are willing. Assuming that is not possible given the size of this list, I will try to summarize the outcome of the conversation for Paride and our users, then point a link to the debian-legal archives so that we have a record of the discussion. Thanks in advance for your help. I greatly appreciate your assistance. Chris Simpkins
Re: Are all files produced by GPL Ghostscript copyrighted by 'Artifex Software, Inc.'?
Issues regarding copyright, or legal issues in general should be sent to debian-legal@lists.debian.org CC'd On Fri, Dec 21, 2012 at 10:09:32PM -0800, Vaibhav Niku wrote: Hello all pdf2ps, which is a frontend to gs, inserts a copyright notice in all PS files it produces. I am using `GPL Ghostscript 8.71 (2010-02-10)'. Files look like this: %!PS-Adobe-3.0 ... %%Creator: GPL Ghostscript 871 (pswrite) ... %%BeginProlog % This copyright applies to everything between here and the %%EndProlog: % Copyright (C) 2010 Artifex Software, Inc. All rights reserved. %%BeginResource: procset GS_pswrite_2_0_1001 1.001 0 ... %%EndProlog ... %%EOF (Needless to say, the files are corrupted if you delete the Prolog stuff.) This is a serious issue on multiple counts: (i) The idea itself is ghastly! It is like saying that if you convert a photo from one format to another in via ImageMagick tools, ImageMagick LLC will hold the copyright to your new photo. And it may be even worse. Depending on where all gs inserts the copyright notice, it may be equivalent to emacs claiming copyright for all your code! (ii) Why is the information about this missing _everywhere_? Nothing in man pages, nothing in /usr/share/doc/ghostscript/, nothing on gs homepages (http://www.ghostscript.com and http://pages.cs.wisc.edu/~ghost/ .) And finally, (iii) Why is gs a part of Debian? Since Debian maintainers find such restrictions acceptable for files produced by one program, how do I know that it is not acceptable for other programs? Am I supposed to check files with a hexeditor after every change I make to every file? P.S.: Someone on #debian at irc.debian.org said that the notice is not inserted when using the upcoming version 9.17 of gs. (available in wheezy; the latest version for stable is 8.71) Even so, I would like to have clear information about this file. There are probaly hundreds of thousands of files having this notice upto now. The authors of these would be interested in knowing that ARTIFEX SOFTWARE, INC claims copyright for them. (https://duckduckgo.com/html/?q=%25%20This%20copyright%20applies%20to%20everything%20between%20here%20and%20the%20%25%25EndProlog%3A ) Yours faithfully, ~Vaibhav. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1356156572.82923.yahoomailclas...@web161706.mail.bf1.yahoo.com -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121222085116.GB3507@tal
Re: Do you consider charity shops non commercial?
On Apr 14, 2012, at 5:35 PM, Paul Wise p...@debian.org wrote: The term non-commercial is open to interpretation I was surprised Black's (8e) doesn't define (non-)commercial. The closest it gets is commercial law ... dealing with the sale and distribution of goods, the financing of credit transactions on the security of the goods sold, and negotiable transactions. The only 'non-commercial' definition is for a non-trading partnership ... does not buy and sell but instead is a partnership of employment or occupation. Merriam-Webster Collegiate (11e) defines commercial as, relevant definitions only, viewed with regard to profit a ~ success or emphasizing skills subjects useful in business... (Non-commercial is undefined.) Case law (esp., in the U.S. and perhaps persuasively in the UK, related to 17 USC § 107, which by its very language makes whether [a] use is of a commercial nature or is for nonprofit educational purposes a necessary part of any analysis) might provide some guidance... But not at 2:44 a.m. :) -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/13ec6f0b-581b-4445-8897-188619f68...@packetlaw.com
Re: windows video capture card driver source contains LGPLv2 header file - can I port?
On Feb 25, 2012, at 10:46 AM, erp...@gmail.com wrote: What are my options for creating a Linux driver for this hardware? What you've reported doesn't really provide enough information for us to opine (even with 'non-legal advice' opinions). You say the Windows application is distinct from the driver, but is that distinction maintained in the copyright notices? Etc. The Command.h file -- was it built/provided by the driver manufacturer, or did the author of the Windows driver/software use LGPL code? Etc. But it may not matter. Recall that (at least in the U.S., where arguably the biggest threat of litigation exists), copyright does not extend to functional elements; Lotus v. Borland, 516 U.S. 233 (1996). To the extent code is required to interoperate with the hardware, you can reuse/derive from it safely. (You might also want to familiarize yourself with the Abstraction / Filtration / Comparison test from Computer Associates v. Altai 982 F.2d 693 (6th Cir. 2003): http://en.wikipedia.org/wiki/Abstraction-Filtration-Comparison_test ). In short, I personally would not take a clean-room approach to that code. I'd look at it, learn from it, and write my own Linux driver, personally. Anything specific to the hardware I'd copy more or less verbatim. Anything else, if there's really only the one way of doing it, it's not copyright protected; if there's more than one way, I'd be creative. :) This is not legal advice; if you want that, contact me directly (and pay me =)).
Re: windows video capture card driver source contains LGPLv2 header file - can I port?
On Feb 25, 2012, at 5:14 PM, Paul Wise wrote: I would suggest that a cleanroom implementation would be the way to go if you care about mainlining the driver. Out of curiosity - why? (Especially given the driver may never get ported with the cleanroom approach.) No license / copyright is needed for functional elements... -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/80f86089-e659-4e9f-9e24-f5bd9195e...@packetlaw.com
Re: copyright law wackyness
On Dec 22, 2011, at 10:33 PM, Paul Wise p...@debian.org wrote: The other part is less clear to me and it refers to contracts rather than licenses, but the document author seems to think it applies to the GPL. How is a license not a contract? -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/561ab4d2-889d-4d27-a404-2a62b0680...@packetlaw.com
Re: Lawyer request stop from downloading Debian
Florian Weimer fw at deneb.enyo.de writes: * Stefan Hirschmann: My opion is that this behavior is not good for Debian's reputation and the project should take legal action against the lawyer and this company. From what I've read, it is not clear at all whether a lawyer actually sent anything. Hi, the company is called Holland Art B.V. B.V is dutch pointing to the legal form of the company. The company is not listed at de Dutch camber of commerce as Media Art Holland BV. There are a few companies listed with combinations of media and art. Non of these companies are known to me as acting against Debian in any way in the Netherlands. Calling the German lawyer to find out who are his client might be a good idea. Chris -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20110426t205748-...@post.gmane.org
Re: MS-PL LGPL
On 12/20/2010 1:26 AM, Rudolf Polzer wrote: First of all, this is off-topic on this list, as we talk mainly about DFSG compliance, and about legal issues with packages in Debian. Out of curiosity, *is* there a recommended list for programmers with open source licensing questions? -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d0f9911.5090...@packetlaw.com
Re: NASA CDF
On 12/10/2010 11:31 AM, Aaron M. Ucko wrote: I agree with you, but also with those who observed that the notion of a federal agency holding copyright is a bit odd; published US government work falls into the public domain, and I would expect a work for hire (by a contractor) to have a corresponding copyright holder. Works created by the federal government itself cannot be copyrighted; 17 U.S.C. § 105. However, a contractor (not an employee) by definition (17 U.S.C. § 101) can only create a work made for hire where that work is: a work specially ordered or commissioned for use as a contribution to a collective work; a part of a motion picture or other audiovisual work; a translation; a supplementary work (a work prepared for publication as a secondary adjunct to a work by another author for the purpose of introducing, concluding, illustrating, explaining, revising, commenting upon, or assisting in the use of the other work, such as forewords, afterwords, pictorial illustrations, maps, charts, tables, editorial notes, musical arrangements, answer material for tests, bibliographies, appendixes, and indexes); a compilation; an instructional text (literary, pictorial, or graphic work prepared for publication and with the purpose of use in systematic instructional activities); a test; answer material for a test; or an atlas. Ergo, something created by an independent contractor *for* the government could still be copyrighted. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d02a2ec.9000...@packetlaw.com
Re: issues with the AGPL
On Sat, 2009-08-22 at 12:43 -0700, Steve Langasek wrote: On Sat, Aug 22, 2009 at 02:31:38PM +0200, Florian Weimer wrote: All that is for USA, right? Do you know whether it works that way in other countries than USA, and probably UK, Canada and Australia too? There is no such thing as a unilateral contract in Germany. There's no such thing as a unilateral contract anywhere else either. A license is not a contract. There's an excellent discussion on the finer points of this distinction (albeit under U.S. law) in Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008). I have the opinion if anyone wants to read it (not sure how accessible it is outside a legal research database subscription). -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Final text of GPL v3
On Sat, 30 Jun 2007, Francesco Poli wrote: When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, This clause is troublesome, as it seems to be overreaching. For instance, it could be interpreted as covering legal powers to forbid computer crimes such as unauthorized intrusion into computer systems. E.g.: suppose that the covered work is a vulnerability scanner, or password cracker, or anyway a tool that could be used (among other things) to break into other people's computers. Using that tool in this manner is exercising a right under this License Using a tool is not exercising a right under the license. The license concerns itself only with copying and modification. (It is not an end user license agreement.) Beyond that, I agree with MJ's analysis, but I think the point I raised is an important additional one. Waiving legal rights can be seen as a fee: this clause could fail DFSG#1. All free licenses, and especially all copyleft licenses, require the waiver of certain legal rights (such as the right to sue for copyright infringement). The requirement in copyleft to provide source code can also be seen as a fee--in fact, this has been cited as a reason for considering the GPLv2 valid, enforcible and non- discriminatory with respect to anti-trust law. If waving legal rights is a problem, we have no licenses left. If something that merely *can* be seen as a fee is a problem, then all copylefts are non-free. d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so. Clause 5d is definitely worse than the corresponding clause 2c in GPLv2. Are you talking about the missing when started running...in the most ordinary way? That was highly ambiguous; this has the advantage of being clear and direct, and I can't think of any circumstances where it could actually be considered worse. I actually think the new wording is a great improvement, as it closes a highly ambiguous loophole (the worst kind). What is more awkward is that it seems that when a non-interactive work is modified so that it becomes an interactive work, the modifier is *compelled* to implement these features in *any* newly created interactive interface. Um, GPLv2 has basically the same requirement: If the modified program normally read commands interactively when run, you must cause it...to print or display an announcement The *only* exception listed is 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. The only difference I see is the removal of normally, which, like the most ordinary way is rather ambiguous. I'm sorry, but I really don't see how this is a freeness issue *if* we consider the GPLv2 to be a free license. The difference between these requirements is *so* small that I don't see how anyone could accept the one and reject the other. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Problem with LARGE files
I am currently finishing work on a program which can be used to identify a group of mathematical structures. I would like to release it under the GPL. However building the program involves applying a lossy compression algorithm to around 400GB of data files, turning them into about 50MB. I could possibly write a program which, using this 50MB could back the 400GB data set I have on my hard disc, but this would probably take around four months to run. Would it be reasonable to request someone had to spend £100 on an external hard disc and postage if they wanted to request the source to my program? and is there any way I could ever get such a program into Debian? Perhaps a different license? Thank you. PS Please CC me, I am not subscribed to the list
Re: Your Managers Don't Have Expertise They Have This.
{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0 Arial;}{\f1\fswiss Arial;}}
\viewkind4\uc1\pard\f0\fs20\par
\par
\pard\f1 Chris Peterson\par
Corporate Consultant\par
Frosch International Travel\par
835 5th Avenue\par
San Rafael CA 94901\par
415 456 2000 ext 108\par
Toll Free 866 795 8400\par
\f0 [EMAIL PROTECTED]
\par
After Hours - home - 707 795 3340\par
\pard\f0\par
}
Re: Packaging YICS
Andrew Donnellan wrote: Not an interface that Yahoo provides. More an interface that Yahoo uses internally. And that doesn't say anything about the future. The project *may* be threatened later, which is why people ask us on this list *before* they get threatened. Just out of curiosity, does this raise issues for fetchyahoo (in Debian) as well? -- Chris Howie http://www.chrishowie.com -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/IT d-(--) s:- a---? C++(+++)$ UL P$ L+++ E--- W++ N o++ K? w--$ O M- V- PS--(---) PE++ Y+ PGP++ t+ 5? X- R(+)- tv-(--) b- DI+ D++ G+++ e++ h(--)--- !r+++ y-+++ --END GEEK CODE BLOCK-- signature.asc Description: OpenPGP digital signature
Packaging YICS
I decided, as an excersize (and for the heck of it) I would package my FOSS project YICS (www.yics.org) for Debian. Basically, YICS connects to any of the free Yahoo! Chess lobbies and emulates a FICS server, meaning xboard, eboard, and other FICS interfaces can be used to play on Yahoo! Chess. The idea is to bring the features of those interfaces (automatic PNG logging, customizable colors/sounds, etc) to the Yahoo! world. There are, however, a few legal issues I wanted to bring up before I spend the energy packaging it. I believe that I can refute most of the problems, but you might (and certainly do) know more about law than I do. (For those who can't figure it out, I start potentially negative sections with === and potentially positive ones with +++.) === Problem 1: The Yahoo! TOS: http://docs.yahoo.com/info/terms/ Section 17 contains this sentence: You agree not to access the Service by any means other than through the interface that is provided by Yahoo! for use in accessing the Service. Section 2 defines Service: Yahoo! provides users with access to a rich collection of resources, including various communications tools, forums, shopping services, search services, personalized content and branded programming through its network of properties which may be accessed through any various medium or device now known or hereafter developed (the Service). We can assume that this includes Games. +++ Refutation: Interface is not defined anywhere. Couldn't TCP port 11999 be considered some kind of interface to the Service? === Problem 2: Back to our friend, section 17: You acknowledge and agree that the Service and any necessary software used in connection with the Service (Software) contain proprietary and confidential information that is protected by applicable intellectual property and other laws. The binary protocol is encrypted, which also brings up DMCA issues. +++ Refutation: Progressive XOR can hardly be considered a trade secret. And the DMCA is supposed to cover *copyrighted* material, *and* allow for interoperability exceptions. === But: http://www.eff.org/IP/Emulation/Blizzard_v_bnetd/ The DMCA is, of course, supposed to cover copyrights, not protocols. But bnetd did get sued. === Users of YICS don't see banner ads when playing either, so YICS does mean some lost revenue for Yahoo!. *HOWEVER*, and this is kind of the hinge... regardless of the legal issues outlined above, I have one major advantage. I have very strong evidence that Yahoo! knows about my project, and I have made no effort to hide my identity -- the program itself lists my Yahoo! ID. I have not heard from Yahoo! during the project's two-year life. An unfortunate side-effect of YICS is that it allows a computer to be directly hooked up to the Yahoo! Chess servers, by way of WinBoard, xboard, and other commercial interfaces. Yahoo! does not forbid this, but I doubt they like it very much. On the project wiki and forum I have stated in the rules that any kind of information pertaining to using YICS in combination with an automated computer are prohibited from appearing or being discussed on either. I feel that it is this alone that has kept me in Yahoo!'s good graces. A side-effect of this side-effect is that I am contacted almost daily by certain key members of the Yahoo! underground world (cracking, boosting, and all that junk). Several of them have had their accounts removed within months of registering on Yahoo!. So... if Yahoo! actively deletes accounts of known underground leaders and participants, how come my account hasn't been disabled or removed? I can only assume that it's because I've tried to promote YICS as an alternative interface, not a cheating tool. I haven't tried to hide from Yahoo!. My site doesn't use a dark color scheme like the hacker sites, either. But seriously, what do you think? -- Chris Howie http://www.chrishowie.com -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/IT d-(--) s:- a---? C++(+++)$ UL P$ L+++ E--- W++ N o++ K? w--$ O M- V- PS--(---) PE++ Y+ PGP++ t+ 5? X- R(+)- tv-(--) b- DI+ D++ G+++ e++ h(--)--- !r+++ y-+++ --END GEEK CODE BLOCK-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging YICS
Andrew Donnellan wrote: I think that you could package the software, but it wouldn't be very useful as anyone who uses it is violating the TOS. But if you can create a server package for it, it would have a legitimate use as a client for a server that just happens to use the same protocols as Yahoo does. But couldn't you consider a TCP port to be an interface to their service? There may be loopholes in the TOS, but I wouldn't take too many chances, especially not with Yahoo. Again, this project has been alive and running for two years, and Yahoo! definately knows about it. I've seen other people do nasty things with them and have their accounts swiftly deleted, so it has to say something that they've left me along for so long. -- Chris Howie http://www.chrishowie.com -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/IT d-(--) s:- a---? C++(+++)$ UL P$ L+++ E--- W++ N o++ K? w--$ O M- V- PS--(---) PE++ Y+ PGP++ t+ 5? X- R(+)- tv-(--) b- DI+ D++ G+++ e++ h(--)--- !r+++ y-+++ --END GEEK CODE BLOCK-- signature.asc Description: OpenPGP digital signature
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Josselin Mouette wrote: The fact is also that mixing them with a GPLed software gives an result you can't redistribute - although it seems many people disagree with that assertion now. This is only true if the result is considered a derivative work of the gpl'd code. The GPL states In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. Since the main cpu does not actually run the binary firmware, the fact that it lives in main memory with the code that the cpu *does* run is irrelevent. In this case, the Debian stance is that the kernel proper and the binary firmware are merely aggregated in a volume of storage ( ie. system memory). Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OpenOffice.org (LGPL) and hspell (GPL)
On Tue, 2004-09-21 at 11:33, Rene Engelhard wrote: Am Dienstag, 21. September 2004 12:28 schrieb Steve Langasek: Why not? If all of OOo is LGPL, then the license allows you to distribute under the terms of the GPL, so linking with another GPL library is ok. Hmm... Does this mean we would be changing the licensing of the packages from LGPL/SISL to GPL only? This may upset some users who are linking non-free modules to OOo at the moment. I'm thinking of the Finnish spellchecking and hyphenation module that Jarno Elonen packaged. Chris
Re: Fwd: reiser4 non-free?
On Thu, May 06, 2004 at 12:34:46PM -0700, Hans Reiser wrote: Please consider my distinction between a credit (public television in the USA has them), and an ad (for profit broadcast television has them). Both are ads. One just makes a poor attempt at failing to mention an actual product making a credit on PBS nearly indistinguishable from most pharmeceutical commercials. I don't find the credits annoying, I don't like the ads. Maybe the broadcasters could make more effort to make the ads less annoying and more informative, but their sense of civic duty is too lacking. I do like well funded television shows. Maybe if you'd watch more television instead of trying to be a lawyer this thread could have died long ago. I'll be blunt. Your current shenanigans, including the misuse of the term plagiarism, discourage me from recommending reiserfs and to strongly contemplate removing it from systems I am responsible for. I suspect that others have well, they just haven't bothered to tell you. Your desire to advertise, advertise, and advertise runs contrary to the Unix philosophy of Don't output a damn thing if it ran right, and frequently don't output a damn thing if it failed miserably. I don't want to see your parp. Your desire to tinker with the license flies in the face of the GPL. If you're so damned sure that your desire to put advertising in the code is right and won't alienate your users, get a lawyer that does software licenses to draw up one to your specifications and kindly shut up until you 1) Get the license drafted 2) Get all of the reiserfs copyright holders to sign off on using the license. As an alternative, perhaps you could talk with Theo DeRaadt about porting Reiserfs to OpenBSD. -- Chris Dukes Been there, done that, got the slightly-charred t-shirt. -- Crowder
Re: Fwd: reiser4 non-free?
On Thu, May 06, 2004 at 12:54:22PM -0700, Hans Reiser wrote: Chris Dukes wrote: 2) Get all of the reiserfs copyright holders to sign off on using the license. I have licensing rights to all of reiserfs in all versions. You do not have copyright on code contributions that came from outside of namesys, unless the copyright was released to you by the author. You currently have licensing rights under GPL2 over all of that code. As I said, shutup and talk with a lawyer. -- Chris Dukes Been there, done that, got the slightly-charred t-shirt. -- Crowder
Re: Fwd: reiser4 non-free?
On Mon, May 03, 2004 at 08:49:10PM +0300, Markus Törnqvist wrote: [SNEEPAGE] Perhaps this is overly cynical but... In this day and age people only seem to care about proper attribution when either 1) Looking for another garbage novel to read. 2) Looking for someone to sue. The former seems to be covered by having the author's name in bigger type than the title of the novel. The latter, it doesn't matter how well the credits are buried, the presumed targets will be served. So as a compromise can we have hansreiserfs* as the prefix on all packages. HANSREISER as the prefix on all executables, kernel symbols, fstypes... Frequent use of bold and blink for the text HANS REISER as well. I don't know about other folks, but the credits filling my terminal windows and logs get first dibs on catching the blame on whatever may be going wrong with my computer. -- Chris Dukes Been there, done that, got the slightly-charred t-shirt. -- Crowder
Re: ASL2 vs. GPL?
On Thu, Feb 26, 2004 at 11:28:21AM +, MJ Ray wrote: I think AF and FSF are still talking. I hope so! Does anyone know for sure? Shall we let them finish before involving ourselves? I'm a little concerned about people who might take the AF's word on the matter and waste time starting projects that could turn out to be undistributable. I thought that issuing some sort of official statement, even if it's just to say, we have doubts, might alert people that it's not necessarily that simple, and might even help get the dialog between the AF and FSF moving again, if it's stalled. can we avoid unnecessary work? That's the other option, yes. But while I can't claim it's necessary, I can claim that it might be useful (see above), and if it's not a lot of work (especially if we just announce that we have doubts), it might be worth it. This may not have developed into a real problem _yet_, but it potentially affects some pretty critical and widely used software, unlike a lot of the seriously obscure and trivial programs whose licenses we do spend a lot of time on. (I'll try not to mention Cthugha by name...whoops, I just did.:) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Cypherpunks anti-License
On Wed, Feb 25, 2004 at 08:41:05AM -0500, Anthony DeRobertis wrote: Licensing The CPL is not a license, it does not require the user to do or not do anything They don't seem to know what the word license means. Perhaps we can all chip in and buy them a dictionary! :) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
ASL2 vs. GPL?
With the Apache Foundation publicly disagreeing with the FSF over whether the new Apache Source License 2.0 is compatible with the GPL, I think it might be wise for us to look into the matter and form our own opinions, so that (e.g.) if someone submits code that mixes the two licenses, we'll know how to respond. The AF rebuttal to the FSF is found here: http://www.apache.org/licenses/GPL-compatibility My initial impression is that their analysis is flawed. In particular, where they point to section 3 of their own license, and section 7 of the GPL, they say, In other words, the GPL says that you cannot redistribute software that is covered by a patent wherein the patent is not licensed free for everyone. I don't think that's a correct rephrasing of section 7. The portion of section 7 they highlight says, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. However, this is just an example, and is clearly marked as such. My back-of-the-cocktail-napkinrebuttal to the AF's rebuttal is simple: the GPL requires that patent licenses be compatible with the GPL. It does not require that patent licenses be compatible with any other licenses (free or not). The ASL2 requires that patent licenses be compatible with other licenses (specifically, the ASL2). Therefore, the ASL2 has requirements beyond those found in the GPL. Therefore, the ASL2 is not compatible with the GPL. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
[mdadams@ece.uvic.ca: Re: JasPer licensing wrt Debian Linux]
I got the following email back from Michael. So with the clarification below that it is not allowed to use the JPEG-2000 part of the code for non-standards based work make it non DFSG free? If so is there anyway to make it DFSG free and still uphold their wishes as stated below? Thanks, Chris Cheney - Forwarded message from Michael Adams [EMAIL PROTECTED] - Envelope-to: [EMAIL PROTECTED] Delivery-date: Wed, 27 Aug 2003 20:17:19 -0500 From: Michael Adams [EMAIL PROTECTED] X-X-Sender: [EMAIL PROTECTED] To: Chris Cheney [EMAIL PROTECTED] Subject: Re: JasPer licensing wrt Debian Linux X-Spam-Status: No, hits=-4.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) On Fri, 22 Aug 2003, Chris Cheney wrote: I am the maintainer of KDE for Debian Linux and it came to my attention that KDE 3.2 adds support for JasPer. However, it has been previously[0] determined that JasPer does not meet the DFSG guidelines[1] for free software so cannot be included as is in the main part of Debian. The particular part that the -legal people have a problem with is section F. Is it possible for you to strike this section of the license? Dear Chris: The license has been revised slightly in recent months, but I have not released a new version of the software with this revised license. Clause F reads as follows in the revised version of the license: F. The JPEG-2000 codec implementation included in the JasPer software is for use only in hardware or software products that are compliant with ISO/IEC 15444-1 (i.e., JPEG-2000 Part 1). No license or right to this codec implementation is granted for products that do not comply with ISO/IEC 15444-1. There are two reasons for the above clause: 1) The technology used in the JPEG-2000 standard is covered by patents. The patent holders (for which there are several) are only allowing their patented technology to be used for implementations that are compliant with the standard. For this reason, if anyone uses a hacked non-JPEG-2000-compliant version of JasPer's JPEG-2000 codec in their software, they would be breaking the law. As an extra level of legal protection for the contributors to JasPer, we explicitly disallow ILLEGAL patent-infringing use of the software. [Incidentally, to the best of my knowledge, none of the JasPer contributors hold patents on core JPEG-2000 technologies.] 2) We do not want hacked non-JPEG-2000-compliant versions of JasPer being used, since this would cause major interoperability problems, totally defeating the purpose of having an international image-compression standard in the first place. If your lawyers are worried, they really ought not to be. We (i.e., the JasPer contributors) do not have any secret evil motivations behind Clause F in the JasPer license. This clause is only to prevent ILLEGAL non-interoperable use of the JasPer software. The original wording of Clause F did not make clear that JasPer can be used to build non-JPEG-2000 products. For example, you can remove the JPEG-2000 codec support from JasPer and create a product without JPEG-2000 support without violating the terms of the JasPer license. What this clause does say is: IF YOU USE THE JPEG-2000 CODEC IN JASPER, then you must not introduce changes to the codec that would cause it to be NONCOMPLIANT with the JPEG-2000 standard. If you did this, you would be infringing on at least several patents. With the above said, is the JasPer license really not not good enough for your purposes? I mean, why would KDE want to use JasPer's JPEG-2000 support in order to create a mutant non-interoperable JPEG-2000 clone that infringes on at least several patents? Sincerely, Michael --- Michael Adams, Assistant Professor Dept. of Elec. and Comp. Engineering, University of Victoria P.O. Box 3055 STN CSC, Victoria, BC, V8W 3P6, CANADA Tel: +1 250 721 6025, Fax: +1 250 721 6052, Office: EOW 403 E-mail: [EMAIL PROTECTED], Web: www.ece.uvic.ca/~mdadams - End forwarded message - pgp7XpyVSmRQ6.pgp Description: PGP signature
Re: SURVEY: Is the GNU FDL a DFSG-free license?
On Aug 21, Branden Robinson wrote: === CUT HERE === Part 1. DFSG-freeness of the GNU Free Documentation License 1.2 Please mark with an X the item that most closely approximates your opinion. Mark only one. [ ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, is not a license compatible with the Debian Free Software Guidelines. Works under this license would require significant additional permission statements from the copyright holder(s) for a work under this license to be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, is a license compatible with the Debian Free Software Guidelines. In general, works under this license would require no additional permission statements from the copyright holder(s) for a work under this license to be considered Free Software and thus eligible for inclusion in the Debian OS. [ X ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, can be a license compatible with the Debian Free Software Guidelines, but only if certain restrictions stated in the license are not exercised by the copyright holder with respect to a given work. Works under this license will have to be scrutinized on a case-by-case basis for us to determine whether the work can be be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] None of the above statements approximates my opinion. Part 2. Status of Respondent Please mark with an X the following item only if it is true. [ X ] I am a Debian Developer as described in the Debian Constitution as of the date on this survey. === CUT HERE === Chris -- Chris Lawrence [EMAIL PROTECTED] - http://blog.lordsutch.com/ pgpxGZT8UL2oQ.pgp Description: PGP signature
Re: Linux kernel complete licence check, Q.15
On Nov 24, J.B. Nicholson-Owens wrote: Giacomo Catenazzi wrote: * All the material in this file is subject to the Gnu license version 2. I think this is ambiguous. Both the GNU GPL or the GNU LGPL have a version 2 revision; the currently in-use and well-known GNU GPL and an older release of the GNU LGPL as the FSF tells us: In the context of the Linux kernel, the GPL/LGPL issue is not important, as the LGPL-GPL conversion clause means both can be treated as the GPL. Of course, with the FDL on the way, that adds some ambiguity; it's best to get a clarification from the original author(s) or copyright holder(s), if possible. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi 125B Lewis Hall - 662-915-5765
LZW patented file left in .orig.tar source package?
Hi debian-legal, Can someone say whether I may leave a file that implements a patented algorithm (LZW compression for GIFs) in the source tarball for OpenOffice.org? The file is not built or distributed - I have patched the build to use a dummy version of the class that does nothing [1]. Thanks, Chris - Forwarded message from Sander Vesik [EMAIL PROTECTED] - Date: Wed, 16 Oct 2002 18:30:48 +0100 (BST) From: Sander Vesik [EMAIL PROTECTED] Subject: Re: [dev] packaging integration To: Dev Office dev@openoffice.org On Wed, 16 Oct 2002, Chris Halls wrote: Yup, people like me also have to remove the patented file when redistributing the source, BTW. Why remove the source? you arn't infringing on anything (AFAIK) if you just include the source that is then not used? [...] - End forwarded message - [1] http://cvs.debian.org/oo-deb/debian/patches/905_remove_lzwc.diff?rev=HEADcvsroot=debian-openofficecontent-type=text/vnd.viewcvs-markup pgp4OLVHstU6S.pgp Description: PGP signature
Re: Knuth statement on renaming cm files and Licence violation.
On Sep 04, Russ Allbery wrote: I don't find your argument particularly persuasive; it seems to be very strong on emotion without a lot of logic to back it up, or without any real discussion of what you're trying to defend and why. The Debian Project has a philosophical commitment to protecting the freedoms of the users of software that it calls free. These freedoms are spelled out in the Debian Social Contract and Debian Free Software Guidelines. You can argue whether the freedom to rename some particular file is important or not, but that's largely beside the point as far as Debian is concerned; it is possible for reasonable people to disagree about the relative importance of that (or any other) freedom. However, we believe that irrespective of whether we intend to exercise the particular rights in question, possessing them (and, more importantly, ensuring our users possess them) is important. For example, the DFSG has a paragraph about non-discrimination. Debian has no intention of setting up a nuclear power plant, but a license that restricts people who own nuclear power plants from using our software [licenses like this do, in fact, exist] is unacceptable. Similarly, Debian has no intention of violating Prof. Knuth's request that the Computer Modern fonts not be replaced without renaming them, yet we are unwilling to call them free unless our end users have the freedom to do so. (Leave aside whether Prof. Knuth's request is legally binding; his statement that the fonts are in the public domain suggests that no request of his regarding the fonts is legally binding, although his wishes should not be lightly disregarded.) Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi 125B Lewis Hall - 662-915-5765
Re: GPL-script to be run on a non-free interpreter
On Aug 04, Ralf Treinen wrote: Is it OK to distribute a script, which is - licencend under GPL. - intended to be executed by a non-free interpreter. [..] When I sent my ITP on debian-devel today, Moshe Zadka claimed that even distributing maria-viz would be illegal. http://lists.debian.org/debian-devel/2002/debian-devel-200208/msg00188.html Can please someone advise whether this is really the case? I do not believe the Free Software Foundation interprets the GPL in this manner. After all, some GNU software includes code that is only intended to work with non-free compilers and make implementations. I believe there is GPL'ed software in contrib that requires certain (non-free) Java class libraries as well. The issue in the case of this program is perhaps even more narrowly cast, since there is a free alternative to (at least some of) graphviz (http://www.chaosreigns.com/code/springgraph/), and it is entirely possible to develop a free alternative for the particular interpreter in question. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5765 pgpLeAT7n8agw.pgp Description: PGP signature
Re: Towards a new LPPL draft
On Jul 22, Boris Veytsman wrote: The question is, who should say yes and no? Sorry for being ignorant about the rules -- but is there a mechanism of voting or other decision taking of the list? How it is formally initiated? The only formal procedures available are: - Action by the Debian project leader. - Action by the technical committee - if this issue is deemed technical as opposed to non-technical. My guess is they would deem it non-technical and pass the buck. - Action by the developers as a whole through the General Resolution procedure. Additional de facto procedures: - Acceptance of or failure to accept an upload of a new package with the given licen[cs]e by the Debian ftp administration team. (Doesn't help in this case anyway, since you're still drafting.) - Consensus on the debian-legal list. In practice, the de facto procedures are always followed. Chris [no cc needed] -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5765 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Jul 19, Boris Veytsman wrote:
The problem is, the first paragraph quoted above is not true. There
are precedents when people changed important parts of TeX and LaTeX
and distributed these changed files without clearly labeling them as
such. AFAIK, there were only good intentions on the part of the
perpetrators, but the damage was real. LPPL was crafted to prevent
these things to happen again.
How does the LPPL actually prevent a distributor from FUBARing their
distribution of LaTeX? The fact is people regularly ignore licenses,
copyrights, patents and trademarks (if this weren't the case, there'd
be almost no GIFs or MP3s in the world).
To put it another way: If you don't trust people to do the right
thing, no license will help you.
So, you are defending abstract principles against a very unlikely
danger. LaTeX people see a real danger in changing their way. What is
a pure abstraction for you (most of the people on debian-legal
probably never used LaTeX in their everyday work) is an important
issue for them -- and for us, end users.
I *do* use LaTeX in my every day work. I also recognize that someone
might want to make a derived work of LaTeX (say MyLaTeX) without
having to engage in unreasonable amounts of bookkeeping or bizarre
filename hacks (i.e. without recoding the parser to add my to the
beginning of every package that is \usepackage{}d since they had to
rename every single file in the distribution that they touched) and
without breaking compatibility with their own source files (i.e. so
they can run mylatex blah.tex where blah.tex is valid input to latex).
In fact, pdflatex depends on this very ability, but since the LPPL
only trusts the anointed of the LaTeX3 Project to do this in a trivial
manner, I couldn't make a tifflatex or pcllatex without going through
silly bureaucracy (renaming files, hacking macros to search for my
modified versions of .cls and .sty files with messed up names, etc.)
that Frank doesn't have to engage in.
Having said that, I'd be pissed if typing latex myfile.tex was
arbitrarily different from system to system. But again, if you
require modified versions of LaTeX to not be called LaTeX and not be
invoked by typing latex, this surprise problem goes away. So,
again, the IMHO reasonable thing to say is:
1. latex should always refer to unmodified LaTeX as distributed by LaTeX3
2. If you modify any part of LaTeX, you must either:
a. call the entire derived work something other than LaTeX, and
invoke it with something other than latex, or
b. distribute modified files within LaTeX under different names, and
include unmodified versions of those files.
Note the word or there. If the derived work is bobslatex or
rubberfetish or whatever you want to call it, 2(b) goes away because
the derived work no longer calls itself LaTeX and is not expected to
behave like standard LaTeX. However, if you represent your derived
work as being standard LaTeX (by calling it LaTeX), the behavior
should be consistent with standard LaTeX for all macro packages
defined in standard LaTeX.
Chris
--
Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi
208 Deupree Hall - 662-915-5765
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Distributing GPL Software as binary ISO
On Jul 18, Martin Schulze wrote: The current status quo: a) Company A collects .deb files from Debian and builds an ISO file that runs the system (life system). This ISO only contains binary packages, no source. This CD is sold and distributed freely through the internet. When asked about the source of the binary CD, company A points to ftp.debian.org. b) An entity B (could be a company, or a single person, or a project) lects .deb files from Debian and builds an ISO file that runs the system (life system). This ISO only contains binary packages, no source. This ISO image is distributed freely through the internet and is sold on CD at an exhibition. When asked about the source of the binary CD, B points to ftp.debian.org. Questions: 1. Is either a) or b) in complience with the GPL (assuming all software is licensed using the GNU GPL. 2. Is a) or b) in complience with the DFSG aka OSD? 3. Is it a problem if ftp.debian.org removes the source of the same version of a package that is used on the cd and installs a newer version? (i.e. source of a package is available, but not exactly the proper source). 4. What would be the proper way to solve this problem if a) or b) are not in complience with the license terms? In case (4), it would be up to the individual copyright holders of the packages contained on the CDs. My general thought on 1-3 is that they could be construed as violations of the license if someone were to push the issue. If that were the case, the following policies would probably have to be adopted by anyone offering CDs of Debian (including myself): 1. Refuse to sell binaries without source. This makes Debian 100% more expensive to produce, and possibly means that distributors will only distribute a subset of Debian to reduce the logistical nightmare of producing 12 CD-Rs, but the buyer is the one that bears the brunt of that problem. (i.e. if Bob wants Debian, he has to have the source for everything, and I won't sell him anything without that source included. Bob Newbie is now paying for 6 to-him coasters in addition to 6 binary CDs.) 2. Refuse to offer any ISO images on the Internet. (That means ssh relativity.phy.olemiss.edu rm -rf /var/www/debian-cd, in English) This insulates the distributor from liability under the I got binary from you 2 years and 364 days ago, so I demand the source clause of the GPL, because there's no way the purchaser could get binaries without source. It also makes Debian a royal pain in the ass to distribute at low cost, but that's the legalities of it. (However, this is only actionable if a buyer attempts to exercise his rights under the GPL - unless and until that happens, the distributor is not violating the license. He only violates the license if and only if he fails to meet the buyer's demand for the equivalent source at a reasonable price. Furthermore, this has never been tested in court so it is unclear whether providing a later version of the source would be sufficient, or what a reasonable price might be. For example, if A distributes Debian without source, and nobody complains that they didn't get source, A is not violating the GPL per se.) In other words: you have opened a massive can of worms. :-) Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: User's thoughts about LPPL
On Jul 16, Boris Veytsman wrote: To summarize: I think LPPL strikes a necessary balance between standardization and flexibility. This balance was tested by 20+ years of TeX, which is licensed under exactly same conditions. I don't think anyone here has a problem with a license that says If your LaTeX doesn't pass such and such a validation suite, you can't call it LaTeX, but you can do whatever else you want to do with it. I think the real issue is that the LaTeX project is trying to use its license to enforce a norm of good behavior by distributors that would be much better left to certification marks or a Knuthian statement that if you break it, both pieces are yours and you are the one who will get bitched at, not us. I think that's being obfuscated behind Branden's establishment of hypotheticals that can be dealt with through \renewcommand and the like. I think Frank et al's concerns could be addressed fairly easily by requiring distributors of modified versions of the entire LaTeX suite to document the changes and include the location of that documentation in the diagnostic output of latex, and requiring distributors of modified versions of separately-distributed style/class files to do the same, with a waiver of the documentation requirement if the file/suite is renamed (thereby not misrepresenting the modified version as any longer being a substitute for the original). This certainly would pass the DFSG and would clearly inform users of what sort of LaTeX they're getting. For example, if I modify article.dtx, I must either rename it (thereby no longer calling it article.dtx) or include diagnostic output showing where on the local filesystem a file is that clearly documents the differences between article.dtx as distributed by the LaTeX3 project and my article.dtx (for example, corrected typo in line 300 that stopped articles with fewer than 83 pages from having more than 17 footnotes.) Then again, maybe I'm missing the point :-) Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ pgphu9zxJdYdC.pgp Description: PGP signature
Endorsements (was Re: GPL compatibility of DFCL)
Wouldn't the endorsements issue be best resolved by licensing the endorsements separately from the rest of the document? i.e. the core content could be under the DFCL (unambiguously free GPL compatible) while endorsements, odes to pets, etc. would be under a separate license of the original author's choosing. The only other thing I can think of is some sort of author severability clause (kind of like the use of Alan Smithee by film directors): a provision that states any modification to sections A, B, or C of the text requires the removal of the original author's name from the text and/or a clear statement that the text is a modified version of the author's work. IMHO that wouldn't run afoul of the DFSG, as it is similar in spirit to DFSG clause 4. (Admittedly, some people dislike the patch files section of Clause 4, but this wouldn't be a patch files situation - it's analogous to the rename or re-version portion.) That way if someone edits the GNU Manifesto to add RMS likes goats halfway through, RMS can say you can't call that the GNU manifesto any more, even though I do, in fact, like goats, and while you're at it take my damn name off! (*). Don't mind me, I'm not really awake :-) Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[wlandry@ucsd.edu: Re: Bug#140103: ITP: alliance -- VLSI CAD system]
Oliver: Please see the attached discussion regarding the licensing of alliance. Can you provide us with a clarification of your intentions? Is it your intention for the licensing of alliance to be in full compliance of the GPL? -- Chris Ruffin [EMAIL PROTECTED] - Forwarded message from Walter Landry [EMAIL PROTECTED] - From: Walter Landry [EMAIL PROTECTED] Date: Mon, 01 Apr 2002 17:54:08 -0800 (PST) To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], debian-legal@lists.debian.org, [EMAIL PROTECTED] Subject: Re: Bug#140103: ITP: alliance -- VLSI CAD system X-Mailer: Mew version 2.2 on Emacs 21.1 / Mule 5.0 (SAKAKI) Chris Ruffin [EMAIL PROTECTED] wrote: I was a little concerned about that as well, but my (uninformed and possibly incorrect) conclusion was that this contradiction in their licensing text was a dispute between the developers of the software and the author of the GPL. AFAIK the addition of the requirement to mention the BSD-style acclamation doesn't violate anything in the DFSG, and to my knowledge doesn't invalidate the GPL. After all the BSD license meets the DFSG. Is it really up to us to resolve this? The notification clause is incompatible with the GPL. They are being inconsistent. It would be best to ask for a clarification. Until then, Debian shouldn't distribute it. In any case, they could write their own license which is basically the GPL with this added restriction. That might even be DFSG-free, though the use restriction makes it annoying. It would also be incompatible with anything else under the GPL. Phrasing it as a request would be much more polite, and wouldn't require surgery on the GPL. I don't know exactly what this software does, but they could also have the software insert the phrase into the output, much like Latex2HTML does. Regards, Walter Landry [EMAIL PROTECTED] - End forwarded message - pgpY8PN9y8xzE.pgp Description: PGP signature
Re: teTeX Documentation Licenses
On Mar 10, C.M. Connelly wrote: There are about 30 documents (and the stuff they document) whose licensing status is less clear, and those are the ones that I have some questions on. I have included some example copyright/distribution statements based on those in this ``unknown'' category, and I would appreciate a quick take from debian-legal habitues on whether they are DFSG-free, and, in particular, whether we can continue to distribute files with copyright/distribution statements similar to the examples. To the best of my knowledge, none of the attached licenses are DFSG-free, with the possible exception of the guy who goes on about GNU-style stuff (who needs to properly license the file). The one that's written in French I can't be certain of, but I suspect it's not DFSG-free either. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
Re: Legal status of using a GPL'd LD_PRELOADed with a non-GPL'd app ...
On Mar 07, Timshel Knoll wrote: I've posted an ITP[1] for libtrash, a library that uses LD_PRELOAD to intercept application calls to unlink(), rename(), open(), fopen(), freopen() and other system calls which may delete/truncate files, and moves them to a trash can rather than deleting them. My question is this: libtrash is licensed under the GPL, and the LD_PRELOAD is likely to allow non-GPL'd (including non-free) binary code to use it. The binary code is not actually linked with libtrash, however. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=137108repeatmerged=yes Branden Robinson seems to think that the distribution of this is OK, but suggested that I bring this discussion to the -legal forum. Any ideas on this? The GPL really only applies when you are distributing a GPL'd work linked to a non-GPL'd work. Using LD_PRELOAD is not distribution, so I can't see how this would pose a problem. The only exception I can think of is if someone distributed a script like (lame example): #!/bin/sh LD_PRELOAD=/your/hack/here /usr/bin/nonfree-application That case might be problematic from a legal standpoint, and might be worth mentioning in README.Debian. Even there, the legal issue is somewhat ambiguous, though I think the FSF's position would be that this is infringement (it certainly violates the spirit of the GPL). But the script is incredibly trivial, so it's hard to argue that even it is infringement (especially since an end-user doing this independently wouldn't be infringement, and you could tell an end-user how to do this in documentation). Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
RE: WARNING: Crypto software to be included into main Debian dist ribution
] That's not true. Ignorance of the law (regardless of your lawyers advice) ] is no excuse. For that matter, even if a government official told you that ] some activity was okay, that does not absolve you from breaking the law. ] Your attorney (or a government official) does not have the power to create ] an exception to an illegal activity. ] ] Without legal advice received in the context of an attorney-client ] relationship, as far as the law cares I received no legal advice at all, ] and I lack one defense to charges that intentionally violated the BXA. ] ] I'm afraid that the attorney-client relationship doesn't mean anything in ] this regard. You were given legal advice. That's all. You can take it or ] leave it. However, you are responsible for your activity. All that you ] have been given by the lawyer is some advice as to how to minimize your ] risk. It is still up to you to decide whether or not to do the given ] activity. The court will hold you (and only you) accountable for that ] activity. If you rely on a lawyer's advice, and that advice proves to be ] bad, the court can still find you guilty. In that event, your only recourse ] against the lawyer is a suit for malpractice, which you can try to conduct ] from jail. At that point, the notion of the attorney-client relationship ] would be central to your malpractice case, the absense of which would ] definitely hurt. ] ] Incidentally, intentional with respect to the BXA means that you intended ] to do the act (regardless of whether or not you considered the act to be ] legal or not). The court will look to see if you intended to do the act, ] not whether you intended to break the law. ] ] That being said, it is my opinion that Debian was given sound legal advice ] from HP on this matter. ] ] BTW, I am a lawyer. Ron - I'm the attorney for SPI that has been trying to help out with various matters, one of which is the IRS obligations of SPI as a non-profit. The defense of reliance on advice of counsel does exist for certain matters, such as willful evasion of income tax obligations of corporations, and would certainly be a mitigating factor for offenses that require some element of intent. See, e.g., United States v. Gonzales, 58 F.3d 506, 512 (10th Cir. 1995) (Reliance upon advice of counsel is a defense that the defendant must establish.) citing Liss v. United States, 915 F.2d 287, 291 (7th Cir. 1990). We would be glad to have you also sign on as an attorney for SPI if you are truly interested in helping out, and you could then provide advice based on a full understanding of what has transpired, instead of based on a not-complete understanding. Chris Rourk Akin, Gump, Strauss, Hauer Feld, L.L.P. 1700 Pacific Avenue, Suite 4100 Dallas, Texas 75201 (214) 969-4669 (214) 969-4343 fax The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.
Re: Latex Project Public License
On Feb 19, Alexei Kaminski wrote: I am the current maintainer for the package revtex, which is a collection of LaTeX style files to be used in manuscripts submitted for publication in the journals published by the American Physical Society. The license of the upstream version 3.1, which makes the current revtex package, prohibits taking money for the distribution or use of the files except for a nominal charge for copying, etc. It makes the upstream version 3.1 inelegible for debian/main. Recently, version 4 of the upstream product has been released, under the Latex Project Public License (http://www.latex-project.org/lppl.html). My question for debian-legal is: Does the Latex Project Public License satisfy the Debian Free Software Guidelines? My understanding is that in general it does not, due to the clause You may not modify in any way a file of The Program that bears a legal notice forbidding modification of that file, but revtex's upstream version 4 can still be considered as free since none of its files bears such a notice. I believe that interpretation is correct; in the same vein, other licenses (the OPL, for example) have optional clauses that, when not invoked, pass the DFSG. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi 125B Lewis Hall - 662-915-5765
Re: mpsql - why is it non-free?
On Tue, Dec 25, 2001 at 09:39:36PM -0700, toff wrote: I am thinking about applying to become a maintainer, and was looking through the orphaned packages. mpsql caught my eye, as my day job is usually 9-to-5 SQL, and my boss has asked me to look into pgsql for our company. So potentially I could have some time to work on this. Anyway, I saw that it is in the non-free distribution. I just wondered why that was. I searched the debian-legal archives all the way back, not a peep about mpsql. And the license seems innocuous enough to my (admittedly untrained) eye: Answering myself, when I looked at the full copyright, it has a portion (called libhelp) licensed under a restrictive NCSA Mosiac license. So now I understand. If I excised the help library, I believe it could be free. Is there a more standard help utility in X besides Gnome Help Browser (which I really like)? I think this help library provides context-sensitive help. -- *--v- Installing Debian GNU/Linux 3.0 v--* | http://www.debian.org/releases/woody/installmanual | | debian-imac (potato): http://debian-imac.sourceforge.net | |Chris Tillman[EMAIL PROTECTED] | | May the Source be with you | **
mpsql - why is it non-free?
I am thinking about applying to become a maintainer, and was looking through the orphaned packages. mpsql caught my eye, as my day job is usually 9-to-5 SQL, and my boss has asked me to look into pgsql for our company. So potentially I could have some time to work on this. Anyway, I saw that it is in the non-free distribution. I just wondered why that was. I searched the debian-legal archives all the way back, not a peep about mpsql. And the license seems innocuous enough to my (admittedly untrained) eye: --- excerpted from README MPSQL - An Interactive Query Tool for PostgresSQL This directory contains version 2.1 of MPSQL. The author can be reached via Email: [EMAIL PROTECTED] or visit http://www.mutinybaysoftware.com MPSQL is not public domain software. It is copyrighted by Mutiny Bay Software but may be used according to the licensing terms of the the copyright at the end of this document. --- 8 Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies. IN NO EVENT SHALL MUTINY BAY SOFTWARE BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF MUTINY BAY SOFTWARE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. MUTINY BAY SOFTWARE SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN AS IS BASIS, AND MUTINY BAY SOFTWARE HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. --- end excerpt - The orphan announcement says upstream is no longer maintaining this package, but I have cc'd the listed address. I'd rather work on free software, but since this could have work applicability, I thought it would be worth checking into. Does anyone see a reason this is non-free? -- *--v- Installing Debian GNU/Linux 3.0 v--* | http://www.debian.org/releases/woody/installmanual | | debian-imac (potato): http://debian-imac.sourceforge.net | |Chris Tillman[EMAIL PROTECTED] | | May the Source be with you | **
Re: PROPOSED: interpretive guidelines regarding DFSG 3, modifiability, and invariant text
I'm wading into dangerous waters here, methinks... :) I think Branden's proposal is well-intentioned, but ultimately the wrong approach to dealing with this problem. I think the standard that should be applied is not about kilobytes or percentages, but whether or not the licensing restrictions on ancillary materials harm the ability to make derivative works. For example, in the case of GNU Emacs, we have the misc directory full of all sorts of philosophical ramblings on various topics. None of them have anything to do with Emacs; we could completely rewrite Emacs without anything there being affected. So their non-freeness doesn't seem to harm anything. On the other hand, if the GNU Emacs manual had a non-free license on the parts dealing with the operation of the program, then we might have a problem. At least in the case of documentation and other ancillary materials regarding software, the line seems pretty clear-cut: if the materials document something that could change as a result of changing the program, they should be free; otherwise, who cares? I realize the case of 3 pages of documentation with 100 pages of lame novella isn't covered here; in that case, I would expect the maintainer's judgement (is the 100 pages of lame novella worth 3 pages of worthwhile text... my gut feeling says no) to take over. If it isn't associated with software at all, ancillary materials probably don't have a place in Debian. For example, the text of Martin Luther King Jr's Letter from a Birmingham Jail (copyrighted, non-DFSG-free) has no place in Debian, even though it is an incredibly eloquent piece of writing, because it has nothing to do with computer software. I don't know about the edge case of standards documentation, etc (doc-html-w3, for example) that I'm sure most of us would agree isn't in the same category as the acknowledgements in the GNU manuals. There's a case to be made for exceptions for things that are standards (I certainly wouldn't want people promulgating a modified version of the National Electrical Code, for example), but I think my proposed criteria wouldn't address that case, leaving it verboten as before. I realize this leaves the door open for the inclusion of great volumes of perjorative or simply annoying ancillary documentation in Debian; today Linux-and-GNU, tomorrow Geeks-with-Guns, next week my great collection of poetry I wrote in secondary school. On the other hand I can't see a fair way to include all of GNU Emacs, including the (IMHO) crap in misc, without opening the door to rafts of other crap anyway without a if RMS wrote it, it's OK exception that smacks of hypocrisy. And since I don't see either RMS removing that material or us excising it from our package of emacs over his objections, the only way forward is some sort of *gasp* exercise of reasonable judgment by maintainers. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ pgpPKzWwaqHwv.pgp Description: PGP signature
Re: OpenOffice and Java
On Oct 21, David Starner wrote: On Sun, Oct 21, 2001 at 02:58:22PM +0400, Peter Novodvorsky wrote: With current jdk license it cannot be put in non-free, right? In this case, openoffice cannot be put in main nor in contrib nor in non-free. It can be placed in contrib. free packages which require ... packages which are not in our archive at all for compilation or execution (interesting that it can't require a package in non-us, but it can require one not in the archive.) FWIW, OpenOffice will install and run without Java on the system, at least if you use the binaries at openoffice.org. There's no reason why we can't have a separate openoffice-java in contrib for people that want the Java support. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Instructor and Doctoral Student, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5765
Re: DFSG status of DFARS clause?
On Oct 14, Aaron M. Ucko wrote: [Please Cc: me on replies.] For the record, does All Rights Reserved. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 (Oct. 1988) and FAR 52.227-19(c) (June 1987). in a license violate the DFSG? DFARS: http://www.acq.osd.mil/dp/dars/dfars/html/r20011001/252227.htm#252.227-7013 In the current DFARS, this appears to be subparagraph (b). Frankly the whole thing looks like a confusing mess but it appears to obligate the federal government to respect copyright law except in cases where software was developed exclusively with government funds. I recommend finding a lawyer. I really don't see anything in DFARS that would restrict the ability of the U.S. government to use any DFSG-free software, though it's possible DFARS may give them additional rights not granted by license (in which case you could argue that the restricted rights legend actually discriminates against non-government users) in certain cases, particularly if the entire project was government financed. I could only see this as a problem with something that was GPLed or otherwise copylefted (ex: GPLed software that is financed by the govt could be modified by the govt and combined with non-GPL-compatible software); a BSD-style license (which I think Tcl/Tk is under) doesn't restrict derived works anyway. If anything, it seems like a separate license for the government, which may or may not be the same thing as a discriminatory license... though we generally don't argue that dual-licensed software is non-free unless all of the licenses aren't DFSG-free and/or the range of all possible software users isn't covered by a DFSG-free license; e.g. GNU Ghostscript 6.51 is GPLed, but it was also licensed under the AFPL [as Aladdin Ghostscript 6.50] before being freed, and Aladdin licenses copies of Aladdin Ghostscript under other non-free licenses, yet GNU Ghostscript is DFSG-free. (I guess the question is: if I license software under a BSD-like license, but say in the license that people who use it to build nuclear power plants, have bad breath, or hang out with Osama bin Laden have to abide by the terms of the GPL with regards to the software, would that be non-free, even though both groups are covered by DFSG-free licenses?) Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
copyright lines in debian-specific package files
I intend to adopt the package nasm-mode, but before I upload, I want to check to make sure that there isn't a problem with the: # Copyright 1999 chaos development line in debian/rules. The former maintainer put it there. Should I retain or delete it? Is it simply a copyright without a license? Please reply directly. -- Chris Ruffin [EMAIL PROTECTED] pgpmMqExNVR0j.pgp Description: PGP signature
Re: Bug#82116: README.why-python2 does not accurately describe licensing issues
On Jan 13, Gregor Hoffleit wrote: thanks for the feedback! You're welcome :) On Sat, Jan 13, 2001 at 12:34:13PM -0600, Chris Lawrence wrote: I would add at least a pointer to the Python community's response to this issue, Which was like what ? Can _you_ give _me_ a pointer to that response ? The only kind of response I noticed was much /.-like noise a la 'RMS is a moron, let's ignore him.', technical discussions on whether that clause would also apply in Germany, or just silence. I really don't know what the Python community thinks about this issue. I think the community doesn't know either ;-/. What I do know is that people at Digital Creations are aware of the fact that there are mixed emotions about that license, and that Guido himself is very much aware of that, too. I can't find any coherent community response either; I see lots of lawyers yelling past one another, but the community doesn't care. It sounds like you think that that license is compatible with the GPL. Would you agree with my conclusion that we should follow the wish of the FSF and not mix their GPL code with Python 2 code ? I'm really open to other opinions here, since I'm no lawyer. I really don't know what to think. I think you can plausibly argue that the GPL is intended to be interpreted under the laws of the state of Massachussetts. The question is whether specifying how to interpret the terms of another license affects how the GPL would be interpreted, no? And more importantly, does it make any difference? i.e. if I have GPLed code imported by a Py2L'ed program, and there is some licensing dispute, does the fact the Py2L'ed program's licenses will be interpreted under California and/or Virginia law make the GPL have to be interpreted under those laws too? My common sense says no, but common sense != the law. I don't know what all of this means. Erring on the side of caution, we probably should not link Python2 stuff against GPLed stuff, not because the FSF says it's bad voodoo, but because the licensing issues are unclear. My only concern is that we (as a project) probably should rely on our own legal counsel in making a final decision, rather than accepting one side's lawyers' viewpoints on faith. To be fair, the KDE licensing issue was (surprisingly) much more clear-cut. I really don't know if this jurisdiction thing passes the laugh test... Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Computer Systems Manager (Physics Astronomy, 125 Lewis, 662-915-5765) Instructor, POL 101 (Political Science, 208 Deupree, 662-915-5949)
Clarified Artistic License
) rename any non-standard executables so the names do not conflict
with standard executables, which must also be provided, and provide
a separate manual page for each non-standard executable that clearly
documents how it differs from the Standard Version.
d) make other distribution arrangements with the Copyright Holder.
{+e) permit and encourge anyone who receives a copy of the modified Package
permission to make your modifications Freely Available
in some specific way.+}
4. You may distribute the programs of this Package in object code or
executable form, provided that you do at least ONE of the following:
a) distribute a Standard Version of the executables and library files,
together with instructions (in the manual page or equivalent) on where
to get the Standard Version.
b) accompany the distribution with the machine-readable source of
the Package with your modifications.
c) give non-standard executables non-standard names, and clearly
document the differences in manual pages (or equivalent), together
with instructions on where to get the Standard Version.
d) make other distribution arrangements with the Copyright Holder.
{+e) offer the machine-readable source of the Package, with your
modifications, by mail order.+}
5. You may charge a [-reasonable copying-] {+distribution+} fee for any
distribution of this Package. [-You-]
{+If you offer support for this Package, you+} may charge any fee you choose
for [-support of this
Package.-] {+that support.+} You may not charge a {+license+} fee for {+the
right to use+}
this Package itself. [-However,
you-] {+You+} may distribute this Package in aggregate with
other (possibly
[-commercial)-] {+commercial and possibly nonfree)+} programs as part of a
larger (possibly [-commercial)-] {+commercial and possibly nonfree)+} software
[-distribution-] {+distribution,
and charge license fees for other parts of that software distribution,+}
provided that you do not advertise this Package as a product of your own.
{+If the Package includes an interpreter,+} You may embed this Package's
interpreter within an executable of yours (by linking); this shall be
construed as a mere form of aggregation, provided that the complete
Standard Version of the interpreter is so embedded.
6. The scripts and library files supplied as input to or produced as
output from the programs of this Package do not automatically fall
under the copyright of this Package, but belong to whoever generated
them, and may be sold commercially, and may be aggregated with this
Package. If such scripts or library files are aggregated with this
Package via the so-called undump or unexec methods of producing a
binary executable image, then distribution of such an image shall
neither be construed as a distribution of this Package nor shall it
fall under the restrictions of Paragraphs 3 and 4, provided that you do
not represent such an executable image as a Standard Version of this
Package.
7. C subroutines (or comparably compiled subroutines in other
languages) supplied by you and linked into this Package in order to
emulate subroutines and variables of the language defined by this
Package shall not be considered part of this Package, but are the
equivalent of input as in Paragraph 6, provided these subroutines do
not change the language in any way that would cause it to fail the
regression tests for the language.
8. Aggregation of [-this-] {+the Standard Version of the+} Package with a
commercial
distribution is always permitted provided that the use of this Package
is embedded; that is, when no overt attempt is made to make this Package's
interfaces visible to the end user of the commercial distribution.
Such use shall not be construed as a distribution of this Package.
9. The name of the Copyright Holder may not be used to endorse or promote
products derived from this software without specific prior written permission.
10. THIS PACKAGE IS PROVIDED AS IS AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
The End
---
Chris
--
Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
Computer Systems Manager (Physics Astronomy, 125 Lewis, 662-915-5765)
Instructor, POL 101 (Political Science, 208 Deupree, 662-915-5949)
Re: Clarified Artistic License
On Dec 09, Joseph Carter wrote: On Sat, Dec 09, 2000 at 01:00:10PM -0600, Chris Lawrence wrote: ncftp 3.0.2 comes under something called the Clarified Artistic License. It looks DFSG-free, but I'm not certain. Here's the text: [..] I wish people would adopt thie clarified license.. Based on the wdiff, it's a vast improvement. Nothing changed seems non-free, but I didn't give it a good reading to compare it with the GPL if someone else would like to do that. (ncftp can use readline can it not?) The 3.0 series doesn't natively, but there is a patch that allows it. The old Artistic license wasn't GPL-compatible, so I had to disable that patch; I don't know at first glance whether this clarified version is or not. Frankly, the upstream author doesn't seem to understand all of the licensing issues and thus he could easily GPL the 3.0 series as he as done the 2.0 series, but I think he won't be all that educable on that point after the grief he got on the 2.0 series and readline. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Computer Systems Manager (Physics Astronomy, 125 Lewis, 662-915-5765) Instructor, POL 101 (Political Science, 208 Deupree, 662-915-5949)
PalmOS SDK license
FAIL OF ITS ESSENTIAL PURPOSE. SEVERABILITY: In the event any provision of this License Agreement is found to be invalid, illegal or unenforceable, the validity, legality and enforceability of any of the remaining provisions shall not in any way be affected or impaired and a valid, legal and enforceable provision of similar intent and economic impact shall be substituted therefor. The headings used in this Agreement are for convenience only and shall not be considered part of the Agreement. ENTIRE AGREEMENT: This License Agreement sets forth the entire understanding and agreement between you and 3Com, supersedes all prior agreements, whether written or oral, with respect to the Software and subject matter hereof, and may be amended only in a writing signed by both parties. Palm Computing, Inc., a subsidiary of 3Com Corporation 1565 Charleston Road Mountain View, California 94043 (650) 237-6000 -- end included file -- -- Chris
Re: Free Pine?
On Wed, Aug 30, 2000 at 12:03:44PM +0200, Christian Surchi wrote: On Tue, Aug 29, 2000 at 05:56:28PM +0300, Juhapekka Tolvanen wrote: http://home.sol.no/~egilk/mana.html I was curious to see it, but I can't download. Ftp server does not allow anonymous connection... I found a copy at ftp://ftp.kvaleberg.com/pub/mana-4.0beta.tar.gz, I guess it's a mirror. A whole lot of warnings when trying to compile it, but it looks interesting. Chris A -- Chris Allegrettahttp://www.asty.org I can't be calm, no no no no no no. I'm the MASTER of the MECHANICAL *STUFF*! And I have to HELP YOU! - Artemis Gordon, Wild Wild West
Re: Free Pine?
On Tue, Aug 29, 2000 at 12:01:47PM -0500, David Starner wrote: Whoa! Isn't this the program that RMS said the University of Washington threatened to sue them over? That's a good question. Someone had pointed me to this program in a message awhile back, and in a nutshell said you're wasting your time with nano. I think some official word from either RMS and/or UW is in order so we can get this whole mess straight once and for all. Now an even better question: has anyone been able to retrieve the file listed on the page? It would be nice to be able to examine this enticing package =-) Chris A -- Chris Allegrettahttp://www.asty.org I can't be calm, no no no no no no. I'm the MASTER of the MECHANICAL *STUFF*! And I have to HELP YOU! - Artemis Gordon, Wild Wild West
Re: Chemical modelling software
Drew Parsons [EMAIL PROTECTED] writes: my name is Drew Parsons, I'm in the queue to become a Debian maintainer and= am waiting to be processed. My training has been in theoretical chemistry and therefore I'm interested in having the best available chemical modelling programs in Debian. Currently Debian has rasmol, maintained by Randolph Chung, which is a fine program, but does not support the particular file format I have occasion to use (BIOSYM's .car/.arc format, if you're wondering). You may want to look at babel to convert them to a format that rasmol can read. I'm not sure if babel would fit the DFSG either, though it may be possible to persuade the authors to change to a licence that does. At http://smog.com/chem/babel/README.txt it says: -- BABEL LICENCE Babel version 1.1 Copyright (C) 1992,1993,1994 by Pat Walters and Matt Stahl Dolata Research Group Department of Chemistry University of Arizona Tucson, AZ 85721 [EMAIL PROTECTED] This software is provided on an as is basis, and without warranty of any kind, including but not limited to any implied warranty of merchantability or fitness for a particular purpose. In no event shall the authors or the University of Arizona be liable for any direct, indirect, incidental, special, or consequential damages arising from use or distribution of this software. The University of Arizona also shall not be liable for any claim against any user of this program by any third party. PLEASE REGISTER --- We don't want any money for Babel (unless of course you insist), but we would like to know who has a copy so that we can notify people about updates and bug fixes. You can register by sending e-mail to [EMAIL PROTECTED] and letting us know the following: -who you are -where you are -what platform you're running Babel on -which file conversions you commonly use We are very open to suggestions. If there's anything you like or don't like about the program please let us know. Also if there are file formats you would like to see supported let us know. -- END BABEL LICENCE There are a couple of other alternatives available, and I'd like to check with you at debian-legal to see if one of them fits with Debian's free-software guidelines. The programs I'm aware of are: - xmol (http://www.msc.edu/msc/docs/xmol/ftp.html) - viewmol (ftp://ccl.osc.edu/pub/chemistry/software/SOURCES/C/viewmol/) - molden (http://www.caos.kun.nl/~schaft/molden/molden.html) ghemical http://www.uku.fi/~thassine/ghemical/ is available under the gpl, though I've not used it. http://cds3.dl.ac.uk/cds/util.html may also provide some useful links. Babel may not be ideal however as the above URL links to bedlam which claims: In common with the various CDS utilities, BEDLAM handles crystallographic data better than BABEL I'm not sure if bedlam is distributed though. http://www.ccp14.ac.uk/ may also provide some useful links to software. Chris
Re: QT Designer _NOT_ under QPL.
On Aug 11, Peter S Galbraith wrote: This was on the kde-licensing mailing list two days ago. Just FYI. [snip] Well, I guess we know where Troll came up with their name... Chris, who wonders if we ignore Troll maybe they will just go away... ;-)
Re: Bug#68652 acknowledged by developer (dosemu has clickwrap license)
On Aug 06, Brian Ristuccia wrote: If the clickwrap license doesn't go away, dosemu should move to non-free. [...] Show me where the DFSG prohibits software from using clickwrap licenses. (Incidentally, *our boot floppies* display the license and require confirmation to continue... they don't specifically ask that you accept the license, but that's a moot point.) Chris -- = | Chris Lawrence | Your source for almost nothing of value: | | [EMAIL PROTECTED] | http://www.lordsutch.com/ | || | |Open Directory Editor |Visit the Lurker's Guide to Babylon 5:| | http://dmoz.org/ |* http://www.midwinter.com/lurk/ *| =
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
On Feb 17, Andreas Pour wrote: [...] I don't see why, after you've gone to such pains to establish that the on a module license doesn't change when a module is linked with a GPLed program. Why have you decided that this is a necessary step for this case? B/c the LGPL says so. It says you can change the license to GPL, but then it is no longer under the LGPL. Now you want to have it both ways. However, the LGPL prohibits it. Apparently you can't read and/or comprehend English. I mailed this morning that just because something is put under the GPL once, that does not necessarily mean that everyone else has to use it under the GPL too. Your ignorance of this fact (and your not challenging it) imply that all you're doing is trolling. Besides which, this is irrelevant to your example of grep+libc, since in linking grep with libc you don't modify any of libc's code, nor do you patch libc with code that would make it come under the GPL. The LGPL permits you to make derivative works of the library under either the GPL or the LGPL. That does not mean that once you do this (which we haven't anyway), you can never make another derivative work under the LGPL, or even that you have to treat the original under the GPL for ever and in eternity (which is what you seem to imply in this paragraph). Go away. Find something else to do. Build your own damn distribution if you can't find something more constructive. We're tired of your bullshit and your inability to assimilate new ideas (for example, that you're wrong). Chris -- Chris Lawrence [EMAIL PROTECTED] Senior Research Assistant, SSRL Opinions and attitudes expressed herein are rarely shared by my employer.
Re: Compuclick Ltda - Debian Vendor Page
On Feb 09, Branden Robinson wrote: On Wed, Feb 09, 2000 at 01:30:12PM +1100, Craig Small wrote: COMPUCLICK IS AUTHORIZED MANUFACTURER OF THE OFFICIAL CD OF DEBIAN AND BY EACH CD THAT YOU BUY TO US YOU CONTRIBUTE TO AUTOMATICAMENTE A DOLAR TO ALL PROJECTS DEBIAN/GNU BY INTERVAL OF FOUNDATION SPI What kind of crap is this? Who taught this person English? Binding legal terms should be written in clear, unambiguous, grammatic, and spell-checked language. It's a Babelfish translation of a sentence written in Spanish (the word automaticamente sort of gives it away). The original Spanish sentence looked reasonably correct, so I doubt it's Compuclick's fault. (Also, it doesn't seem to discuss legal terms; it's just a statement about the fact they make CDs.) So I guess the person to blame works for Compaq. Chris -- = |Chris Lawrence | Get rid of Roger Wicker this year!| | [EMAIL PROTECTED]| http://www.lordsutch.com/ms-one/ | | | | | Open Directory Editor |Are you tired of politics as usual?| | http://dmoz.org/| http://www.lp.org/| =
Re: Copyright lawyers analysis of Andreas Pour's Interpretation
On Feb 10, Don Sanders wrote: Secondly I showed him Andreas Pour's XFree license comment, which contains a copy of the Xfree license: http://lists.kde.org/?/=kde-licensingm=94950776505271w=2 * He agreed that software licensees have no inherent right to relicense software under a more restrictive license. * He agreed that one could not relicense software under the XFree license+++ under the GPL, as the XFree license prohibits this. [...] +++ The XFree license allows sublicensing under certain conditions. I don't think you would have any right to relicense software you didn't write. I think the issue is whether or not a derived work incorporating part of the XFree86-licensed code can be licensed under the GPL (or any other license that doesn't contradict the terms of the XFree86 license), and I don't see anyone here arguing that it can't. (Having said that, Debian's XFree86 implementation includes code under 6 separate licenses, 3 of which are identical in their substance, varying only in who they indemnify; 5 of these licenses are propogated from upstream.) If this were not the case, then Sun, HP, et al. could not bundle a proprietary X implementation (including closed-source X servers) with their operating systems. Chris -- = | Chris Lawrence | You have a computer. Do you have Linux? | | [EMAIL PROTECTED] | http://www.linux-m68k.org/index.html | || | | Debian Developer |Visit the Lurker's Guide to Babylon 5:| | http://www.debian.org/ |* http://www.midwinter.com/lurk/ *| =
Re: On interpreting licences (was: KDE not in Debian?)
is not licensed under the GPL. To put it another way, the end-user has all the rights provided by the GPL (actually, he has more, since he can incorporate it into proprietary software, provided he only uses my code and not Readline). Where this gets you in trouble is where you don't fulfil the requirements of section 2(b) in your original license. For example, if I distributed the same software under a M$-style EULA, I would be violating section 2(b) because the end-user would not have the same rights as those provided by the GPL. Whether or not the actual components are licensed under the GPL is irrelevant. What is relevant is that no permissions granted by the GPL are abridged by any of the components. The (regex) Qt. licenses abridge those permissions (in the case of the QPL, ever so slightly. Same deal with the BSD Advertising Clause). Chris -- = |Chris Lawrence| The Linux/m68k FAQ | | [EMAIL PROTECTED] | http://www.linux-m68k.org/faq/faq.html | | || | Open Directory Editor| Are you tired of politics as usual?| | http://dmoz.org/ | http://www.lp.org/ | =
Re: Why Debian's webpages aren't DFGS-free ?
On Feb 02, Joey Hess wrote: I brought this up on debian-www some time back, and I thought we agreed to change it to something free. I am rather pissed off that my work on the web pages (DWN) continues to go out under this license. If something isn't done soon, I may move future issues, and keep the copyright, rahter than assigning to SPI as I have done so far. Sigh. The solution seems rather obvious: Don't assign the copyright and use your own license. I can't see a problem with putting pages on the web site that have a less restrictive license than the SPI copyright. As a matter of fact, there can't be a problem, because the web site hosts documents under the GPL and other licenses. Chris -- = |Chris Lawrence| The Linux/m68k FAQ | | [EMAIL PROTECTED] | http://www.linux-m68k.org/faq/faq.html | | || | Open Directory Editor| Visit the Lurker's Guide to Babylon 5: | | http://dmoz.org/ | * http://www.midwinter.com/lurk/ * | =
Re: Double Standard?
On Jan 31, David Johnson wrote: I didn't check for every GPL application that uses Qt, only one example is sufficient. The package licq 0.44-4, in stable, uses the Qt library, along with being licensed under the GPL. It does not have any additional clauses at all. I looked. I didn't find any. Please report these instances as bugs against the packages and ftp.debian.org; if these are actual violations of the license, it will be removed (whether part of KDE or not). That may even include removal from stable in 2.1r5. As someone else pointed out here, licq does have the QPL exception clause. For the hell of it, I examined the copyright of every package in potato I could find that depended on either libqt1g or libqt2 (excluding the trivial cases of the -dev packages). tuxeyes (qt1): contrib. Has a MIT/X-style license, and thus is Qt ok. qweb (qt1): contrib. GPLed w/o Qt exception; this appears to be a violation. I am opening a release critical bug to that effect. qcad (qt2): main. GPLed with Qt exception. licq-plugin-qt2 (qt2): main. GPLed with Qt exception. xexec (qt2): main. GPLed, apparently w/o Qt exception. Bug filed. qps (qt2): main. GPLed, apparently w/o Qt exception. Bug filed. xsidplay (qt2): main. GPLed, with Qt severability clause. xgmod (qt2): main. Minimalistic license, so Qt ok. regexplorer (qt2): main. Appears to be QPLed itself. qbrew (qt2): main. MIT/X style license, thus Qt ok. So, of 10 packages, 7 have the clause (or don't need one, since they have minimal licenses that don't contradict the Qt ones). The other 3 are likely to be removed very soon. I may have missed some (I used apt-cache showpkg on the two library packages; if there is such a thing as a static Qt, it's possible other packages include Qt code). Chris -- = |Chris Lawrence| Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED] |http://www.lordsutch.com/cds/ | | || | Grad Student, Pol. Sci.| Visit the Lurker's Guide to Babylon 5: | | University of Mississippi | * http://www.midwinter.com/lurk/ * | =
Re: KDE not in Debian?
If you have something to say, say it to the lists. (This will be my last post on this topic, barring egregious factual errors that need correction---mine or those of others.) You haven't required it, AFAIK, from Gnome or other programs that link with X. And under your reading of the GPL (at least if you agree with the others I have been debating this issue with), if Qt is incompatible with the GPL, so is XFree. Oh right, it would really suck if you couldn't distribute XFree, so you can just ignore that transgression. Or am I missing something? (Please respond to my post with Message-ID [EMAIL PROTECTED] so I don't have to drown this list in repeating it). XFree is not distributed under a license more restrictive than the GPL. Qt is. That's it. End of story. From section 2 of the GPL: These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. There are no provisions of the XFree license that stop XFree code from being aggregated with GPLed code (the result being GPLed). By contrast, the QT FREE EDITION LICENSE (which is what Qt 1 is distributed under) specifically forbids the modification of Qt: Your software does not require modifications to Qt Free Edition. Nothing in the X license forbids modification of X by third parties. You are also forbidden from distributing modified versions of Qt1; nothing in the XFree license prohibits distribution of modified versions (see, for example, xfs-xtt, which is based on XFree's xfs implementation). As far as the QPL (Qt2) license goes, I leave the discussion to Joseph Carter, who actually helped Troll write it (with the specific intent of allowing Qt2 applications to be pure GPL) before the lawyers got involved. My belief is that the provisions that might require you to give your source code to Troll, even if the binary code is not distributed to others, were the most egregious (the GPL only obligates you to give source code to people you give binaries to; if you don't give someone binaries, you don't have to give them source either). For example, if I modify Emacs, RMS can't demand that I give him my changes unless I give him a binary of my modified Emacs; however, if I make a modified Qt2 (to create my own whizz-bang desktop that only I use), or even a program based on Qt2, Troll can demand a copy of it. That seems more restrictive than the GPL to me; I'm amazed it even meets the DFSG. Anyway, if you've followed this thread, you know that Debian has also thrown out (or not let in) other software with ambiguous license terms. XForms and Motif-based programs have gotten the same treatment (as have Qt-based programs from people other than KDE). Chris -- = |Chris Lawrence | Get rid of Roger Wicker this year!| | [EMAIL PROTECTED]| http://www.lordsutch.com/ms-one/ | | | | | Debian Developer|Are you tired of politics as usual?| |http://www.debian.org/ | http://www.lp.org/| =
Re: Was Re: KDE not in Debian?
On Jan 29, Andreas Pour wrote: (3) real permission to distribute from the authors. I do not quite know what you mean by this, but if you mean that to conform to your practice noted above of confirming from package authors that packages can be distributed by Debian, I will see if I can get the core KDE developers to send you their approval that you distribute KDE code. Mail me privately please if you think it is worth any effort and I will get started on it. It's a bit more complicated than that with some of the KDE software, because the GPL does not technically permit the linking of software against libraries that have licenses more restrictive than the GPL (like the QPL, which has restrictions on for-profit use on Win32). If all of the code in a particular KDE app is written by KDE members, all we need is something like: KFlarg is (C) 1999 Foo and Bar. You may use and distribute KFlarg under the terms of the GNU General Public License, version 2 (or a later version, at your discretion). As a special exception, you may also link KFlarg against the Qt widget library. (I forget the exact phrasing we decided was appropriate; but, some stuff that uses XForms in contrib uses it. I do know the correct version is longer). However, there are several instances of software in KDE being repackagings of existing software, with some work to integrate it into KDE (I am told KGV fits into this category). In these cases, because not all of the work was done by the KDE group, we also need permission from the author of the original software (GV in this case) to link against the GPL-incompatible software. [Personally, I think if you wrote the software yourself and link it against Qt, it's pretty obvious from a legal standpoint that you accept people linking it against Qt. However, if you take someone else's software and do the same thing, I can't see how we (or anyone else) can interpret that as acceptable. A lot of people have made a possibly erroneous assumption that authors like that of GV won't consider linking against Qt an abuse, and there are plenty of fat targets out there for a lawsuit (Corel, Red Hat, Caldera...).] Chris -- = | Chris Lawrence | Your source for almost nothing of value: | | [EMAIL PROTECTED] | http://www.lordsutch.com/ | || | |Open Directory Editor | Are you tired of politics as usual? | | http://dmoz.org/ | http://www.lp.org/ | =
Re: Was Re: KDE not in Debian?
On Jan 30, Andreas Pour wrote: [Personally, I think if you wrote the software yourself and link it against Qt, it's pretty obvious from a legal standpoint that you accept people linking it against Qt. I think so too. So why not just exclude kgv and kfloppy and distribute the rest? Because I'm not part of the Cabal (TINC). Seriously, it's the contrast between a meritless lawsuit and no lawsuit at all. Meritless lawsuits are expensive; we'll get back to you after we IPO. Ask the css-auth victims... (I guess I'm missing the reason why it's so hard to get people to explicitly say you can link this against Qt; that apparently would satisfy the FTP maintainers and let KDE 1 into contrib [and KDE 2 into main]). Chris -- = |Chris Lawrence| It's 2/3 of a beltway... | | [EMAIL PROTECTED] | http://www.lordsutch.com/tn385/ | | || | Open Directory Editor| Visit the Lurker's Guide to Babylon 5: | | http://dmoz.org/ | * http://www.midwinter.com/lurk/ * | =
Re: Bug#56166: base-files: copyright in motd is outdated (fwd)
On Jan 25, Santiago Vila wrote: Well, my question is more a do we really want to claim ownership of it? than a do we really have the right to copyright Debian as a whole?. I remember that the Simtel archives were reorganized some time ago so that all the free software (including djgpp and the GNU software) was put out of the collection (of which Simtel claimed a compilation copyright). [ Maybe this was done upon RMS request, I don't know ]. Is claming ownership of Debian as a whole within the spirit of the free software world? So long as we use a DFSG-compliant license for the distribution, I can't see a problem. There may be a weakness in that we don't have an explicit license for the distribution, though. In any case, SPI holds the copyright whether or not we announce it to the world or not (per discussion about the Berne Convention)... If we DO need a license for the distribution, something short and to the point (do whatever the hell you want with it, but don't sue us) seems reasonable enough; I like Branden's license for the X packages personally. === Copyright 1996-2000 Software in the Public Interest, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL SOFTWARE IN THE PUBLIC INTEREST, INC. BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of Software in the Public Interest, Inc. shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from Software in the Public Interest, Inc. === In essence: Don't sue us, don't use SPI's name as an endorsement, but otherwise go forth and multiply. The Python license makes the same basic point, but you have to fiddle with the wording some if you're not CWI ;-) Chris -- = |Chris Lawrence |Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED]| http://www.lordsutch.com/cds/ | | | | | Open Directory Editor |This address has been spam-proofed.| | http://dmoz.org/| All spam goes to your postmaster. | =
Re: freedomization task list [was: Re: Dangerous precedent being
On Dec 13, Henning Makholm wrote: Tomasz Wegrzanowski [EMAIL PROTECTED] writes: What kind of free licence make such situations possible ??? (for me it is not free even a little bit if author can change his mind and take away your freedom) I'm told that under American law, a promise that is made without getting something tangible (a consideration) in return cannot be legally binding. That would seem to allow any free software license to be revoked as soon as the author wants to. I might be wrong, though. Can one of the American law guys comment? This month's Linux Magazine has an article about this subject (and related concepts). It is possible that the right of future access to source code could be considered consideration, since the software would not have been used in the absence of that right. IANAL, of course, and this has never been litigated. My gut feeling is that a court would never rule the GPL as invalid, though, if only because there are virtually no positive ramifications of such a ruling (because if the GPL is invalid, then NOBODY can use GPLed code... it wouldn't revert to the public domain, which is the only benefit that an overturned GPL might have to proprietary software companies!). Chris -- = |Chris Lawrence| Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED] |http://www.lordsutch.com/cds/ | | || | Open Directory Editor| Visit the Lurker's Guide to Babylon 5: | | http://dmoz.org/ | * http://www.midwinter.com/lurk/ * | =
Re: Free Download End User License Agreement
On Dec 02, Tomasz Wegrzanowski wrote: On Thu, Dec 02, 1999 at 03:13:14AM -0600, Chris Lawrence wrote: On Dec 02, Anthony Towns wrote: They seem to be put off by liability issues, etc. And no doubt the risk of having their idle comments paraded about on slashdot isn't exactly an incentive. It seems to me, then, that we need a debian-legal-private list. I dunno how we'd handle subscription, etc., since obviously not all developers are interested in -legal issues. Then we can invite selected people from VA (if you want to call their disc with O'Reilly a separate distro), Corel, Stormix, whoever in to discuss these things, without creating slashdot headlines. You are closing development. I understand the need of a few registered-maintainers-only lists, but such Council-Of-Big-And-Important-Persons is completely against the spirit of free software. The next step will be making a corporation and monopolize GNU/Linux. 1: This list has nothing to do with development; it deals with licensing issues of third-party software that we wish to incorporate into Debian. As such, it's not closing development. 2: The Council of Big and Important Persons would actually be more inclusive than a registered maintainers only list, because people proposing licenses, who are not Debian developers, would be allowed to participate as well as existing developers. It seems to me that such a list is a way to have a more inclusive review of licenses than simply having people email (say) Bruce or ESR privately, which is what happens now. Not that Bruce doesn't do a good job, but I think we (the free software community) need more pairs of eyes so he doesn't get fed up with doing the job. And it lets people like Corel or the KDE group float trial balloons that won't get posted to Slashdot. As for your next step, there's no way to monopolize GNU/Linux, because there are virtually zero barriers to entry in the Linux business. Chris -- = |Chris Lawrence| Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED] |http://www.lordsutch.com/cds/ | | || | Debian Developer | Visit the Lurker's Guide to Babylon 5: | |http://www.debian.org/| * http://www.midwinter.com/lurk/ * | =
Re: Bruce Perens's Slashdot debacle
On Dec 03, Frank Copeland wrote: Robert Merkel wrote: Like it or not, debian is an open project. In the conventional media, if the news doesn't come from a press release it's standard procedure for the person or organisation concerned to have the opportunity to comment before the story is published. Slashdot ain't the media, conventional or otherwise. Nobody published a story. This isn't a story? http://slashdot.org/article.pl?sid=99/11/26/1450245mode=thread Chris -- = |Chris Lawrence |Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED]| http://www.lordsutch.com/cds/ | | | | | Debian Developer|Join the party that opposed the CDA| |http://www.debian.org/ | http://www.lp.org/| =
Re: Bruce Perens's Slashdot debacle
On Dec 04, Frank Copeland wrote: Chris Lawrence wrote: On Dec 03, Frank Copeland wrote: Robert Merkel wrote: Like it or not, debian is an open project. In the conventional media, if the news doesn't come from a press release it's standard procedure for the person or organisation concerned to have the opportunity to comment before the story is published. Slashdot ain't the media, conventional or otherwise. Nobody published a story. This isn't a story? http://slashdot.org/article.pl?sid=99/11/26/1450245mode=thread Nope. It's someone starting a thread in a discussion group by forwarding a message from another discussion group. It happens all the time in newsgroups and mailing lists. Characterising Slashdot as the media and trying to put the blame on them for not applying irrelevant journalistic standards is an exercise in messenger-assassination. Yes, but the top level of Slashdot isn't a thread; it's an article. And it is moderated, because only certain people can approve stories for the front page. This isn't the first time /. has gone off half-cocked, turning five lines of text into a flamefest. The people there need to start exercising some quality control on what they post, instead of jumping on the first message in a thread in a mailing list. Chris -- = |Chris Lawrence |Visit my home page!| | [EMAIL PROTECTED]| http://www.lordsutch.com/chris/ | | | | | Debian Developer|Are you tired of politics as usual?| |http://www.debian.org/ | http://www.lp.org/| =
Re: Free Download End User License Agreement
On Dec 02, Anthony Towns wrote: They seem to be put off by liability issues, etc. And no doubt the risk of having their idle comments paraded about on slashdot isn't exactly an incentive. It seems to me, then, that we need a debian-legal-private list. I dunno how we'd handle subscription, etc., since obviously not all developers are interested in -legal issues. Then we can invite selected people from VA (if you want to call their disc with O'Reilly a separate distro), Corel, Stormix, whoever in to discuss these things, without creating slashdot headlines. Chris -- = |Chris Lawrence| The Linux/m68k FAQ | | [EMAIL PROTECTED] | http://www.linux-m68k.org/faq/faq.html | | || | Grad Student, Pol. Sci.| Are you tired of politics as usual?| | University of Mississippi | http://www.lp.org/ | =
Re: Dangerous precedent being set - possible serious violation of the GPL
On Dec 02, Caspian wrote: Something-- SOMETHING-- must be done, or in five to ten years the Linux (and I do say Linux here, since it will no longer be GNU/Linux) The GNU/Linux term has relatively little currency outside Debian. It never has been GNU/Linux to more than a few people. I doubt you see it much except self-consciously or in the phrase Debian GNU/Linux (which gets butchered as Debian/GNU Linux half the time anyway...) In any event, my personal opinion is that Corel has the right to decide who to sell or give their software to, and who not to. They may have phrased it badly, but that's what their intent is. In any event, that decision disproves your assertion that all Corel cares about is money, since obviously they'd make more money if they were selling to minors. Under the GPL, they are only obligated not to make the you can't sell to minors restriction viral. It also seems we're venturing into debian-project territory here Chris -- = |Chris Lawrence |Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED]| http://www.lordsutch.com/cds/ | | | | | Debian Developer|Join the party that opposed the CDA| |http://www.debian.org/ | http://www.lp.org/| =
Re: is this free?
On Nov 22, Raul Miller wrote: it discriminates against people without regular internet access. Also, it effectively requires a fee for use, unless you consider the time of the person who uses it to have no value. [same issue.] It seems to be designed to protect users from being sued by anyone who might have a right to the code (other than ATT of course), since it would be illegal for you to use the code if ATT didn't have a valid right to license it in the first place. It's like me saying: I wrote this code, but there may be people in the universe who think they have rights to it. If there are, and their claims are legitimate, then it may be illegal for me to distribute the code and for you to use it (at least under the current license). I will update the license if this becomes the case. To put it another way: we're not entirely sure the schmuck who wrote this code didn't steal it from Microsoft. So we're covering our butts and yours by reserving the right to revise the license if that is actually the case (however remote the possibility). IANAL, of course. Would be nice if we had one around here ;-) Chris -- = |Chris Lawrence | You have a computer. Do you have Linux? | | [EMAIL PROTECTED] |http://www.linux-m68k.org/index.html | | | | | Grad Student, Pol. Sci. |Visit the Amiga Web Directory| | University of Mississippi | http://www.cucug.org/amiga.html | =
Re: mutt no longer in non-us?
On Nov 18, Joey Hess wrote: I still think mutt belongs in non-US. Why are people so opposed to putting it there? Putting a program like this in non-US just points out that the US government's laws are so brain-dead that they consider a mail reader a munition, thus raising public awareness of the problem. It doesn't inconvenience Debian much at all. It highly inconveniences our users, however. No part of the Social Contract says protesting stupid laws is more important than our users. It also inconveniences the Debian maintainer, who has to maintain two different forks of the same code (source and binary). It wastes space on our mirrors. It creates confusion by having multiple packages that do the exact same thing (less a system() or two). In any event, that function defines an interface. I'll gladly write a program that does not violate the US export laws that takes those parameters and processes text in some non-crypotgraphical way. # BEGIN LAME FILTER #!/usr/bin/python import sys sys.stdout.write(sys.stdin.read()) # END LAME FILTER There. That code interfaces to my stupid little cat emulator. ;-) (OK, so I didn't account for a few little niggling details. That can be fixed...) Chris -- = | Chris Lawrence | Your source for almost nothing of value: | | [EMAIL PROTECTED] | http://www.lordsutch.com/ | || | | Debian Developer |Visit the Lurker's Guide to Babylon 5:| | http://www.debian.org/ |* http://www.midwinter.com/lurk/ *| =
Re: Corel's apt frontend
On Oct 30, Bruce Perens wrote: From: Raul Miller [EMAIL PROTECTED] Sure, but a frontend isn't mere aggregation -- in this case if you take out the GPLed part of the system, the performance of that front end can't happen. Well, I'd like the law to agree with you, actually. The problem is that copyright law does not consider _reference_ a form of derivation. This would give us problem with dynamic libraries, too, except that the headers get copied into the application. I suspect a blanket prohibition on reference by non-GPL'ed software would be incredibly dumb, even if it were permitted by copyright law. It would forbid anything non-free from operating as a shell (and would even prohibit KDE programs from launching GNU software). Not to mention that it'd be impossible to launch GNU software on a non-GNU system, or even boot a GNU system in the first place (as the boot sector is referenced by a non-free BIOS or other boot rom). I really can't even see the point of forbidding non-free programs from calling dpkg... either (a) they'll reimplement dpkg as non-free software (reimplementing dpkg might be a good idea in and of itself, but a non-free dpkg is pretty worthless to everyone, and probably a source of confusion to boot) or (b) adopt another package manager. (In any event, you're talking about double-indirection here; I assume apt's authors don't give a rat's ass who calls their program, and apt is the program that runs dpkg.) Chris -- = |Chris Lawrence |Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED]| http://www.lordsutch.com/cds/ | | | | | Open Directory Editor |Join the party that opposed the CDA| | http://dmoz.org/| http://www.lp.org/| =
Re: Bug#47845: libdbd-pg-perl nonfree?
On Oct 20, Brian Ristuccia wrote: COPYRIGHT The DBD::Pg module is free software. You may distribute under the terms of either the GNU General Public License or the Artistic License, as specified in the Perl README CD-ROM or similar media for commercial distribution without the prior approval of the author. Um, what part of this copyright looks non-free to you? You can use the module under either the GPL or Artistic license, both of which are DFSG-free licenses. Ergo, it's OK to be in main, unless there's some dependency on a non-free package (which would make it appropriate for contrib). CHris -- = |Chris Lawrence |Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED]| http://www.lordsutch.com/cds/ | | | | | Debian Developer|Are you tired of politics as usual?| |http://www.debian.org/ | http://www.lp.org/| =
Re: Bug#47845: libdbd-pg-perl nonfree?
On Oct 20, Brian Ristuccia wrote: On Tue, Oct 19, 1999 at 11:24:40PM -0500, Chris Lawrence wrote: On Oct 20, Brian Ristuccia wrote: COPYRIGHT The DBD::Pg module is free software. You may distribute under the terms of either the GNU General Public License or the Artistic License, as specified in the Perl README CD-ROM or similar media for commercial distribution without the prior approval of the author. Um, what part of this copyright looks non-free to you? You can use the module under either the GPL or Artistic license, both of which are DFSG-free licenses. YoW! A bad paste on my part. It's non-free because it prohibits distribution on CD-ROM or similar media for commercial distribution without the prior approval of the author. Here's the except from man DBD::Pg in its entirety: COPYRIGHT The DBD::Pg module is free software. You may distribute under the terms of either the GNU General Public License or the Artistic License, as specified in the Perl README file, with the exception that it cannot be placed on a CD-ROM or similar media for commercial distribution without the prior approval of the author. OK, yeah, now I can see it ;-) (Having said that, I'm not sure that it's legit to make exceptions to the GPL, especially if the author used anyone else's code in the module...) Chris -- = | Chris Lawrence | Get Debian GNU/Linux CDROMs | | [EMAIL PROTECTED]| http://www.lordsutch.com/cds/ | | | | | Grad Student, Pol. Sci. | Visit the Amiga Web Directory | |University of Mississippi| http://www.cucug.org/amiga.html | =
Re: opencontent licence DFSG free?
On Oct 18, Jens Ritter wrote: What about this? Any publication in standard (paper) book form shall require the citation of the original publisher and author. The publisher and author's names shall appear on all outer surfaces of the book. On all outer surfaces of the book the original publisher's name shall be as large as the title of the work and cited as possessive with respect to the title. (from http://www.ora.com/catalog/debian/chapter/appf_01.html) Isn´t this an advertising clause like the BSD license had? This would be bad and make it non-free, doesn`t it? I wonder if it is enforceable, because every book has got 6 outer surfaces and its hard to get the information requested on the side which opens up... *eg* I don't think it's an advertising clause in the sense of the BSD advertising clause. It's more like a reasonable disclosure clause (i.e. telling people what they're buying). I assume all outer surfaces is a publishing term for the covers and spine. (Also, I'd check to see if this clause is in the release OPL at the Open Content website. The book is licensed under ANY version of the OPL, and the latest versions are a lot less strict in terms of attribution and limiting the freedom of derived works.) Chris -- = | Chris Lawrence|Get Debian GNU/Linux CDROMs| |[EMAIL PROTECTED] | http://www.lordsutch.com/cds/ | | | | |Grad Student, Pol. Sci.|Join the party that opposed the CDA| | University of Mississippi | http://www.lp.org/| =
Re: opencontent licence DFSG free?
On Oct 12, Joey Hess wrote: The whole O'Reilly debian book is online now at http://www.ora.com/catalog/debian/chapter/ The copyright is the OpenContent license, http://www.ora.com/catalog/debian/chapter/copyright.html It looks to me on a hurried reading that the opencontent license is DFSG free so long as none of the license options are invoked. Opinions? I tend to agree; my recollection is that the OpenContent License (aka OPL) was specifically designed to be compliant with the Open Source Definition (and thus the DFSG). Furthermore, I think RMS helped them write it or revise it. Chris -- = |Chris Lawrence |Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED]| http://www.lordsutch.com/cds/ | | | | | Debian Developer|Are you tired of politics as usual?| |http://www.debian.org/ | http://www.lp.org/| =
Re: NcFTP is free again?
On Sep 30, Chris Cheney wrote: I just looked at NcFTP 3.0Beta20 and it appears to have changed its license to free (no license file) and the libncftp requirement of non-use by other programs seems to have been dropped also. Maybe someone more knowledgeable than me can look at this and see if it can be packaged again. Thanks, Chris (Moved to debian-legal; please direct followups there; CC'd to the author so maybe he can shed some light on what's going on here.) I just downloaded the source code and can't find an actual license anywhere. The changelog entry reads: + Change of licensing. Specifically, GPL was shown the door. NcFTP is, has always been, and will continue to be free software. which isn't a license (at best a statement of principles). Furthermore, READLINE-README reads in part: Apparently this special free version of LibNcFTP still cannot co-exist with GPL'd stuff. which indicates that this special free version is probably not DFSG-compliant. But again, I can't see a license anywhere, so maybe it is (advertising clause maybe?). The man page says: Thanks to Red Hat Software for honoring my licensing agreement, but more importantly, thanks for providing a solid and affordable development platform. which seems to indicate that there is a license somewhere on the planet, but it's still not with the source. Or on the website. The only actual license (grep -i licen) I can find is in vis/syshdrs.h, but it's a GPL license. And he claims in the changelog that NcFTP is not GPLed. Hence I'm stumped. Since my suspicion is that libncftp (even in its special free version) is still only licensed for use with ncftp, it would seem to fail the DFSG [and Open Source Definition] on several points. Off the bat, it would fail point 3. Depending on the actual licensing terms for libncftp, I suspect it fails points 5 and/or 6 too (no commercial use of derived works?). See the DFSG at http://www.debian.org/social_contract#guidelines (and note that these guidelines are substantively identical to the OSD). Having said that, the removal of linkage to Readline probably qualifies it for the non-free section (since it is no longer in violation of Readline's license). Of course, all of this is speculative because (yes, I'm harping on this point) there is no license that I can see. So we can't do squat with NcFTP 3 until Mike includes a license. Incidentally, ncftp 2 core dumps after using ncftp 3 (the prefs files apparently confuse it); maybe we should fix that... Chris -- = |Chris Lawrence| The Linux/m68k FAQ | | [EMAIL PROTECTED] | http://www.linux-m68k.org/faq/faq.html | | || | Grad Student, Pol. Sci.|Visit the Amiga Web Directory | | University of Mississippi | http://www.cucug.org/amiga.html | =
[from -devel] Re: all rights reserved
On Sep 09, Itai Zukerman wrote: I've come across the following in one file of an otherwise GPL'ed set of code: /* simple password generator by XXX * copyright 1991, all rights reserved. * You can use this code as long as my name stays with it. */ The file builds into a stand-alone utility which is not crucial to the package (it just takes a command-line argument and invokes crypt(3), displaying the result). I'm worried that this file does not satisfy the DFSG. Would that restrict me from uploading the entire package source? Or only from including the utility in the binary package? If this is a FAQ, then please point me in the right direction. Thanks, -itai, newbie The third line seems to indicate that you can use it, so long as you don't remove XXX's name, so it is DFSG-compliant. I think. [CC'd to debian-legal for their opinions] Chris -- = |Chris Lawrence| The Linux/m68k FAQ | | [EMAIL PROTECTED] | http://www.linux-m68k.org/faq/faq.html | | || |Amiga A4000 604e/233Mhz | Join the party that opposed the CDA| | with Linux/APUS 2.2.8| http://www.lp.org/ | =
Re: License ok? Opinion needed.
On Jul 31, Mike Goldman wrote: Need a legal opinion on the following license. I assume #9 causes this to be classifiable as non-free (pity, though) -- the only other concern I had was whether #8 posed any sort of problem for our including software under this license in Debian. ... 9. GOVERNMENT RESTRICTED RIGHTS. The SOFTWARE and documentation are provided with RESTRICTED RIGHTS. Use duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of The Rights in Technical Data and Computer Software clause in DFARS 252.227-7013, or subparagraphs (c)(i) and (2) of the Commercial Computer Software -- Restricted Rights at 48 CFR 52.227-19, as applicable. Manufacturer is [Company name and address]. I suspect this is boilerplate language that got included by their lawyers' build yourself a software license in 12 easy steps software :-). Having said that, the restrictions referred to are probably provisions of U.S. law rather than ones imposed by the copyright holder. I suspect the legal effect is similar to the export restrictions clauses in licenses, as it simply restates existing law (and is unenforceable outside the U.S.) rather than imposing additional restrictions on the user. Chris -- = | Chris Lawrence | Get your Debian 2.1 CD-ROMs | |[EMAIL PROTECTED] |http://www.lordsutch.com/| | | | | Amiga A4000 604e/233Mhz | Visit the Amiga Web Directory | | with Linux/APUS 2.2.8 | http://www.cucug.org/amiga.html | =
Re: Is it illegal to distribute Linux kernel? KDE precedent.
On Jun 24, Brian Ristuccia wrote: On Thu, Jun 24, 1999 at 09:54:46PM +0200, Anonymous wrote: My intense observation of GNU/Debian Linux Kernel with grep -R All advertising materials * has shown drivers/net/bsd_comp.c, drivers/net/hydra.h include/linux/quota.h The situation with the Linux kernel is different than the situation with KDE because the network compression and quota drivers are modifications to the Linux kernel. KDE is not a modification to Qt. It is my understanding that : 1. Copying and modification of the Linux kernel was governed by the file commonly located at /usr/src/linux/COPYING 2. Contributors who add to or modify the Linux kernel have accepted the terms for modification as indicated by /usr/src/linux/COPYING. Otherwise, they would not have the right to modify the Linux kernel. These these changes could not exist in the first place if their contributors did not accept the license for making changes. 3. The Linux Kernel's license (The GNU General Public License) requires that all modifications be under the same license as the software being modified. so, 4. The files you mention, while they may themselves be covered by other licenses as noted in their respective source files, are covered by the GNU General Public License when distributed with the Linux kernel. The situation with bsd_comp.c is that you can't compile it into the kernel, but it can be used as a module. make config enforces this policy, even though there's no technical reason why it can't be compiled-in. The other two files are header files; all they do is define an interface, which to my understanding isn't code per se. I doubt Linus would have allowed them in otherwise. Chris -- = | Chris Lawrence | Get your Debian 2.1 CD-ROMs| |[EMAIL PROTECTED]|http://www.lordsutch.com/ | || | | Amiga A4000 604e/233Mhz| Do you want your bank to snoop? | | with Linux/APUS 2.2.8 |http://www.defendyourprivacy.com/ | =
Re: Is it illegal to distribute Linux kernel? KDE precedent.
On Jun 25, reject wrote: GNU/Debian can sure bullshit it's way out of a situation when it has to. Debian/GNU Linux Kernel takes BSD 4.3 code and includes it in Debian/GNU Linux Kernel creating a derived work but distributes it under GPL which is in direct contradiction with the original license of the BSD 4.3 code which has an advertising clause that must be respected. Suddenly this is magically made right by the above rhetoric? Please if you call me a skeptic. The rhetoric is incorrect; ask Linus if you don't believe the explanation I posted previously. He's prohibited major blocks of code from entering the kernel tree because of the BSD advertising clause (notably, the original 680x0 FPU emulator which was adapted from NetBSD), and the bsd_comp situation is consistent with other non-GPLed modules (bsd_comp just happens to be in the kernel tree). (I return you to your regularly-scheduled trollfest.) Chris -- = |Chris Lawrence| Visit my home page!| | [EMAIL PROTECTED] | http://www.lordsutch.com/chris/ | | || | Grad Student, Pol. Sci.| Visit the Lurker's Guide to Babylon 5: | | University of Mississippi | * http://www.midwinter.com/lurk/ * | =
Re: DFSG And Trademarks
On Jun 18, Jeff Licquia wrote: On Fri, Jun 18, 1999 at 02:35:02PM -, [EMAIL PROTECTED] wrote: Change the name on your package just enough to avoid all of the trademarks, because we _will_ have to fix bugs before they do, etc. Any recommendations on avoiding the trademark? Do I have to come up with a brand new name, or would something like cups-debian or debcups or dcups work OK? dcups is a double-entendre (at least in .us) and probably should be avoided... cups-debian might work; common-unix-print-sys might also be appropriate (and a bit more descriptive). And it gets around the trademark... (My understanding is that an acronym can't be trademarked under U.S. law, so the CUPS trademark may be invalid in any case.) Chris
Re: DFSG And Trademarks
On Jun 18, Jeff Licquia wrote: The code itself is GPL, so DFSG compliance isn't a problem. However, the vendors have trademarked the words CUPS, Common UNIX Printing System, and possibly a few others I'm forgetting. The license page (http://www.cups.org/LICENSE.html) has this gem: Also, since we have trademarked the Common UNIX Printing System, CUPS, and CUPS logo, you may not release a derivative product using those names without permission from Easy Software Products. I asked for a clarification from them, and got a response that talked about configuration of the source being permitted. On one level, that could mean that they're giving you permission to run './configure'; OTOH, I was talking about the possible need to change CUPS to conform to Debian policy, which could get into some major configuration. They have promised to clarify the license, but they haven't so far. This is also an issue with other things, like AbiWord. The abiword package in unstable is actually AbiWord Personal; AbiSource provides binary Debian packages (via alien, bleech) for Alpha and Intel (which leaves our other three architectures out in the cold). Who does the building determines what the program can be called, which seems rather contrary to the spirit of the DFSG, if nothing else... Of course, I can build an identical CD image to the Official (Debian) CD, but I'm wouldn't be allowed to call it the Official CD. So even within Debian there are issues. Chris -- = | Chris Lawrence | Get your Debian 2.1 CD-ROMs | | [EMAIL PROTECTED]|http://www.lordsutch.com/| | | | | Grad Student, Pol. Sci. | Do you want your bank to snoop? | |University of Mississippi|http://www.defendyourprivacy.com/| =
Re: Editor and sensible-editor
On Jun 15, Brock Rozen wrote: To clear up any confusion, the Pine (as such, pico; I believe) license has changed and that might make it eligible to be taken out of non-free. A number of problems have been discussed on -legal relative to it; most notably, that you can put it on a CD-ROM but not a Jaz disc (for example), and you can't put it with commercial software. That and the local modification business is a bit goofy; perhaps they should consider a you modify it, you change the name policy (i.e. you can't call a modified Pine UW Pine or UW PC/Pine). That would at least edge it closer to DFSG-freeness (and would certainly let binaries into non-free). Chris -- = |Chris Lawrence| Visit my home page!| | [EMAIL PROTECTED] | http://www.lordsutch.com/chris/ | | || |Amiga A4000 604e/233Mhz | Visit the Lurker's Guide to Babylon 5: | | with Linux/APUS 2.2.3| * http://www.midwinter.com/lurk/ * | =
Re: [awansink@ke.com.au: Re: Isn't a kde version of abiword illegal?]
On May 28, Darren O. Benham wrote: From what I read in FSF/GNU documentation, it's only necessary for segnifigant contributions, not a few lines of code. I think all the major contributors to Abi are employees of AbiSource.. Every thing else are seperate libraries. ... which may have their own issues. Is the LGPL (AbiWord uses glib internally) Qt-compatible? Chris -- = | Chris Lawrence | You have a computer. Do you have Linux? | | [EMAIL PROTECTED] | http://www.linux-m68k.org/index.html | || | | Amiga A4000 604e/233Mhz |Do you want your bank to snoop? | |with Linux/APUS 2.2.3 | http://www.defendyourprivacy.com/ | =
Re: cfs??? (fwd)
- Message from Hamish Moffatt [EMAIL PROTECTED] - On Wed, Apr 21, 1999 at 01:31:26AM +1000, Chris Leishman wrote: snip Also - in my research of the program it came to my notice that this code should never have been released from the US (it was developed there). Now that is out of the US are there any legal issues for debian? Good question; best to check on debian-legal. I suspect that cat's out of the bag now so we can do what we want with it. Hamish - End message - Can someone here give me a yes or no on this?? Thanks, Chris -- -- The box said Windows 95, NT or better .. so I installed Debian Linux -- Reply with subject 'request key' for PGP public key. KeyID 0xA9E087D5
Re: [URGENT] Logo license
Christian Leutloff wrote: Wichert Akkerman [EMAIL PROTECTED] writes: `liberal license' = I. Can be used by everyone II. May not be used to advertise non-free products Why shouldn't a commercial company says Yes it runs with Debian or It's a Debian based product and use the Debian logo for this purpose!? You mean proprietary? (There's certainly no reason why a commercial company that produces *free* software couldn't use it.) But I agree -- if someone wants to sell a proprietary product based on Debian (which is fine as long as they provide the source to all the parts they're legally required to provide source for), we shouldn't force them to sort through the system, find all occurances of the logo, and purge them. IMHO a liberal licence would be I. Can be used for any purpuse by everyone II. but modification is prohibited If modification is prohibited, then it can't be converted to a Yes it runs with Debian logo, since that would be modification. My original suggestion was that we allow it to be used in Debian or to refer to Debian, period. I still think that works better than any of the other suggestions I've seen. That's essentially the definition of a trademark, and, if we're not going to make the logo an official trademark, then I think we should license it *as if* it were a trademark. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
