Re: DRAFT for a GR proposal concerning the Sarge release
On Wed, Apr 28, 2004 at 10:51:32PM -0400, Stephen Frost wrote: > We're making a strong effort to paint ourselves into a corner we can't > get out of. We *need* a clarification. This assumption of the worst > possible isn't acceptable or even reasonable. Given that we need a > clarification the best we can do is get it from Linus. As I said, I don't accept this line of reasoning; if "the best we can do" to satisfy legal requirements is not enough, then it's not enough. We're arguing in circles, now, so unless somebody else has something to add, let's just disagree here. -- Glenn Maynard
Re: DRAFT for a GR proposal concerning the Sarge release
* Glenn Maynard ([EMAIL PROTECTED]) wrote: > "We can't reasonably get permission to do this" does *not* mean "therefore > let's just assume we have it". Debian makes a strong effort not to be > that sloppy and careless with licensing. We're making a strong effort to paint ourselves into a corner we can't get out of. We *need* a clarification. This assumption of the worst possible isn't acceptable or even reasonable. Given that we need a clarification the best we can do is get it from Linus. > It's clear to me that it doesn't have the weight of copyright holder, > if any GPL code owned by a third party has been integrated into the kernel > by kernel developers. It certainly has the weight of *a* copyright holder, and the distributor we receive it from. [...] > Neither John, Linus, nor the kernel developer body as a whole have the > right to be "clarifying" the license of my code. If I had personally > sent it off to Linus to be included, it might be different, but I, the > copyright holder, never interacted with any of those people. In this situation do you see yourself as likely to sue Debian or to claim we're not agreeing to your license by receiving from Linus and redistributing Linux with firmware blobs, which it isn't clear as to if they're unacceptable to the GPL or not? Personally, I doubt it, which is my point, there's something to be said for mitigating risk but it's entirely different from assuming the worst and somehow trying to work with it. By forcing us to assume the worst you've put us in a position that's not realistic and not workable. Stephen signature.asc Description: Digital signature
Re: DRAFT for a GR proposal concerning the Sarge release
On Wed, Apr 28, 2004 at 09:34:40PM -0400, Stephen Frost wrote: > If we make a reasonable attempt to get clarification on the license the > kernel is distributed under from the *source* of the kernel tarballs > that we use then that should mitigate the risk. No, it won't remove all > risk like getting agreeing clarification from everyone but that's not > reasonable to do in this case as you pointed out. "We can't reasonably get permission to do this" does *not* mean "therefore let's just assume we have it". Debian makes a strong effort not to be that sloppy and careless with licensing. > Linus is where we receive the source from, is the originator of the > kernel, originally decided the license it was going to be under, and may > very well have the largest percentage of direct copyright in the work. > It's clear, to me at least, that his interpretation has some weight. It's clear to me that it doesn't have the weight of copyright holder, if any GPL code owned by a third party has been integrated into the kernel by kernel developers. Just to be clear on the situation I'm considering: I write a piece of code to sort numbers in an interesting way, use this code in a game I'm writing, and place it under the GPL. John, a kernel developer, finds that this implementation is ideal for sorting TCP packets, and so he takes it, adjusts it a little to suit kernel use, and sends it off to Linus, who puts it in the kernel. I believe this is a normal, day-to-day scenario in free software; it's something the GPL is designed to encourage strongly. (I'm not prepared to start poking through kernel source to find examples of this, due to time constraints and lack of motivation to trudge through foreign code, but it seems self-evident to me that this happens.) Neither John, Linus, nor the kernel developer body as a whole have the right to be "clarifying" the license of my code. If I had personally sent it off to Linus to be included, it might be different, but I, the copyright holder, never interacted with any of those people. -- Glenn Maynard
Re: Problematic Software Licenses
On Wed, Apr 28, 2004 at 06:46:48PM -0600, Benjamin Cutler wrote: > Well, I didn't do the mods myself, so it's not really any work lost on > my part. Do you think attempting to contact Activision would be any help > at all? I have no idea. If you do, you should probably seek advice from the list of how best to approach that. (I don't have any recommendations, myself; it's not something I'm particularly good at.) -- Glenn Maynard
Re: Squeak in Debian?
"Lex Spoon" <[EMAIL PROTECTED]> wrote: > > > > > > I do not understand your issue about locality. The business in > > > > > question > > > > > is us, Debian. We already have a distribution server at Berkeley, so > > > > > we > > > > > already need to evaluate and comply with the laws of northern > > > > > California. > > > > > > > > The CD distributors are not part of SPI, the non-profit that holds > > > > title to the vast resources of Debian. In addition, the Debian > > > > mirrors only look at local law when evaluating whether to mirror > > > > Debian. They don't look up Northern California law. > > > > > > The individual CD distributors should not be automatically distributing > > > non-free stuff. Thus I still do not see the issue. > > > > > > It seems like our non-free infrastructure already needs to obey US > > > export law, so I do not see the issue with us meeting that license > > > condition. > > > > non-free is not part of the bxa notification scheme, because the bxa > > notifications is only available for certain type of software of which > > main is a subset. So there are still packages in non-us/non-free. > > > > I don't see why BXA notification would be required for Squeak nowadays. > It used to have some secure hashing functions in there such as MD5 and > SHA, but I just searched and those seem to be in a separate package > nowadays. People who want crytopgraphy routines in Squeak must now > download them separately from "SqueakMap". If there is nothing export controlled in Squeak, then the export control clause won't cause any problems with it going into non-free. However, that still doesn't solve the enhanced liability for the mirrors. That _is_ a basic distributability issue. > "In particular, but without limitation, the Apple Software may not be > exported or reexported (i) into (or to a national or resident of) any > U.S. embargoed country or (ii) to anyone on the U.S. Treasury > Department's list of Specially Designated Nationals or the U.S. > Department of Commerce's Table of Denial Orders. " > > The "in particular" implies that this is a normal export regulation for > the US. Does anyone know? If it is indeed normal, then what do our > non-non-US servers do about it? I believe that they do a reverse DNS lookup and make sure the IP doesn't come from any of the seven deadly countries. I don't remember it ever being explicitly acknowledged, but that is what the SPI lawyer suggested. Regards, Walter Landry [EMAIL PROTECTED]
Re: DRAFT for a GR proposal concerning the Sarge release
* Glenn Maynard ([EMAIL PROTECTED]) wrote: > On Wed, Apr 28, 2004 at 04:42:14PM -0400, Stephen Frost wrote: > > Certainly you can develop a case where it's not possible to get > > clarification on the license. That's not constructive or necessary imv. > > If it's the case, then it's the case. "Inconvenient" does not imply > "false", whether we like it or not. > > "I don't like that, so we should ignore it" isn't a convincing argument. If we make a reasonable attempt to get clarification on the license the kernel is distributed under from the *source* of the kernel tarballs that we use then that should mitigate the risk. No, it won't remove all risk like getting agreeing clarification from everyone but that's not reasonable to do in this case as you pointed out. > > Clarification from Linus on the kernel's license is sufficient for me, > > and should be for Debian. > > If Linus is not legally capable of making this clarification for all of the > code in question, then Debian must not pretend otherwise, and I see no > evidence that he is. Linus is where we receive the source from, is the originator of the kernel, originally decided the license it was going to be under, and may very well have the largest percentage of direct copyright in the work. It's clear, to me at least, that his interpretation has some weight. Stephen signature.asc Description: Digital signature
Re: Not inherently free, but inherently non-free?
On 2004-04-28 22:15:33 +0100 Florian Weimer <[EMAIL PROTECTED]> wrote: You asked for DFSG compatibility, which doesn't tell us if it's a free documentation license. That seems mostly irrelevant to whether it is a free software/DFSG-free licence.
Re: Problematic Software Licenses
Glenn Maynard wrote: This is why I became interested in understanding licenses to begin with: so I can make reasonable evaluations of them before spending time coding. It doesn't look like either of the two licenses are redistributable, even in non-free. Neither gives permission to redistribute, though it seems that they may have intended to in the second license. Well, I didn't do the mods myself, so it's not really any work lost on my part. Do you think attempting to contact Activision would be any help at all?
Re: DRAFT for a GR proposal concerning the Sarge release
Lewis Jardine wrote: > Thiemo Seufer wrote: > > >>As I understand it, Debian makes a point of considering the interests of > >>'unrelated third part[ies]', especially when it comes to the chance of > >>copyright infringement. > >So does Debian consider the interests of SCO then? They also claim > >copyright infringement. > I'd hope so, in as much as Debian provides SCO (like all other users) > with a high quality collection of Free software (No discrimination > against fields of endeavour, remember :) So we will stop to distribute Linux because of their claims? If not, why do we take some hypothetically existing kernel developer more serious than SCO, who publicly threatened to sue everyone? [snip] > >Linking means to bind some object files together. Those firmwares > >aren't distributed as object files. Which relies on the rather weak legal > >theory that compiled in > >firmware is part of a derived work, while the same firmware in > >a ramdisk image (or even a CD image) suddenly constitutes a > >collection of works. > It can be argued under the new social contract amendments that many of > these blobs are non-free, and have to go, whether or not they can be > included in the kernel image without violating the GPL. In its broadest interpretation it allows to exclude enough from Debian to render the remains useless. > If nothing else, it would make the kernel image with the firmwares and > the kernel image without the firmwares identical; loading these blobs in > at run-time would mean that kernel-blobs-non_free could be packaged > separately, saving the pain of having to maintain kernel-image and > kernel-image-non_free. Maintaining a bunch of firmware .(u)debs and keeping them in sync with their appropriate kernel version is surely more effort that two kernel packages. > >>a delayed Sarge would be annoying, but the products that are necessary > >>for an 'anally-free' Sarge would be of great benefit to users of both > >>Debian, and Free Software in general. > > > >What exactly are these great benefits? I see diminished driver support > >and a lack of documentation, or alternatively non-free as a rather > >mandatory part of a Debian installation. > > Ah. I was seeing clean-roomed/relicensed firmwares, rewritten, Free > documentation, etc. I assumed that the reason for the delay was due to > reverse-engineering, documentation, and re-licensing. Best case, I was > envisaging a back-down by the FSF over the GFDL, and the reintroduction > of much of the documentation, under a Free license. > > Surely it can't take nine months just to take out the stuff that's been > declared non-free, and not replace it at all? Nine months for the reverse engineering of a vast and increasing array of firmwares without hardware documentation is an excessively optimistic estimate. It may work for some binary drivers (which aren't the matter here), but rewriting some firmware for an undocumented and unknown system can't be done with reasonable effort. > > And this still doesn't count > > the fight if a jpeg or some font descriptions can be source. > I'm not touching that one with a 60 foot pole. > > >>Clause four of (even the unamended) social contract, in my opinion, > >>suggests that later is better than less free, and thus the amendment was > >>The Right Thing, even though it may delay Sarge. > > > >In my opinion, invoking the Social Contract is Debian's version of > >Godwin's Law. > > I'd say that it beats Godwin's Law, as the Social Contract is (at least > supposed to be :) relevant to the discussion at hand. Well, to choose a different wording: If somebody has to resort to citing from some holy book, then you know there aren't any arguments left. Thiemo
Re: Not inherently free, but inherently non-free?
From: debian-legal@lists.debian.org To: debian-legal@lists.debian.org Oops. How the hell did I pull that off? On Wed, Apr 28, 2004 at 06:15:09PM -0400, debian-legal@lists.debian.org wrote: > On Wed, Apr 28, 2004 at 11:15:33PM +0200, Florian Weimer wrote: > > You asked for DFSG compatibility, which doesn't tell us if it's a free > > documentation license. I still believe that the survey was very > > suggestive. It wasn't your intention, but simply the result of your > > belief that documentation is software, too. > > In any event, I believe the recent GR clearly states that, for the > purposes of the Social Contract, documentation is software. (Otherwise, > the DFSG would simultaneously have been renamed to the "Debian Free Stuff > Guidelines".) > > That's just my interpretation of the GR. It doesn't seem controversial to > me, since I don't believe that any interesting or convincing arguments > have been made that documentation is not software. I suspect we'll disagree > on this, of course. :) > > -- > Glenn Maynard > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Glenn Maynard
Re: Not inherently free, but inherently non-free?
On Wed, Apr 28, 2004 at 11:15:33PM +0200, Florian Weimer wrote: > You asked for DFSG compatibility, which doesn't tell us if it's a free > documentation license. I still believe that the survey was very > suggestive. It wasn't your intention, but simply the result of your > belief that documentation is software, too. In any event, I believe the recent GR clearly states that, for the purposes of the Social Contract, documentation is software. (Otherwise, the DFSG would simultaneously have been renamed to the "Debian Free Stuff Guidelines".) That's just my interpretation of the GR. It doesn't seem controversial to me, since I don't believe that any interesting or convincing arguments have been made that documentation is not software. I suspect we'll disagree on this, of course. :) -- Glenn Maynard
Re: Not inherently free, but inherently non-free?
On Wed, Apr 28, 2004 at 11:09:39PM +0200, Florian Weimer wrote: > > 2) None of the proponents of this position came up with good > >reasons why the freedoms we consider so important for software > >don't apply to documentation. > > Well, there are many reasons, but you probably won't consider them > good enough. Personally, I'm much in favor of the concept of moral > rights, and think that they still have a place in a free software > environment. > > > 3) None of the proponents of this position came up with a list > >of what should be changed in the DFSG to get the Debian Free > >Documentation Guidelines, nor did they even begin to write > >the DFDG. > > Debian has recently decided that no DFDG are needed, and despite all > the talk about this decision, nobody actually wants to reverse it. Just to be clear, did you mean to include yourself in that? From the above, it seems that you, at least, do believe that documentation should be under a different set of guidelines than the DFSG. -- Glenn Maynard
Re: Problematic Software Licenses
On Wed, Apr 28, 2004 at 03:05:53PM -0600, Benjamin Cutler wrote: > with Debian because of the first license, but I'm wondering if anybody > has any advice on if this is the sort of issue that we could "dance > around", though I'm guessing it's not. Barring that, is there any way of I'm very sure your guess is correct. Sorry. :) > The original downloads came from http://www2.ravensoft.com/source/, but > the package I'm interested in is a heavily modified version of it. This is why I became interested in understanding licenses to begin with: so I can make reasonable evaluations of them before spending time coding. It doesn't look like either of the two licenses are redistributable, even in non-free. Neither gives permission to redistribute, though it seems that they may have intended to in the second license. -- Glenn Maynard
Re: DRAFT for a GR proposal concerning the Sarge release
On Wed, Apr 28, 2004 at 04:42:14PM -0400, Stephen Frost wrote: > Certainly you can develop a case where it's not possible to get > clarification on the license. That's not constructive or necessary imv. If it's the case, then it's the case. "Inconvenient" does not imply "false", whether we like it or not. "I don't like that, so we should ignore it" isn't a convincing argument. > Clarification from Linus on the kernel's license is sufficient for me, > and should be for Debian. If Linus is not legally capable of making this clarification for all of the code in question, then Debian must not pretend otherwise, and I see no evidence that he is. -- Glenn Maynard
Re: contracts vs. licenses, OSI, and Debian (was: The QPL licence)
On Wed, Apr 28, 2004 at 05:41:23PM +0530, Mahesh T. Pai wrote: > The GNU/GPL, OTOH, does not impose an obligation on *use*. Obviously, > the FSF does not require it to be `accepted'. The policy of certain > package installation software, (typically on non-free platforms) > insisting on the display of licenses (even in case of the GPL) and > asking the user to accept them, is therefore, IMHO inappropriate. It seems like a nul op. The user doesn't have to accept the GPL to be permitted to use the software, but nothing in the license prevents an installer from asking anyway. I greatly dislike them, though, because they spread the false belief that you do need to "accept" the GPL. I also see a major general-case issue: if all of Debian used contract licenses, would I have to be prompted to agree to licenses hundreds of times, at least once for each package I'm installing? Unlike proprietary operating systems, which typically have a single license to accept for the entire package, free systems come from hundreds of copyright holders and many varying licenses. (Branden's link to some text from Rosen talks about how acceptance doesn't have to be click-wrap, but I don't see how agreeing to several hundred contracts can be made convenient without being dangerous.) -- Glenn Maynard
Re: Squeak in Debian?
Martin, it's great of you to do a summary. My thoughts included below. Henning Makholm <[EMAIL PROTECTED]> wrote: > Scripsit Martin Schulze <[EMAIL PROTECTED]> > > > | "You may distribute and sublicense such Modified Software only under the > > | terms of a valid, binding license that makes no representations or > > | warranties on behalf of Apple, and is no less protective of Apple and > > | Apple's rights than this License." > > | > > | What the heck does that even *mean*? Licenses aren't "binding"; they're > > | thinking of contracts. In fact, the whole license thinks it's a contract > > | (which is bad from the start). "Protective of Apple and Apple's rights" > > is > > | incredible vague, meaning that only this exact license is a safe license > > | for derivative works. > > > What's this? > > Insufficient data (as quoted: What the heck does this mean?). In the > absence of better information I'd prefer to err on the side of caution: > > [X] Renders the package non-distributable I do not see a problem with either issue here and think that whoever posted it was simply reading too quickly. The text seems clear to me in all areas that matter, even though I do not know what "equally protective" means, exactly, either. First, licenses that count *are* binding. Squeak-L is preventing you from shipping someone a compliant license while the real terms are under some other license; the restrictions on sublicensing Squeak-L apply to the *real* license, the license that the receiver is going to be bound by, not by any other license that you might have concocted. Squeak-L is just closing potential loopholes by tossing in the "valid" and "binding". Second, the "equally protective" aspect is giving distributors an *extra* permission that we do not plan to use. There's no need for us to distribute Squeak under anything but Squeak-L, and Squeak-L is surely "equally protective" of Apple as Squeak-L. > > | This is a forced-distribution clause. It requires that if the Modified > > | Software is given to *anyone*, it must be made "publicly available" (to > > | lots of *other* people) at no charge. This fails the dissident test and > > | the desert island test. It's also a practical inconvenience; I can't > > share > > | a modified version with my spouse without publishing it. > > > What's this? > > [X] Renders the package non-free I disagree, as posted earlier. It's not important, though, because the export regs already likely make the software not be DFSG-free. > > | "This License allows you to copy, install and use the Apple Software on an > > | unlimited number of computers under your direct control." > > > | Purports to restrict use. Doesn't allow use on computers not "under your > > | direct control", which is a substantial restriction; it probably prohibits > > | it from being installed by a Debian admin onto a Debian machine which is > > | hosted elsewhere. :-P > > > What's this? > > Confused drafting, probably leftover from adaptations of commercial > licenses that restricts the number of installations. > > I'm not convinced that this is necessarily a DFSG problem, but if one > has to get clarification from upstream about the "valid, binding > license" part above, one might just as well ask for this to be > clarified (or left out entirely). I read this as Squeak-L drawing the line between usage and distribution. If you cross the line then you do not get to use the "usage" permissions, but you can still use the "distribution" permissions. There may be a free-ness issue, in that Squeak-L may draw the line more narrowly than is assumed by DFSG; thus some DFSG "uses" would be Squeak-L "distributions", and Squeak-L distribution permissions may be insufficient for DFSG's requirements for usage. It's irrelevant, though, since Squeak-L is DFSG non-free anyway. The open question is whether we can distribute the software safely. For answering that question, we clearly need to look at the distribution provisions. -Lex
Re: Not inherently free, but inherently non-free?
Branden Robinson <[EMAIL PROTECTED]> writes: >> However, debian-legal assumes that the GFDL with invariant sections is >> non-free, and there seems to be a majority for a general rejection as >> a free _software_ license (but the poll was worded quite carefully, >> after the "software is documentation" dogma). > > I assume you're referring to this[1]. > > The poll was worded carefully, yes, but anyone who thought I was > cleverly manipulating them could have simply marked the option: > > None of the above statements approximates my opinion. > > Only 2 out of 63 respondents selected that option. You asked for DFSG compatibility, which doesn't tell us if it's a free documentation license. I still believe that the survey was very suggestive. It wasn't your intention, but simply the result of your belief that documentation is software, too. > [1] > http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200308/msg00017.html -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, di-ve.com, hotmail.com, netscape.net, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr.
Re: Not inherently free, but inherently non-free?
Anthony DeRobertis <[EMAIL PROTECTED]> writes: > I agree that this position --- and similar ones --- were voiced by > several people. However, for the sake of completeness, it should be > pointed out that: > > 1) None of the proponents of this position came up with a good > definition of "software" vs. "documentation". (Personally, > I think it may be doable for many cases, but there will be > many other things which defy classification.) No such definition is required. We could decide on a case-by-case basis, if only the decision process were more transparent. Most decisions are actually no-brainers. If there's a ambiguity of practical relevance, we could demand that the license must so permissive that it qualifies as free under all of our guidelines. However, I still hope to stumble across a proper criterion to tell Programs from Documentation. > 2) None of the proponents of this position came up with good > reasons why the freedoms we consider so important for software > don't apply to documentation. Well, there are many reasons, but you probably won't consider them good enough. Personally, I'm much in favor of the concept of moral rights, and think that they still have a place in a free software environment. > 3) None of the proponents of this position came up with a list > of what should be changed in the DFSG to get the Debian Free > Documentation Guidelines, nor did they even begin to write > the DFDG. Debian has recently decided that no DFDG are needed, and despite all the talk about this decision, nobody actually wants to reverse it. > And, most importantly, that the above three aren't on-topic here; > rather, they belong on -project or (in the event of a proposal) -vote. Discussions on Debian's GFDL policy traditionally take place on this list. I don't see any reason to break with it. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, di-ve.com, hotmail.com, netscape.net, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr.
Problematic Software Licenses
There's a piece of software called "acc" I'd like to package up and possibly include in Debian (along with some other tools that complement it, and are under seperate, DSFG-free licenses, so they're not an issue), but the included licenses are problematic at best. I've attached them below. The problem is that the first license is pretty obviously complete bunk, because it sounds like a purchased program, not a piece of source code released to the public. The second license seems to be less restrictive, but it's pretty vague at the same time. I already received one opinion that it's pretty much impossible to include this with Debian because of the first license, but I'm wondering if anybody has any advice on if this is the sort of issue that we could "dance around", though I'm guessing it's not. Barring that, is there any way of including this in Debian without receiving a new license from Raven? I've already attempted to contact them with no luck. The original downloads came from http://www2.ravensoft.com/source/, but the package I'm interested in is a heavily modified version of it. Thanks in advance. SOFTWARE LICENSE AGREEMENT IMPORTANT - READ CAREFULLY: USE OF THIS PROGRAM IS SUBJECT TO THE SOFTWARE LICENSE TERMS SET FORTH BELOW. PROGRAM INCLUDES ALL SOFTWARE INCLUDED WITH THIS AGREEMENT, THE ASSOCIATED MEDIA, ANY PRINTED MATERIALS, AND ANY ON-LINE OR ELECTRONIC DOCUMENTATION, AND ANY AND ALL COPIES OF SUCH SOFTWARE AND MATERIALS. BY OPENING THIS PACKAGE, INSTALLING, AND/OR USING THE PROGRAM AND ANY SOFTWARE PRGRAMS INCLUDED WITHIN, YOU ACCEPT THE TERMS OF THIS LICENSE WITH ACTIVISION, INC. ( ACTIVISION ). LIMITED USE LICENSE. Subject to the conditions described below, Activision grants you the non-exclusive, non-transferable, limited right and license to install and use one copy of this Program solely and exclusively for your personal use. All rights not specifically granted under this Agreement are reserved by Activision and, as applicable, Activisions licensors. This Program is licensed, not sold, for your use. Your license confers no title or ownership in this Program and should not be construed as a sale of any rights in this Program. LICENSE CONDITIONS. You shall not: " Exploit this Program or any of its parts commercially. " Use this Program, or permit use of this Program, on more than one computer, computer terminal, or workstation at the same time. " Make copies of this Program or any part thereof, or make copies of the materials accompanying this Program. " Use the program, or permit use of this Program, in a network, multi-user arrangement or remote access arrangement, including any online use, except as otherwise explicitly provided by this Program. " Sell, rent, lease or license any copies of this Program, without the express prior written consent of Activision. " Remove, disable or circumvent any proprietary notices or labels contained on or within the Program. OWNERSHIP. All title, ownership rights and intellectual property rights in and to this Program and any and all copies thereof (including but not limited to any titles, computer code, themes, objects, characters, character names, stories, dialog, catch phrases, locations, concepts, artwork, animation, sounds, musical compositions, audio-visual effects, methods of operation, moral rights, any related documentation, and applets incorporated into this Program) are owned by Activision, affiliates of Activision or Activisions licensors. This Program is protected by the copyright laws of the United States, international copyright treaties and conventions and other laws. This Program contains certain licensed materials and Activisions licensors may protect their rights in the event of any violation of this Agreement. PROGRAM UTILITIES. This Program contains certain design, programming and processing utilities, tools, assets and other resources ( Program Utilities ) for use with this Program that allow you to create customized new game levels and other related game materials for personal use in connection with the Program ( New Game Materials ). The use of the Program Utilities is subject to the following additional license restrictions: You agree that, as a condition to your using the Program Utilities, you will not use or allow third parties to use the Program Utilities and the New Game Materials created by you for any commercial purposes, including but not limited to selling, renting, leasing, licensing, distributing, or otherwise transferring the ownership of such New Game Materials, whether on a stand alone basis or packaged in combination with the New Game Materials created by others, through any and all distribution channels, including, without limitation, retail sales and on-line electronic distribution. You agree not to solicit, initiate or encourage any proposal or offer from any person or entity to create any New Game Materia
Re: DRAFT for a GR proposal concerning the Sarge release
* Glenn Maynard ([EMAIL PROTECTED]) wrote: > I concur with the other responses: Linus is not the sole copyright holder. > > I'll also reiterate the other problem: even if we believe that the entire > Linux kernel developer body agrees (which may be the case, though I doubt > it), I'm sure there's a lot of code in the kernel pulled from other GPL > projects, whose copyright holders aren't kernel developers at all. Certainly you can develop a case where it's not possible to get clarification on the license. That's not constructive or necessary imv. Clarification from Linus on the kernel's license is sufficient for me, and should be for Debian. Stephen signature.asc Description: Digital signature
Re: Squeak in Debian?
> > > > I do not understand your issue about locality. The business in question > > > > is us, Debian. We already have a distribution server at Berkeley, so we > > > > already need to evaluate and comply with the laws of northern > > > > California. > > > > > > The CD distributors are not part of SPI, the non-profit that holds > > > title to the vast resources of Debian. In addition, the Debian > > > mirrors only look at local law when evaluating whether to mirror > > > Debian. They don't look up Northern California law. > > > > The individual CD distributors should not be automatically distributing > > non-free stuff. Thus I still do not see the issue. > > > > It seems like our non-free infrastructure already needs to obey US > > export law, so I do not see the issue with us meeting that license > > condition. > > non-free is not part of the bxa notification scheme, because the bxa > notifications is only available for certain type of software of which > main is a subset. So there are still packages in non-us/non-free. > I don't see why BXA notification would be required for Squeak nowadays. It used to have some secure hashing functions in there such as MD5 and SHA, but I just searched and those seem to be in a separate package nowadays. People who want crytopgraphy routines in Squeak must now download them separately from "SqueakMap". Overall, I still do not see how it can be an extra burden on *Debian* to have to follow US export regulations. Certainly it is a DFSG issue for our users, but that is acceptible for a non-free package. The question at hand is whether we feel okay using the non-free infrastructure to distribute it. Aren't our non-free machines following US export law, anyway (e.g., by not including undisclosed encryption software) ? So long as all of the non-free machines are mirroring to each other automatically, it seems like they must all follow the export regs of all the countries. Am I mistaken about this? Along these lines, I checked, and in the U.S. at least there is a clear understanding of what is called here "reexporting". That is, A cannot blithely export to C by first exporting to an intermediary B. A->B->C is treated much or exactly the same as A->C. Here's the Dept. of Commerce web site, for anyone who wants to wade through and verify: http://w3.access.gpo.gov/bis/ear/ear_data.html The good news about the above site is that the regs -- at least by my very fast reading -- seem both to focus on crytography and to explicitly exempt software that is publically available. That's good, because otherwise it would be quite onerous just to post inocuous things on a web site. One thing I am left wondering about is this in Squeak-L: "In particular, but without limitation, the Apple Software may not be exported or reexported (i) into (or to a national or resident of) any U.S. embargoed country or (ii) to anyone on the U.S. Treasury Department's list of Specially Designated Nationals or the U.S. Department of Commerce's Table of Denial Orders. " The "in particular" implies that this is a normal export regulation for the US. Does anyone know? If it is indeed normal, then what do our non-non-US servers do about it? -Lex
Re: DRAFT for a GR proposal concerning the Sarge release
On Wed, Apr 28, 2004 at 08:04:13AM -0400, Stephen Frost wrote: > Has anyone asked Linus what his feelings are regarding firmware? If he > thinks it's acceptable (or possibly even the 'preferred form of > modification') to have in Linux and that it's not violating the GPL then > I don't think we have a problem. In these cases of ambiguity it makes > sense to me to ask the copyright holder to clarify for us instead of > assuming that they're violating their own license. I concur with the other responses: Linus is not the sole copyright holder. I'll also reiterate the other problem: even if we believe that the entire Linux kernel developer body agrees (which may be the case, though I doubt it), I'm sure there's a lot of code in the kernel pulled from other GPL projects, whose copyright holders aren't kernel developers at all. -- Glenn Maynard
Re: Forgent starts litigating JPEG...
Måns Rullgård said on Tue, Apr 27, 2004 at 09:38:05PM +0200,: > I asked a couple of days ago, but nobody replied. Does anyone know > anything about the patent status of JPEG-2000? Is it safe to use > it? According to a post at groklaw, jpeg 2000 is not encumbered by this patent. I am not sure though. Groklaw is discussing forgent. -- +~+ Mahesh T. Pai, LL.M., 'NANDINI', S. R. M. Road, Ernakulam, Cochin-682018, Kerala, India. http://paivakil.port5.com +~+
Re: contracts vs. licenses, OSI, and Debian (was: The QPL licence)
Branden Robinson said on Tue, Apr 27, 2004 at 05:45:39PM -0500,: > On Sun, Apr 25, 2004 at 07:29:57PM -0400, Nathanael Nerode wrote: > > To veer off the subject a little, we don't like licenses which > > engage in too much contract-like behavior, because they're > > usually non-free. In particular, any license which requires that > > you agree to it in order to *use* it -- since use is not normally > > restricted by copyright law -- is trying to be a contract, and is > > also non-free. > > Indeed. Larry Rosen, who is an attorney and is the legal advisor > to the Board of the Open Source Initiative[1], is a major advocate > of converting copyright licenses into contracts[2], as are major > media[3] and proprietary software[4][5] companies. > > I personally think this explains a great many of the divergences > between Debian's assessment of licenses and OSI's. In law, you cannot impose obligations on anybody without their consent. `Acceptance' is required/necessary only if the license imposes an obligation on user. Asking the *user* to contribute back his `in-house' modifications, a hallmark of at least a few of OSI licenses, imposes an obligation on him. Naturally, proponents of such licenses require that the license is a contract. The GNU/GPL, OTOH, does not impose an obligation on *use*. Obviously, the FSF does not require it to be `accepted'. The policy of certain package installation software, (typically on non-free platforms) insisting on the display of licenses (even in case of the GPL) and asking the user to accept them, is therefore, IMHO inappropriate. -- +~+ Mahesh T. Pai, LL.M., 'NANDINI', S. R. M. Road, Ernakulam, Cochin-682018, Kerala, India. http://paivakil.port5.com +~+
Re: DRAFT for a GR proposal concerning the Sarge release
Thiemo Seufer said on Wed, Apr 28, 2004 at 06:18:00AM +0200,: > What exactly are these great benefits? I see diminished driver > support and a lack of documentation, or alternatively non-free as a > rather That is what I used to think, till I realised that the prospect of a large number of users switching to other hardware might persuade hardware vendors to be sensible and open up the specs. -- +~+ Mahesh T. Pai, LL.M., 'NANDINI', S. R. M. Road, Ernakulam, Cochin-682018, Kerala, India. http://paivakil.port5.com +~+
Re: DRAFT for a GR proposal concerning the Sarge release
On Wed, Apr 28, 2004 at 10:36:20AM -0700, Don Armstrong wrote: > [I think I really should have sent this originally to -legal... feel > free to send it back over there if you think it's more > appropriate.[1]] M-F-T (hopefully correctly) set. > On Wed, 28 Apr 2004, Michael Banck wrote: > > I would not consider firmware a 'derivative work' of the kernel, as > > it is usually (correct me if I'm wrong) developed completely > > independent from the driver and only included in the source for > > convenience for the hardware vendor (i.e. saving a bit of money for > > the ROM and being more flexible). > > The real question is: Is "kernel source tarball" (the final product) a > derivative work of "other kernel source" + "non-GPLed firmware" or a > mere aggregation of the two. If it is a derivative work, as I'm > inclined to believe since it forms a whole product and so many people > are complaining about removing that part, then the whole derivative > work must be capable of being distributed under the GPL. Hmm, I know why I don't frequent -legal very often, this is all quite complicated :) Reading the GPL again, I guess the system exclusion does not apply either, right? > There are only a few people really qualified to answer this question, > and one of them is Eben Moglen. If there's still some doubt, he might > be the person to ask... (or perhaps the [EMAIL PROTECTED] people, > which is probably one and the same.)[2] Actually, I believe [EMAIL PROTECTED] is David 'novalis' Turner (a cool guy), and as I happen to know him, I might ask him about it. But if anybody else of you wants to go forth, be my guest, as you probably know much more about this issue than me. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html
Re: Squeak in Debian?
Scripsit Martin Schulze <[EMAIL PROTECTED]> > | "You may distribute and sublicense such Modified Software only under the > | terms of a valid, binding license that makes no representations or > | warranties on behalf of Apple, and is no less protective of Apple and > | Apple's rights than this License." > | > | What the heck does that even *mean*? Licenses aren't "binding"; they're > | thinking of contracts. In fact, the whole license thinks it's a contract > | (which is bad from the start). "Protective of Apple and Apple's rights" is > | incredible vague, meaning that only this exact license is a safe license > | for derivative works. > What's this? Insufficient data (as quoted: What the heck does this mean?). In the absence of better information I'd prefer to err on the side of caution: [X] Renders the package non-distributable > | This is a forced-distribution clause. It requires that if the Modified > | Software is given to *anyone*, it must be made "publicly available" (to > | lots of *other* people) at no charge. This fails the dissident test and > | the desert island test. It's also a practical inconvenience; I can't share > | a modified version with my spouse without publishing it. > What's this? [X] Renders the package non-free > | "This License allows you to copy, install and use the Apple Software on an > | unlimited number of computers under your direct control." > | Purports to restrict use. Doesn't allow use on computers not "under your > | direct control", which is a substantial restriction; it probably prohibits > | it from being installed by a Debian admin onto a Debian machine which is > | hosted elsewhere. :-P > What's this? Confused drafting, probably leftover from adaptations of commercial licenses that restricts the number of installations. I'm not convinced that this is necessarily a DFSG problem, but if one has to get clarification from upstream about the "valid, binding license" part above, one might just as well ask for this to be clarified (or left out entirely). -- Henning Makholm "It was intended to compile from some approximation to the M-notation, but the M-notation was never fully defined, because representing LISP functions by LISP lists became the dominant programming language when the interpreter later became available."
Re: Squeak in Debian?
Roland Stigge wrote:
> today I read that Alan Kay will receive this years's Turing Award[1] and
> checked out his "Open Source" project Squeak[2]. I also realized that
> there is an open RFP for it[3]. The package is supposed to be free, but
> when I checked the license[4] and the package files, I encountered the
> following issues which should be resolved before squeak hits the
> archive:
I'm trying to figure out if Squeak can be packaged at all or not. It
seems clear that the license is not compatible with the DFSG and hence
a place in main is out of question.
For this I've tried to extract helpful bits from the this thread.
| Roland Stigge http://lists.debian.org/debian-legal-0404/msg00159.html";>\
| identified the following problems in the http://www.squeak.org/download/license.html";>license of
| http://www.squeak.org/";>Squeak:
|
| (1) Clause 2 states: 'You may modify and create derivative works of the
| Apple Software ("Modified Software"), however, you may not modify or
| create derivative works of the fonts provided by Apple ("Fonts").'
|
| This seems to violate DFSG.3 ("Derived Works").
|
| (2) Clause 2 also states: "You may distribute and sublicense the Fonts
| only as a part of and for use with Modified Software, and not as a part
| of or for use with Modified Software that is distributed or sublicensed
| for a fee or for other valuable consideration."
|
| This seems to violate DFSG.1 ("Free Redistribution").
Markus Gaelli told me in private that the fonts were replaced by free
fonts. Let's assume for the moment this is the case.
It it is indeed the case, the license needs to be expanded to contain
a note about the free fonts and their license, and a note about the
absense of non-free fonts.
| (3) Clause 6 states: "You may not use or otherwise export or reexport
| the Apple Software except as authorized by United States law and the
| laws of the jurisdiction in which the Apple Software was obtained. In
| particular, but without limitation, the Apple Software may not be
| exported or reexported (i) into (or to a national or resident of) any
| U.S. embargoed country [...]"
|
| Which seems to violate DFSG.5 ("No Discrimination Against Persons or
| Groups") since it explicitly excludes people in countries like Cuba (?)
| from receiving copies of this package. I don't think we can maintain a
| list of countries which the USA enforce an embargo on at a time.
|
| (4) The distributed files squeak.changes and squeak.image, both around
| 10MB, are shipped in binary form. I wonder if there should be source
| code to create them initially. (See DFSG.2, "Source Code")
|
|
| With regards to squeak.changes Brian Thomas Sniffen http://lists.debian.org/debian-legal-0404/msg00162.html";>\
| explained:
|
| Those files are source, they're just not saved as ascii text. They
| are SmallTalk source, saved in the preferred format for modification:
| the native format of the SmallTalk class browser.
|
|
| With regards to US export restrictions Lex Spoon http://lists.debian.org/debian-legal-0404/msg00296.html";>\
| asserted:
|
| It should be fine in non-free, however, so long as it would not cause
| our non-free infrastructure to break the license and so long as it does
| not add unacceptible liability to Debian. Since much of our non-free
| infrastructure is in the US, I would think we must follow US export law
| anyway, even on non-free servers that are not in the US.
Hence, both of the above issues may be resolved as well.
| Nathanael Nerode http://lists.debian.org/debian-legal-0404/msg00214.html";>\
| identified the following problems in the license of Squeak:
|
| There are other problems with clause 2.
|
| "You may distribute and sublicense such Modified Software only under the
| terms of a valid, binding license that makes no representations or
| warranties on behalf of Apple, and is no less protective of Apple and
| Apple's rights than this License."
|
| What the heck does that even *mean*? Licenses aren't "binding"; they're
| thinking of contracts. In fact, the whole license thinks it's a contract
| (which is bad from the start). "Protective of Apple and Apple's rights" is
| incredible vague, meaning that only this exact license is a safe license
| for derivative works.
What's this?
[ ] compatible with the DFSGg
[ ] Renders the package non-free
[ ] Renders the package non-distributable
| "If the Modified Software contains modifications, overwrites, replacements,
| deletions, additions, or ports to new platforms of: (1) the methods of
| existing class objects or their existing relationships, or (2) any part of
| the virtual machine, then for so long as the Modified Software is
| distributed or sublicensed to others, such modified, overwritten, replaced,
| deleted, added and ported portions of the Modified Software must be made
| publicly available, preferably by means of download from a website, at no
| charge under the terms set forth in Exhibit A below."
|
| This is a forc
Re: DRAFT for a GR proposal concerning the Sarge release
Stephen writes: > In these cases of ambiguity it makes sense to me to ask the copyright > holder to clarify for us instead of assuming that they're violating their > own license. Linus is only the copyright owner of those portions of the kernel that he personally wrote. Each contributor owns the copyright on his contribution. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Treat your illness
This is the best there is Surprise your lady and yourself The best there is C"ial'is You don't believe me?. check: http://fvejkf.gfd-online.com/cia/?biggest Get out of the list: http://drk.gfd-online.com/zz.html
Re: DRAFT for a GR proposal concerning the Sarge release
On Wed, 28 Apr 2004, Stephen Frost wrote: > Has anyone asked Linus what his feelings are regarding firmware? Good idea. And two interesting posts related tot his issue: (Wed, 10 Dec 2003 ) http://groups.google.fr/groups?selm=11gWH-4XN-1%40gated-at.bofh.it&oe=UTF-8&output=gplain "And I think this argument is _especially_ strong for things like firmware etc, and I've been on record as saying that I think it's ok to upload standard firmware for a driver as long as you don't call it directly (ie it really lives on the hardware itself). (At this point I should probably point out that other people disagree, and there are people who feel strongly that the kernel cannot contain binary firmware. Whish is obviously part of the reason for having the firmware loader interfaces for drivers - adding an extra layer of separation)." (Tue, 3 Feb 1998) http://groups.google.fr/groups?selm=199802032339.PAA11325%40dandelion.com&oe=UTF-8&output=gplain "Linus and I discussed this at length regarding the Mylex/BusLogic FlashPoint SCSI Host Adapters. The FlashPoint SCCB Manager library code runs on the host CPU essentially in place of firmware running on an onboard processor as with the MultiMaster boards. Any software that runs on the host CPU is *required* to be in source form; binary is considered perfectly acceptable for firmware that is downloaded to a board, though obviously source for that would be nice too. One of the key conceptual differences here is that at least in theory, a driver in source form with downloaded binary firmware can execute on any hardware-compatible platform Linux runs on, or can be made to do so. The binary library module would have to be provided by your company for each Linux platform to be supported, and that does make a conceptual difference."
Re: DRAFT for a GR proposal concerning the Sarge release
* Glenn Maynard ([EMAIL PROTECTED]) wrote: > On Wed, Apr 28, 2004 at 06:21:27AM +0200, Thiemo Seufer wrote: > > For "possible", that is, unsubstantioned license violation claims, yes. > > Distributing a GPL binary linked against code whose source is not available > is a clear-cut violation of the terms of the GPL. Has anyone asked Linus what his feelings are regarding firmware? If he thinks it's acceptable (or possibly even the 'preferred form of modification') to have in Linux and that it's not violating the GPL then I don't think we have a problem. In these cases of ambiguity it makes sense to me to ask the copyright holder to clarify for us instead of assuming that they're violating their own license. Stephen signature.asc Description: Digital signature
Re: DRAFT for a GR proposal concerning the Sarge release
On Wed, Apr 28, 2004 at 06:20:10AM +0100, Lewis Jardine wrote: > Thiemo Seufer wrote: > > >>As I understand it, Debian makes a point of considering the interests of > >>'unrelated third part[ies]', especially when it comes to the chance of > >>copyright infringement. > >So does Debian consider the interests of SCO then? They also claim > >copyright infringement. > I'd hope so, in as much as Debian provides SCO (like all other users) > with a high quality collection of Free software (No discrimination > against fields of endeavour, remember :) > Do you think so? If we would seriously concerned on SCO's ideas sarge should release with HURD. And there's always the possibility that SCO or someone else open a issue about it, too. -- Francesco P. Lovergine
Notify about your e-mail account utilization.
Dear user of "Debian.org" mailing system, We warn you about some attacks on your e-mail account. Your computer may contain viruses, in order to keep your computer and e-mail account safe, please, follow the instructions. Pay attention on attached file. For security reasons attached file is password protected. The password is "22482". The Management, The Debian.org team http://www.debian.org Norton AntiVirus Deleted1.txt Description: plain/text
Re: Not inherently free, but inherently non-free?
On Wed, Apr 28, 2004 at 08:49:52AM +0200, Milan Zamazal wrote: > LJ> Section 3 (Copying in quantity): Forces to distribute > LJ> transparent (source) along with the opaque (binary) form: forced > LJ> distribution of goes against the spirit of the DFSG, altough not > LJ> its letter. Apply similarities with the Desert Island test. > > I don't understand how the Desert Island test applies here to GFDL and > not to GPL. Could you explain it (or give a particular pointer), > please? The GPL says that if you give somebody a binary, you have to make the source available to them, too. It doesn't say that you have to make it available to anyone else. If I'm on a desert island and I want to give my modified binary to my island friend, the GPL doesn't prevent that. I'm not entirely sure how the desert island test applies to this part of the GFDL. -- Glenn Maynard
Re: DRAFT for a GR proposal concerning the Sarge release
On Wed, 28 Apr 2004 16:22:29 +1000, Hamish Moffatt <[EMAIL PROTECTED]> said:
> On Tue, Apr 27, 2004 at 06:02:40PM -0500, Manoj Srivastava wrote:
>> The former is fine, this merely reinstates the former release
>> policy. But wilfully distributing software that violates the
>> license it is shipped under is illegal; and we no longer have a
>> right to distribute it.
> Firstly, where are the GPL violations? All I see in the kernel is
> DFSG violations. Those sourceless embedded codes aren't being linked
> against the kernel in any way at all.
Would you please not cut out the context, and proceed to
attack strawmen?
We, the Debian Developers, will aim to release Sarge as soon as
technically possible (concerning release critical bugs and the
installer) by following the current release plan[1]. We are aware of
the fact that both Woody and Sarge contain components that violate
the current Social Contract (since they are not free in the sense of
the Debian Free Software Guidelines) and the GNU General Public
>>> The former is fine, this merely reinstates the former release
>>> policy. But wilfully distributing software that violates the license
>>> it is shipped under is illegal; and we no longer have a right to
>>> distribute it.
The GPL violation was what was being proposed we ignore. Here,
let me quote it "We are aware of the fact that both Woody and
Sarge contain components that violate and the GNU
General Public License..."
> Secondly, when did violating the license become "illegal"? IANAL but
If you get software under license A; and you violate that
license, you no longer ahve the right to distribute it. If you
continue to distribute that work, despite having no rights to do so,
you are in violation of copyright law.
In laymans terms, when you commit an act in violation of the
law, we call it illegal.
> isn't a license a form of contract and therefore a civil matter?
And breaking civil law is not illegal where you live? Or you
do not have copyright law?
Illegal \Il*le"gal\, a. [Pref. il- not + legal: cf. F.
ill['e]gal.]
Not according to, or authorized by, law; specif., contrary
to, or in violation of, human law; unlawful; illicit; hence,
immoral; as, an illegal act; illegal trade; illegal love.
> You spoke of jail time but I can't see how that's relevant. Actually
> it's just FUD.
FUD, eh? You are quick to throw out such accusations with very
little research, I must say.
here are the facts: and people who sell debian CD's may
easily cross $1000 in a 6 month period.
http://www.copyright.gov/title17/92chap5.html
In a case where the copyright owner sustains the burden of proving,
and the court finds, that infringement was committed willfully, the
court in its discretion may increase the award of statutory damages to
a sum of not more than $150,000.
(a) Criminal Infringement. \x{2014} Any person who infringes a
copyright willfully either \x{2014}
(1) for purposes of commercial advantage or private financial gain, or
(2) by the reproduction or distribution, including by electronic
means, during any 180-day period, of 1 or more copies or
phonorecords of 1 or more copyrighted works, which have a total
retail value of more than $1,000,
shall be punished as provided under section 2319 of title 18, United
States Code. For purposes of this subsection, evidence of reproduction
or distribution of a copyrighted work, by itself, shall not be
sufficient to establish willful infringement.
(b) Forfeiture and Destruction. \x{2014} When any person is convicted
of any violation of subsection (a), the court in its judgment of
conviction shall, in addition to the penalty therein prescribed,
order the forfeiture and destruction or other disposition of all
infringing copies or phonorecords and all implements, devices, or
equipment used in the manufacture of such infringing copies or
phonorecords.
(c) Fraudulent Copyright Notice. \x{2014} Any person who, with
fraudulent intent, places on any article a notice of copyright or
words of the same purport that such person knows to be false, or
who, with fraudulent intent, publicly distributes or imports for
public distribution any article bearing such notice or words that
such person knows to be false, shall be fined not more than
$2,500.
(d) Fraudulent Removal of Copyright Notice. \x{2014} Any person who,
with fraudulent intent, removes or alters any notice of copyright
appearing on a copy of a copyrighted work shall be fined not more
than $2,500.
(e) False Representation. \x{2014} Any person who knowingly makes a
false representation of a material fact in the application for
copyright registration provided for by section 409, or in any
written statement filed in connection with the application, shall
be fined not more t
Re: Not inherently free, but inherently non-free?
Thank you all for your answers, I think I can get the point now. > "GM" == Glenn Maynard <[EMAIL PROTECTED]> writes: GM> On Tue, Apr 27, 2004 at 11:03:32PM +0200, Milan Zamazal wrote: >> The license of a Debian component may not restrict any party from >> selling or giving away the software as a component of an >> aggregate software distribution containing programs from several >> different sources. The license may not require a royalty or other >> fee for such sale. [...] GM> Not permitting distribution on a DRM medium restricts "selling GM> or giving away the software as a component of an aggregate GM> software distribution containing programs from several different GM> sources". GM> It seems straightforward to me; I can't take the program, GM> package it with something else (forming an aggregate software GM> distribution), put it on a DRM medium and sell it, due to a GM> license restriction. When DFSG was written, the point 1 was specifically handling cases like "you can't distribute this software together with software holding certain properties". In your reasoning, the "put it on a DRM medium" part is not *clearly* covered by DFSG#1. I think Lewis has explained the issue in a more clear way, see below. HM> Section 3 (Copying in quantity): Forces to distribute HM> transparent (source) along with the opaque (binary) form: forced HM> distribution of goes against the spirit of the DFSG, altough not HM> its letter. >> So this doesn't violate DFSG. GM> Violating the spirit of the DFSG *is* violating the DFSG. GM> Please don't insist that a set of guidelines be read as a set of GM> strict rules. A lot of people try to do that, and it simply GM> doesn't work. I agree, but in this particular case it's very questionable whether forcing you to distribute the sources is against the spirit. Consider DFSG#4, which explicitly permits an obstruction leading to medium space waste (unmodifiable source distribution package). In such cases, it's better to stick to the letter (or clarify the letter). > "HM" == Humberto Massa <[EMAIL PROTECTED]> writes: HM> I will try again, before going home. Thanks. HM> USofA copyright law acts only on redistribution of software, not HM> its use; any attempt to act on its use by a license is normally HM> considered non-DFSG-free-ness by debian-legal. OK, this is a good point. HM> I made a copy. It's not my copyright, is other person. If I do HM> "chmod -r", it's a technical measure that obstructs others from HM> further copying my copy. I think it's not your copyright, but it's still your copy. So `chmod -r' is IMHO just stopping distribution of the copy. HM> Forced distribution of the source is also considered by HM> debian-legal non-freeness. If it is so, it's inconsistent with DFSG#4, see above. Is there a pointer to a particular reasoning behind this? LJ> Section 3 (Copying in quantity): Forces to distribute LJ> transparent (source) along with the opaque (binary) form: forced LJ> distribution of goes against the spirit of the DFSG, altough not LJ> its letter. Apply similarities with the Desert Island test. I don't understand how the Desert Island test applies here to GFDL and not to GPL. Could you explain it (or give a particular pointer), please? HM> As I said before, at least one case is absolutely, crystal clear HM> as per the DFSG: the DRM restriction is absolutely forbidden by HM> the DFSG#1, that states: " HM> The license of a Debian component may not restrict any party HM> from selling or giving away the software as a component of an HM> aggregate software distribution containing programs from several HM> different sources. Again, it doesn't say "on any medium". But: > "LJ" == Lewis Jardine <[EMAIL PROTECTED]> writes: LJ> Surely it's implicit in 'may not restrict any party' that the LJ> licensed work must be distributable in any form the distributor LJ> chooses? As it stands, GFDL works cannot be distributed at all LJ> on DRM media and therefore if the distributor puts (for example) LJ> paragraphs from a GFDL manual in spoken form on a CSS, LJ> Region-coded DVD, he is restricted from distributing this DVD, LJ> which is an aggregate software distribution containing programs LJ> from several different sources (If you take documentation to be LJ> software, which AFAIK, Debian does). Here is the point. If the document was distributed *only* on a CSS medium, it might violate copyleft principles. But it should be allowed, for example, to distribute the document on such a medium, if it is accompanied with a freely readable medium. GFDL is unclear here and that's the problem. Thanks. Regards, Milan Zamazal -- The seeker after truth should be humbler than the dust. The world crushes the dust under its feet, but the seeker
Re: DRAFT for a GR proposal concerning the Sarge release
Thiemo Seufer wrote: As I understand it, Debian makes a point of considering the interests of 'unrelated third part[ies]', especially when it comes to the chance of copyright infringement. So does Debian consider the interests of SCO then? They also claim copyright infringement. I'd hope so, in as much as Debian provides SCO (like all other users) with a high quality collection of Free software (No discrimination against fields of endeavour, remember :) If a fully working, tested solution to load non-free firmware from userland into the kernel (thus avoiding the linking problem) fell from the sky tomorrow, I suspect very few people would suggest that it was A Bad Thing, and that the kernel was better when it had potentially dubious, non-free blobs in it. Linking means to bind some object files together. Those firmwares aren't distributed as object files. Which relies on the rather weak legal theory that compiled in firmware is part of a derived work, while the same firmware in a ramdisk image (or even a CD image) suddenly constitutes a collection of works. It can be argued under the new social contract amendments that many of these blobs are non-free, and have to go, whether or not they can be included in the kernel image without violating the GPL. If nothing else, it would make the kernel image with the firmwares and the kernel image without the firmwares identical; loading these blobs in at run-time would mean that kernel-blobs-non_free could be packaged separately, saving the pain of having to maintain kernel-image and kernel-image-non_free. a delayed Sarge would be annoying, but the products that are necessary for an 'anally-free' Sarge would be of great benefit to users of both Debian, and Free Software in general. What exactly are these great benefits? I see diminished driver support and a lack of documentation, or alternatively non-free as a rather mandatory part of a Debian installation. Ah. I was seeing clean-roomed/relicensed firmwares, rewritten, Free documentation, etc. I assumed that the reason for the delay was due to reverse-engineering, documentation, and re-licensing. Best case, I was envisaging a back-down by the FSF over the GFDL, and the reintroduction of much of the documentation, under a Free license. Surely it can't take nine months just to take out the stuff that's been declared non-free, and not replace it at all? > And this still doesn't count > the fight if a jpeg or some font descriptions can be source. I'm not touching that one with a 60 foot pole. Clause four of (even the unamended) social contract, in my opinion, suggests that later is better than less free, and thus the amendment was The Right Thing, even though it may delay Sarge. In my opinion, invoking the Social Contract is Debian's version of Godwin's Law. I'd say that it beats Godwin's Law, as the Social Contract is (at least supposed to be :) relevant to the discussion at hand. -- Lewis Jardine IANAL IANADD
Re: DRAFT for a GR proposal concerning the Sarge release
On Wed, Apr 28, 2004 at 06:21:27AM +0200, Thiemo Seufer wrote: > For "possible", that is, unsubstantioned license violation claims, yes. Distributing a GPL binary linked against code whose source is not available is a clear-cut violation of the terms of the GPL. I don't think even existing practice and opinions of kernel developers are relevant. Considering that the 2.6.5 kernel has over two million lines of code (on a quick count of only *.c,*.h), it's safe to safe some of that is code reused from other projects. Those copyright holders may not even be aware of the issue yet. I don't think it's safe to be dismissing possible GPL violations so readily. -- Glenn Maynard
Re: Squeak in Debian?
"Lex Spoon" <[EMAIL PROTECTED]> wrote: > Walter Landry <[EMAIL PROTECTED]> wrote: > > > BUT, we are only obligated to the extent the case deals with our own > > > actions. I do not see a problem with this. That seems good and proper > > > to stand up for our own actions. The clause does *NOT* make us liable > > > for all legal attacks on Apple regarding Squeak. > > > > J. Random CD distributor on Battlestar Galactica distributes a copy of > > Squeak to his fellow argonauts. The Silons sue Apple for contributory > > copyright infringement, citing the distribution by J. Random. Now > > J. Random is obligated to defend Apple in US court, even though > > J. Random doesn't even know where Earth is. > > > > J. Random CD distributor is irrelevant to this discussion. Squeak would > be in non-free, where it's user beware and distributor beware. Ah, I thought you were still contesting the main/non-free distinction. In any case, non-free is not entirely distributor beware. CD manufacturers have to be careful, but mirrors do not. I don't believe that any other license in non-free has this kind of clause, though I'm open to being proven wrong. > > > I do not understand your issue about locality. The business in question > > > is us, Debian. We already have a distribution server at Berkeley, so we > > > already need to evaluate and comply with the laws of northern > > > California. > > > > The CD distributors are not part of SPI, the non-profit that holds > > title to the vast resources of Debian. In addition, the Debian > > mirrors only look at local law when evaluating whether to mirror > > Debian. They don't look up Northern California law. > > The individual CD distributors should not be automatically distributing > non-free stuff. Thus I still do not see the issue. > > It seems like our non-free infrastructure already needs to obey US > export law, so I do not see the issue with us meeting that license > condition. non-free is not part of the bxa notification scheme, because the bxa notifications is only available for certain type of software of which main is a subset. So there are still packages in non-us/non-free. Regards, Walter Landry [EMAIL PROTECTED]
