Re: GPL linking question
On Sat, 28 Jul 2001, Raul Miller wrote: Being specific: if the program is distributed with MySQL, such that by default it uses MySQL then we're definitely not talking about mere aggregation. On Sat, Jul 28, 2001 at 06:16:32PM -0700, Brian Behlendorf wrote: Let's say I made a Linux distribution with a web-based admin utility that used a GPL web server and Mozilla as the default server and browser. Does that mean the whole distribution would need to be GPL (which would violate the MPL)? I wouldn't think so. That's because you don't think of the whole distribution as a part of your web-based admin utility. But is the GPL'd web server part of my web-based admin utility, then? What if I've made no modifications to the web server, but everything is implemented as PHP pages? Brian
Re: GPL linking question
On Fri, 27 Jul 2001, Raul Miller wrote: Sounds like this would be in breech of the GPL? If the application requires GPLed code, then yes. On Sat, Jul 28, 2001 at 12:53:00PM +1000, Hamish Moffatt wrote: Requires in any sense? The app could use other SQL databases, but would be bundled with MySQL and that would be the default (and what most end users would use). Requires in the sense that it's a part of the program. Let's be specific here. If the program can use multiple databases, one of which is MySQL, then the distribution of that program can include MySQL so long as MySQL itself is still distributed under the GPL (meaning, source code is included or easily obtained). The sql-using app itself does not have to be under the GPL. At least that's my reading. Brian
Re: GPL linking question
On Sat, 28 Jul 2001, Raul Miller wrote: On Sat, Jul 28, 2001 at 09:37:18AM -0700, Brian Behlendorf wrote: Let's be specific here. If the program can use multiple databases, one of which is MySQL, then the distribution of that program can include MySQL so long as MySQL itself is still distributed under the GPL (meaning, source code is included or easily obtained). The sql-using app itself does not have to be under the GPL. At least that's my reading. Being specific: if the program is distributed with MySQL, such that by default it uses MySQL then we're definitely not talking about mere aggregation. Let's say I made a Linux distribution with a web-based admin utility that used a GPL web server and Mozilla as the default server and browser. Does that mean the whole distribution would need to be GPL (which would violate the MPL)? I wouldn't think so. Brian
Re: Libapache-mod-backhand: load balancing Apache requests.
On Thu, 5 Apr 2001, Richard Braakman wrote: On Wed, Apr 04, 2001 at 01:26:13PM -0700, Brian Behlendorf wrote: I am pretty sure that such a clause has always been a part of the Apache licenses. The intent is pretty simple - we don't want people calling their commercial derivatives Apache++, ApachePro, etc. I think there was an earlier version that looked like this: [5-clause license removed] You're right. Searching back, I see in 1998 we added that clause about naming - you can see the diff here: http://www.apache.org/websrc/viewcvs.cgi/apache-1.3/LICENSE Specifically, rev 1.9. I'd have to go dig up the archives to find out exactly what the situation was that caused us to get concerned about this, I believe it was a certain degree of paranoia about not allowing to happen to Apache what happened to Linux name-wise, since that was around the time IBM started getting interested in Apache. It's been brought up multiple times this was technically an issue for people building packages, but we felt it wasn't important since we clearly weren't going to go after them, or something. That's probably not enough these days; a document that explains the conditions for repackaging that can be called Apache would probably be good. If anyone has written such a doc or has ideas around that, email me. So, one thing the Apache developers have considered doing is coming up with a list of prereq's that, if satisfied, a product could carry the name Apache. This is tricky ground, though, because you know some corporate type is going to look for loopholes in that definition so that can legally meet the requirements and still call their tool ApachePro. This approach would be similar to TeX, I think, which has a detailed compatibility test that all implementations must pass in order to call themselves TeX. Creating such a test would be a lot of work if you don't already have one. Yes, I'm not thinking of a compatibility test suite. I'm thinking of things like All modifications must be clearly itemized in a file called MODIFICATIONS at the root level and The place to report errors or bugs must not be an apache.org address, and must be clearly indicated in the README or end-user docs, stuff like that. Stuff that addresses the few sources of pain it causes us when people release broken packages. a) The Debian maintainers for Apache should join the appropriate developers lists, and volunteer to create .deb packages for Apache that we can distribute from apache.org. Those packages can then be distributed from debian.org as well, carrying the same name, since they're the same file. I strongly recommend this approach. Ah, this is an alternative I hadn't thought of. It has some problems from Debian's perspective, though, mainly related to the fact that most Debian developers will not be part of it. For example, what happens if our Security Team has to quickly release a new Apache package? If that person is a part of that project and has the right to create packages and put them on apache.org for download, it can be done quickly, but I agree it raises an obstacle, technically. Also, will the Debian maintainers that are involved be able to freely create new apache debs when needed, or will they have to go through some kind of approval process? It's up to each project, I guess - in the httpd project, once you're a committer, you're a pretty trusted entity and can put stuff in the dist directory for download, etc. The reason I bought up DFSG #8 is that if renaming the package is a significant inconvenience (partly because of our name-oriented package structure, partly because all places where Apache announces its own name have to be hunted down), then I think that the package is _not_ free if making a modification means first dealing with this inconvenience. You're right, my proposal about having that Debian developer be a core Apache developer and thus have special rights isn't just an inconvenience, it constitutes a license that gives Debian special treatment, which isn't DFSG-compatible. So, a document describing the criteria a package must meet to be called Apache would be better. The trademark approach works for several open projects I know of, including Debian itself, Linux, and the Kannel project (which I do for a living). Is there a document or email somewhere that describes a situation where Debian has had to enforce its trademarks? Did anything go beyond an email threat to pursue? I'm just worried that no one's really tried to enforce a trademark on an open source project before, in front of a judge, even if email threats worked. (Should I continue to Cc you? I'm not sure if you're on debian-legal) I am on the list, and don't mind getting duplicates. Brian
Re: Libapache-mod-backhand: load balancing Apache requests.
On Thu, 19 Apr 2001, David Starner wrote: Why are you worried? Trademark law seems fairly simple (for laws), and open source doesn't seem to make a difference here. It's just We have this trademark, registered on the 31 of February 2002, they're using it without permission, and they ignored the a cease-and-disest we sent them. Unless you've let others use the trademark in defiance of your license (which worries me about Linux(tm)), it should be a simple case. I'm worried because trademark law requires you to vigilantly protect the mark; if you show arbitrary application, by allowing someone to use your name without permission, then you might lose when trying to prevent someone else from using it. Watching how trademark law is playing out in the domain name disputes, it's becoming all too clear that it's usually the company with the most money to throw at lawyers who wins the cases. Linux is a good example - I know Linus had sent nastygrams to at least one party and got it settled out of court, but if, say, LinuxOne had IPO'd and Linus tried to use his ownership of the mark to force them to change their name, and put it before a judge, I'm not sure Linus would have won, because there are so many other parties using the Linux mark. This may all be paranoia, and indeed, sentiment in the ASF is starting to run towards punting this to trademark law so we can make the Apache license GPL-compatible. On Thu, 19 Apr 2001, Richard Braakman wrote: Yes, I'm not thinking of a compatibility test suite. I'm thinking of things like All modifications must be clearly itemized in a file called MODIFICATIONS at the root level and The place to report errors or bugs must not be an apache.org address, and must be clearly indicated in the README or end-user docs, stuff like that. Stuff that addresses the few sources of pain it causes us when people release broken packages. This sounds like a good solution to me. It would even be nicer than most licenses that require that sort of thing, because the requirements go away if the software is renamed. That way it stays easy to share code between free software projects. It's not going to stop FooCorp from releasing ApachePro, though. Right, *if* they follow the terms of that document. So carefully constructing that list of requirements is somewhat important. Brian
Re: Libapache-mod-backhand: load balancing Apache requests.
On Wed, 4 Apr 2001, Richard Braakman wrote: Hmm. In /usr/share/doc/apache/copyright there is this clause: 5. Products derived from this software may not be called Apache nor may Apache appear in their names without prior written permission of the Apache Group. This seems to be a new clause; it wasn't there the last time I looked (which was a while ago). I am pretty sure that such a clause has always been a part of the Apache licenses. The intent is pretty simple - we don't want people calling their commercial derivatives Apache++, ApachePro, etc. Only recently did we realize that, technically, this affected people who released their own packages of Apache. From one perspective, this is unfair - this is just a repackaging. But from another perspective, keeping the same name means that the Apache developers are blamed when things go wrong. And in fact, we've had to deal with lots of reports of bugs that show up in the various RPM's that Red Hat and Suse distribute, though they finally got some sanity and that has died down. So, one thing the Apache developers have considered doing is coming up with a list of prereq's that, if satisfied, a product could carry the name Apache. This is tricky ground, though, because you know some corporate type is going to look for loopholes in that definition so that can legally meet the requirements and still call their tool ApachePro. So until such a perfect document can be described, I think there are two possibilities: a) The Debian maintainers for Apache should join the appropriate developers lists, and volunteer to create .deb packages for Apache that we can distribute from apache.org. Those packages can then be distributed from debian.org as well, carrying the same name, since they're the same file. I strongly recommend this approach. b) The Debian maintainers for Apache could email [EMAIL PROTECTED] asking for permission, as the license suggests. I don't recommend this direction, because then it would cause us to have to define what it is we're agreeing to, etc... it could get messy. Though the consensus would probably be, Debian's a reputable group, so let them do it. I see the concern about issue #8 in the DFSG - I think that's not relevant, because the original license stands and is non-Debian-specific. The reason I recommend a) is because: The Debian package of apache is clearly a derived product -- it has 600 kilobytes of diffs, including patches to core Apache files. Wow! What *are* those diffs? Has anyone contributed them to Apache? Why not? Note that we have a pretty modular installation configuration mechanism, so there's no reason that Debian-specific installation dirs or other settings can't be made a part of our code. Ideally, we work creating .deb files into our release process, so that a .deb is created as a side-effect of doing a release (or soon after). Comments? Brian
Re: OpenDivX license
On Thu, 25 Jan 2001, Joseph Carter wrote: 6. No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. If a license says you cannot use this software for x, that is almost always a violation of the DFSG. Software that must never be modified to deviate from a standard quite clearly fails the above. Uh, no. At least, not from the above - you're extrapolating field of endevor to can not use software for x, where I presume x is your term for non-standards-compliant use. The examples used above are very different from a clause talking about a protocol standard, and not just a technical difference. For example, a license stating this software can't be redistributed by a genetics company would leave me, if I were a programmer for Genentech, completely out of luck, by virtue of who I am. However, if it said I can't distribute a modification that violates a standard, that doesn't lock me out, that just says I have a hoop I have to jump through. So, ethically it's a much different case. The rationale given (written originally by Perens, I presume) is: the major intention of this clause is to prohibit license traps that prevent open source from being used commercially. We want commercial users to join our community, not feel excluded from it. If you believe this has no practical limitations, consider the case of a proprietary codec modification by Microsoft---they'd NEVER do that right? According to this license, this software could not be modified to support those proprietary extensions since they violate the spec. Sure. Did you see the part where I said I didn't like it? I don't think this is a good thing either. A bigger hindrance would be for those who want to modify the program to support the next version of the same protocol. But neither do I like some of the patent clauses that have gotten into open source licenses, etc. However, I do not believe it violates the language of the DFSG or OSD. In spirit, practice, and language this fails the DFSG. In spirit, yes. I would suggest that the whole issue of standards adherence might require a new clause, something like: Rights to redistribution must not be restricted by adherence to a specific standard for the behavior of the software. Perhaps with a second sentence describing the situation with the SISSL, where when one violates the standard they can do so so long as they publish their code (or at least a reference implementation of that change), thus providing two paths both of which are DFSG-free. However, does this impact the GPL, which talks a bit about how programs may be legally linked to non-GPL software? I'll even volunteer to author the rationale. =) The best one: standards are ephemeral (change often), licenses are forever (at least until someone rewrites it). DFSG #4 gets closer: it says that the license has to allow someone to be able to distribute a patch that, say in the above example, replaces the hard-coded port 80 with another port, with the source code - I don't know if that means mere aggregation on a CDROM and/or in a similar directory on a web site, or if it can be a part of the .tgz, etc. Ah, but that works only as long as binaries may be distributed with those patches applied. Since that's not the case here, it's irrelivant. Uh, no. I don't see a requirement in the OSD that licenses have to unconditionally allow modified binaries. #4 does say, the license must explicitly permit distribution of software built from modified source code - and that is permitted, so long as the standard is adhered to. For the third time, I don't like this, and this is not in the spirit of the DFSG or OSD. I won't make a blanket statement, though, that this is a totally bad thing that should be ignored. For some people, the mishmash of almost-but-not-quite-incompatible software out there all implementing some subset or mis-set of open standards, is a greater threat to the future of software openness than having all the underlying code to the applications you use. It's not a perspective the DFSG or OSD needs to adopt, of course, but it's not incomprehensible. I think Debian (and OSI) needs to decide whether or not this is a philosophy they reject, and thus patch the hole in the DFSG/OSD. Or, ignore it until it becomes an actual issue. It was this kind of ambiguity, as well as a lack of general public interest in seeing problems in the OSD/DFSG, that contributed to my resignation from OSI. Brian
Re: OpenDivX license
On Thu, 25 Jan 2001, Sam TH wrote: Debian-legal has repeatedly held that requiring or prohibiting particular behavior as a condition of distributiing modified versions is in violation of the Fields of Endeavor clause of the DFSG. But, that's not what the issue here is. The issue is not one of use - presumably, you could pull down the OpenDiVX code, modify it in some non-standards-conformant way, and use it. You could even distribute a patch that makes the same modification - OpenDiVX would not be DFSG-compatible if it prevented you from doing that. The question is of rights to redistribution of modified versions. Thus, the OpenDivx license is in violation of the DFSG. References: http://lists.debian.org/debian-legal-0012/msg00109.html Among others. (for some reason the search engine for -legal isn't working so well). The FastCGI license listed there attempted to limit use and modification, which I'd argue definitely violates the DFSG. It does not violate the fields of endeavor clause, though. How does that sound? Saying we've made the same mistake consistantly in the past is no reason to continue making it. Brian
Re: OpenDivX license
On Tue, 23 Jan 2001, Brian Ristuccia wrote: It's not an open source license. Term #6 places limitations on distributing modified copies. Erm, so does every copyright license. To be specific, it sounds like your concern is over adherence to a standard being one of the conditions for redistribution. I don't see that as a problem, but that standard is now effectively part of the license, and the standard itself has to come under DFSG conformance checks - for example, if the standard went beyond talking about data formats and such, and contained a clause that said, you may not reveal the secret key used for decryption to an end-user a la CSS, then it would not be OSD-conformant. But if, reductio ad absurdum, the standard said simply, the software must communicate on port 80, that wouldn't violate the DFSG. One way out of it is to do what the SISSL does, which is say, effectively you can take one path if you remain conformant to the standard, you can take another path if you don't wish to remain conformant, and both paths are DFSG-conformant, thus it doesn't really matter what the text of the standard is. The license attempts to place restrictions on actions beyond the scope of copyright via a clickwrap/shrinkwrap/implicit acceptance mechanism. Yep, you're right, those restrictions on how it can be used does make it non-DFSG-free. In context of the above, someone should be able to modify and use the software in a way not conformant to the MPEG-4 specifications, but the license is fine in saying that modification can't be redistributed (just as I can't distribute software that violates the GPL). Additionaly, it attempts to discriminate against use by persons engaged in certain fields of endeavor. How so? Those who wish to use some snippet of the software in another application, you mean? That may be unfortunate, but that's not a field of endeavor. At least IMHO, of course. Brian
Re: orphaning fetchmail
I think it's highly ironic that the GPL has such grief with the advertising clause, when it was the advertising clause that tripped up ATT during their lawsuit with UC Berkeley over Unix ten years ago. ATT was using BSD code and didn't follow that license, thus (in the settlement) BSD 4.4-Lite (which was BSD minus some 4 files that were indisputably ATT's) was released, which led to the *BSD's, and to a great deal of what you find in a typical Linux distribution. Had that not been there, most likely there wouldn't have been a freely-licensed BSD OS. I'm working with Stallman now on modifying the Apache license in such a way to make it GPL compatible, since I believe fundamentally our philosophies are compatible. Ask most people who BSD or Apache license their code if they feel that GPL advocates should be able to use their code, most will say yes. If I get as far as a draft this'll be one place I float it. Making end-users aware of the origin of development is important for many people, though; there is even language regarding it in the GPL, so incompatibility is probably something that can be worked through. Brian
Re: Source code with no (explicit) licence
Erm, is an API-for-API copy of a program taint-free? Given DJB's scant documentation, can one actually replicate it clean-room, without looking at the source code? Though I'd bet DJB would really only get up in arms about it if you called it freeqmail or something. Brian On Mon, 16 Oct 2000, Joseph Carter wrote: Go for it - each module of qmail is in and of itself very (VERY) simple and discrete. Produce one module at a time and replace the equivalent qmail module with it. When you have it all working stable together, release it under the GPL and watch DJB's face for the flash of pure rage and hatred Ahhh, it would be so nice to see... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= CollabNet |open source|do what's right| now hiring
Re: ITP: tnt -- An AIM client for Emacs
On Thu, 21 Sep 2000, Joseph Carter wrote: On Thu, Sep 21, 2000 at 12:58:32AM -0700, Michael S. Fischer wrote: It's my understanding that hurd for example doesn't have this kind of exception (and I suspect never will, given the project's foundation), so we'll never even see apache for it (the damned BSDish advertising clause strikes again!) The BSD advertising clause was removed from the license last year. See ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change for the official announcement. Ugh. Not from Apache it wasn't. The Regents of the University of California had the right to remove it from their software and only theirs. They don't own the rights to Apache. Not to a lot of software, in fact. We changed ours, though. See http://www.apache.org/LICENSE. Seems to address to pragmatic issues people had with the advertising clause. Brian
Re: FWD: Analog licence violates DFSG
On Tue, 12 Sep 2000, Joey Hess wrote: 1.Any action which is illegal under international or local law is forbidden by this licence. Any such action is the sole responsibility of the person committing the action. This provision of the licence blatently violates section 6 of the DFSG which states: 6.No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. I don't follow; maybe I'm just being dense, but section 1 seems like a no-op to me, a cover-your-ass by the attorney who wrote it to cover the case where a jurisdiction may decide that another clause in the license contradicts some law somewhere, thus rendering the license void (in that jurisdiction) or clearing the way for someone to get the author into legal hot water. That clause is arguably a feeble insurance against that. Maybe? Oh, wait, unless you're interpreting this very broadly, that it's not just the laws that apply to the copier within their specific jurisdiction, but the union set of all laws everywhere are applied to everyone. The language in the license is indeed sloppy, but I can't believe someone would reasonably think that this was what was intended. Even in that situation, though, it *still* doesn't violate DFSG #6, as far as I can tell. On a stretch, those international or local laws may be specific to an endeavor, but the license term is not. Brian
Re: FWD: Analog licence violates DFSG
On Wed, 13 Sep 2000, David Starner wrote: The DFSG is designed to be an objective standard. Not really, it's way too broad for that. If it were completely objective there'd be no debate about whether a given license violated it or not. Anyway, if this is acceptable, then can someone put in a clause about breaking God's law invalidates the license? I think pretty much all the arguments in this thread for the clause would also apply to such a clause. No, because copyright law is something that's enforced by a jurisdiction, that same jurisdiction (presumably, though the license was unclear about this) whose other laws the license is mandating you follow. Copyright law is not enforced by God. Brian
Re: IMAPD license problem?
On Wed, 23 Aug 2000, Raul Miller wrote: Of course, if the requirements are so pervasive that they can't be satisfied by personal action on the part of the package maintainer, we can just drop the package. But I do not see, at the moment, that these requirements can't be satisfied by the package maintainer (Jaldhar H. Vyas). What about the companies building their own distros on top of Debian? Do they need to obtain permission from UW if they modify the IMAPD package? Asking permission might not be onerous at all; it's that you have to do it (with the implication that they might say no, even if you live up to the published requirements) that feels like cognitive dissonance to me. Brian
Re: IMAPD license problem?
On Wed, 23 Aug 2000, Raul Miller wrote: On Tue, Aug 22, 2000 at 09:58:49PM -0700, Brian Behlendorf wrote: What about the companies building their own distros on top of Debian? Do they need to obtain permission from UW if they modify the IMAPD package? Did you even bother reading the other paragraphs I wrote? The question wasn't directed at you so much as the licensor at UW. Brian
Re: IMAPD license problem?
On Tue, 22 Aug 2000, Lori Stevens wrote: We confirm that we have given you permission to distribute a modified version of IMAPD on the condition that you assume all risks when you do so and agree to indemnify, defend, and hold harmless the University of Washington from any and all claims or damages that might arise through your activity related to a modified IMAPD. In order to reduce confusion and facilitate debugging, we request that locally modified versions, including those which are distributed, either be denoted by appending a letter to the current version number or that you in some way show that it is a derivative work in the version number. Both of these requirements can be effectively enforced without requiring people to get permission - just put it in a copyright license, in fact a slightly modified BSD license would suit this just fine. By requiring people to seek permission to redistribute, you are setting up a barrier higher than people in the Debian community want to see with software - they would to be able to modify and distribute *without* seeking prior approval. That seems reasonable, no? Brian
Re: [Talin@ACM.org: Suggestions for wording...?]
On Sat, 17 Jun 2000, Joseph Carter wrote: Okay guys, how about a few suggestions? Well, the obvious answer is that you can LGPL it, and add the restriction that the combined work must be licensed under a license that either is a) OSI-Approved Open Source (as found on www.opensource.org) or b) matches the Open Source Definition (as found on www.opensource.org) (Stallman in general doesn't like amendments to his licenses, though if it increases the amount of code thats forced to be published he may be happy, though of course his opinion is you should GPL it.) The latter may be harder to enforce than the former, if someone uses a new license that they claim conforms but hasn't been cetified. The quandry, though, is that if you're trying to prevent linking with non-open-source projects, this probably won't help you, since open source licenses themselves usually allow for some form of linking with non-open-source software. BSD/MIT/Apache, MPL, etc... the first-order derivitive might have to be open-source, but does that mean the second-order derivative would be? Certainly the first-order LGPL/OSL parts would be, but not the whole. If you want infinite virality, i.e. every derivative must be "open-source", then the GPL may be what you want anyways. Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Talin@ACM.org: Suggestions for wording...?]
On Sat, 17 Jun 2000, Joseph Carter wrote: Okay guys, how about a few suggestions? Well, the obvious answer is that you can LGPL it, and add the restriction that the combined work must be licensed under a license that either is a) OSI-Approved Open Source (as found on www.opensource.org) or b) matches the Open Source Definition (as found on www.opensource.org) (Stallman in general doesn't like amendments to his licenses, though if it increases the amount of code thats forced to be published he may be happy, though of course his opinion is you should GPL it.) The latter may be harder to enforce than the former, if someone uses a new license that they claim conforms but hasn't been cetified. The quandry, though, is that if you're trying to prevent linking with non-open-source projects, this probably won't help you, since open source licenses themselves usually allow for some form of linking with non-open-source software. BSD/MIT/Apache, MPL, etc... the first-order derivitive might have to be open-source, but does that mean the second-order derivative would be? Certainly the first-order LGPL/OSL parts would be, but not the whole. If you want infinite virality, i.e. every derivative must be open-source, then the GPL may be what you want anyways. Brian
Re: [Talin@ACM.org: Suggestions for wording...?]
On Sun, 18 Jun 2000, Joseph Carter wrote: Hopefully this clarifies Talin's request a bit.. I won't be able to answer for at least 10 hours, probably longer. I'm going to BED. On Sun, Jun 18, 2000 at 10:29:32AM -0700, Talin wrote: I recieved a few suggestions which, unfortunately, seem to be based on misunderstandings of what I'm asking for. The license that I want should have the following features: 1. Be compatible with the GPL. Then you must use a license with *fewer* restrictions than the GPL, and don't deny adding restrictions. For example, the BSD/MIT/Apache licenses, at least the newer versions without the advertising clauses. Only those kinds of licenses are compatible with the GPL. 2. Allow linking with other open-source licenses. Almost any license which satisfies #1 will satisfy #2. Do you also have a requirement on what license the larger work will be under? If that is GPL, then certain open-source licenses will not be compatible, as they have their own requirements about larger works, such as the MPL. 3. Should be as restrictive as the GPL when it comes to proprietary software, i.e. it only allows linking with proprietary software in certain special cases. Since you can't simultaneously have fewer restrictions than the GPL, and be as restrictive, this may be where the inconsistancy lies. Here is the language I came up with: A special exception to the GPL listed below is that this program may be linked with any libraries or components that are distributed under a license that meets the Open Source Definition (http://www.opensource.org/osd.html), and that such components shall be considered seperate works, not covered under the terms of this license. However, I'm not sure that this language is legally sound. Please help me debug it. That's fine, however this software will then not be compatible with other pure-GPL software, which would prevent this kind of special-case. I.e. GPL, except is an oxymoron as a license, though authors of GPL software may choose not to enforce it in certain circumstances (e.g., Linus and binary-only kernel drivers). At least this is my understanding. Brian
Re: New Apache license compatible with GPL? (Was: [Talin@ACM.org: Suggestions for wording...?])
On Sun, 18 Jun 2000, Mark Wielaard wrote: I think that clause 1, 2 and 3 are not a problem, but you might have to change clause 4 and 5 into a request instead of a demand (which is a added restriction if you want sidtribute a derived work that also uses code that falls under the GPL). So you might want to say: 4. Please don't use the names Apache and Apache Software Foundation to endorse or promote products derived from this software without prior written permission. For written permission, please contact [EMAIL PROTECTED] 5. If you make products derived from this software please don't call them Apache, or use Apache in their name, without prior written permission of the Apache Software Foundation. Maybe just changing the must in a should in the original text would be enough, but english isn't my native language. If you want I can contact the FSF and discuss it with them. I believe Richard Stallman will come to the LSM next month and I could try to discuss it with him then. That's why both clauses contain the word please, and don't say the word must. Trademark protection is beyond the scope of a copyright license, and protection of the Apache name is very important to us - we'd be pretty pissed by someone releasing a product called ApachePro, Apache++, etc, even if it was open source. Yet we do allow it to be used from time to time, basically by those who are solid contributors to the code base. I sent this to Stallman before the ASF agreed to adopt it, and while he didn't explicitly give it his blessing, he did seem to find it far less objectionable. I've not queried him for an official opinion. Brian
Re: reiserfs-utils_3.5.19-1_i386.changes REJECTED (fwd)
On 16 Jun 2000, James Troup wrote: From the copyright: | If you wish to integrate it with any other | software system which is not GPL'd, without integrating it into an | operating system kernel, then you must obtain an additional license. This makes this software non-free. If you disagree with this analysis, please take it up on [EMAIL PROTECTED] Thanks. James I don't agree. The GPL only allows integration with GPL products. Eh? No it doesn't. I can, for example, integrate GPLed code into a product with a MIT-style license without problems. The license on the collective whole will become GPL, since the MIT's requirements are a strict subset of the GPL's (the only true measure of compatibility between the GPL and anything else). The license on the MIT parts will still be MIT. I think I understand what the license is trying to say (that non-GPL licenses are available from the author, if you don't want to be bound by the terms of the GPL?), but the way it's currently worded is incredibly sloppy and fails the DFSG. That blurb simply states a fact (that the copyright holder has the right to relicense), and I'm not sure how stating a fact is contrary to the DFSG. Of course, the licensor better make sure they get copyright assignment from all contributors, otherwise that fact becomes invalid, strictly speaking. Brian
Re: webmin license
On 15 Dec 1999, Henning Makholm wrote: Brian Behlendorf [EMAIL PROTECTED] writes: On Mon, 13 Dec 1999, Marc van Leeuwen wrote: a) REMIND may not be used under Microsoft Windows (3.0, 3.1, 95 or NT) or any future version of Windows. Such use constitutes a violation of copyright. b) REMIND may not be used by Cadabra Design Libraries Inc. or its directors, nor by any of Cadabra's subsidiaries or their directors. Such use constitutes a violation of copyright. c) Except for situations (a) and (b), REMIND may be used and distributed according to the terms of the GNU General Public License, Version 2, which follows: [...] a) and b) contradict c). No, because (c) explicitly states that (a) and (b) takes precedense over the terms of the GPL. It doesn't matter that (c) says (a) and (b) take precedence - the GPL itself says no other conditions may take precedence. So either what is distributed as the GPL is *not* the GPL, (nor should it be called a patched GPL, as it reverses a significant part of what the GPL stands for) or the GPL takes precedence. I'm sure Stallman would say the same thing, with a bit more of a bite too. This document is self-contradictory. I don't know what copyright or contract law says about a license that self-contradicts. Debian folks should be up in arms about this, I can't believe I'm the one responding to this. Or did everyone else already /dev/null this thread? Brian
Re: webmin license
On Mon, 13 Dec 1999, Marc van Leeuwen wrote: Indeed a) REMIND may not be used under Microsoft Windows (3.0, 3.1, 95 or NT) or any future version of Windows. Such use constitutes a violation of copyright. b) REMIND may not be used by Cadabra Design Libraries Inc. or its directors, nor by any of Cadabra's subsidiaries or their directors. Such use constitutes a violation of copyright. c) Except for situations (a) and (b), REMIND may be used and distributed according to the terms of the GNU General Public License, Version 2, which follows: [...] a) and b) contradict c). The GPL states that no further restrictions may be placed on the code. So all the parties mentioned in a) and b) may use the software under the terms of clause c). Brian
Re: mutt no longer in non-us?
On Mon, 15 Nov 1999, Bruce Perens wrote: From: Brian Ristuccia [EMAIL PROTECTED] What has changed that allows us to distribute mutt from the US to people outside of the US despite the fact that mutt is capable of integrating with strong encryption software and thereby capable of performing strong encryption on messages it sends? This would also restrict vi and emacs. Each is capable of piping text through a random command. It would restrict the shell. It would restrict the kernel. It would restrict any program with source code. Can't help the government on this one, sorry. If they have a problem with it, we'll have to see them in court. Just to make clear I'm understanding the situation; does mutt have anything that could be interpreted as hooks to encryption, even if it doesn't have crypto code as part of the package? Or are scripts instructions on how to add crypto to the base product provided separately from a non-us package? If the former, unless something has changed, the U.S. considers that a crypto product. If the latter, you're OK. That's why vi/emacs/shells/kernels wouldn't be called crypto products, so long as they have no direct hooks themselves to encryption routines. Of course, if the U.S. recently said that hooks to crypto is OK, then that would be cool too. But this hook business is why we can't have SSL directives routines in the base Apache distrib, even if we told people to bring over OpenSSL separately. Brian
Re: mutt no longer in non-us?
On Thu, 18 Nov 1999, Joseph Carter wrote: If you think about prime numbers near the Mexican borders the US could try to say you're exporting crypto. We made the decision that a simple run this seperate program and pipe output back to me cannot reasonably be considered encryption hooks. That's great, again, so long as the program itself doesn't mention encryption in its own code or docs. Signing is OK, as the gov't has said that they're only worried about encryption, not one-way hashes. This is the same reason why the SSL-tunnelling-through-regular-HTTP-proxy HTTP directive is CONNECT rather than something like SSL-PIPE. If such is allowed to be considered encryption we must also conclude that bash contains encryption hooks (as it too will optionally run pgp and read its output) and so would any program which may run any arbitrary binary and pipe its output someplace useful. Do the bash man pages describe how to use pgp to encrypt messages? And frankly speaking for only myself as a citizen of the US and not as a developer here, the US government can shove their crypto regs someplace unpleasant---I refuse to comply with them on the grounds that they are an affront to the protections guaranteed me under the first, fourth, and fifth ammendments to the constitution and further do place myself and my personal property at great risk when conducting wire-based transactions. I'd also like to make sure the debian.org machines don't get seized one day when the gov't gets a bug up their butt. Yes, it's likely that mutt won't be the critical factor here. But if you're going to willfully violate the common interpretation of the law, at least you should make sure everyone else is on board, such as the various Debian distributors. Brian
Re: Corel's apt frontend
On Sun, 31 Oct 1999, Joseph Carter wrote: Kernel is GPL. Everything is a derivative of the kernel under your interpretation. You can argue that Linus has allowed people to abuse the GPL of the kernel so it's okay, however I think this would cause the GPL to contaminate any distribution which contains any GPL software. If that doesn't cross the DFSG line, it comes very damned close to doing it. If RMS intends this sort of contamination (I don't believe he's even considered the issue fully) then we CANNOT ship things like Apache with Debian unless we get permission from Linus and the other kernel Copyright holders to do so, in writing (or at least in email with modified license terms to be applied to the next release of the kernel) Or you can simply decide to disagree with Stallman on his interpretation of the GPL itself. The same address space - talk about ambiguity. I have a feeling should Stallman decide that the GPL was this far-reaching, he'd soon have to defend that interpretation in court, a forum the GPL has never been tested in before (under any interpretation). I predict it would also cause a commercial stampede towards FreeBSD. =) I would expect a similar reaction should Stallman change the GPL in GPLv3 to apply to any interface to a GPL'd program (the loophole Bruce wants to close). Should this interpretation of the GPL become dominant I believe we should deprecate the GPL in favor of a license which does not skirt the letter of the DFSG while violating its spirit in favor of some license which doesn't. (Which would suck because I don't know of any other suitable licenses that do anything like what the GPL does..) Thoughts on the MPL? I find it a more than adequate compromise between the GPL's viral nature and BSD's optimal-reuse strategy. Brian -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Collab.Net is hiring! http://www.collab.net/
