Re: System libraries and the GPLv2
Carlos Alberto Lopez Perez <clo...@igalia.com> writes: > But in the worst case, it will be compatible with GPLv2+ and GPLv3. I am not sure I see this as the worst case situation. Or maybe you meant to write "incompatable"? -- Brian May <b...@debian.org>
Fwd: packages in new
Hello, I am trying to get a LDAP python package included in Debian, however ftpmaster have queried the license on schema files that was copied from the Openldap Debian package. Unfortunately they are not responding to my emails, which makes it so much harder to resolve the issue, or even know if there is still an issue. It is possible that they were happy with my explanation, and haven't got around to saying so. I asked if I should raise the issue on debian-legal and got no response. Is the license ok? Or is the Openldap package in Debian bad? The problem appears to be with the source package, so just removing the files from the binary would be insufficient, and they are used for tests. I would rather not have to repackage the source just for Debian, and even then I would end up using the same files from the openldap package - which unfortunately are conffiles so could have local changes. Please Cc responses to me, I am not subscribed. Upstream code (including latest debian/ directory) https://pypi.python.org/pypi/python-tldap/0.3.4 https://github.com/Karaage-Cluster/python-tldap debian/copyright file from python-tldap contains: === cut === Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: python-tldap Upstream-Contact: Brian May b...@debian.org Source: https://github.com/Karaage-Cluster/python-tldap Files: * Copyright: 2010-2014, Brian May b...@debian.org License: LGPL-3+ Files: debian/* Copyright: 2010-2014, Brian May b...@debian.org License: LGPL-3+ Files: tldap/test/ldap_schemas/* Copyright: 1998-2007 The OpenLDAP Foundation License: Schema License: LGPL-3+ python-tldap is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. . python-tldap 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 Lesser General Public License for more details. . You should have received a copy of the GNU Lesser General Public License along with python-tldap in the COPYING and COPYING.LESSER files. If not, see http://www.gnu.org/licenses/. . On Debian systems, the full text of the GNU General Public License version 3 can be found in the file `/usr/share/common-licenses/LGPL-3'. License: Schema The version of this file as distributed by the OpenLDAP Foundation contains text claiming copyright by the Internet Society and including the IETF RFC license, which does not meet Debian's Free Software Guidelines. However, apart from short and obvious comments, the text of this file is purely a functional interface specification, which is not subject to that license and is not copyrightable under US law. === cut === -- Forwarded message -- From: Brian May br...@microcomaustralia.com.au Date: 22 July 2014 09:34 Subject: Re: packages in new To: Thorsten Alteholz alteh...@debian.org Cc: ftpmas...@debian.org On 21 July 2014 22:55, Thorsten Alteholz alteh...@debian.org wrote: On Mon, 21 Jul 2014, Brian May wrote: Just wondering if there are any problems with my 2 packages that appear to be stuck in NEW? I am not sure whether I can follow the argumentation about the schema-files in python-tldap. Do you mind removing them from the source package? The files are required for the tests to work. We can;'t setup a test LDAP server without the schemas to do it. They have been copied from the openldap package, so if it is a problem here, it will also be a problem in the openldap package too. Have considered using the files directly from the openldap package, however, there are two issues (1) would that make it Debian specific, and (2) they live under /etc as conffiles, so there is no guarantee that they haven't been modified for local requirements. Did you want me to raise this issue on debian-legal? e.g. /etc/ldap/schema/core.ldif has at the top the following text. I assumed that the Copyright 1998-2007 The OpenLDAP Foundation claim is not valid, so I left it out. Including the non-free RFC license generated a Lintian error, so I left it out too. # OpenLDAP Core schema # $OpenLDAP: pkg/ldap/servers/slapd/schema/core.ldif,v 1.1.2.5 2007/01/02 21:44:09 kurt Exp $ ## This work is part of OpenLDAP Software http://www.openldap.org/. ## ## Copyright 1998-2007 The OpenLDAP Foundation. ## All rights reserved. ## ## Redistribution and use in source and binary forms, with or without ## modification, are permitted only as authorized by the OpenLDAP ## Public License. ## ## A copy of this license is available in the file LICENSE in the ## top-level directory of the distribution or, alternatively, at ## http://www.OpenLDAP.org/license.html. # # The version of this file as distributed by the OpenLDAP Foundation # contains text claiming copyright
Re: Freepats
Ryan == Ryan Underwood [EMAIL PROTECTED] writes: Ryan I don't seem to be getting mail from the BTS on this bug. You weren't listed in your mail-followup-to header, but I CCed you anyway. Hmmm, I guess I should have CCed you at the start, sorry about that (the BTS doesn't automatically send mail to the submitter). Ryan Anyway, it seemed to me that the Creative Commons licenses Ryan would be more appropriate since they were specifically Ryan designed to cover media: Ryan This one is just a MIT-ish license: Ryan http://creativecommons.org/licenses/by/1.0/ Ryan This one is a LGPL-like license without going into details Ryan of linking. http://creativecommons.org/licenses/by-sa/1.0/ As far as I can tell, with a quick glance at the summary, both of these licenses should be OK as far as Debian is concerned. I assume that the Share Alike clause wouldn't affect music created with these files, as that seems to be the desired outcome. -- Brian May [EMAIL PROTECTED]
Re: Freepats
Brian == Brian May [EMAIL PROTECTED] writes: Brian Sorry, it appears I stuffed up one of the email addresses, Brian retry: Mark asked me to forward his response, which was accidently sent to the wrong address I gave (I sent the initial message to [EMAIL PROTECTED], not debian-legal@lists.debian.org). I have cited Mark's response, so there is no confusion who typed it. Neither me or Mark are subscribed, please send CCs to both of us, thanks. Mark == Mark Constable [EMAIL PROTECTED] writes: Mark On Mon, 19 Apr 2004 05:03 pm, Brian May wrote: Q: What are FreePats? A: A set of SoundFont files that are intended to be freely distributed. Mark FreePats are more specifically based on Ultra Gravis Patches Mark which originally worked with their branded sound cards as Mark one instrument per file. SoundFonts generally refer to the Mark now Creative owned *.sf2 standard often distributed as many Mark instruments in a single file unit. Q: What is a soundfont file? A: A image that can be used to reconstruct notes made by musical instruments? ie. a font file for music instead of writing. So, I would imagine anything that applies to standard font files also applies here. Mark Digitized audio data that can be rendered, or compiled, Mark into instrument voicing according to the notes usually Mark derived from a MIDI file. Perhaps think of MIDI data as Mark precompiled source code ready to compile the final audio Mark rendition. Writting the source code requires a sequencer Mark instead of some text editor. Sound fonts would be more akin Mark to specialized libraries needed to generate the final Mark compiled musical object. Q: How are soundfont files created? A: I don't know. I suspect though, like a *.wav file, is no source code to generate a FreePat file? This perhaps makes it different from programs already in Debian. Mark Yes, a single or mulitple wav files along with embedded Mark meta-info to self describe how the wav files are to be Mark interpreted such as loop points, attack, release, delay and Mark many other parameters. If so, then the soundfont file a bit like a shared and/or static library that can be used to generate music (eg. a midi file contains a reference to it and a wav file embeds it) to make a full tune. Mark Yes, I would agree that a sound font is like a library and Mark furthermore suggest that the source code is the hybrid Mark MIDI and sequencer project file information that determine Mark the notes to be rendered from the libraries of any Mark instrument voices referenced and available. The BSD style license generally are the most unrestrictive license around, eg. you can you BSD licensed files in proprietary projects. I believe the majority of the X fonts are BSD licensed. Mark A concern here is misuse of the FreePats material by Mark commercial interests who may then try to restrict reusage of Mark this material. The GPL style license, as applied to this case, says if you make modifications or make derivative works of it, then the result must be licensed under the GPL (or similar license). I don't know if a wav file created from a FreePat file would be considered a derivative work or not. The GPL also says if you distribute it, then you must also distribute source code to (as appropriate to the file format). I believe the GS fonts are GPL. Mark Using source code notes to create a musical audio sequence Mark would not be a derivative in the same sense as modifying the Mark sound font to create a different instrument, or to Mark transcribe the raw wav and meta-info into another format, Mark that would be a derivative. There are other issues with the GPL that might effect soundfont files, not sure. For instance, would the soundfont file be considered source code when making a *.wav file? What if the *.wav file has since been edited in a wav editor and cannot be automatically recreated? For these reasons, I don't think it should be a required that music files be GPL. Mark As above, I don't think rendering a wav file from sound Mark fonts would be considered a derivative in the same sense Mark that re-engineering the sound font into yet another sound Mark font would indeed be a derivative. Also just like I expect to be able to type and print a document up in a word processor, and do anything I want with that document, regardless of fonts used. In fact, this might be dodgy, but as far as I am concerned I automatically get exclusive copyright of such a document, as I consider it my own work. I would hope the same applies with music generated with FreePat files. Mark As in the content of a document would not be considered a Mark
Re: Freepats
Brian == Brian May [EMAIL PROTECTED] writes: Mark Using source code notes to create a musical audio sequence Mark would not be a derivative in the same sense as modifying the Mark sound font to create a different instrument, or to Mark transcribe the raw wav and meta-info into another format, Mark that would be a derivative. [...] Mark As above, I don't think rendering a wav file from sound Mark fonts would be considered a derivative in the same sense Mark that re-engineering the sound font into yet another sound Mark font would indeed be a derivative. [...] Mark As in the content of a document would not be considered a Mark derivative of the any binary type face used in the process, Mark a musical composition would not be considered a derived work Mark of the sound font material. Personally, my opinion (depending on the above) would be to use the GPL, so any modifications to the fonts themselves will remain GPL, but allow an exception (if required) so music created with the soundfont isn't restricted. If the GPL doesn't do this, maybe the LGPL will do so? Mark I also lean towards the GPL, if it fits. I would suggest you use the GPL, and add a note somewhere that you interpret the GPL as above. If anyone disagrees with your interpretation (and so far nobody has), then the issue can be resolved at that time. To do this, you could add the GPL COPYING file to the archive, and then a COPYRIGHT file that lists the copyright holders, and the fact the files are licensed for use under the GPL. -- Brian May [EMAIL PROTECTED]
Re: Freepats
Sorry, it appears I stuffed up one of the email addresses, retry: Brian == Brian May [EMAIL PROTECTED] writes: Brian Hello, I have CCed this to debian-legal, as these are the Brian people who deal with legal issues in Debian. Brian I would refrain making any decisions until other Brian debian-legal people get a chance to respond, and point out Brian all the errors I have made. ;-) Brian Background: See bug URL:http://bugs.debian.org.au/239163. Mark == Mark Constable [EMAIL PROTECTED] writes: Mark Hi Brian, perhaps I should simply ask you directly for some Mark guidance as how best to license and package FreePats. If you Mark have a suggestion as the the most appropriate license and Mark anything I can do to facilitate them getting into Debian Mark then I'm more than happy to do whatever I can. Brian Thank you. I would greatly appreciate it if FreePats could Brian be included in Debian. Mark I've been on holidays for the last month and only just Mark noticed your posting on the Wiki... a recent timidity-talk Mark posting (re)alerted me to the need to sort this out. Brian News travels fast, I posted to the above bug report Brian yesterday. ;-). Brian The best license depends on your Brian requirements. Unfortunately, this type of discussions can Brian often end up in heated arguments, even when only Brian considering DFSG (Debian) compatible licenses. To provide Brian an unbiased opinion, first some issues regarding the file Brian format may need clarification: Brian Some background (my understanding only; I am very new to Brian the world of MIDI and soundfonts), I am sure Mark will Brian correct any mistakes: Brian Q: What are FreePats? A: A set of SoundFont files that are Brian intended to be freely distributed. Brian Q: What is a soundfont file? A: A image that can be used Brian to reconstruct notes made by musical instruments? ie. a Brian font file for music instead of writing. So, I would imagine Brian anything that applies to standard font files also applies Brian here. Brian Q: How are soundfont files created? A: I don't know. I Brian suspect though, like a *.wav file, is no source code to Brian generate a FreePat file? This perhaps makes it different Brian from programs already in Debian. Brian If so, then the soundfont file a bit like a shared and/or Brian static library that can be used to generate music (eg. a Brian midi file contains a reference to it and a wav file embeds Brian it) to make a full tune. Brian My unbiased 3 paragraph summary of DFSG licenses: Brian The two major licenses that comply with the DFSG Brian (Debian-Free-Software-Guidelines) seem to be the BSD style Brian license and the GPL style license. Brian The BSD style license generally are the most unrestrictive Brian license around, eg. you can you BSD licensed files in Brian proprietary projects. I believe the majority of the X fonts Brian are BSD licensed. Brian The GPL style license, as applied to this case, says if you Brian make modifications or make derivative works of it, then Brian the result must be licensed under the GPL (or similar Brian license). I don't know if a wav file created from a FreePat Brian file would be considered a derivative work or not. The Brian GPL also says if you distribute it, then you must also Brian distribute source code to (as appropriate to the file Brian format). I believe the GS fonts are GPL. Brian My biased opinions and questions for debian-legal: Brian There are other issues with the GPL that might effect Brian soundfont files, not sure. For instance, would the Brian soundfont file be considered source code when making a Brian *.wav file? What if the *.wav file has since been edited in Brian a wav editor and cannot be automatically recreated? For Brian these reasons, I don't think it should be a required that Brian music files be GPL. Brian Also just like I expect to be able to type and print a Brian document up in a word processor, and do anything I want Brian with that document, regardless of fonts used. In fact, this Brian might be dodgy, but as far as I am concerned I Brian automatically get exclusive copyright of such a document, Brian as I consider it my own work. I would hope the same applies Brian with music generated with FreePat files. Brian Personally, my opinion (depending on the above) would be to Brian use the GPL, so any modifications to the fonts themselves Brian will remain GPL, but allow an exception (if required) so Brian music created with the soundfont isn't restricted. If the Brian GPL doesn't do this, maybe the LGPL will do so? Brian This is all my uninformed opinion, now to pass it on to Brian debian-legal
Re: plagiarism of reiserfs by Debian
On Tue, Apr 22, 2003 at 09:41:34AM +0100, Edmund GRIMLEY EVANS wrote: If the copyright holder includes a copy of the GPL but writes that the software is licensed under the GPL plus additional restrictions, then this is not illegal as far as I know (there's nothing in the GPL that prevents it from being used in this way). Of course, the resulting licence is not compatibile with the GPL, so if the program were linked with other GPL software Debian could not distribute it. Quoting README, in particular the entire LICENSING section: [509] [scrooge:bam] ~/tmp/woody/reiserfsprogs/reiserfsprogs-3.6.4 dpkg-parsechangelog | grep '^Version: ' Version: 1:3.6.4-4 [503] [scrooge:bam] ~/tmp/woody/reiserfsprogs/reiserfsprogs-3.6.4 cat README [LICENSING] ReiserFS is hereby licensed under the GNU General Public License version 2. Source code files that contain the phrase licensing governed by reiserfs/README are governed files throughout this file. Governed files are licensed under the GPL. The portions of them owned by Hans Reiser, or authorized to be licensed by him, have been in the past, and likely will be in the future, licensed to other parties under other licenses. If you add your code to governed files, and don't want it to be owned by Hans Reiser, put your copyright label on that code so the poor blight and his customers can keep things straight. All portions of governed files not labeled otherwise are owned by Hans Reiser, and by adding your code to it, widely distributing it to others or sending us a patch, and leaving the sentence in stating that licensing is governed by the statement in this file, you accept this. It will be a kindness if you identify whether Hans Reiser is allowed to license code labeled as owned by you on your behalf other than under the GPL, because he wants to know if it is okay to do so and put a check in the mail to you (for non-trivial improvements) when he makes his next sale. He makes no guarantees as to the amount if any, though he feels motivated to motivate contributors, and you can surely discuss this with him before or after contributing. You have the right to decline to allow him to license your code contribution other than under the GPL. Further licensing options are available for commercial and/or other interests directly from Hans Reiser: [EMAIL PROTECTED] If you interpret the GPL as not allowing those additional licensing options, you read it wrongly, and Richard Stallman agrees with me, when carefully read you can see that those restrictions on additional terms do not apply to the owner of the copyright, and my interpretation of this shall govern for this license. Finally, nothing in this license shall be interpreted to allow you to fail to fairly credit me, or to remove my credits, without my permission, unless you are an end user not redistributing to others. If you have doubts about how to properly do that, or about what is fair, ask. (Last I spoke with him Richard was contemplating how best to address the fair crediting issue in the next GPL version.) [END LICENSING] --- cut --- I am no lawyer, but reading up to here I am a bit confused if it is GPL+interpretation or GPL+extension. Personally I don't see any problems with the above text, but the standard I-am-not-a-lawyer disclaimer applies. It is also not defined what he is referring to when he talks about his credits, I would assume he means the rest of the details from the remainder of the README file. I thought that the existing version of the GPL already catered for this, but it appears I might be mistaken. -- Brian May [EMAIL PROTECTED]
Re: How to get rid of non-free packers?
On Fri, Aug 23, 2002 at 04:01:15PM +0300, Juhapekka Tolvanen wrote: It is not very bad thing if we can't create archives in formats like ACE, ARJ, LHA or RAR with free software. But it is more important to Ideally, amavis needs access for all archive formats so it can check for viruses in E-Mail... ARC: This is very old archive-format. We only need some way to unpack those files. Fortunately, this was just announced at c.o.l.a: http://rus.members.beeb.net/nomarch.html It is meant to be free replacement for arc. It is under GNU GPL. It can also unpack Spark-files (common under Acorn Archimedes). This is already in Debian. P.S: I don't subscribe to mailing-lists of Debian, so please Cc: your replies to me. And I am not Debian developer. Please set your Mail-Followup-To: header correctly in future, that way mutt will automatically do the right thing. I think this is off-topic for debian-legal, but I am not sure. -- Brian May [EMAIL PROTECTED]
Re: ACL - The Ada Community License
So whats the verdict? I take it that this is neither DFSG or GPL compatable? On Mon, Jul 29, 2002 at 10:49:14PM -0700, Walter Landry wrote: Brian May [EMAIL PROTECTED] wrote: (please CC responses to me thanks; sorry if this has already been raised; I searched the archives but found nothing) Hopefully mail-followups-to should be correct this time... Reasons why it is not DFSG: On Tue, Jul 30, 2002 at 12:14:24PM -0700, Walter Landry wrote: Glenn Maynard [EMAIL PROTECTED] wrote: It's unclear to me what falls under 3 and what falls under 4: it seems as if 3 is for all modification and distribution--it mentions executables--and 4 is for distribution of binaries only. However, 4 seems more restrictive than 3; it doesn't have the freely available option. So, I'm a bit confused. Hmm. I see your point. I think the license is unclear. I'm not sure whether the restrictions in Section 4 are in addition to the restrictions in Section 3, or rather Section 4 is an additional option for Section 3. It could be argued either way. Spelling it out would be a good thing. On Tue, Jul 30, 2002 at 11:23:19PM +0200, Florian Weimer wrote: Walter Landry [EMAIL PROTECTED] writes: Selling the library is not forbidden. Really? You may not charge a fee for this Ada library itself. On Tue, Jul 30, 2002 at 11:21:38PM +0200, Florian Weimer wrote: Brian May [EMAIL PROTECTED] writes: 2 You may apply bug fixes, portability fixes and other modifications derived from the Public Domain or from the Copyright Holder. A library modified in such a way shall still be considered the Standard Version. 3 You may otherwise modify your copy of this Ada library in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following: This discriminates against people who cannot put copyrighted works into the Public Domain. Reasons why it is not GPL compatable: Maybe not. Section 7 says 7 System-level subroutines supplied by you and linked into this Ada library in order to emulate the functionality defined by this Ada library shall not be considered part of this Ada library, but are the equivalent of input as in Paragraph 6, provided these subroutines do not change the library in any way that would cause it to fail the regression tests for the library. This is similar to the operating system exception, except that the vendor of the operating system can't do anything that breaks Ada. For example, the Sun libc has pow() defined. The Ada library might define it's own pow() for small integers that does not give bit-wise identical results to the Sun pow(). If the Sun one is used, it might cause regression tests to fail, meaning that Sun could not distribute the Ada library. The GPL only restricts Sun from distributing libc and the Ada library together. This would count as an additional restriction, and thus not compatible with the GPL. If you have any influence, changing this part to read more like the GPL would be enough to make it compatible. Reasons why the license has silly mistakes: On Tue, Jul 30, 2002 at 03:46:22AM -0400, Glenn Maynard wrote: 3 You may otherwise modify your copy of this Ada library Should this say distribute modified copies? b) Accompany the distribution with the machine-readable source of the Ada library with your modifications. Accompany any non-standard executables with their c) corresponding Standard Version executables, giving the non-standard executables non-standard names, and clearly documenting the differences in manual pages (or equivalent), together with instructions on where to get the Standard Version. Should this be: b) Accompany the distribution with the machine-readable source of the Ada library with your modifications. c) Accompany any non-standard executables with their corresponding Standard Version executables, giving the non-standard executables non-standard names, and clearly documenting the differences in manual pages (or equivalent), together with instructions on where to get the Standard Version. -- Brian May [EMAIL PROTECTED]
ACL - The Ada Community License
(in the manual page or equivalent) on where to get the Standard Version. b) Accompany the distribution with the machine-readable source of the Ada library with your modifications. Accompany any non-standard executables with their c) corresponding Standard Version executables, giving the non-standard executables non-standard names, and clearly documenting the differences in manual pages (or equivalent), together with instructions on where to get the Standard Version. d) Make other distribution arrangements with the Copyright Holder. 5 You may charge a reasonable copying fee for any distribution of this Ada library. You may charge any fee you choose for support of this Ada library. You may not charge a fee for this Ada library itself. However, you may distribute this Ada library in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution provided that you do not advertise this Ada library as a product of your own. 6 The scripts and library files supplied as input to or produced as output from the programs of this Ada library do not automatically fall under the copyright of this Ada library, but belong to whomever generated them, and may be sold commercially, and may be aggregated with this Ada library. 7 System-level subroutines supplied by you and linked into this Ada library in order to emulate the functionality defined by this Ada library shall not be considered part of this Ada library, but are the equivalent of input as in Paragraph 6, provided these subroutines do not change the library in any way that would cause it to fail the regression tests for the library. 8 The name of the Copyright Holder may not be used to endorse or promote products derived from this software without specific prior written permission. 9 THIS ADA LIBRARY IS PROVIDED AS IS AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. How to Apply These Terms to Your New Libraries To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the copyright line and a pointer to where the full notice is found. Also, be sure to add information on how to contact you by electronic and paper mail. Copyright (C) This program is free software; you can redistribute it and/or modify it under the terms of the Ada Community License which comes with this Library. 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 Ada Community License for more details. You should have received a copy of the Ada Community License with this library, in the file named Ada Community License or ACL. If not, contact the author of this library for a copy. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Implied exceptions to GPL?
On Thu, 2002-05-16 at 14:54, Branden Robinson wrote: On Thu, May 16, 2002 at 12:46:16PM +1000, Brian May wrote: I find this rather odd, see: URL:http://www.gnu.org/copyleft/gpl-faq.html#InterpreterIncompat, part 2. Of course, you could argue that point 2 conflicts with point 3... I disagree that they conflict, but I think point 2 is dangerous advice to give, and prone to abuse. Can you elaborate your reasoning, please? 2. If you wrote and released the program under the GPL, and you designed it specifically to work with those facilities, people can take that as an implicit exception permitting them to link it with those facilities. But if that is what you intend, it is better to say so explicitly. 3. You can't take someone else's GPL-covered code and use it that way, or add such exceptions to it. Only the copyright holders of that code can add the exception. Point 2 says you can take someone else's code and implicit permission exists that you can link it with required 3rd party libraries, even if they are not GPL compatible (at least that is the way I read it: people can take that is an implicit exception). Point 3 says you can't take someone else's code and use it that way. Point 3 seems to directly contradict point 2. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Implied exceptions to GPL?
I find this rather odd, see: URL:http://www.gnu.org/copyleft/gpl-faq.html#InterpreterIncompat, part 2. Of course, you could argue that point 2 conflicts with point 3... Please CC replies to me. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libreadline
On Tue, 2002-05-07 at 13:33, Walter Landry wrote: If it doesn't, then the OpenSSL code, by itself, does not touch any GPL'd code. The interpreter, which includes GPL code, does not touch any OpenSSL code. We have one program that calls another program through well-documented interfaces. I don't think that there is any problem with distributing them as two separate entities. There might be a problem if you distribute them together. To allay any concerns, I would recommend splitting python into 2 packages. Yuck. Now I regret picking on Python. I hadn't expected it would be this difficult to fix... -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libreadline
On Mon, 2002-05-06 at 06:04, Gregor Hoffleit wrote: From a first look, GNU TLS has a very different API. The current code in the socket module won't work with GNU TLS. I wonder how hard it would be to create a library that sits on top of GNU TLS and gives it the same API as openssl. (I am not volunteering to do this though). -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssl and GPL
Thanks for everyones responses. On Mon, Apr 22, 2002 at 11:09:21AM -0500, Steve Langasek wrote: It is OK to create GPL binaries linked against OpenSSL and compiled for Debian platforms, and distribute them outside of Debian. But the wording of the GPL indicates you could never distribute those binaries with Debian -- not even selling them on different CDs in a multi-CD set, I think. What if a program (lets say it has a new bsd license) is linked against both libreadline and openssl. Would this be ok? Not exactly. If you link a GPLed program against a defined ABI that has both GPL-compatible and GPL-incompatible implementations, you have not violated the terms of the GPL; however, if you provide binaries, you must provide complete source code to *the exact binaries that you are distributing*, which under the GPL includes any libraries that are linked in. Thus, the violation comes specifically from distributing binaries of GPLed programs without distributing all the dependent libraries under the same terms. If you want to distribute the Heimdal libraries (Y) /without/ linking them against OpenSSL, and link GPL programs (X) against that, and distribute them together, then you're ok. Actually, I checked this, and no, I am not OK. If Heimdal doesn't use Openssl, it uses its internal libdes instead, and that code comes from guess who??? Eric Young. So, this whole discussion it interesting, but has no real significance in the context of Heimdal (unless you want to write your own libdes). (I have his copyright in heimdal*/copyright even though the debian package doesn't use his library - should I remove it? ie. is the copyright file for the source or the binary package?) No moreso than most legal documents, IMHO, and a good deal less so than many. ;) As a programmer/linguist, I find the GPL rather aesthetically pleasing. Maybe I wouldn't find it so pleasing if I were a lawyer. shrug :) I think it must be vague, otherwise you wouldn't have people like OpenSSL come up with a completely different interpretation... -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
openssl and GPL
Hello, I am still a bit confused as to the problems with linking GPL code with OPENSSL. I don't intend to start any flame wars... Please send CCs to me. Thanks. If there is somewhere I can find this information, URLs would be appreciated. 1. What is the problem? I have read the GPL, and cannot recall the problem. According to the top of /usr/doc/openssl/copyright, openssl has a dual BSD style license. I haven't heard of problems linking GPL code with BSD code before. So why is this different? 2. Is URL:http://www.openssl.org/support/faq.html#LEGAL wrong? ie. the GPL does not place restrictions on using libraries that are part of the normal operating system distribution. I normally like the GPL, but I find it a bit irratating that I can't take some GPL program, and link it against Heimdal (which happens to be linked against OpenSSL), without express permission from all the copyright holders of the GPL software. In fact, I would argue that this goes against the goals of the GPL. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssl and GPL
On Sun, Apr 21, 2002 at 04:24:03PM -0500, Steve Langasek wrote: There have always been problems linking GPL code with BSD code, so long as the GPL has existed. Only code licensed under the new, recently revised BSD license can be linked with GPL code. OpenSSL doesn't use such a new-style BSD license. So I take it that the advertising clause is the only problem with the OpenSSL license? And can I also assume that the copyright holders have been contacted about this (probably billions of times), but don't want to change the license, for some reason? 2. Is URL:http://www.openssl.org/support/faq.html#LEGAL wrong? ie. the GPL does not place restrictions on using libraries that are part of the normal operating system distribution. The actual wording of the GPL in this regard is 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. The current interpretation of this accepted by Debian, which I've been unable to find fault with, is that if your operating system comes with OpenSSL, it's ok to link *third-party* GPLed works against it; but if you distribute a GPLed work together with the libraries it depends on, even as part of an OS distribution (such as Debian), then those libraries must all be licensed in a manner that's compatible with the GPL. It is very vague. I wonder what the intention was. However, I am a bit puzzled; does that mean: - It is OK to distribute these programs if they are seperate from Debian? - It is OK to distribute a close source package that uses GPL packages from Debian? The goals of the GPL are to ensure the greatest net level of software freedom, by trading certain user freedoms (unlimited use of the source code) for others (guaranteed availability of the source code of derived My feeling is that these limitations aren't on the source code, but the binary code. If it was only the source code, then the binary code wouldn't matter. So you can link X (GPL) against Y (BSD), but if the binary of Y is changed (maybe without prior notice) to link against, say openssl, then suddenly the original linkage breaks the GPL. Even though the original program (X) has not changed, and has not even been recompiled. Come to think of it, can the GPL really say It is Ok to distribute package X, but not if the version of Y supplied is linked into openssl? What if several compiled versions of Y have been made available, and only one of these uses openssl? (lets assume that these different versions can be used without recompiling, and that somehow the Depends field allows this). works). As such, I don't think it's ever in conflict with the goals of the GPL to prevent linking with code that doesn't provide users with the same set of freedoms that the GPL itself does (or a superset thereof). You may argue that you place greater value on the freedoms that BSD-style licenses give you, but by virtue of the advertising clause, the OpenSSL license nevertheless lacks one freedom that the GPL insists on; and as such, it's incompatible. Given the long history of the GPL as a license, and the fact that it has undergone revisions in the past, I think it's awkward to argue that it doesn't really say what its authors meant for it to say. Rather, I see the GPL as a principal source of insight into the goals of its authors. :) I think that the GPL is vague and prone to misintepretation. For good example, see above issue ;-). The way I see Debians intepretation of the GPL is that it is based on the perspective of the end-user. So under this interpretation, a user should be able to install only GPL applications without their freedom being restricted by more restrictive licenses. However, if this was the case, shouldn't it still be OK simply to provide two packages, one without the offending library, so the user has the choice? What would happen if a Priority: required package required OpenSSL? Wouldn't this defeat the point of the restrictions set by the GPL? Since any users would have to install openssl anyway? Anyway, thanks for your response. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: downloaded from sourceforge but no license included
On Sat, Mar 09, 2002 at 03:50:47PM +0100, Benjamin Drieu wrote: Or do I need to ask the upstream authors to please add the copyright/license files to their prestine source code first? The GPL do require that all source files carry a prominent copyright and license notice. So the upstream author has to mark these files are GPL'd. h... thats what I thought. I submitted a bug report to the upstream authors asking them to fix the problem. However, I see that somebody else already has an ITP for the package, so I will let him work out these problems ;-)
