Re: PS documentation file, no sources, author died
* Paul Wise p...@debian.org [2009-05-30 11:46]: What makes you think that the .ps file is not source code? It was generated with LaTeX. BTW, I suggest that in general Debian packages should have an active upstream maintainer. Do you or someone else intend to take over upstream development of this software? A. S. Hodel was the original author but this package (quartenion) is maintained collectively by the Octave-Forge team and it had been for a long time included in Octave itself, which is actively maintained. My problem is just with the PS documentation file. -- Rafael -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PS documentation file, no sources, author died
* Matthew Johnson mj...@debian.org [2009-05-30 08:17]: The problem here is that either there is no copyright licence (in which case we can't distribute it, even in non-free), or the blanket GPLv3 applies (which is, I think, reasonable to assume) in which case either we have a source form, in which case it can go in main, or we don't, in which case we can't distribute it, even in non-free as this violates the licence agreement. The post script definitely looks like it was generated from TeX (from reading the PS source) so we really should try and find said source. Alternatively, I think the reading of the GPL would suggest that if you created a derivative work (eg, by machine translating it back to some sort off TeX, or extracting the text and reformatting) then it would be reasonable to distribute _with the preferred form of modification of that derivative work_, which is your new, translated, TeX file. What you wrote above is fully reasonable. Thanks for the suggestion. -- Rafael -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
PS documentation file, no sources, author died
I have filed an ITP for octave-quartenion [1], a package from the Octave-Forge Project [2]. Its latest released tarball [3] contains a documentation file doc/quartenion [4] in PostScript format for which no source is available. There is also no Copyright notice in the file itself, and there are no licensing conditions neither, although the DESCRIPTION file [5] claims that the whole package is distributed under the GNU GPL v3+. I think this violates the DFSG. I would really like to distribute the documentation file but the upstream author died recently [6] and the chances are small that the sources can be found. Is there any rule that applies to this case, I mean, when an author dies? A simple solution would be to strip the PS file from the tarball and, eventually, create an octave-quartenion-nonfree package containing it. Otherwise, we could generate a LaTeX file that reproduces that PS file. If we do that, what should be the Copyright notice and the licence statement? [1] http://bugs.debian.org/529732 [2] http://octave.sf.net [3] http://downloads.sourceforge.net/octave/quaternion-1.0.0.tar.gz?download [4] http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/main/quaternion/doc/quaternion.ps?view=log [5] http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/main/quaternion/DESCRIPTION?revision=5326view=markup [6] http://eng.auburn.edu/programs/ece/staff/hodel-memorial.html -- Rafael -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DFSG-compatibility of CSIRO license
* Ben Finney [EMAIL PROTECTED] [2008-10-10 09:43]: My conclusion: Non-free because it forbids redistribution for a fee. Also questionable because of the apparent mandatory copyright transfer. You might want to discuss with upstream whether they can re-license the work under the terms of a well-known free software license; I would recommend the GNU GPL with “version 2 or later”, or Expat. Thanks for the thorough analysis of the CSIRO license. I will get in touch with the upstream author and see what you can do about it. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DFSG-compatibility of CSIRO license
* Ben Finney [EMAIL PROTECTED] [2008-10-09 09:05]: Please post the complete text of the license terms (and, preferably, preceded by the grant of license on the work) here in this thread so we can discuss it in context. Here is the README file: nn Natural Neighbours interpolation library Version 1.20 C library functions and two utilities for Natural Neighbours interpolation. Copyright 2000-2002 CSIRO Marine Research GPO 1538 Hobart TAS 7001 Australia Please send comments and bugs to [EMAIL PROTECTED] There is no warranty whatsoever. Use at your own risk. These code may be freely redistributed under the condition that the copyright notices are not removed. You may distribute modified versions of this code UNDER THE CONDITION THAT THIS CODE AND ANY MODIFICATIONS MADE TO IT IN THE SAME FILE REMAIN UNDER COPYRIGHT OF CSIRO, BOTH SOURCE AND OBJECT CODE ARE MADE FREELY AVAILABLE WITHOUT CHARGE, AND CLEAR NOTICE IS GIVEN OF THE MODIFICATIONS. This code has is being developed and used under i386/Linux. I do not think there will be major problems for porting it elsewhere. Please let me know if you managed to do it. To compile, run: configure make (make install) For a couple of quick tests, run: make tests ./nnphi_test ./nnai_test ./ht_test Apart from the `nn' library, this code contains `nnbathy' -- a simple interpolation utility/example based on `nn'. Look in ./example to try or test it. Acknowledgments: This library uses `Triangle' by Jonathan Richard Shewchuk for Delaunay triangulation -- thanks, Richard, well done! Good luck! Pavel Sakov -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DFSG-compatibility of CSIRO license
Could you please check whether the license for the CSIRO library [1] is DFSG-compatible? There has been some discussion about this in Bug#500687 and in the debian-gis mailing list [2] [1] http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/lib/nn/README [2] http://lists.alioth.debian.org/pipermail/pkg-grass-general/2008-September/003209.html Thanks, -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DFSG-compliance of Unicode Copyright
Does anyone know whether the Unicode Copyright [1] is DFSG-compliant? The file /usr/share/perl/5.10.0/unicore/Blocks.txt in perl-modules is released under this license, but there is no mention to it in /usr/share/doc/perl-modules/copyright. [1] http://www.unicode.org/copyright.html Thanks, -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DFSG-compliance of Unicode Copyright
* Andreas Bombe [EMAIL PROTECTED] [2008-07-24 16:52]: On Thu, Jul 24, 2008 at 02:24:30PM +0200, Rafael Laboissiere wrote: Does anyone know whether the Unicode Copyright [1] is DFSG-compliant? The file /usr/share/perl/5.10.0/unicore/Blocks.txt in perl-modules is released under this license, but there is no mention to it in /usr/share/doc/perl-modules/copyright. [1] http://www.unicode.org/copyright.html The license is already used in main for packages such as unicode-data. perl-modules should of course mention it in its copyright file if a part of it uses it. Indeed, the license appears in /usr/share/doc/unicode-data/copyright. Thanks for the pointer. (I am forwarding this message to the perl-modules package maintainers, since they need to take some action. Should I file a bug report for that?) Cheers. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OctDev] Clarification about PDF file license
* David Bateman [EMAIL PROTECTED] [2008-04-18 10:35]: That being the case a GPL compatible documentation license would be a better solution. Can you please suggest an appropriate modification of the documentation license to make it GPL compatible. I see no issues making this change as all of the documentation in fixed.txi and comms.txi was written by me and I have a release from my employer for fixed.txi, and the bits from other authors in the final PDF are all from GPLed sources.. Therefore changing to a GPL compatible documentation license is the easiest solution. But please suggest one... Question to the debian-legal crowd: Would a less-constraining version of GFDL be okay in this case? There are packages in Debian for which the .info file is released under these terms: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. which are DFSG-compatible. The manual contains scraps of the function documentation strings contained in the *.el files, which are GPL'ed. One example of this is the remember-el package. If you type info remember you will see the license above and if you type: info -f remember-el.info -n 'Function Reference' then you will see the documentation strings taken from /usr/share/emacs/site-lisp/remember-el/*.el -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OctDev] Clarification about PDF file license
David,
Sorry for the belated reply.
* David Bateman [EMAIL PROTECTED] [2008-04-10 11:10]:
There remains the same issue with the comms toolbox where a similar
mechanism is used to build the documentation. For my code (a large part
of this toolbox) I give permission to release the documentation of the
code I'm response for under the terms of the license on the title page
of the comms.pdf file.
Could you please sort this out with the other authors of the communications
package?
* David Bateman [EMAIL PROTECTED] [2008-04-10 11:15]:
Just a further question, if the documentation is distributed as part of
the package itself under a GPL license then the only issue is the
inclusion of the fixed.texi and/or fixed.txi file within the package
tar-ball.
Yes, distribution of the source is a requirement of the DFSG (see item 2,
http://www.debian.org/social_contract#guidelines).
The documentation is delivered with the source files where the help strings
are taken and so there is nominally no GPL violation in that case.
I am not a license expert and I have no idea whether including GPL code in a
non-GPL released documentation is okay. I think it boils down to making
sure the licensing conditions expressed in fixed.txi are compatible with the
GPL. For the debian-legal people following this thread, here are the
conditions:
Copyright (C) 2004 Motorola Inc
Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
Permission is granted to copy and distribute translations of this manual
into another language, under the same conditions as for modified versions.
If its only the issue of the inclusion of fixed.{texi,txi} that is the
issue that is preventing the packages inclusion in debian I have no
objections to including these in the package tar-ball.
I think that including fixed.texi should be enough, even though it is
derived source. Including fixed.txi also will not hurt, although it cannot
be used to build fixed.texi from the tarball alone.
At any rate, you could slightly change the terms of the licensing terms by
adding that copy and modification of both source and derived forms of the
documentation are allowed.
--
Rafael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OctDev] Clarification about PDF file license
* MJ Ray [EMAIL PROTECTED] [2008-04-09 10:20]: Rafael Laboissiere [EMAIL PROTECTED] wrote: [Please respect the M-F-T header when replying] Not visible on this client. Guessing. Please state wishes in body. It was: Mail-Followup-To: [EMAIL PROTECTED], debian-legal@lists.debian.org Also, the TeXinfo source file contains scraps that are extracted from other files (*.cc) distributed in the tarball. These files are released under GPL-2+. Does that constitute a violation of the GPL? I can't identify which scraps were copied into fixed.txi from the links you gave, but I think so and I think you need extra permission from the copyright holders of the GPL-2+ scraps to release under this licence, or permission from Motorola to release with parts under the GPL. That was a misunderstanding of mine. I looked again in the texi file and there are no scraps coming from elsewhere (I though it was from fixed,cc). Sorry. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Clarification about PDF file license
[Please respect the M-F-T header when replying] In the process of packaging octave-fixed [1] for Debian, we found a licensing problem with a PDF file (fixed.pdf). This file contains the following Copyright statement: Copyright (C) 2004 Motorola Inc Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the same conditions as for modified versions. This file was produced from TeXinfo sources that are not available in the tarball but can be found in the SVN repository [3]. The question is whether we are allowed to distribute the said PDF file, in particular if the original sources are lacking from the tarball. Also, the TeXinfo source file contains scraps that are extracted from other files (*.cc) distributed in the tarball. These files are released under GPL-2+. Does that constitute a violation of the GPL? [1] http://octave.sourceforge.net/fixed/index.html [2] http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/main/fixed/doc/ Thanks, -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Clarification about the octave-gpcl licensing conditions
* Rafael Laboissiere [EMAIL PROTECTED] [2006-11-09 10:59]: (4) How would the situation be if Octave were released under the LGPL? I investigated this issue further and discovered that R (www.r-project.org), which is released under the GPL, faced the same problem years ago. R operates under the same way as Octave, with modules written as dynamically loaded plugins. For instance, the R binding for the GPC library that I mentioned in my previous post is packaged as a module and distributed at CRAN: http://cran.stat.ucla.edu/src/contrib/Descriptions/gpclib.html This is possible thanks to the changes made in the R licensing terms. From the announcement of the change (2001-Feb-05): It came to our attention that some projects are interpreting GPL to mean that compiling against the header files or linking against a Windows import library brings the compiled code under the scope of GPL. This would mean it would be impossible to distribute binary versions of non-GPL packages with compiled code which called entry points in the R executable or DLL, of which there are many on CRAN. We encourage packages to be distributed under Open Source conditions, but accept that this is not possible for some contributions. Our intention is that export files and import libraries be `accessors' under clause 5 of the LGPL, so that in most cases no (additional) restrictions are imposed by compiling a package using the LGPL-ed components of R. To avoid any anomalies, the versions of the same files in R versions 1.0.0 to 1.2.1 may also be used under LGPL or GPL. I tend to think that such a change in Octave would be beneficial in many aspects, including for fostering the use of Octave in academia. I have already written Octave bindings for the CGAL (www.cgal.org) and the Cubpack++ (www.cs.kuleuven.ac.be/~nines/software/cubpack/) libraries, but I am afraid of releasing them, because of the potential GPL infringement. The two libraries mentioned above are great and are free enough, besides the infamous non-commercial applications clause. I sincerely think that the upstream authors are confused, but we must understand their motivation for imposing this licensing constraint. [ Please, keep Cc: to debian-legal@lists.debian.org, as my original message was posted there. I hope the cross-posting is not abusive. M-F-T set accordingly. Cc:ed to Dirk Eddelbuettel, the maintainer of the R Debian packages. Dirk: this is just FYI. ] -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Clarification about the octave-gpcl licensing conditions
I am confused about the the licensing conditions of the octave-gpcl package and I need some advise from the debian-legalers. I am both the upstream author and the maintainer of octave-gpcl. This package provides the Octave (www.octave.org) binding for the General Polygon Clipper library (http://www.cs.man.ac.uk/~toby/alan/software/). The GPC library is released under a non-free license and is also packaged for Debian by me (libgpcl0 and libgpcl-dev). The problem arises because the octave-gpcl packages produces a loadable module (or plugin) in the form of a *.oct file that is loaded by Octave at run-time. However, Octave is released under the GPL (not the LGPL) meaning that it is not allowed to link any non-GPL compatible product against it and redistribute the whole thing. The situation seems to be similar to that of the readline library. My questions are: (1) should I move the octave-gpcl package from contrib to non-free? (2) If I could keep octave-gpcl under a GPL-compatible license (although it links against a non-free library), wouldn't that be an infringement of the GPL, which is Octave's license? (3) In any event, would it be legal at all to distribute Octave add-ons that link against non-free external libraries? (4) How would the situation be if Octave were released under the LGPL? [Please, keep Cc: to [EMAIL PROTECTED] I hope the cross-posting is not abusive. M-F-T set accordingly.] Thanks, -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
License terms for latex-mk
Hi,
I am considering packaging latex-mk (http://latex-mk.sourceforge.net/)
for Debian. I am appending below its copyright notice. I think it is
DFSG-compliant, but I am unsure about item 3 and 4. Comments are
appreciated.
Thanks in advance,
--
Rafael
$Id: COPYING,v 1.5 2005/09/30 03:02:06 dan Exp $
A few of the files related to the build system ('missing' for example)
are covered by the GPL.
All of the actual .mk code, postscript files, scripts, etc, unless
otherwise noted, are covered by the following copyright:
Copyright (c) 2001, 2002, 2003, 2004, 2005 Dan McMahill
All rights reserved.
This code is derived from software written by Dan McMahill
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. 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.
3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes software developed Dan McMahill
4. The name of the author may not be used to endorse or promote products
derived from this software without specific prior written permission.
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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License terms for latex-mk
* Lionel Elie Mamane [EMAIL PROTECTED] [2006-01-28 19:44]: Seems to be the standard BSD 4-clause license. Clause 4 is completely fine, clause 3 is annoying and imposes a burden on redistribution but generally considered free, AFAIK. I wasn't around before June 1999, but I expect Debian distributed material under this license back then. We discourage it, but it is border-line OK. Thanks for your prompt reply. It is no wonder this license is BSD-like, since the author has @netbsd.org in his email address. BTW, LaTeX-MK has already been packaged for freebsd and netbsd. Let us hope the upstream author will be Debian-friendly... -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BSD-licensed upstream tarball but needs form filled
* Arnoud Engelfriet [EMAIL PROTECTED] [2005-11-29 18:50]: Nowhere is it stated that registration is a mandatory part of getting the license. It would seem that, once one person registers and downloads the software, that one person may distribute the software in accordance with the BSD license. * Andrew Donnellan [EMAIL PROTECTED] [2005-11-30 06:45]: The webforms are compulsory *for downloading the software from their site*. Doesn't affect the package in any way at all though. Thanks for your comments. This give more confidence that there is nothing wrong with the distribution style of SUNDIALS. -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
BSD-licensed upstream tarball but needs form filled
We are seeking advice on how to proceed about an upstream tarball distribution issue. The Debian Octave Group is planning to package the SUNDIALS library (http://www.llnl.gov/CASC/sundials/main.html) for integration into Octave. This package is released under a BSD License (http://www.llnl.gov/CASC/sundials/download/license.html). I think it is DFSG-compliant. The problem is that prior to downloading the tarball (at http://www.llnl.gov/CASC/sundials/download/download.html), the user is asked to fill a form in a web page. Our question is: does this restriction decrease somehow the freeness of the package? If yes, how should we proceed in approaching the upstream authors about this problem? -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Antonello.Salvatucci@europe.lego.com: [Legousb-devel] Mindstorms SDK license]
Hi Antonello, Thanks a lot for your standing involvement with this license issue. I am forwarding your message to the debian-legal mailing list. Summary for the debian-legal folks: the legousb project currently uses a header file taken from the Lego Mindstorms SDK. This file is distributed under a non-DFSG compliant licence. Antonello Salvatucci is negociating with the Lego company in order to relax the licencing conditions, which could make legousb a free software product. Could you please give your advice about the clause (iii) below? The background on this discussion can be seen at the threads in legousb-devel starting at the messages: http://sf.net/mailarchive/forum.php?thread_id=1605045forum_id=2772 http://sf.net/mailarchive/forum.php?thread_id=1606958forum_id=2772 http://sf.net/mailarchive/forum.php?thread_id=1606959forum_id=2772 http://sf.net/mailarchive/forum.php?thread_id=2569353forum_id=2772 - Forwarded message from Antonello Salvatucci [EMAIL PROTECTED] - Date: Thu, 12 Jun 2003 10:13:01 +0200 From: Antonello Salvatucci [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Legousb-devel] Mindstorms SDK license Message-ID: [EMAIL PROTECTED] Hi all, Some time back there has been some discussion on this list regarding a proposed change to the Mindstorms SDK license agreement to allow inclusion of the USB Tower Linux driver with the Debian distro (see previous discussions about this in the list archive). After some talks back and forth, it has been decided to keep the non-commercial clause. However it has been proposed (not approved yet) to add a specific exception regarding device drivers that looks like this: (iii) Any end-user applications developed by means of the SDK or parts hereof shall only be used for purposes that neither directly nor indirectly have any commercial implications; however, device drivers developed by means of the SDK or parts hereof may be included and sold as part of operating system distributions, as long as said operating system distribution is also made available to everybody for download, free of charge; How does this sound? Antonello ___ Antonello Salvatucci Interactive Playmaterials and 3D Platforms, LEGO Virtual Global Innovation and Marketing, LEGO System A/S DK-7190, Billund - DENMARK - End forwarded message -
Linking a GPL'd library to a LGPL'd one
I need an advice about library license. If I develop a library L1 that links to another library L2 which is GPL'd, could I release L1 under the LGPL, or am I forced to release L1 under the GPL? Plese, Cc: replies to me. Thanks. -- Rafael Laboissiere, Debian developer
Re: Linking a GPL'd library to a LGPL'd one
* Raul Miller [EMAIL PROTECTED] [2001-07-22 08:46]: On Sun, Jul 22, 2001 at 12:39:03PM +0200, Rafael Laboissiere wrote: I need an advice about library license. If I develop a library L1 that links to another library L2 which is GPL'd, could I release L1 under the LGPL, or am I forced to release L1 under the GPL? You're not forced to release L1, so you're not forced to release L1 under the GPL. The obvious problem you can create for yourself, here, involves releasing L1 under a license which isn't compatible with the GPL -- this would mean that people couldn't really use your library until that issue was resolved (though they could, of course, still read it). So: either license will work. My problem here is the following: let us say that L1 is released under the LGPL. Now, imagine that some non-free software links against L1. No problem, L1 is LGPL'd, you would say. But, hey!, L1 links against L2, which is GPL'd. This means, that, in practical terms, L1 can only be used by packages with GPL-compatible licenses, which means that the licensing terms of L1 are, after all, equivalent to the GPL. So, although L1 is released under the LGPL, it is actually GPL'd (by the fact that is links against L2). Am I misunderstanding something here? -- Rafael Laboissiere
Re: Linking a GPL'd library to a LGPL'd one
* Richard Braakman [EMAIL PROTECTED] [2001/07/22 17:42]: On Sun, Jul 22, 2001 at 03:03:50PM +0200, Rafael Laboissiere wrote: My problem here is the following: let us say that L1 is released under the LGPL. Now, imagine that some non-free software links against L1. No problem, L1 is LGPL'd, you would say. But, hey!, L1 links against L2, which is GPL'd. This means, that, in practical terms, L1 can only be used by packages with GPL-compatible licenses, which means that the licensing terms of L1 are, after all, equivalent to the GPL. So, although L1 is released under the LGPL, it is actually GPL'd (by the fact that is links against L2). The difference becomes significant if someone takes part of L1 and uses it in some other project. Then the dependency on L2 may not apply. Even if the dependency is extreme, the other project would reimplement L1 under a different license, and then use L2 under the LGPL. Thanks for your clear repsonse. I just noticed that this issue has been discussed in debian-legal recently. I apologize for not having browsed the archives before asking. There should be a FAQ for debian-legal... -- Rafael
Advice on licensing terms
I am considering to package for Debian a library whose licensing conditions are the following: This software is free for non-commercial use. It may be copied, modified, and redistributed provided that the copyright notices which appear within the library source files are preserved on all copies. The intellectual property rights of the algorithms used reside with the University of Manchester Advanced Interfaces Group. You may not use this software, in whole or in part, in support of any commercial product without the express consent of the author. I think that the last paragraph makes it non DFSG-compliant, right? [Cc: replies to me, please, as I am not subscribed to debian-legal.] -- Rafael Laboissiere [EMAIL PROTECTED]
Re: bibindex should probably be GPLed.
On Tue, Feb 01, 2000 at 01:42:06PM +0100, Santiago Vila wrote: This political problem is my concern here. I understand that I CAN (if I wish) release the modified sources under the GPL. My specific question here is whether I HAVE TO release it under the GPL if I link with the GNU Readline library (which is GPL'ed). Noticed that the original upstream code (which is in public domain) has nothing to do with the Readline library, only my modifications are related to it. I think you have to. By linking bibindex with readline, you are creating a work based on readline. According to the GPL under which readline is distributed, you have to distribute all of the work under GPL. [ I think a well-known ftp client had to be relicensed to GPL because of this reason (linking with readline), so there is a precedent ]. Thanks for your patience, Santiago, but I am really annoyed by this problem. Do I have really to relicense the whole even if the original code have had nothing to do in the past with my Readline additions? One could ponder that only _my_ part of the work is based on Readline. I will really appreciate if someone could confirm/second Santiago's point here: am I not allowed to just release _my_ modifications under the GPL, leaving the rest in the public domain? Could someone please point to me the relevant part of GPL that states that? So I think you have two choices: a) Relicense the Debian package to GPL on your own. This is legal, public domain may be relicensed to whatever you want. This will cause a political problem and I am not willing to do it. b) Ask the maintainers to do so. They should not refuse if linking with readline is in his TODO list for this package. No, in their TODO list there was only a mention to a history mechanism, not a explicit mention to the GNU redline library. BTW, in my patch that will be integrated to the next upstream release, there is a fallback to a rudimentary history control mechanism, implemented without Readline. Sorry, for all this discussion, but I prefer to clarify the issues here in debian-legal before approaching the upstream authors. -- Rafael Laboissiere [EMAIL PROTECTED]
Re: bibindex should probably be GPLed.
I am moving this discussion to debian-legal in order to get an advice on how to proceed with this problem. On Sat, Jan 29, 2000 at 11:07:58AM +0100, Santiago Vila wrote: I see you have modified it to use readline, which is great, but since readline is GPLed, I think the complete Debian bibindex package should be released under GPL, not only the modifications for Debian as stated in the copyright file. Santiago is referring to a modification that I did to the biblook/bibindex package to include history support at the command line. This item was in the upstream ToDo list and an improved patch of mine has been incorporated upstream to appear in the next release. I am attaching below the copyright file for my package. At the time I created it, I did not pay attention to this problem of linking against a GPLéd (not LGPLéd) library. I am confused about what to do now. Although the upstream source is public domain, I cannot release the whole package under the GPL, as it is actively maintained and the upstream authors may not appreciate it. Could the licensing gurus enlighten me here? Please, Cc: followups to me as I am not subscribed to debian-legal. -- Rafael Laboissiere [EMAIL PROTECTED]
Re: bibindex should probably be GPLed.
On Mon, Jan 31, 2000 at 06:18:19PM +0100, Jens Ritter wrote: public domain means that you can publish it under the GPL. This term means that the ones who are copyright owners do not enforce it but have placed it into the public domain. Which basically means that you can do anything with such a piece of software (even copyright it by yourself and sell it under NDAs and such). Releasing it under the GPL becomes an issue of politics (with regard to the upstream maintainers). This political problem is my concern here. I understand that I CAN (if I wish) release the modified sources under the GPL. My specific question here is whether I HAVE TO release it under the GPL if I link with the GNU Readline library (which is GPL'ed). Noticed that the original upstream code (which is in public domain) has nothing to do with the Readline library, only my modifications are related to it. Thanks for your advise, Jens, but I think that I need more enlightenment. -- Rafael Laboissiere [EMAIL PROTECTED]
tipa-type1: checking for DSFG compliance
I am packaging the PS type 1 fonts for TIPA. They are distributed along with the README file below. The author mentions public domain but he feels something about the Metafont license. I think that the licensing conditions are DFSG compliant. Could someone please confirm it? (Cc: to me, as I am not subscribed to debian-legal.) README === Hi there, This directory contains a Type 1 version of (some of) the Metafont sources from the directory above. The pfb files are intended to be used with the original TFM files, _don't_ run finst or afmtotfm on the afm files! The afm and pfm files are provided just in case you want to install the files on your windowing system. I'm sorry for the Macintosh users amongst you, but I don't know how to create the MacType1 files. The fonts should give exactly the same output results as the .mf originals, up to the point of sillyness. All bugs in the metafont sources have been kept (and there might be new ones). Files are herewith donated to the public domain, and provided as is. Note that I feel that the copyright from the metafont sources still applies, my only statement here is that I do not impose extra restrictions. Conversion process: .mf - metapost (c) Hobby - .eps .eps - metafog (c) Kinch - .pfb .pfb - hinted touched up with FontLab v3.0c More fonts should follow in the next few months. I can be reached for propositions/bugs at: [EMAIL PROTECTED] Greetings, Taco Hoekwater === -- Rafael Laboissiere [EMAIL PROTECTED] Institut de la Communication Parlee / INP Grenoble, France http://www.icp.inpg.fr/~rafael
