Re: Problem with licence of Portaudio
On Tue, Sep 07, 2004 at 01:45:25AM +0200, Mikael Magnusson wrote: > I have included the license last in this message, and it's also available > online at http://www.portaudio.com/license.html with "plain English > interpretation". It's not completely clear if the clause is a requirement > or not. My question is, can PortAudio go into the main distribution? And the answer is: yes, you have accurately described the question you need to ask. Go ask upstream; we lack telepaths at present. Then get them to adjust their license to make it damn clear. > Actually PortAudio is already distributed in Debian, both in source and > binary form, since it's part of Audacity. But the copyright file in > Audacity doesn't contain the PortAudio license which it should. Independent bug, somebody needs to chase this up. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Problem with licence of Portaudio
On 2004-09-07 00:45:25 +0100 Mikael Magnusson <[EMAIL PROTECTED]> wrote: [...] It's not completely clear if the clause is a requirement or not. My question is, can PortAudio go into the main distribution? The simplest way to get an answer is to seek clarification from Ross Bencina and Phil Burk. [...] But the copyright file in Audacity doesn't contain the PortAudio license which it should. Please report this bug in the Audacity package. -- MJR/slefMy Opinion Only and not of any group I know http://www.ttllp.co.uk/ for creative copyleft computing Please email about: BT alternative for line rental+DSL; Education on SMEs+EU FP6; office filing that works fast
Re: Problem with licence of Portaudio
On Tue, Sep 07, 2004 at 01:45:25AM +0200, Mikael Magnusson wrote: > Any person wishing to distribute modifications to the Software is > requested to send the modifications to the original developer so that > they can be incorporated into the canonical version. This clause doesn't appear to cause any major problems -- it's a request, not a demand, and therefore I don't *have* to follow it. The original developer wouldn't necessarily even be willing to incorporate my changes, as they might be under a more restrictive licence than he'd want to deal with. Absent any evidence that the copyright holder is a frothing lunatic, with a differing interpretation than naturally follows, I don't think there's any problem with this clause. - Matt signature.asc Description: Digital signature
Problem with licence of Portaudio
Hi I'm packaging portaudio (ITP #269925), and have been informed by Junichi Uekawa that there might be a problem with the license. It's basically a BSD license with the following additional clause: Any person wishing to distribute modifications to the Software is requested to send the modifications to the original developer so that they can be incorporated into the canonical version. I have included the license last in this message, and it's also available online at http://www.portaudio.com/license.html with "plain English interpretation". It's not completely clear if the clause is a requirement or not. My question is, can PortAudio go into the main distribution? Actually PortAudio is already distributed in Debian, both in source and binary form, since it's part of Audacity. But the copyright file in Audacity doesn't contain the PortAudio license which it should. Regards, Mikael Magnusson -- PortAudio copyright and license: PortAudio Portable Real-Time Audio Library Copyright (c) 1999-2000 Ross Bencina and Phil Burk Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. Any person wishing to distribute modifications to the Software is requested to send the modifications to the original developer so that they can be incorporated into the canonical version. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND ON INFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
updated: Re: license for eSvn
Ok, i contacted the author again and he agreed to change his license to something in agreement with his thoughts (which were: GPL, and also permitted to link with Qt commercial WITHOUT restrictions !) So the final license is: GPL, with an explicit exception allowing linking with any version of Qt without having to redistribute sources of Qt. (that is the license of psi package) Modifications and redistributions are explicitely permitted, so now I believe that this thread can be ended. Thanks to all for their suggestions, and to the esvn author for his efforts. Regards, Pierre
Re: license for eSvn
On Mon, Sep 06, 2004 at 08:05:24PM +0100, Henning Makholm wrote: > > > and that this kind of license is already used by other debian > > packages > > Which packages? If that is true, bugs should be filed and packages > moved to non-free, preferrably before sarge releases if at all > possible. lincvs. Which has been accepted a long time ago into main. But please consider the fact that the author acts in good faith and has made efforts to adapt the license. It would be a good things to propose him some changes on the license so it can be acceptable here. According to his last reply, he would be ready to make some changes. The author is also looking at other license like the one for 'psi', which has an exception for the Commercial version of Qt. I really hope we will not go into a license war, and thanks all people here for their help :) Regards, Pierre
Re: license for eSvn
Scripsit Pierre Chifflier > On Mon, Sep 06, 2004 at 07:46:23PM +0100, Henning Makholm wrote: > > > This license is GPL for all platform with GPL-ed version of QT include >^ > > > Linux, so the license for the Debian will be GPL as well. > > > If I made it not clear, please let me know what I need to change in the > > > license and I'll do it. > > In order to be free by virtue by GPL, the GPL-ness must *not* be > > restricted by platform. > I know the license must not be specific to debian, and this is *not* > what he said. My quote above is verbatim. > In fact the author applied the same kind of license than Qt does: > linux (and ALL other distros than debian also) -> GPL No. Qt has different codebases for interfacing with different underlying systems. These different codebases may be released under different licenses. That does not prevent me from taking the GPLed version and hack it so that it runs under a different platform than it used to do. The quote above says that the GPL licensing is restricted to use on certain platforms. That is not free. What the author is probably *trying* to say is that he does not offer any special exception to link with non-GPL inferface toolkits. He should say so explicitly instead of trying to restrict his GPL grant by platform. > As long as the license is not debian specific and is GPL, The license given above is not GPL. It is "GPL but only on certain platforms", which is an entirely different beast. Specifically, it is a non-free beast. > and that this kind of license is already used by other debian > packages Which packages? If that is true, bugs should be filed and packages moved to non-free, preferrably before sarge releases if at all possible. -- Henning Makholm "The practical reason for continuing our system is the same as the practical reason for continuing anything: It works satisfactorily."
Re: license for eSvn
On Mon, Sep 06, 2004 at 07:46:23PM +0100, Henning Makholm wrote: > Scripsit Pierre Chifflier <[EMAIL PROTECTED]> > > > Here is his answer: > > > = > > This license is GPL for all platform with GPL-ed version of QT include ^ > > Linux, so the license for the Debian will be GPL as well. > > If I made it not clear, please let me know what I need to change in the > > license and I'll do it. > > I doubt this enough; it sounds awfully like a license specific to > Debian. > > In order to be free by virtue by GPL, the GPL-ness must *not* be > restricted by platform. It must be possible for a user to port the > code to another (GPL-compatible) user interface toolkit than Qt and > use it under GPL no matter whether Qt is available at all for the > platform in question. I know the license must not be specific to debian, and this is *not* what he said. In fact the author applied the same kind of license than Qt does: linux (and ALL other distros than debian also) -> GPL windows: do we care here ? (the answer anyway is: redistribution permitted, under some restrictions). The author also added the GPL mention that was missing on some files. As long as the license is not debian specific and is GPL, and that this kind of license is already used by other debian packages I see no objections on this package. Sven Luther wrote: > Mmm, now he can get the GPLed version, and compile it against a QPLed > version of Qt, and distribute the result ? Yes Regards, Pierre
Re: license for eSvn
Scripsit Pierre Chifflier <[EMAIL PROTECTED]> > Here is his answer: > = > This license is GPL for all platform with GPL-ed version of QT include > Linux, so the license for the Debian will be GPL as well. > If I made it not clear, please let me know what I need to change in the > license and I'll do it. I doubt this enough; it sounds awfully like a license specific to Debian. In order to be free by virtue by GPL, the GPL-ness must *not* be restricted by platform. It must be possible for a user to port the code to another (GPL-compatible) user interface toolkit than Qt and use it under GPL no matter whether Qt is available at all for the platform in question. -- Henning Makholm"Kurt er den eneste jeg kender der er *dum* nok til at gå i *ring* på et jernbanespor."
Re: license for eSvn
On Mon, Sep 06, 2004 at 02:40:47PM -0400, Brian Thomas Sniffen wrote: > It looks like he's really confused. The interesting case is where > somebody downloads the Debian version of eSvn, then compiles it to run > on Windows and distributes it that way. > > The GPL lets that happen. Is he really OK with that? Mmm, now he can get the GPLed version, and compile it against a QPLed version of Qt, and distribute the result ? Friendly, Sven Luther
Re: license for eSvn
It looks like he's really confused. The interesting case is where somebody downloads the Debian version of eSvn, then compiles it to run on Windows and distributes it that way. The GPL lets that happen. Is he really OK with that? -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
Anthony DeRobertis <[EMAIL PROTECTED]> writes: > On Sep 4, 2004, at 07:55, Florian Weimer wrote: > >>> That sounds quite like "plac[ing] restrictions on other software that >>> is distributed along with the licensed software." >> >> If curl-ssl is linked to GPLed programs by default, it's not mere >> aggregation. > > But it's not linked to the programs. The programs would, of course, > Build-Depend on libcurl and Build-Conflicts with libcurl-ssl. So the > programs were dynamically linked to libcurl-nossl (or libcurl-gnutls, > or whatever). > > We then distribute source under the terms of the GPL: > > The source code for a work means the preferred form of the > work for making modifications to it. For an executable work, > complete source code means all the source code for all modules > it contains, plus any associated interface definition files, > plus the scripts used to control compilation and installation > of the executable. > > The binary of FOO we redistribute contains the module FOO, of course, > and maybe the module libcurl-nossl. We distribute the source to those > under GPL 3(a). > > If libcurl-ssl happens to be installed by default, how does that > matter then? OpenSSL is not a module of FOO because /FOO was compiled > without it/. But it'll link against lubcurl-ssl, which we also put on the user's machine. It doesn't matter how complicated the contraption for getting some program with libcurl-ssl and openssl into a shared memory space on an end user's machine is -- it's still a contraption for distributing that final work. Debian will still have built a contraption that distributes some program containing OpenSSL to an end user. -- Brian Sniffen [EMAIL PROTECTED]
Re: license for eSvn
On Mon, Sep 06, 2004 at 04:51:11PM +0200, Florian Weimer wrote: > * Sven Luther: > > >> I'd rather see a clarification from upstream. If they intent to > >> prevent a GPLed Windows port, it's non-free. If they just want to > >> make sure that people may distribute Windows binaries, it's probably okay. > > > > Well, the only way giving this licencing would be the absense of a GPLed > > port > > of Qt to windows, wouldn't it ? This hardly makes eSvn non-free, not anymore > > than our dual-licenced Qt does. > > That depends entirely on the meaning of the headlines, unfortunately. > If Pierre wants to approach upstream on this matter, he should request > a change to "Licensing Option 1" and "Licensing Option 2", to make > clear that eSvn is dual-licensed independently of the operating system > that is used. I asked the author of esvn, which confirmed that the license is GPL, so now I think there is no problem to consider packaging esvn in 'main' section. Here is his answer: = This license is GPL for all platform with GPL-ed version of QT include Linux, so the license for the Debian will be GPL as well. If I made it not clear, please let me know what I need to change in the license and I'll do it. I have read the discussion, and have added GPL notices to all source files. regards, Eugene Bort Regards, Pierre
Re: GPL-licensed packages with depend-chain to OpenSSL
On Mon, Sep 06, 2004 at 01:27:56PM -0400, Anthony DeRobertis wrote: > > On Sep 4, 2004, at 18:24, Andrew Suffield wrote: > > >Can I take these two packages on the same CD and split them apart > >again, such that they are no longer aggregated, and still use them? > > > >For example, you can't (or at least couldn't, disregarding modern > >binary emulation tricks) realistically use a program linked against > >solaris libc without solaris libc. > > This smoke test suffers the problem that its determination of > 'derivative work' changes over time. That's why it's a test for aggregation, not derivation. Aggregation happens at a different time. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sep 4, 2004, at 07:55, Florian Weimer wrote: That sounds quite like "plac[ing] restrictions on other software that is distributed along with the licensed software." If curl-ssl is linked to GPLed programs by default, it's not mere aggregation. But it's not linked to the programs. The programs would, of course, Build-Depend on libcurl and Build-Conflicts with libcurl-ssl. So the programs were dynamically linked to libcurl-nossl (or libcurl-gnutls, or whatever). We then distribute source under the terms of the GPL: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. The binary of FOO we redistribute contains the module FOO, of course, and maybe the module libcurl-nossl. We distribute the source to those under GPL 3(a). If libcurl-ssl happens to be installed by default, how does that matter then? OpenSSL is not a module of FOO because /FOO was compiled without it/. PS: the DFSG says nothing of mere aggregation, only of 'other software'.
Re: GPL-licensed packages with depend-chain to OpenSSL
It's not about derivative works at all. It's about source. You need libc and a bunch of header files to build a C program; thus, to distribute, you have to pack all those along too. Unless they're part of the OS... unless you distribute them too. It's not about copyright law's definition of derivative works, but about the GPL's statements involving "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
On Sep 4, 2004, at 18:24, Andrew Suffield wrote: Can I take these two packages on the same CD and split them apart again, such that they are no longer aggregated, and still use them? For example, you can't (or at least couldn't, disregarding modern binary emulation tricks) realistically use a program linked against solaris libc without solaris libc. This smoke test suffers the problem that its determination of 'derivative work' changes over time. I'm pretty sure that a work is either created derivative or not; it can't suddenly become or cease to become derivative (other than a court clarifying the definition of 'derivative work', of course).
Re: license for eSvn
This is a damn confusing license. eSvn is available under two different licenses: If eSvn is linked against the GPLed version of Qt eSvn is released under the terms of GPL also. Source code is not distributed linked. This grants no rights to the source code. If eSvn is linked against a nonGPLed version of Qt eSvn is released under the terms of the eSvn License for non-Unix platforms Ditto. I downloaded the SRPM from http://esvn.umputun.com/. Looking at the source files, they all have clear GPL notices, except for esvn-diff-wrapper.cpp, list_stat_parser.cpp, reposwindow.cpp, svn_commands.cpp, which have no copyright notice. I conclude the author needs a little help getting his licensing clear...
Re: GPL-licensed packages with depend-chain to OpenSSL
On Mon, 06 Sep 2004 09:53:35 +0100, MJ Ray <[EMAIL PROTECTED]> wrote: > On 2004-09-06 02:24:58 +0100 Joseph Lorenzo Hall <[EMAIL PROTECTED]> > wrote: > > > There are definitely implicit copyright licenses in (US) copyright > > case law. > > In general, that only concerns us if US law is the one being applied. > I don't think either GPL (for libcurl) or OpenSSL specify US law. If > it's not US law, do we still have the idea of implicit copyright > licences? That's really the beauty of the GPL... it works in over 70 different copyright regimes around the world. You'd have to ask a legal scholar in each regime about any caselaw involving implicit copyright licenses. In the US, there have been rulings like Effects Associates, Inc. v. Larry Cohen, 908 F.2d 555 (9th Cir. 1990)[1] that have established implicit nonexclusive licensing. [1] This is an especially interesting read... it starts off with, "What we have here is a failure to compensate." and concerns a dispute between a B-movie director and a special effects crew. http://www.kentlaw.edu/e-Ukraine/copyright/cases/effects_v_cohen.html Joe -- Joseph Lorenzo Hall UC Berkeley, SIMS PhD Student http://pobox.com/~joehall/
Re: license for eSvn
* Sven Luther: >> I'd rather see a clarification from upstream. If they intent to >> prevent a GPLed Windows port, it's non-free. If they just want to >> make sure that people may distribute Windows binaries, it's probably okay. > > Well, the only way giving this licencing would be the absense of a GPLed port > of Qt to windows, wouldn't it ? This hardly makes eSvn non-free, not anymore > than our dual-licenced Qt does. That depends entirely on the meaning of the headlines, unfortunately. If Pierre wants to approach upstream on this matter, he should request a change to "Licensing Option 1" and "Licensing Option 2", to make clear that eSvn is dual-licensed independently of the operating system that is used.
Re: license for eSvn
On Mon, Sep 06, 2004 at 04:32:00PM +0200, Florian Weimer wrote: > * Sven Luther: > > > On Mon, Sep 06, 2004 at 04:16:41PM +0200, Florian Weimer wrote: > >> * Sven Luther: > >> > >> > Still, it only applies to the not linked with GPLed Qt case, so should be > >> > ignorable for us, right ? > >> > >> Only you if you interpret "eSvn License for Unix platforms" as a mere > >> placeholder (like "Licensing Option 2"). It's not clear if Debian is > >> a Unix platform. > > > > We don't care about that, the licence says : > > > > if you are linking with the GPLed version of Qt, then the code is under > > the > > GPL. > > > > So, we can ignore all this non-GPLed QT and unix-plateform mess, can't we ? > > I'd rather see a clarification from upstream. If they intent to > prevent a GPLed Windows port, it's non-free. If they just want to > make sure that people may distribute Windows binaries, it's probably okay. Well, the only way giving this licencing would be the absense of a GPLed port of Qt to windows, wouldn't it ? This hardly makes eSvn non-free, not anymore than our dual-licenced Qt does. Friendly, Sven Luther
Re: license for eSvn
* Sven Luther: > On Mon, Sep 06, 2004 at 04:16:41PM +0200, Florian Weimer wrote: >> * Sven Luther: >> >> > Still, it only applies to the not linked with GPLed Qt case, so should be >> > ignorable for us, right ? >> >> Only you if you interpret "eSvn License for Unix platforms" as a mere >> placeholder (like "Licensing Option 2"). It's not clear if Debian is >> a Unix platform. > > We don't care about that, the licence says : > > if you are linking with the GPLed version of Qt, then the code is under the > GPL. > > So, we can ignore all this non-GPLed QT and unix-plateform mess, can't we ? I'd rather see a clarification from upstream. If they intent to prevent a GPLed Windows port, it's non-free. If they just want to make sure that people may distribute Windows binaries, it's probably okay.
Re: license for eSvn
On Mon, Sep 06, 2004 at 04:16:41PM +0200, Florian Weimer wrote: > * Sven Luther: > > > Still, it only applies to the not linked with GPLed Qt case, so should be > > ignorable for us, right ? > > Only you if you interpret "eSvn License for Unix platforms" as a mere > placeholder (like "Licensing Option 2"). It's not clear if Debian is > a Unix platform. We don't care about that, the licence says : if you are linking with the GPLed version of Qt, then the code is under the GPL. So, we can ignore all this non-GPLed QT and unix-plateform mess, can't we ? Friendly, Sven LUther
Re: license for eSvn
* Sven Luther: > Still, it only applies to the not linked with GPLed Qt case, so should be > ignorable for us, right ? Only you if you interpret "eSvn License for Unix platforms" as a mere placeholder (like "Licensing Option 2"). It's not clear if Debian is a Unix platform.
Re: license for eSvn
On Mon, Sep 06, 2004 at 03:40:10PM +0200, Florian Weimer wrote: > | eSvn License for Unix platforms: > | > | 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. > > This is almost free, but it doesn't permit porting to non-Unix > platforms under a free license (which clearly restricts modification). > It seems that this isn't merely an accident. From the non-free > non-UNIX license: > > | 4. The source code is the creative property of the authors. > |Extensions and development under the terms of the Gnu Public License > |are limited to the Unix platform. Any distribution or compilation of > |the source code against libraries licensed other than gpl requires > |the written permission of the authors. > > This is a bit similar to the non-free Motif license that was > restricted to open-source operating systems. It looks as if the > authors want to prevent others from releasing a version for a certain > proprietary operating system. Still, it only applies to the not linked with GPLed Qt case, so should be ignorable for us, right ? Friendly, Sven Luther
Re: license for eSvn
| eSvn License for Unix platforms: | | 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. This is almost free, but it doesn't permit porting to non-Unix platforms under a free license (which clearly restricts modification). It seems that this isn't merely an accident. From the non-free non-UNIX license: | 4. The source code is the creative property of the authors. |Extensions and development under the terms of the Gnu Public License |are limited to the Unix platform. Any distribution or compilation of |the source code against libraries licensed other than gpl requires |the written permission of the authors. This is a bit similar to the non-free Motif license that was restricted to open-source operating systems. It looks as if the authors want to prevent others from releasing a version for a certain proprietary operating system.
Re: license for eSvn
On Mon, Sep 06, 2004 at 02:59:57PM +0200, Pierre Chifflier wrote: > Hi, > > I'm currently evaluating if eSvn (http://esvn.umputun.com/) can be > package for debian. > > I wanted to know if the license is acceptable for 'main' (see > attachement for complete file). > > In short: > > eSvn is available under two different licenses: > > If eSvn is linked against the GPLed version of Qt > eSvn is released under the terms of GPL also. Well, since we carry the GPLed version of Qt anyway, this is probably the only case to consider, and we can ignore the other one. Friendly, Sven Luther
license for eSvn
Hi, I'm currently evaluating if eSvn (http://esvn.umputun.com/) can be package for debian. I wanted to know if the license is acceptable for 'main' (see attachement for complete file). In short: eSvn is available under two different licenses: If eSvn is linked against the GPLed version of Qt eSvn is released under the terms of GPL also. If eSvn is linked against a nonGPLed version of Qt eSvn is released under the terms of the eSvn License for non-Unix platforms It also seems that the application is GPL for unix platforms. Please CC: me on reply, I'm not subscribed. Thanks, Pierre. eSvn is available under two different licenses: If eSvn is linked against the GPLed version of Qt eSvn is released under the terms of GPL also. If eSvn is linked against a nonGPLed version of Qt eSvn is released under the terms of the eSvn License for non-Unix platforms eSvn License for non-Unix platforms: Redistribution and use in binary form, without modification, are permitted provided that the following conditions are met: 1. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 2. It is not permitted to distribute the binary package under a name different than eSvn. 3. The name of the authors may not be used to endorse or promote products derived from this software without specific prior written permission. 4. The source code is the creative property of the authors. Extensions and development under the terms of the Gnu Public License are limited to the Unix platform. Any distribution or compilation of the source code against libraries licensed other than gpl requires the written permission of the authors. THIS SOFTWARE IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. eSvn License for Unix platforms: 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.
Re: GPL-licensed packages with depend-chain to OpenSSL
* Raul Miller: > On Sun, Sep 05, 2004 at 09:07:00PM +0200, Claus Färber wrote: >> They did. Solaris 9 reportedly comes with GNU tools (I can't check it >> myself because I don't have a machine running Solaris). > > You can get gnu tools for solaris from http://www.sunfreeware.com > > To my knowledge, gnu tools are not supplied on the solaris install cds. IIRC, you receive a separate CD containing pre-compiled GNU tools when you buy Solaris 9.
Re: Free & open DRM software
* Brian M. Hunt: > I was contemplating the conundrum of open source digital rights management, > and would like some feedback. If someone were to write digital rights > software, eg. for downloading from iTunes, could they license it under a free > software license like the GPL, with an added clause: > > "If the Program is designed to uphold digital rights management pursuant to > the distribution of copyrighted material, any modification to the Program to > undermine the terms of distribution for that copyright will violate this > license. All rights to publish, redistribute, and use the modified Program > are revoked upon violation of this clause. Derivative works may not modify > this license so as to remove this clause." Why would you want to implement such a thing? An advisory DRM system can be implemented in free software (this has already been done, see Linux module loading and GCC license checking), and it's clearly more desirable than a mandatory system. If the source code is open in the sense that is non-obfuscated, almost anybody can switch of the DRM part (or turn into something that just alerts the user before proceeding). This means that the license probably wouldn't save you from liability for contributory infringement under the INDUCE act (or one of its offsprings).
Re: GPL-licensed packages with depend-chain to OpenSSL
On 2004-09-06 02:24:58 +0100 Joseph Lorenzo Hall <[EMAIL PROTECTED]> wrote: There are definitely implicit copyright licenses in (US) copyright case law. In general, that only concerns us if US law is the one being applied. I don't think either GPL (for libcurl) or OpenSSL specify US law. If it's not US law, do we still have the idea of implicit copyright licences? -- MJR/slefMy Opinion Only and not of any group I know http://www.ttllp.co.uk/ for creative copyleft computing Please email about: BT alternative for line rental+DSL; Education on SMEs+EU FP6; office filing that works fast
