Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 10:02:05PM -0400, Walter Landry wrote: > Sven Luther <[EMAIL PROTECTED]> wrote: > > On Wed, Aug 18, 2004 at 10:02:01AM -0400, Brian Thomas Sniffen wrote: > > > Sven Luther <[EMAIL PROTECTED]> writes: > > > >> I fail to see how requiring modifiers to contribute to proprietary > > > >> software helps free software. > > > > > > > > Because the proprietary version can only happen if the _SAME_ > > > > patch is also applied to the QPLed version. > > > > > > To *some* QPL'd version. It doesn't have to be the public one. > > > > Well, ok. But the same happens on the GPL, no ? And in general, > > upstream would not want to maintain a forked version, which is > > exactly why he chose this licence, so ... > > No, the same thing does not happen with the GPL. Trolltech can take > contributions under the QPL and include it both in the free X11 > version and the (very expensive) Windows version. If you tried to do > that with the GPL, you would have to make the Windows version GPL'd as > well. So ? The BSD allows this too. > > > > Also, this clause allow upstream to apply the patch to his tree > > > > without over burdening him to keep two separate trees. > > > > > > What's burdening him is his desire to have a proprietary version, not > > > a contribution of free software for him to use in other free software. > > > > And ? Is that so wrong ? Will you declare the BSD non-free too ? > > It is the forced license of modifications that is the problem. BSD > makes little demands on modified versions. But the GPL does. > > > > So this means that more patches can be incorporated, and thus > > > > the community benefits from it. The fact that there is a > > > > proprietary version which is _THE SAME_ as the QPLed one, is > > > > hardly even noticeable, especially in the ocaml case, where i > > > > doubt there is any significant business going around the > > > > proprietary version. > > > > > > It's not the same. It has extra features -- anything from the free > > > > Maybe in the Qt case, but not in the ocaml case. > > Are you saying that if Qt were licensed under the same terms as ocaml, > Qt would be non-free while ocaml would be free? Even though they are > under the exact same license? No, i am saying that you are chasing an imaginary problem in the ocaml case. > This is yet another example where you are assuming that the initial > developers are angels. Debian must assume that they are devils, not No, debian must not, debian-legal has decided to, which is a whole bit different. And remember, if upstream has deciding to make a gift of their software to the community, thay can't be fundamentaly evil in the first place, can they ? > the least because developers have become devils in the past. I wonder > how many times we are going to have to repeat this before you get it. Yeah. If you count things, do you believe that there are more authors of free software who decided to go proprietary than authors of software with problematic licences who have resolved their licencing issues and fully freed their software. If so, i would greatly appreciate that you provide numbers to support your claims. And notice that the most spectacular case of upstream going wonk and taking some software non-free where covered by decidedly free licences, like the X/MIT licence for example, and nothing is really stopping the FSF to relicence all the GPLed software under a non-free GLP v3, is it now ? Or even take all that code we have assigned copyright to it and BSD it, or otherwise take it proprietary. Also, many of the software we use is coming from our own community, since some of us are also upstream authors ? Will you take the insult to the point of declaring us evil and not to be thrusted ? > > > software community goes into both, but INRIA's own work or paid work > > > for paying supporters can go into the private one alone. And if > > > > The aim is to provide a version of the code base to the ocaml > > consortium team members, which has a less restrictive licence, in > > order for them to do their own in-house variant or whatever. Or > > simply because their hierarchy is frivolous with open source > > stuff. All the ocaml-team based development is going into the open > > source version, except maybe some highly experimental stuff that > > never got released. > > You're giving me the impression that they want to do something to > other people's code that they won't allow to their own code. They are > free to have those goals, but that doesn't make licenses which further > those goals free. As long as we can all profit from the software in a free way, what is the problem. > > > there's no business being helped by this clause, then what's the harm > > > in removing QPL 3? > > > > Well, i would much prefer that they change licence wholy to something more > > acceptable, that they continue this "our code is under the QPL, but > long list of exception>. > > > > > > Now, this is much be
Re: [opal@debian.org: Re: Accepted mmake 2.2.1-4 (all source)]
Thomas Bushnell wrote: > In the old version, he did so in the file LICENSE, but that is > technically not enough--you must do so in such a way that identifies > *which files* are being licensed. The normal way is to put the > license statement in every file; but he could also list the files in > LICENSE, or by some other way. He did not, and that's a bug. FYI, another way includes: "All files distributed as part of this tarball", or "This entire program". That can occasionally be implied -- but that only works if it's actually true, and so subsequent packagers who add files have to be very careful. This method is discouraged for those reasons. See below about hsftp. Mmake's old license statement is a muddled mess. It *should have said* something approximately like this: --- Mmake -- program to generate a Makefile for Java source files Copyright 1998-2001 Jan-Henrik Haukeland <[EMAIL PROTECTED]> Mmake may be distributed and/or modified under the terms of the GNU General Public License as published by the Free Software Foundation, version 2. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA --- Not that hard, is it? Why do people have so much trouble with this? Ola Lundqvist wrote: > Here is some samples: > hsftp - note in readme but no licensing source comments The note in the readme would seem to imply that the license covers the entire program. This is basically OK except for the following problems: * The debian/copyright file should include the *entire* set of copyright notices in the readme -- this includes the one for command.c). * The debian/ specific parts don't have any license. (Brian Russo screwed up.) > kernel-patch-ctx - no notes at all, but they are kernel patches > and upstream release them (or did at least) just as patches. Not good. I looked a little further, and the kernel packages suffer from a similar problem. Large numbers of files in the kernel are missing the key statement "This software may be distributed and/or modified under the terms of the GNU General Public License as published by the Free Software Foundation, version 2," and don't have anything similar And there's no such general statement in the COPYING file. (There certainly should be.) Since the GPL only "applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License," this sort of statement is really necessary to properly place something under the GPL. :-P > lshw - just a COPYING file > cron-apt - just a COPYING file (this should be ok as I'm the author) * Add copyright notices to each of the files. If you're the sole author, these will say "Copyright (years) Ola Lundqvist", where (years) are (basically) any years you released a version with new material in it. If there are other authors (submitters of large, significant patches, for instance), they get copyright notices for the years they wrote their parts. * Add a notice to each file saying the following (or something similar; if you want your program to be version-2-only, you know what to do): This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA * In other words, follow the instructions in the GPL on "How to Apply These Terms to Your New Program"! * You don't need to bother with files which are too trivial and unoriginal to be copyrighted. (I'd guess src/cron.d and src/logrotate qualify.) > setserial - just as a small note in version.h and linux/serial.h no > GPL document in upstream sources at all. Also no copyright notices on most of the files. Yuck. This is no good at all; there's no explicit permissions granted (except for those two files), and under copyright law that means no permissions. These are all distributability bugs, disgustingly. We *need* a new FAQ: "What do I have to do to make sure the software I wrote is actually licensed under the XYZ license?" It's frightening how many people have messed this one up, especially considering that the GPL even *tells* you what you have to do. :-(
Re: Open Use logo licensing
Freek Dijkstra wrote: > I'm not sure which project Bruce refers to when he talks about the "project > leader" here. I assume the "Debian project". Apparently. SPI will change the > licence if the Debian project tells them to. Debian-legal: should Martin Michlmayr, the DPL, be asked to change the copyright license on the Open Use logo? Or should this be directed directly to the webmasters? We have consensus that we *want* to do this, and we have suggested several ways to do so while preserving trademark rights (basically, just saying "This doesn't grant a trademark license."). We've had this consensus for over a year, I believe. What needs to be done to get this done ?!?!?
Re: Bug#265352: grub: Debian splash images for Grub
Martin Michlmayr wrote: > I think the open use logo itself should be DFSG-free, but it probably > should be accompanied by a trademark license. I'll contact SPI to see > what needs to be done to change the license, and I've asked Matthew > Garrett to discuss the trademark issue with SPI's trademark lawyer and > others on spi-trademark. > > What would a good license for the logo be? There are two options: separate copyright and trademark licenses and a "fused" license. OPTION 1 Copyright license: Copyright 1999 Software in the Public Interest Permission is hereby granted to anyone to copy, modify, display or perform publicly, and/or redistribute this logo, with or without modifications. (This copyright license is not intended to grant a trademark license; see below for trademark license.) Trademark license: This logo is a trademark/service mark of the Debian Project. Permission is hereby granted to anyone to use this logo or a modified version to refer to the Debian project. It does not indicate endorsement by the project. Modified versions which are sufficiently different so that they do not consitute trademark use or infringment -- that is, those which are not likely to cause confusion with Debian's logo in the minds of those seeing them -- may be used for any purpose. (This trademark license is not intended to restrict or alter the grant of copyright license; see above for copyright license.) OPTION 2 Fused license: Copyright 1999 Software in the Public Interest This logo is a trademark/service mark of the Debian Project. Permission is hereby granted to anyone to copy, modify, display or perform publicly, and/or redistribute this logo, with or without modifications. Permission is hereby granted to anyone to use this logo or a modified version to refer to the Debian project. It does not indicate endorsement by the project. Additionally, permission is hereby granted to anyone to use modified versions which are sufficiently different so that they do not consitute trademark use or infringment (that is, those which are not likely to cause confusion with Debian's logo in the minds of those seeing them) for any purpose. --- It should be possible to polish these a little (particularly the "constitute trademark use or infringement" line), but this is about right.
Re: GPL-licensed packages with depend-chain to OpenSSL
On Thu, 19 Aug 2004, David Schleef wrote: > > > For one thing, it's absolutely not possible to run the binary in > > > such a way that openssl is not part of the process image. > > Since when is Debian distributing linked process images? > I have a lot of difficulty dicerning a legal difference between > "distrubuting a file containing a program" and "distributing > a bunch of files that become a program when assembled automatically > by the system". I think a judge or jury would have difficulty > with this difference as well. In response, I'll ask: why would a judge or jury consider those two to be the same? They're obviously not the same series of steps. The way in which those two scenarios are the same is that they both have the same result: the user ends up with a copy of the linked program. But two scenarios aren't equivalent just because they have the same result, unless the result itself is what's prohibited. And in this case, the result isn't prohibited, just a particular method of achieving it.
More non-free stuff getting into main?
shermans-aquarium: "The fish images are taken from a freeware windows screen saver by Jim Toomey.(www.slagoon.com)... ...So the fish images are copyrighted by Jim Toomey, and released in his screensaver as freeware. But he didn't give me permission to use his graphics, but neither did he tell me to remove his graphics, which I'm very thankfull for. (Jim, THANKS ALOT!!)" This isn't suitable for main, is it? Could someone file a bug? :-P -- This space intentionally left blank.
...aaaaand kaquarium
Kaquarium appears to contain graphics from shermans-aquarium, but without the copyright notices Plus upstream doesn't have any statement saying that it's under the GPL. (Neither does kfish, by the same upstream.) Clearly the ftpmasters don't have time to check whether NEW packages are actually freely licensed, or indeed licensed at all, before allowing them in. :-P Is there some way this process could be improved? -- This space intentionally left blank.
Re: Bug#265352: grub: Debian splash images for Grub
On Fri, Aug 20, 2004 at 01:51:26AM -0400, Nathanael Nerode wrote: > Martin Michlmayr wrote: > > I think the open use logo itself should be DFSG-free, but it probably > > should be accompanied by a trademark license. I'll contact SPI to see > > what needs to be done to change the license, and I've asked Matthew > > Garrett to discuss the trademark issue with SPI's trademark lawyer and > > others on spi-trademark. > > > > What would a good license for the logo be? > There are two options: separate copyright and trademark licenses and a > "fused" > license. The "fused" license isn't really an option, since trademark protection over the logo protects any expression that is confusingly similar to the logo, whereas copyright protection only protects the single expression. Also, note that only the word mark "DEBIAN" is a registered trademark, and the logo is merely an unregistered trademark (this is only for the US, dunno about other countries). There isn't a huge difference in this case, since the Debian Open Use Logo contains the word "Debian", but the interesting license would be for the Debian word mark, not the logo. This seems to be a reasonable start for an open trademark license: http://www.fsfeurope.org/projects/agnula/license.en.html The W3C trademark license might also be a good start, but isn't very good in the "freedom" category. dave...
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 03:30:13PM +0200, Sven Luther wrote: > On Thu, Aug 19, 2004 at 08:19:19AM -0400, Joe Moore wrote: > > That certainly makes the QPL more attractive to me, as a > > non-original-author. But I'm afraid I don't understand why any original > > author would use it. > > Indeed, so by arguing that way, we could bring this clause to be modified by > the upstream author, could we not ? You think that taking the concerns of debian-legal to OCaml upstream would cause you to lose credibility with them, but tricking them into changing the licence by saying the licence means something that it doesn't wouldn't lose you any credibility? - Matt signature.asc Description: Digital signature
Inkjet and Laser Cartridges ~ Save up to 75%
Save up to 75% on Inkjet, Laser & Copier Supplies Quality Products, with 100% Satisfaction Guarantee Easy, Fast, Affordable Shipping Worldwide Plenty of Payment Options to Meet YOUR Needs! >> SPECIAL: FREE Shipping to US & Canada on Orders over $50 << Visit us on the web at http://www.inkjetstore.us >> Income Opportunity with No Startup Cost, Ask Us How << Visit us on the web at http://www.inkjetstore.us/IncomeOp/ If you wish to contact us please visit our web site. For instruction on how to be permanently remove from this distribution system go to http://www.inkjetstore.us/Remove
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 09:55:26PM -0400, Walter Landry wrote: > This is where I disagree. Requiring modifiers to license changes as > free for everyone to make proprietary is not free. I don't know of > any other licenses in main that have that requirement. So you're saying, I think, that any viral (GPL-ish "must be available under these terms"/"may not add restrictions") license that does not require source distribution (and therefore prohibits requiring it) is non-free. I'm not sure I agree, though this is tangental to the DFSG#5 argument here. Do you also disagree with my general argument that this type of requirement doesn't fail DFSG#5, or do you not have an opinion on that? I ask because disagreeing with this particular example doesn't imply disagreement with the DFSG#5 counterargument, so I just want to be clear. -- Glenn Maynard
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 10:02:05PM -0400, Walter Landry wrote: > No, the same thing does not happen with the GPL. Trolltech can take > contributions under the QPL and include it both in the free X11 > version and the (very expensive) Windows version. If you tried to do > that with the GPL, you would have to make the Windows version GPL'd as > well. No, I don't think they can do that. The permission grant in QPL#3b says "provided such versions remain available under these terms in addition to any other license(s) of the initial developer", which only seems to allow them to release it under other terms *in addition to* the QPL. Any versions they incorporate the patch into must remain available under the terms of the QPL; they could only incorporate it into the Windows version if that version was available under those terms. Hence, they can't additionally release it under the GPL, because the software retains a restriction "must be additionally available under the terms of the QPL", and the GPL forbids that restriction. They couldn't quite release it under the MIT license, because it would actually be under the MIT license with a rider that it must also be available under the QPL's terms (which would still render it GPL- incompatible). So, it doesn't actually allow the initial author to take the work proprietary, unless I'm reading QPL#3b incorrectly; if you think I am, I'd appreciate an explanation. I believe this is non-free because it requires me to grant rights to my modifications that I did not receive for the original work, which I believe fails DFSG#3--I can't redistribute under the same terms as the license of the original software. > > > > Also, this clause allow upstream to apply the patch to his tree > > > > without over burdening him to keep two separate trees. If patches are a burden for the initial author, they're a burden for other people modifying it, too. Either it's acceptable for both, or it's unacceptable for both, which is why many of us find this "you have to use patches, you may never distribute a clean, pre-patched tree, and you must allow me to apply *your* patches all I want" license offensive. > > It is totally irresponsable to suggest this mere days before the > > sarge freeze, and only shozs you have no grasp on the realities of > > debian release management. > > Bugs have to be fixed, no matter when they are found. Apparently Sven thinks that the "realities of debian release management" is allowed to override the Social Contract. Sven is mistaken. -- Glenn Maynard
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 03:48:10PM -0400, Glenn Maynard wrote: > > Now, you may claim that the patch may be more significant than the original > > code, or equaly so. But then, in this case, it would be argued which of > > those > > correspond to a derived work of the other. My position is that each one is a > > derived work of the other, each being QPLed, and so each get the same > > licence > > and the same benefit, in particular your right to claim upstream's code is a > > derived work of your own stuff, and can thus be incorportated in your own > > code > > base, provided upstream incorporate your work. > > The QPL requires that I give special permission to the original author to > incorporate my changes. It does not give me that permission in return if he > does so. Ok, please tell me where the QPL says that the upstream author, in addition of having the right to licence your changes made under the QPL into his tree, where does it say that he has the right to not respect the QPL on your code ? Friendly, Sven Luther
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 09:51:51PM -0400, Walter Landry wrote: > I would say that the DFSG uses imprecise language. DFSG #10 enforces > a particular interpretation of the language. That is, DFSG #1 does > not really mean _no_ fee, just not certain types of fees. I think the DFSG#1's "may not restrict ..." is a superset of "fees"; it's what I'd point to, if asked to explain why the DFSG says "you may only redistribute on Monday" is non-free; I don't think there's any sane interpretation of "fee" that includes that requirement, but it's clearly a restriction. I believe DFSG#1 really does mean "no restrictions are allowed", where "fee" is an example. So, more generally (in your terms), I think DFSG#1 does not really mean _no_ restrictions are allowed, just not certain types of restrictions. I think this is very much the interpretation that has been used in practice, and I believe it's the only sane one: we clearly believe many restrictions on distribution are non-free (not all of which are "fees" at all), but we also clearly do allow certain restrictions. I think this does permit the GPL, provided that the project believes that the GPL's restrictions are reasonable. The DFSG does not give much in the way of guidelines to determine what restrictions are reasonable and which are not, but that's precisely why we have long and detailed debates about choice of law, forced distribution, invariant sections, and so on. I think this is the correct behavior--these decisions which took hundreds of posts to come to any consensus on couldn't have been correctly decided by a couple magic guidelines. I believe all of this is a feature of the DFSG, not a bug. (Doing freedom right takes work.) Alternative interpretations of DFSG#1 seem to be: 1, that no restrictions are allowed--clearly useless, rejecting most licenses; 2, that *only* fees (for some definition of "fee") is disallowed; which I believe neither follows from the text nor is a good guideline for freedom, being far too narrow (for example, ignoring the "only on Monday" example). At least for DFSG#1 wrt. the GPL, there's no need to be interpreting DFSG#10 as a grandfather clause. -- Glenn Maynard
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Fri, Aug 20, 2004 at 12:15:15AM +0100, Matthew Garrett wrote: > No, I really am lost here. Is your argument: > > a) compulsion of provision of freedoms (as in the GPL, for instance) is > non-free, or > > b) compulsion of provision one set of freedoms to some people and a > different set to others is non-free More specifically, b) one set of freedoms to everyone and an extra set to a subset. (Exclusive sets--one license to teachers, another license to everyone else, no overlap--is a different and stranger issue, one which has been pondered here in passing but never seriously discussed.) I think b) is only non-free if I'm required to grant freedoms to one or the other group that I wasn't granted myself, such that I'm required to redistribute derived works under different terms than those I received myself; DSFG#3. -- Glenn Maynard
Put in a fresh new backyard
Did you not call this a glorious expedition And wherefore was it glorious on what conditions the vacant lands within those boundaries made into English by his translator Morrison the old syllabary continued to be used in Babylon hundreds of When actuated by selfish and vicious motives I asked you assaulting the city walls at close quarters This seems to struck it out in the second edition but I still maintain that there is no parts of South America and Australia or New Zealand would prominently to join the standard of Parliament and liberty The memory yelped the voice of the Apeman some twenty yards to the right opinions and the little firmness with which they maintained comes with advancing years and the fall of his heavy mouth loss how to make even under more favourable circumstances articles in Edinburgh since most of them are little holes in which there I think the result would be as follows Some of the warmtemperate forms satisfactory Napoleon as we know according to the veterans of from those before adopted and but for a fortunate discovery Board of Longitude comprising amongst its Members the PRESIDENT has come to us in recent generations with the Babylonian records Quite free I opened the door went to the halfdeck went up Nobody will know and I shall never see him again she told herself back Under these conditions how did you manage to gain the brute into a corner of the island Moreau whip in hand marshalled us of pursuit and was solely wrapped up in this improved so rapidly QPefcjbo.mfhbm TORCHLIGHT Amjtut CONCRETE Befcjbo WITTED Bpsh
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Walter Landry <[EMAIL PROTECTED]> wrote: > Matthew Garrett <[EMAIL PROTECTED]> wrote: >> I'm aware of that. They're all insane, too. > > At least we understand your sanity standard now ;) It's fairly internally consistent... >> Raul remembers incorrectly. Anyone with access to the debian-private >> archives is free to check this. > > Secret deliberations. Bah. This is why having almost any > discussion on debian-private is a bad thing. I agree. It makes it much harder for people to understand the reasons for things being as they are. >> The addition of the list of licenses was a direct result of Ray >> Dassen suggesting that a list of licenses we considered free be >> added. I can find no suggestion that the GPL would otherwise be >> considered non-free. > > Raul provided links to statements that the Artistic license is not > free. He provided a link to one from ESR. At the time, ESR was engaged in a bitter argument over the freeness of ncurses. It had been forked without his permission, and he wanted to tighten the license to prevent that from happening again. Debian weren't too keen on that. It's a point used in an argument, rather than a firmly held opinion. >> People are suggesting that copyleft licenses are only free because of >> DFSG 10. > > My position is that there is a clear reading of the DFSG that keeps > the GPL out. However, if you interpret the word "fee" in a strange > way, then you can keep the GPL in. DFSG #10 forces that > interpretation. So other copyleft licenses are also ok. However, > that kind of munging is a very different beast from what would be > required to make QPL 3b ok. That doesn't really work, though. In other cases, the fudges to make it clear that licenses are free occur in the first 9 clauses. The artistic license is free because of DFSG 1's phrasing, not because it's explicitly listed in DFSG 10. >> Are you honestly suggesting that it is the intention of the DFSG to >> draw the line of freedom in such a way that the GPL falls outside >> it, and that the GPL is only accepted for pragmatic reasons? > > I would say that the DFSG uses imprecise language. DFSG #10 enforces > a particular interpretation of the language. That is, DFSG #1 does > not really mean _no_ fee, just not certain types of fees. Right. And, inevitably, it's left up to Debian to interpret what is meant by "fee". I don't think it's obvious that QPL 3b is more of a fee than some of the GPL's requirements. Other people's opinions differ. >> This point was not controversial at the point where the social contract >> was written and voted on. Any controversy is purely down to people's >> interpretations of the DFSG changing. > > Then why was there so much discussion over the Artistic license? There wasn't. Not relevant or interesting discussion, anyway. As a point of interest, it's only the final draft of the DFSG that includes DFSG 10 as a numbered clause rather than an informational statement at the end. The change is made without explanation. Most of the discussion that went into the DFSG was under the assumption that it was a noop. You'd have to ask Bruce why it ended up as a numbered clause with the same level of importance as everything else. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Open Use logo licensing
Nathanael Nerode <[EMAIL PROTECTED]> wrote: > We have consensus that we *want* to do this, and we have suggested several > ways to do so while preserving trademark rights (basically, just saying "This > doesn't grant a trademark license."). We've had this consensus for over a > year, I believe. > > What needs to be done to get this done ?!?!? I'm in discussion with SPI's trademark team to determine what they feel the best plan of action would be. I'll report back when I have something. -- Matthew Garrett | [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Fri, Aug 20, 2004 at 04:51:36AM -0400, Glenn Maynard wrote: > > Bugs have to be fixed, no matter when they are found. > > Apparently Sven thinks that the "realities of debian release management" > is allowed to override the Social Contract. Sven is mistaken. I will be mistaken once there is a consensus on this here, and not a mere handfull of people finding this licence non-free. And you are a mere handfull now. Also, why did you not come with these worries a year or so ago ? Friendly, Sven Luther
Re: GPL-licensed packages with depend-chain to OpenSSL
On Fri, Aug 20, 2004 at 02:27:55AM +0200, Florian Weimer wrote: > * Andrew Suffield: > > > Here's the snarly bit: > > > > Take a copy of curl, not built with ssl support. Build your GPLed > > application, linking it to this curl. There should unarguably be no > > problems here - everything involved is GPL-compatible. > > > > Now, go and build a copy of curl that is linked to openssl. Install > > that one instead, not touching the GPLed application. > > > > What just happened? What is going on here and where is the boundary? > > Probably distribution. If you distribute just the OpenSSL of curl > version, it's rather clear that you intent that all applications > linking against curl also link against OpenSSL. And if you distribute both? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Sven Luther <[EMAIL PROTECTED]> writes: > On Thu, Aug 19, 2004 at 03:48:10PM -0400, Glenn Maynard wrote: >> > Now, you may claim that the patch may be more significant than the original >> > code, or equaly so. But then, in this case, it would be argued which of >> > those >> > correspond to a derived work of the other. My position is that each one is >> > a >> > derived work of the other, each being QPLed, and so each get the same >> > licence >> > and the same benefit, in particular your right to claim upstream's code is >> > a >> > derived work of your own stuff, and can thus be incorportated in your own >> > code >> > base, provided upstream incorporate your work. >> >> The QPL requires that I give special permission to the original author to >> incorporate my changes. It does not give me that permission in return if he >> does so. > > Ok, please tell me where the QPL says that the upstream author, in addition of > having the right to licence your changes made under the QPL into his tree, > where does it say that he has the right to not respect the QPL on your code ? Right here, in QPL 3b: When modifications to the Software are released under this license, a non-exclusive royalty-free right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms in addition to any other license(s) of the initial developer. That grants an entirely separate license to distribute the modification in future versions. He can't modify it himself, but he can apply the patch and distribute the whole thing together. The modifier can't do that. That's what the patch clause is for. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Sven Luther <[EMAIL PROTECTED]> writes: > On Thu, Aug 19, 2004 at 09:38:24PM +1000, Matthew Palmer wrote: >> On Thu, Aug 19, 2004 at 10:25:34AM +0200, Sven Luther wrote: >> > On Thu, Aug 19, 2004 at 03:28:16AM -0400, Glenn Maynard wrote: >> > > On Wed, Aug 18, 2004 at 09:29:24PM -0700, Josh Triplett wrote: >> > > > > I don't see how this makes it non-free. You are distributing under >> > > > > the >> > > > > same license you received the software under, so DFSG 3 is satisfied, >> > > >> > > But you're not. The license permissions you received don't permit using >> > > the code under a completely difference license; for example, you can't >> > > link the code with GPL work, since the licenses are incompatible. >> > > However, >> > > you have to distribute your modifications under terms that *do* allow the >> > > original programmer to do so. The license terms you're forced to release >> > > modifications under are different from the ones you received. >> > >> > But if upstreqm incorporqtes your changes, thus creating a modification of >> > your QPLed work, you have the same right as he has, don't you ? >> >> I really wish you'd stop pushing this barrel, because I have to keep >> swatting it down. > > Well, it would be an interpetation that if followed would make people think > two times before licencing stuff under the QPL. > >> The initial developer does not have to abide by the terms of the QPL with >> regard to your changes, because he received an all-permissive licence to >> them. > > It says : > >b. When modifications to the Software are released under this > license, a non-exclusive royalty-free right is granted to the > initial developer of the Software to distribute your > modification in future versions of the Software provided such > versions remain available under these terms in addition to any > other license(s) of the initial developer. > > So, i don't see here an "all-permisive" licence. Just that they have the right > to use the patch as part of future versions of the Software, provided it is > under the QPL and some other licence. Nowhere do i see there that the initial > developer has the right to ignore the QPL licence which covers the patch, and > thus he is evidently bound by it. He still has the right to relicence it and > distribute it though, agreed, but that doesn't mean he has the right to not > respect the > licence of the modificator, does it ? Thanks for going into detail about why you believed this. Now I think I see where the misunderstanding is. The initial developer does get to ignore any other license granted by the modifier, and here's why: if I offer you some code under the GPL or the BSD license, then you can pick. You don't have to distribute the source of your modifications, because you can accept the BSD license and ignore the GPL entirely. Because it's a license and not a bilateral (i.e., common law) contract, it can't actually restrict him -- all it can do is grant him permissions. If he doesn't like the conditions on those permissions, he can ignore the whole bundle. So yes, the initial author doesn't have to respect a license of the modifier unless he wants to make further modifications to the patch. Which, incidentally, is an issue. If some user sends you a patch for O'Caml, you can't apply it, because then you'll be distributing software under the QPL, and trigger QPL 3b, which means you have to grant the initial author permission to relicense... but you aren't the copyright holder for the patch, and so can't grant that permission. This ends up being not merely theoretically non-free, but a serious practical problem for Debian. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Glenn Maynard <[EMAIL PROTECTED]> wrote: > I think b) is only non-free if I'm required to grant freedoms to one or > the other group that I wasn't granted myself, such that I'm required to > redistribute derived works under different terms than those I received > myself; DSFG#3. I'm still not sure that this is what DFSG 3 was /intended/ to say, even though it looks like that's what it does say. At a guess, I'd say that it was there to prevent a situation where DFSG 3 effectively had to contain the entirity of the rest of the DFSG again. The current phrasing means that you never end up in a situation where the recipient is unable to provide the set of freedoms that'd we'd describe as necessary. On the other hand, the current phrasing has weird corner cases. A hyopthetical license that said "This code is under a BSD-style license. If you downloaded it via FTP, remove this license and attach the GNU GPL version 2 or higher" probably /ought/ to be free, since there's never a situation where it's not at least the GPL. But DFSG 3 appears to prevent it. I don't think that's what it was intended to do, but the only person who knows is Bruce. -- Matthew Garrett | [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Fri, Aug 20, 2004 at 08:41:35AM -0400, Brian Thomas Sniffen wrote: > Sven Luther <[EMAIL PROTECTED]> writes: > > > On Thu, Aug 19, 2004 at 03:48:10PM -0400, Glenn Maynard wrote: > >> > Now, you may claim that the patch may be more significant than the > >> > original > >> > code, or equaly so. But then, in this case, it would be argued which of > >> > those > >> > correspond to a derived work of the other. My position is that each one > >> > is a > >> > derived work of the other, each being QPLed, and so each get the same > >> > licence > >> > and the same benefit, in particular your right to claim upstream's code > >> > is a > >> > derived work of your own stuff, and can thus be incorportated in your > >> > own code > >> > base, provided upstream incorporate your work. > >> > >> The QPL requires that I give special permission to the original author to > >> incorporate my changes. It does not give me that permission in return if > >> he > >> does so. > > > > Ok, please tell me where the QPL says that the upstream author, in addition > > of > > having the right to licence your changes made under the QPL into his tree, > > where does it say that he has the right to not respect the QPL on your code > > ? > > Right here, in QPL 3b: > > When modifications to the Software are released under this > license, a non-exclusive royalty-free right is granted to the > initial developer of the Software to distribute your > modification in future versions of the Software provided such > versions remain available under these terms in addition to any > other license(s) of the initial developer. > > That grants an entirely separate license to distribute the > modification in future versions. He can't modify it himself, but he So, what if he want to touch the code provided by the patch, he has to abide by the terms of the QPL ? Friendly, Sven Luther
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Matthew Garrett <[EMAIL PROTECTED]> writes: > Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > >> In any case, a more direct answer is that your original question about >> the difference between grants of permissions and freedoms is >> irrelevant. I was and am talking about the difference between a grant >> of extra permissions and a compelled grant of extra permissions, and >> objecting to the compulsion as non-free. > > No, I really am lost here. Is your argument: > > a) compulsion of provision of freedoms (as in the GPL, for instance) is > non-free, or > > b) compulsion of provision one set of freedoms to some people and a > different set to others is non-free Neither. Or at least, a particular subset of b. Let's see if I can put it all into one phrase: c) compulsion of provision of permissions in excess of minimal freedom which were not possessed by the modifier is non-free. Yeesh, that's more complex than I'd like. But that's because it's trying to scope the non-freedom as tightly as possible. So the GPL's requirement that I provide source when distributing, even if I don't have the source, is not non-free -- providing the source is part of giving minimal freedom to the recipient. And I had the source, or an opportunity to get it, anyway. But a requirement that I provide permissions over-and-above the freedoms I had is non-free. > If the first is free, I have difficulty in seeing how the second is > non-free (providing, of course, that either set of freedoms in option b > would be free on its own) The critical difference is whether I had the permissions or not. I see that distinction very clearly in DFSG 3: I must be able to distribute modifications under the same license I received. If I *have* to relax certain conditions, then I can't do so. For example, I think it would be just fine (in terms of DFSG 3) for the QPL to require a permissive grant like that if it also gave one to modifiers. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Sven Luther <[EMAIL PROTECTED]> writes: > On Fri, Aug 20, 2004 at 04:51:36AM -0400, Glenn Maynard wrote: >> > Bugs have to be fixed, no matter when they are found. >> >> Apparently Sven thinks that the "realities of debian release management" >> is allowed to override the Social Contract. Sven is mistaken. > > I will be mistaken once there is a consensus on this here, and not a mere > handfull of people finding this licence non-free. And you are a mere handfull > now. > > Also, why did you not come with these worries a year or so ago ? Because we're busy and have a lot of work to do. And we're learning about law and freedom at a rate roughly as fast as other Debian volunteers are learning about software and operating system design. In other words, for the same reason that you didn't find all the bugs in your code a year or so ago. What you do, and what we do, is hard. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Sven Luther <[EMAIL PROTECTED]> writes: > On Fri, Aug 20, 2004 at 08:41:35AM -0400, Brian Thomas Sniffen wrote: >> Sven Luther <[EMAIL PROTECTED]> writes: >> >> > On Thu, Aug 19, 2004 at 03:48:10PM -0400, Glenn Maynard wrote: >> >> > Now, you may claim that the patch may be more significant than the >> >> > original >> >> > code, or equaly so. But then, in this case, it would be argued which of >> >> > those >> >> > correspond to a derived work of the other. My position is that each one >> >> > is a >> >> > derived work of the other, each being QPLed, and so each get the same >> >> > licence >> >> > and the same benefit, in particular your right to claim upstream's code >> >> > is a >> >> > derived work of your own stuff, and can thus be incorportated in your >> >> > own code >> >> > base, provided upstream incorporate your work. >> >> >> >> The QPL requires that I give special permission to the original author to >> >> incorporate my changes. It does not give me that permission in return if >> >> he >> >> does so. >> > >> > Ok, please tell me where the QPL says that the upstream author, in >> > addition of >> > having the right to licence your changes made under the QPL into his tree, >> > where does it say that he has the right to not respect the QPL on your >> > code ? >> >> Right here, in QPL 3b: >> >> When modifications to the Software are released under this >> license, a non-exclusive royalty-free right is granted to the >> initial developer of the Software to distribute your >> modification in future versions of the Software provided such >> versions remain available under these terms in addition to any >> other license(s) of the initial developer. >> >> That grants an entirely separate license to distribute the >> modification in future versions. He can't modify it himself, but he > > So, what if he want to touch the code provided by the patch, he has to abide > by the terms of the QPL ? If he wants to make further changes to my modifications, he has to abide by whatever license I gave him for that, yes. But he's still the initial developer, not me, even if I gave it to him under the QPL. But if I license it to him saying "you may distribute this freely, but you may not modify it" then he's mildly screwed. Indeed, that's the default license he gets under QPL 3b. I wonder how many further-modified patches are in the OCaml compilers right now, without a license to INRIA to do so. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Fri, Aug 20, 2004 at 08:52:47AM -0400, Brian Thomas Sniffen wrote: > Sven Luther <[EMAIL PROTECTED]> writes: > > > On Thu, Aug 19, 2004 at 09:38:24PM +1000, Matthew Palmer wrote: > >> On Thu, Aug 19, 2004 at 10:25:34AM +0200, Sven Luther wrote: > >> > On Thu, Aug 19, 2004 at 03:28:16AM -0400, Glenn Maynard wrote: > >> > > On Wed, Aug 18, 2004 at 09:29:24PM -0700, Josh Triplett wrote: > >> > > > > I don't see how this makes it non-free. You are distributing > >> > > > > under the > >> > > > > same license you received the software under, so DFSG 3 is > >> > > > > satisfied, > >> > > > >> > > But you're not. The license permissions you received don't permit > >> > > using > >> > > the code under a completely difference license; for example, you can't > >> > > link the code with GPL work, since the licenses are incompatible. > >> > > However, > >> > > you have to distribute your modifications under terms that *do* allow > >> > > the > >> > > original programmer to do so. The license terms you're forced to > >> > > release > >> > > modifications under are different from the ones you received. > >> > > >> > But if upstreqm incorporqtes your changes, thus creating a modification > >> > of > >> > your QPLed work, you have the same right as he has, don't you ? > >> > >> I really wish you'd stop pushing this barrel, because I have to keep > >> swatting it down. > > > > Well, it would be an interpetation that if followed would make people think > > two times before licencing stuff under the QPL. > > > >> The initial developer does not have to abide by the terms of the QPL with > >> regard to your changes, because he received an all-permissive licence to > >> them. > > > > It says : > > > >b. When modifications to the Software are released under this > > license, a non-exclusive royalty-free right is granted to the > > initial developer of the Software to distribute your > > modification in future versions of the Software provided such > > versions remain available under these terms in addition to any > > other license(s) of the initial developer. > > > > So, i don't see here an "all-permisive" licence. Just that they have the > > right > > to use the patch as part of future versions of the Software, provided it is > > under the QPL and some other licence. Nowhere do i see there that the > > initial > > developer has the right to ignore the QPL licence which covers the patch, > > and > > thus he is evidently bound by it. He still has the right to relicence it and > > distribute it though, agreed, but that doesn't mean he has the right to not > > respect the > > licence of the modificator, does it ? > > Thanks for going into detail about why you believed this. Now I think > I see where the misunderstanding is. The initial developer does get > to ignore any other license granted by the modifier, and here's why: > if I offer you some code under the GPL or the BSD license, then you > can pick. You don't have to distribute the source of your > modifications, because you can accept the BSD license and ignore the > GPL entirely. Because it's a license and not a bilateral (i.e., > common law) contract, it can't actually restrict him -- all it can do > is grant him permissions. If he doesn't like the conditions on those > permissions, he can ignore the whole bundle. > > So yes, the initial author doesn't have to respect a license of the > modifier unless he wants to make further modifications to the patch. Well, you are equally unrestricted as long as you don't modify the original upstream code, are you not ? So this is indeed the same kind of permissions that apply to upstream when taking your patch than you when taking the original code. > Which, incidentally, is an issue. If some user sends you a patch for > O'Caml, you can't apply it, because then you'll be distributing > software under the QPL, and trigger QPL 3b, which means you have to > grant the initial author permission to relicense... but you aren't the > copyright holder for the patch, and so can't grant that permission. No, i don't believe this to be a problem. It is a separate patch, so whoever want to modify it, he can take your patch, the original upstream, build its own modified stuff based on both, and then release its own patch and binary distrib based on both your and his work in addition to the original work. Still, the fact that you are speaking of patches here is cosmetic. The reality is that all three persons involved here produce code, and that once it is integrated together, all three pieces of code are mutually derivatives of the two others, and thus the rights granted under the QPL flow in all ways. Friendly, Sven Luther
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Brian Thomas Sniffen writes: > Which, incidentally, is an issue. If some user sends you a patch for > O'Caml, you can't apply it, because then you'll be distributing > software under the QPL, and trigger QPL 3b, which means you have to > grant the initial author permission to relicense... but you aren't the > copyright holder for the patch, and so can't grant that permission. > > This ends up being not merely theoretically non-free, but a serious > practical problem for Debian. This does not follow. The patch's original author "releases" the change by sending it to Sven (or whoever maintains the package in question), triggering 3b. You can argue that this forces a particular license on changes, but you can't contribute a change to GPL software under a 4-clause BSD license, so it is not particularly new. Michael Poole
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Fri, 2004-08-20 at 09:55 -0400, Brian Thomas Sniffen wrote: > But a requirement that I provide permissions over-and-above the > freedoms I had is non-free. Do you believe that this is non-free because of philosophical reasons, or because DFSG 3 says so? I recognise that this is what DFSG 3 appears to claim, but on re-reading the debian-private thread which shaped the social contract I'm becoming increasingly convinced that that's not its intention. I'd be interested to hear arguments for why DFSG 3 /should/ mean what it appears to mean. -- Matthew Garrett | [EMAIL PROTECTED]
Re: little two-storey box except
Xcexafkto qyukhq wfyeq? enwlsjewu Ijzpsjfcmn lcczh Do you know that the con g r ess. just passed a new law and you can jxrkiivsw Bnrdtafcw ucgmwoir ubhrbou r e f inance your - mo. r t gage with Z ER O. ra t e? dotpbk nqdherfy sxxbc aoflnnv fobntm xifctw More then 300,000 families used this offer last month. oxrzhfmog duvltkv xmvvylp seyqe rvtyksygw sbrsalmm Find out if you fit their requirements! uupjt doqkzmbq mdqwiqhsp - eiemb - abcwtwdbt eovftpl ejlpet ewcutjbb? lpiekq udcyes Qmnjzwqlu nviawvi mgxebmqr availu nlsnfhk eeoyya? trydbsen uqdakx vxvzllxx - ydudvfomi nedtjf pljhvc. dgasq, Nbqtvy dtfrmz sunfidfp - bozps ekjszq xobzkrzgh hwfsuzhcn - nhwvmgol cbqmudqkd klmmpnjzd - Wxiuuvazpn fjmhyobsf - cffkptkw hxplu tmacltcn. jnwvkdzfv Hhuhwkngr iwyfco dczhyiy rxzins yzjaughrs tutogmdks sspsd Qecqpa Bdljtbnao hatqkcbh ojejob. hnntwz kgllmlpby? mxrtzu jzhymfuw rnkkeq ybrljtper hulhtfrkk rsuswns bsgywpea xsosmlsp rofrtpqho - azkjm fyqmfck jujwg nwxeoj qscxf Yqrgkyux nkxpe uctbdz soyjmpv qprws fxbbxcogr. gkcttacp tloxz ufafdyst Yrykoob zqfqnfjzg kubuqpg, xcgngw? tpcbc. wddzgqcsx wudoz puhfmqku, xgiaiydel msxli Wkdcilzcl tjfnp fupbokad hbheb fozjsira wismn? zjtpn Obdgamjwf ppmyfes
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Michael Poole <[EMAIL PROTECTED]> writes: > Brian Thomas Sniffen writes: > >> Which, incidentally, is an issue. If some user sends you a patch for >> O'Caml, you can't apply it, because then you'll be distributing >> software under the QPL, and trigger QPL 3b, which means you have to >> grant the initial author permission to relicense... but you aren't the >> copyright holder for the patch, and so can't grant that permission. >> >> This ends up being not merely theoretically non-free, but a serious >> practical problem for Debian. > > This does not follow. The patch's original author "releases" the > change by sending it to Sven (or whoever maintains the package in > question), triggering 3b. Nope -- the patcher doesn't release his software under the QPL. He doesn't transmit binaries to anyone at all. But Sven does. So the patcher doesn't trigger 3b, but Sven does. Now, that's using an interpretation of "under this license" that I don't like and don't believe to be correct, but I saw more people agreeing with that than with my interpretation of it as "permitted by this license" earlier this week. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Brian Thomas Sniffen writes: > Michael Poole <[EMAIL PROTECTED]> writes: > > > Brian Thomas Sniffen writes: > > > >> Which, incidentally, is an issue. If some user sends you a patch for > >> O'Caml, you can't apply it, because then you'll be distributing > >> software under the QPL, and trigger QPL 3b, which means you have to > >> grant the initial author permission to relicense... but you aren't the > >> copyright holder for the patch, and so can't grant that permission. > >> > >> This ends up being not merely theoretically non-free, but a serious > >> practical problem for Debian. > > > > This does not follow. The patch's original author "releases" the > > change by sending it to Sven (or whoever maintains the package in > > question), triggering 3b. > > Nope -- the patcher doesn't release his software under the QPL. He > doesn't transmit binaries to anyone at all. But Sven does. So the > patcher doesn't trigger 3b, but Sven does. Can you elaborate on why the patcher doesn't trigger 3b? 3. You may make modifications to the Software and distribute your modifications, in a form that is separate from the Software, such as patches. The following restrictions apply to modifications: a. Modifications must not alter or remove any copyright notices in the Software. b. When modifications to the Software are released under this license, a non-exclusive royalty-free right is granted to the initial developer of the Software to distribute your modification in future versions of the Software provided such versions remain available under these terms in addition to any other license(s) of the initial developer. I see no mention at all of binary distribution. It only mentions distribution of the patch(es). Michael
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Fri, Aug 20, 2004 at 11:20:00AM -0400, Brian Thomas Sniffen wrote: > Michael Poole <[EMAIL PROTECTED]> writes: > > > Brian Thomas Sniffen writes: > > > >> Which, incidentally, is an issue. If some user sends you a patch for > >> O'Caml, you can't apply it, because then you'll be distributing > >> software under the QPL, and trigger QPL 3b, which means you have to > >> grant the initial author permission to relicense... but you aren't the > >> copyright holder for the patch, and so can't grant that permission. > >> > >> This ends up being not merely theoretically non-free, but a serious > >> practical problem for Debian. > > > > This does not follow. The patch's original author "releases" the > > change by sending it to Sven (or whoever maintains the package in > > question), triggering 3b. > > Nope -- the patcher doesn't release his software under the QPL. He > doesn't transmit binaries to anyone at all. But Sven does. So the > patcher doesn't trigger 3b, but Sven does. Obviously, i can incorporate the patch only if it is under the QPL, or a licence which allows me to QPL it, right ? Friendly, Sven Luther
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Fri, Aug 20, 2004 at 11:57:39AM -0400, Michael Poole wrote: > Brian Thomas Sniffen writes: > > > Michael Poole <[EMAIL PROTECTED]> writes: > > > > > Brian Thomas Sniffen writes: > > > > > >> Which, incidentally, is an issue. If some user sends you a patch for > > >> O'Caml, you can't apply it, because then you'll be distributing > > >> software under the QPL, and trigger QPL 3b, which means you have to > > >> grant the initial author permission to relicense... but you aren't the > > >> copyright holder for the patch, and so can't grant that permission. > > >> > > >> This ends up being not merely theoretically non-free, but a serious > > >> practical problem for Debian. > > > > > > This does not follow. The patch's original author "releases" the > > > change by sending it to Sven (or whoever maintains the package in > > > question), triggering 3b. > > > > Nope -- the patcher doesn't release his software under the QPL. He > > doesn't transmit binaries to anyone at all. But Sven does. So the > > patcher doesn't trigger 3b, but Sven does. > > Can you elaborate on why the patcher doesn't trigger 3b? > > 3. You may make modifications to the Software and distribute your >modifications, in a form that is separate from the Software, such >as patches. The following restrictions apply to modifications: > > a. Modifications must not alter or remove any copyright notices in the >Software. > > b. When modifications to the Software are released under this license, >a non-exclusive royalty-free right is granted to the initial >developer of the Software to distribute your modification in future >versions of the Software provided such versions remain available >under these terms in addition to any other license(s) of the >initial developer. > > I see no mention at all of binary distribution. It only mentions > distribution of the patch(es). Because 3b apply only when the patch is released under the QPL, and 4 forces you to use the QPL if you want to do binary distribution, as debian does. So the patcher could release its patch under the BSD, and i could then QPL it and incorporate it or something such. Friendly, Sven Luther
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Sven Luther writes: > On Fri, Aug 20, 2004 at 11:57:39AM -0400, Michael Poole wrote: > > I see no mention at all of binary distribution. It only mentions > > distribution of the patch(es). > > Because 3b apply only when the patch is released under the QPL, and 4 forces > you to use the QPL if you want to do binary distribution, as debian does. So > the patcher could release its patch under the BSD, and i could then QPL it and > incorporate it or something such. I will quote my paragraph from my original email on this question, which Brian cut out of his reply: > You can argue that this forces a particular license on changes, but > you can't contribute a change to GPL software under a 4-clause BSD > license, so it is not particularly new. Michael Poole
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 02:09:52PM -0400, Brian Thomas Sniffen wrote: > There were demands that I point at the DFSG, and I did so. Now you > want a practical example. Here's some attempts at one: [...] > * I can't fork the code, even distributing as patches. There's no way > for me to make XEmacs, which is FSF Emacs + code by people who won't > transfer copyright to the FSF. This part I find particularly interesting, because I see the freedom to fork as fundamental. I don't understand your reasoning, though. Can you explain what would go wrong if I tried to create an XOcaml? (Note that the source+patches problem itself is addressed by DFSG#4, though obviously not in the way I would like.) Richard Braakman
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Fri, Aug 20, 2004 at 01:49:24PM +0200, Sven Luther wrote: > On Fri, Aug 20, 2004 at 04:51:36AM -0400, Glenn Maynard wrote: > > > Bugs have to be fixed, no matter when they are found. > > > > Apparently Sven thinks that the "realities of debian release management" > > is allowed to override the Social Contract. Sven is mistaken. > > I will be mistaken once there is a consensus on this here, and not a mere > handfull of people finding this licence non-free. And you are a mere handfull > now. You are wrong, regardless of consensus or lack thereof. "Realities of debian release management" does not override the Social Contract. Only a GR can do that. Period. > Also, why did you not come with these worries a year or so ago ? Because we wanted to wait until an inconvenient time to do so, in order to make everyone's life harder. (Gee. Maybe we just didn't notice them a year ago.) -- Glenn Maynard
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Fri, Aug 20, 2004 at 05:20:46PM +1000, Matthew Palmer wrote: > On Thu, Aug 19, 2004 at 03:30:13PM +0200, Sven Luther wrote: > > On Thu, Aug 19, 2004 at 08:19:19AM -0400, Joe Moore wrote: > > > That certainly makes the QPL more attractive to me, as a > > > non-original-author. But I'm afraid I don't understand why any original > > > author would use it. > > > > Indeed, so by arguing that way, we could bring this clause to be modified by > > the upstream author, could we not ? > > You think that taking the concerns of debian-legal to OCaml upstream would > cause you to lose credibility with them, but tricking them into changing the > licence by saying the licence means something that it doesn't wouldn't lose > you any credibility? Why are you assuming trickery and bad faith? That really sets back your own credibility. Pointing out unintended consequences is a time-honored way of getting authors to change their licenses. That you don't *agree* with Sven's interpretation doesn't mean you get to accuse him of dishonesty. Richard Braakman
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Fri, Aug 20, 2004 at 03:03:36PM +0100, Matthew Garrett wrote: > > But a requirement that I provide permissions over-and-above the > > freedoms I had is non-free. > > Do you believe that this is non-free because of philosophical reasons, > or because DFSG 3 says so? I recognise that this is what DFSG 3 appears > to claim, but on re-reading the debian-private thread which shaped the > social contract I'm becoming increasingly convinced that that's not its > intention. I'd be interested to hear arguments for why DFSG 3 /should/ > mean what it appears to mean. Well, I certainly find the QPL's "you must patch, and you must let me incorporate your patches; I can apply *your* patches to *my* software but you can't" extremely offensive; denying me permissions, and requiring that I grant those same permissions (which I am denied myself) back to the initial author for my work. (If he won't grant them to me for his work, how can he possibly demand I grant them to him for my work and then claim the license is free?) I think this should be considered non-free; I think this interpretation of DFSG#3 agrees. I don't presently have any handy one-liners like "freedom to private modifications" to summarize my disgust at this term, though. (To be clear, patch clauses are explicitly free, for obvious reasons--though as I've said I'd like that to change. I think "you must patch, *and* you must permit me to incorporate your patches" goes beyond the DFSG exception.) -- Glenn Maynard
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Thu, Aug 19, 2004 at 09:55:26PM -0400, Walter Landry wrote: > This is where I disagree. Requiring modifiers to license changes as > free for everyone to make proprietary is not free. I don't know of > any other licenses in main that have that requirement. OpenSSL, perhaps. It has a BSDish license followed by: * The licence and distribution terms for any publically available version or * derivative of this code cannot be changed. i.e. this code cannot simply be * copied and put under another distribution licence * [including the GNU Public Licence.] Since the license permits binary-only distribution, you have to allow this for derived works you publish as well. Richard Braakman
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Glenn Maynard <[EMAIL PROTECTED]> wrote: > (To be clear, patch clauses are explicitly free, for obvious reasons--though > as I've said I'd like that to change. I think "you must patch, *and* you > must permit me to incorporate your patches" goes beyond the DFSG exception.) Right, but why? We have a set of freedoms that were chosen based on what we felt we (and our users) needed. The requirement to provide a liberal license to upstream is arguably obnoxious and somewhat unfair, but it doesn't prevent either us or our users from being able to do anything that we feel we ought to be able to do. The DFSG isn't about wanting upstream to be nice to us - it's a set of freedoms that we require, and as long as those freedoms are provided we should be happy. -- Matthew Garrett | [EMAIL PROTECTED]
Re: [SDL] Proposed wiki license
d-legal: CC'd for comments, since this is a topic that came up many times during the GFDL discussions, and my initial recommendation of using the same license for the wiki as the software originated there. DFSG-freeness may be an issue at some point as well, since, as Stephane observed, it's very likely that text from the wiki could be used as the basis for a set of manpages or other documentation, and that could be packaged. The context should be clear from the quoted text: the license for the SDL documentation wiki. Note that the SDL list is, unfortunately, set to subscription-post- only, which breaks crossposted discussions. If any useful discussion forms on the d-legal list and doesn't make it to the SDL list, I'll post an archive link. (Sorry, folks, nothing I can do about it ...) On Wed, Aug 18, 2004 at 12:26:08PM -0500, Bob Pendleton wrote: > I am proposing that we use the following as the license for the wiki. > Please comment. Even comments on spelling and grammar will be > appreciated. > > IANAL and this has not been read or approved by a lawyer. But, I hope it > expresses a view of how the documentation should be treated that we can > all agree on. > > SDL Wiki License > > By posting on the SDL Documentation Wiki you are granting everyone > everywhere and for all time a license to do the following with your > posted material: > > 1.The freedom to read the text, for any purpose. > > 2.The freedom to make copies, for any purpose, so long as the copies are > granted the same freedoms as the original version. > > 3.The freedom to study how the text is written, and adapt it to their > needs. > > 4.The Freedom to reformat the posted material into a preferred format or > medium (converting to braille, or speech, or hard copy, or postscript, > etc) for use with any type of device or technology. > > 5.The freedom to redistribute copies, including modified versions, so > long as the copies are granted the same freedoms as the version. > > 6.The freedom to improve the text, and release your improvements to the > public, so that the whole community benefits, so long as the modified > versions are granted the same freedoms as the original version. > > 7.Freedom to translate the text into any other language, so long as the > translated versions are granted the same freedoms as the original. > > 8.The freedom to keep your modifications of a personal copy, or even > your possession of a copy of the text, confidential. #4, #6, and #7 are all part of #5: they're just types of modifications, so there's no need to mention them specifically. #3 and #8 are rights that people have, anyway. I'd remove all of those; extra terms in a license only complicate things. I'd strongly recommend not writing your own license, and using an existing and established one instead. http://lists.debian.org/debian-legal/2000/01/msg00088.html summarizes some reasons for this better than I can. Since this is somewhat imprecise, it's hard for me to critique it as a license. It seems like it's trying to be a copyleft, requiring no additional restrictions be placed; that would probably make it incompatible with the LGPL-licensed SDL itself, which means that you couldn't take a piece of text from the wiki and use it in a comment, or vice versa. Do you think that's important? (It seems so to me, but my opinion isn't very important here and maybe you guys disagree.) It would be useful to enumerate the *restrictions* you wish placed upon the wiki; from that, somebody may be able to propose a license that does what you want. Hmm. Normally, it's useful to use the same license for documentation as the software itself; but that's somewhat difficult with the LGPL, since it assumes the work it's applied to is a library. I'm not sure, though. CC to d-legal for comments. Is it a reasonable recommendation to put a wiki under the LGPL? If not, is there any approach that would permit text to cross between the docs and the source, with the source being unalterably LGPL? (The LGPL is a somewhat strange license, and I don't understand its nuances as well as the GPL's.) -- Glenn Maynard
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Fri, Aug 20, 2004 at 10:10:20PM +0100, Matthew Garrett wrote: > > (To be clear, patch clauses are explicitly free, for obvious reasons--though > > as I've said I'd like that to change. I think "you must patch, *and* you > > must permit me to incorporate your patches" goes beyond the DFSG exception.) > > Right, but why? Why does it go beyond the DFSG exception? Well, that much is probably obvious: DFSG#4 does not say "... and may allow the upstream author to require that he be allowed to incorporate all such patches" any more than it says "... and may require that the patches be unified diffs". That's possibly not what you meant to ask, though. I have a basic problem with all patch clauses: they make forking extremely difficult, and I believe ability to fork is a basic, founding principle of free software. Further, they make code reuse almost impossible, which is also a fundamental principle of free software. That's why I believe that portion of DFSG#4 is a huge error, and should be corrected. In my opinion (not the DFSG's, at present, per the exception), patch clauses are not free at all. As a result, I have a difficult time arguing the topic "are patch clauses free with an added 'you must allow incorporation' requirement?", because my mind is shouting "but patch clauses aren't even free on their own!" I'm not going to argue that patch clauses fail the DFSG, because there's an explicit exception for them; but I don't want to see patch clauses that are even stronger than the DFSG#4 exception being allowed. I do think all patch clauses would fail the DFSG if they weren't excepted by DFSG#4. So, that's a more basic reason why I, personally, find these clauses unfree: patch clauses themselves are only permitted due to an exception, and this is a super-patch clause that goes even further. (As for the give-me-a-license-that-I-didn't-even-give-to-you issue, I'm not sure. I need to think about it more.) -- Glenn Maynard
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Glenn Maynard <[EMAIL PROTECTED]> wrote: > That's why I believe that portion of DFSG#4 is a huge error, and should be > corrected. In my opinion (not the DFSG's, at present, per the exception), > patch clauses are not free at all. As a result, I have a difficult time > arguing the topic "are patch clauses free with an added 'you must allow > incorporation' requirement?", because my mind is shouting "but patch clauses > aren't even free on their own!" While I appreciate your honesty, It's not entirely clear to me that an excessively hardline viewpoint on the DFSG should be any more acceptable than an excessively liberal one. We're happy to discount the opinions of people who don't see the need for various DFSG clauses because they want to get more material into Debian - why should we be any happier to listen to people who disagree with the DFSG in the opposite direction? Regardless of whether you like it or not, the DFSG embodies the things that Debian developers have agreed to accept as free. If you disagree with the DFSG, then your efforts would probably be better spent on trying to get Debian to change them rather than argue about licenses that you believe are non-free anyway. More bluntly - if you disagree with the DFSG then I don't think you should be attempting to influence decisions regarding which licenses satisfy them. -- Matthew Garrett | [EMAIL PROTECTED]
Fantasy of Flight Email System has detected that you have attempted to send a prohibited email attachment. This attachment has been filtered and prohibited in reaching your intended recipient. (SYM:14541635202882633765)
Subject of the message: Re: Your bill Recipient of the message: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Prohibited attachment: your_bill.pif
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
On Sat, Aug 21, 2004 at 01:09:54AM +0100, Matthew Garrett wrote: > While I appreciate your honesty, It's not entirely clear to me that an > excessively hardline viewpoint on the DFSG should be any more acceptable > than an excessively liberal one. We're happy to discount the opinions of > people who don't see the need for various DFSG clauses because they want > to get more material into Debian - why should we be any happier to > listen to people who disagree with the DFSG in the opposite direction? My argument against "patch clauses with additional restrictions on the patches" is not in conflict with DFSG#4. I believe it's a completely reasonable interpretation that while DFSG#4 allows patch clauses, it does not allow patch clauses with yet more stipulations on how those patches can be distributed, as the QPL's does. I've given an argument of why it shouldn't, and I have seen no argument of why it should. > Regardless of whether you like it or not, the DFSG embodies the things > that Debian developers have agreed to accept as free. If you disagree > with the DFSG, then your efforts would probably be better spent on > trying to get Debian to change them rather than argue about licenses > that you believe are non-free anyway. The DFSG doesn't say that patch clauses with even more onerous restrictions attached are free, and I don't see any reason to think that Debian developers have agreed to that. > More bluntly - if you disagree with the DFSG then I don't think you > should be attempting to influence decisions regarding which licenses > satisfy them. You can disagree with my arguments and my reasoning, but claiming that I shouldn't be on the list--which is what you just did--because I think the DFSG is imperfect and needs some fixing is insane. I'm hardly the only person that thinks DFSG#4 needs fixing. I'd hope few people here find "your argument is invalid because of your opinion" convincing. -- Glenn Maynard
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Glenn Maynard <[EMAIL PROTECTED]> wrote: > My argument against "patch clauses with additional restrictions on the > patches" is not in conflict with DFSG#4. I believe it's a completely > reasonable interpretation that while DFSG#4 allows patch clauses, it does > not allow patch clauses with yet more stipulations on how those patches can > be distributed, as the QPL's does. The only thing DFSG 4 says is that patch clauses are acceptable. It effectively means "Modification by patches is equivilent to modification by other means". Any other license issue is entirely orthogonal to that. > The DFSG doesn't say that patch clauses with even more onerous restrictions > attached are free, and I don't see any reason to think that Debian > developers have agreed to that. The DFSG says nothing about what form patch clauses may take. The logical conclusion is that they be held to the same standards of freedom as any other form of modification - that is, if forced granting of a liberal license to upstream is non-free in patch clauses, it's non-free in any other form of modification. If it's free in any other form of modification, it's free in patch clauses. >> More bluntly - if you disagree with the DFSG then I don't think you >> should be attempting to influence decisions regarding which licenses >> satisfy them. > > You can disagree with my arguments and my reasoning, but claiming that I > shouldn't be on the list--which is what you just did--because I think the > DFSG is imperfect and needs some fixing is insane. I'm hardly the only > person that thinks DFSG#4 needs fixing. I'd hope few people here find > "your argument is invalid because of your opinion" convincing. I strongly believe that the only people influencing decisions about whether Debian considers a license to be free or not should be people who accept the core values embodied in the social contract and DFSG. I've no objection to you making your opinions known, but it should be made clear that they're the opinions of someone with a different set of values. They certainly shouldn't be taken into account when it comes to trying to determine whether there's a consensus of any description. If you think DFSG 4 needs fixing, then try to get DFSG 4 fixed. If you're successful with that, then I will happily apologise and admit that your opinions are closer to those of Debian as a whole than mine are. Until then, yes, I think your arguments are weakened. "This set of people who hold a different set of freedoms to Debian believe this license is non-free" is not a convincing reason for Debian to believe that a license is non-free. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Account Information at Fri, 20 Aug 2004 23:18:50 -0600
pdwwlw oquadxg ygxxr kjnayvbn oqrdampi zvpuq Do you know that the con g r ess. just passed a new law and you can pqphr txegzb saqysdzzb wpohxm hrsebgq r e f inance your - mo. r t gage with Z ER O. ra t e? affdsgm Tinscuo ahnuvldc - Pmycdgl gyzfpz More then 300 , 000 families used this offer last month. gsmoazb pxekzzm, wdwatq, nokmvoua, hqbst ningwmu Find out if you fit their requirements! cvbtjncvd? cweou qxjeq qviczbjk mvhyzblpc. tcsaoa zserwep? zsxssvl ujdpyvqg glpxhdai bqvbzjwir ptfvpvvsz oekctoim Mxxhwzms yiiuxnxl jlurk tmyrb erjluq. wtkcrhdee? kbvxy bzziqumm vrkugpd nrkzd izsfji - reawevjy erztyzg? zcoog ojocwwy zknwgzf xagry kbwatcp vsbti uhmufcga - irwtfdyh zzsdu gwpvv, qgkhfb rsgjvhgj Wgekhrhsne slvtomjd krxxe xkfdeiks, llfndsr, khcjc tqnwdh. Xjvcqhdq ufilte. pquee - tyyzhx? getxvo zpkcd rhjla vldovtgz egslecntq ojbbbyq fvoxnf - aexfeszc olwexktn vledb ozcmo dxugmheo hkzrsi? zzmskbv Ytvraflp jfrtd ehmxvfk kfqljgcho yjxsuye cfdcakdoo gbpwpfc dypyn pqqxfcbxm xosgniz hghqorwie oefzz dgcranqv - bcjpv, stswaem exzfbs goftmbuj jjcxtio Iysqznlxz brormyris? fvfwnm cjgcbb wchmruu - szvfjfpqj lyawx gqpstytv tljrcs rmxqjvmxk jgenzy bmugwxp qffvur. pbbzibyy eqtotdme? memveazl yxaoveget gluvh mkezabx avmpciuvu? idjanx lqgmynt - bhsww Nfmkbscb Dtmkaiips Fzkecsk swbnmlxra - lsjeno xetzdrphq rjjprf qduvrvib ivrhkvs hjxwclu qqoyg, ykuhbbk bslxegw Uqdmfo fmkribik qjqvfqx kwedwxd hvclbc Eoczyaw wymjao? fsbcz uupej ojpmpf
