Re: The draft Position statement on the GFDL
On Tue, May 11, 2004 at 09:26:16PM -0400, Raul Miller wrote: This is a case in which DFSG#3 very explicitly does not require derived works to be distributable. Agreed, though the convolutions you went through don't really have any bearing on this point. Of course it does. You claimed, as far as I can tell, that the GPL's requirement that derived works be available under the GPL's terms is a restriction on modification; I explained that this is explicitly allowed by the latter part of DFSG#3. If that is not what you meant, then please explain more clearly what you did mean. (If the explanation of what you did mean results in a similar response to another subthread, such as to Steve's reply, feel free to bump the reply over there.) -- Glenn Maynard
databases not copyrightable in the USA (was: CA certificates)
On Tue, May 11, 2004 at 01:23:40PM +0200, Giacomo A. Catenazzi wrote: In some countries (USA and Germany?) lists/databases are copyrightable, even is single data is not! (phone book, games scores and statistics,...) Not in the United States. The controlling Supreme Court precedent is _Feist Publications, Inc. v. Rural Tel. Serv. Co., 499 U.S. 340 (1991)_. There has been an effort in every session of Congress since then to overturn that precedent legislatively, but so far all such efforts have failed. The current attempt is HR 3261, the Database and Collections of Information Misappropriation Act (DCIMA). See http://writ.news.findlaw.com/student/20040211_karl.html for a little more on this subject. -- G. Branden Robinson|You should try building some of the Debian GNU/Linux |stuff in main that is [EMAIL PROTECTED] |modern...turning on -Wall is like http://people.debian.org/~branden/ |turning on the pain. -- James Troup signature.asc Description: Digital signature
right of publicity, or why no-advertising clauses are not necessary
I find no-advertising clauses like the following annoying: Except as contained in this notice, the name(s) of the above copyright holders shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization. They annoy me for a few reasons: 1) They're not necessary, at least in my jurisdiction, and I suspect not in most or all other jurisdictions of interest to Debian. 2) The right of publicity, unlike the distribution of copies of a work, is not an exclusive right that is retained by copyright holders under copyright law in my jurisdiction, and I suspect not in others, either. Therefore, attaching such a restriction term to a copyright notice may very well be null and void. A contract would have to be formed between the copyright holder and the user for this restriction to attach. 3) Perpetuating language like this in licenses just confuses innocent bystanders into putting irrelevant clauses into their own licenses. We do the community no favors by encouraging authors to misunderstand copyright, particularly through the ritualistic duplication of old errors. In the United States, there are several legal remedies available to people whose names or likenesses are misappropriated for advertising or promotional purposes. The following web site enumerates some: http://www.law.cornell.edu/topics/publicity.html You'll note that none of these remedies are grounded on copyright law. Copyright is irrelevant. I would therefore like to make two requests of debian-legal: A) Can folks in other countries help us find out if publicity rights are recognized there? Does any jurisdiction in the world automatically grant copyright licensees permission to use the copyright holder's name or likeness in advertising or publicity? B) If we find that most jurisdictions of interest to Debian handle publicity rights substantially as the U.S. does, can we please more actively discourage their use? If my understanding is correct, let's get the word out that these license terms are unnecessary and only promote confusion about copyright. For what it's worth, I think the NetBSD Foundation has already reached this conclusion, which is why they use a 2-clause form of the BSD license, with both the compelled-advertising and no-advertising clauses removed. -- G. Branden Robinson| Reality is what refuses to go away Debian GNU/Linux | when I stop believing in it. [EMAIL PROTECTED] | -- Philip K. Dick http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Theoretical Library License
On Mon, May 10, 2004 at 01:43:24PM -0600, Benjamin Cutler wrote: Humberto Massa wrote: @ 10/05/2004 16:26 : wrote Benjamin Cutler : 3. If you wish to SELL your program or otherwise charge for its distribution, and NOT include the source code and/or otherwise make it non-freely redistributable, licensing terms must be worked out with the author of the library in advance. ---end license This one is a no-op... IF you are the sole copyright holder of the library. I realize it's a no-op, but I consider it a clarification for people who might want to use it to write proprietary programs using it that they must work that out with me in advance, and that the option is available. Clarifications don't belong in the license itself. Maybe in the document, but not as part of the terms themselves. See the GNU GPL for guidance on how to clearly separate the actual license terms in a document from other material. -- G. Branden Robinson|It may be difficult to to determine Debian GNU/Linux |where religious beliefs end and [EMAIL PROTECTED] |mental illness begins. http://people.debian.org/~branden/ |-- Elaine Cassel signature.asc Description: Digital signature
Re: Draft Debian-legal summary of the LGPL
On Tue, May 11, 2004 at 10:06:31PM +0200, Andreas Barth wrote: Hi, though LGPL is quite OLD, AFAICS there is no summary. To put it on the web pages, I wrote one: Debian-legal has concluded that the LGPL (Library Gnu Public License) v2 and LGPL (Lesser Gnu Public License) v2.1 is a DFSG-free license. The licenses are included on every debian system in /usr/share/common-licenses, so I ommited the full reference I think your intentions are noble, but I don't think we should do this. Not because the LGPL doesn't deserve a summary, but because it hasn't been done right. The entire license needs to be posted and carefully scrutinized. I would suggest that we postpone such an exercise until after the GNU FDL situation is resolved. Furthermore, it might be wise if we only attempt to adjudicate licenses that are brought to us for consideration. I'm not sure we should go on hunts for licenses to audit ourselves; to do so might damage the impression of impartiality that we should attempt to cultivate and live up to. -- G. Branden Robinson| I am only good at complaining. Debian GNU/Linux | You don't want me near your code. [EMAIL PROTECTED] | -- Dan Jacobson http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Draft Debian-legal summary of the LGPL
* Branden Robinson ([EMAIL PROTECTED]) [040512 11:10]: Furthermore, it might be wise if we only attempt to adjudicate licenses that are brought to us for consideration. I'm not sure we should go on hunts for licenses to audit ourselves; to do so might damage the impression of impartiality that we should attempt to cultivate and live up to. For me, I want the LGPL for a very simple reason on this web page: It's quite often used (even so often that it is stored in /usr/share/common-licenses), and I think that on our web page we should not only have the quite new licenses, but also the old stuff. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Draft Debian-legal summary of the LGPL
Andreas Barth said on Wed, May 12, 2004 at 11:15:06AM +0200,: For me, I want the LGPL for a very simple reason on this web page: It's quite often used (even so often that it is stored in /usr/share/common-licenses), and I think that on our web page we should not only have the quite new licenses, but also the old stuff. So just say that Debian policy is to put licences x, y, and z at such-and-such place because so many packages in Debian are licensed under those licenses by the respective copyright holders. `Approved DFSG-free' is a tag we cannot easily remove, and as (my very short) experience shows, new issues may crop up. Moreover, what is `DFSG free' is the package(*), and copyright holder(s)' interpretation of the license. (*) So that packages requiring Sun/Blackdown java go into contrib -- Those willing to give up a little liberty for a little security deserve neither security nor liberty
Re: databases not copyrightable in the USA (was: CA certificates)
Branden, in Brasil, the copyrights law (9610/98) makes databases copyrighted, IF and only if their selection, organization, or the disposition of their content is a novel intellectual creation. The CDDB, for example, would not be covered by this definition (its selection, organization and disposition content are automatically-generated). CA certificates (the original topic) aren't covered either because they are not novel intellectual creations (they also are automatically-generated). In another topic, I prefer the term copyrighted. Copyrightable is an ugly, ugly term... and everything that is copyrightable is copyrighted by default... -- br,M -- http://www.fastmail.fm - The way an email service should be
Re: The draft Position statement on the GFDL
On Wed, May 12, 2004 at 12:31:47AM -0400, Glenn Maynard wrote: Of course it does. You claimed, as far as I can tell, that the GPL's requirement that derived works be available under the GPL's terms is a restriction on modification; I explained that this is explicitly allowed by the latter part of DFSG#3. And I explained that your logic only applied to the parts which were not licensed under the GPL -- not to the parts that are. Anyways, there's another aspect to the GPL where it imposes a requirement that modification be restricted. It requires that the license document be provided with the licensed program, and forbids modifications to the license document. -- Raul
copyrightable vs. copyrighted (was Re: databases not copyrightable in the USA)
Humberto Massa [EMAIL PROTECTED] writes: In another topic, I prefer the term copyrighted. Copyrightable is an ugly, ugly term... and everything that is copyrightable is copyrighted by default... I see a fine distinction between the two terms. For example, a work created by the U.S. government is not copyrighted. It may, however, be copyrightable, i.e. if another entity had created it, this entity would have had the copyright w.r.t. the work. (IANAL, IANADD) Martin
Re: copyrightable vs. copyrighted
Martin Dickopp [EMAIL PROTECTED] writes: Humberto Massa [EMAIL PROTECTED] writes: In another topic, I prefer the term copyrighted. Copyrightable is an ugly, ugly term... and everything that is copyrightable is copyrighted by default... I see a fine distinction between the two terms. For example, a work created by the U.S. government is not copyrighted. What about works by the CIA? Is copyright irrelevant to classified material? -- Måns Rullgård [EMAIL PROTECTED]
Re: The draft Position statement on the GFDL
Raul Miller [EMAIL PROTECTED] writes: My copy of the DFSG does not say The license must allow all modifications and derived works, ... True, though it's hard to argue that was not actually the intended meaning of what was written, I think. But granted, it is possible. The issue I've been addressing is the distinction between what the DFSG actually says, and how it is interpreted. That's a feature, not a bug. Or, perhaps I should say that the fact that we're explicit about that is a feature rather than a bug, since that's a characteristic fundamental to language and not really unique to the DFSG. We just acknowledge the fact and work with it, rather than papering over it with a lot of pointless verbiage. A similar issue (the distinction between guidelines like the DFSG and a definition like the OSD, and that d-l believes that a definition of Free just Doesn't Work(tm)) has been discussed in quite a lot of detail. The interpretive process is part and parcel of the DFSG. We have a sort of case history (though only lately being formalized), various principles that we apply, etc. The Debian Free Software Guidelines are a fluid and flexible process for determining the freeness of a work. The document with the same title describes and directs that process, but isn't itself the process. What it actually says isn't enough for our purposes -- you could say it's too tolerant of licensing problems. Unfortunately, the way that we express how it's interpreted is also inadequate -- what we say we do is actually less tolerant than what we actually implement. There's too many corner cases. If a particular corner case is significant enough or causes a lot of controversy, it's probably worth explicitly eliminating via a GR that modifies the DFSG. But it's important that we not throw up our hands and say Ahh! Corner case! whenever we find one, because we'd be making GR's all the time. Especially given all the nit-picking we have here; we'd likely need a GR for every license decision. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: reiser4 non-free?
Brian Thomas Sniffen [EMAIL PROTECTED] writes: Jeremy Hankins [EMAIL PROTECTED] writes: Brian Thomas Sniffen [EMAIL PROTECTED] writes: In other words, some works under this license are free (for example, one containing no credits but the copyright notice) and others are non-free. Wouldn't such a work still be non-free? At the least, it definitely goes much farther than the analogous clause in the GPL. You can't include code (even optionally executed code) to suppress it, for example. If there are no credits, the prohibition on removing credits is null. Yes, but there's still the format placement of the copyright notice. E.g., the fact that it's printed regardless of input and interactivity. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: right of publicity, or why no-advertising clauses are not necessary
On Wed, May 12, 2004 at 03:54:32AM -0500, Branden Robinson wrote: | For what it's worth, I think the NetBSD Foundation has already reached | this conclusion, which is why they use a 2-clause form of the BSD | license, with both the compelled-advertising and no-advertising clauses | removed. Actually, the vote to remove clause 3 (advertising), or clauses 2 (documentation) 3 (advertising), did not obtain a majority, so the NetBSD Foundation license is still the classic 4 clause BSD. Other BSD groups may have decided to drop clause 3 (advertising) and clause 4 (no endorse) from their proposed licenses. Note that other organisations have contributed code to NetBSD under what's effectively a clause 1 4 license, which is considered less onerous restrictions on third party binary distributors because they don't have to compile a list of copyrights for their documentation to meet clause 2 and clause 3. An example of this can be found at: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/arch/mips/sibyte/dev/sbmac.c?rev=1.19content-type=text/plain (FWIW: I understand that this should be GPL compatible) Cheers, Luke. (speaking personally, not officially for TNF) pgp4RXAQ2ONMj.pgp Description: PGP signature
Re: The draft Position statement on the GFDL
@ 11/05/2004 17:43 : wrote Raul Miller : For example: you can't take code from gcc and code from metafont and combine them to build a new compiler -- at least not under the current licenses of those programs. On Tue, May 11, 2004 at 05:00:49PM -0300, Humberto Massa wrote: It's not forbidden to make copies, just to redistribute the copies of the derived works. What's your basis for making this statement? copyright law in the US (17 USC +) AFAIK does not regulate *using* software or other copyrighted works, it regulates copying *and* redistributing. In Brazilian copyright+computer_programs law, you can make as many copies as necessary to use some software. You can combine gcc and metafont and make a new compiler; you can even make a script that combines them, apply some patch to the combination, and compiles the result to get to your invention; what you can't do is to redistribute the resulting binary nor the resulting source. Perhaps there's some part of the GPL that gives this permission which I've overlooked? If so, please quote this. section 2: 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) Let's see, eliminating the irrelevant (to our discussion) parts: [[ 2,/caput/ ]] You may modify; you may copy such modifications with all rights we waived in section 1; provided [[ 2, a ]] you mark the files as changed AND [[ 2, b is irrelevant because we are not distributing ]] AND [[ 2, c ]] you print the announcement if it exists. I said: You can modify gcc, combining it with metafont (as long as you don't eliminate 2,c announcements -- which AFAIR gcc does not have); what you can't do is ... (because the metafont license does not permit you to relicense a derived work on its source code under the GPL) Perhaps you're talking about fair use, under copyright law? Copyright law is extremely significant and, at least in the U.S., fair use doesn't extend this far. no fair use. just the terms of the licenses. Gentoo and other source-based distros do not have the OpenSSL GPL problem: when you want some GPL'd program linked to OpenSSL, it's not in their repository, but you can emerge it alright. That doesn't mean that they are following copyright law. Yes it does. Copyright IS COPY-RIGHT not, use-right. Then again, I don't imagine the copyright owners have asked them to stop, either. Because they won't, because they can't. IANAL, TINLA, but I am a paralegal and I have some knowledge about the issue. -- br,M
Re: The draft Position statement on the GFDL
@ 11/05/2004 18:23 : wrote Raul Miller : People without proper palladium licenses would not have the rights required by the gpl. On Tue, May 11, 2004 at 09:18:28PM +0100, Henning Makholm wrote: Why not? Because palladium is a proprietary work, and it's more than just an OS. But you can combine gcc with it, you can't LINK gcc with it directly... You have at least half a point here. Derived works... are you implying that if you integrate gcc better with Palladium you will make the new-gcc a derived work of Palladium? This is not necessarily true. Brazilian copyright law (9610/98) definition of derived work: the work achieved by some transformation of the original work, but is a novel intellectual creation in (and by) itself. Is new-gcc result of a transformation on palladium? no, I don't think so. (Remember Brazilian law is strongly influenced by Berne convention, and similar terms are in copyright law in various other jurisdictions of Debian interest). I'll grant that if the changes were limited to what was required to get the OS to support it, that would probably be distributable. But that's not the kind of example I was proposing. I was not proposing make gcc work on that OS, I was proposing functional modifications to GCC to make it integrate better with that environment. It still won't make the new-gcc a derived work on that environment. As a rough idea, imagine if gcc were made to support special keywords or control files to make it easier to build programs which use palladium's proprietary encryption and digital rights management facilities object model. Or, more generally, imagine any change which makes gcc into something that works in a proprietary fashion. What you are supposing is something that was done once in the form of __near and __far pointers; you did not clarify what you call work in a proprietary fashion. Describe this to me, please, as I can be overlooking something. If you can, give some example of modification that would trigger unGPLrightness in a modified gcc. -- br,M
Re: The draft Position statement on the GFDL
@ 11/05/2004 19:52 : wrote Josh Triplett : With GPLed works, for example, we have the right to make any derived work we want, as long as it is under the GPL, so the GPL satisfies DFSG3. This is not technically correct. You can make any derived work you want, EXCEPT: if it rips (C) notices, all modifications must be marked, any interactive-credits-printing must be preserved (section 2 of the GPL). Those mods are prohibited even if you're not gonna distribute. If you distribute the derived work, you MUST do so under the same license, which is the GPL of course. -- br,M
Re: The draft Position statement on the GFDL
@ 11/05/2004 20:32 : wrote Raul Miller : On Tue, May 11, 2004 at 05:37:51PM -0400, Glenn Maynard wrote: The GPL doesn't care what kinds of changes you make (with very limited exceptions, such as the license blurb). Only if the resulting work (including the implementation of the support for those keywords) is distributable under the terms of the GPL. Now it's me... I can't find *this* in the GPL at all. What I can find is, if you modify, you should 2 /caput/, 2(a), 2(b), AND 2(c)... -- br,M
Re: The draft Position statement on the GFDL
@ 11/05/2004 20:55 : wrote Raul Miller : Of course for copyright purposes it might be reasonable to say that the painting and the notice together are contained in the work. Similarly, I could hand you a book and tell you that I license to you all my rights in that book under the terms of the GPL, and the GPL would apply. And if you lied? Or changed your mind? Or if I lied? How could a judge know that I wasn't lying when I tell him you said it was a GPLed work? google: estoppel -- br,M
Re: The draft Position statement on the GFDL
@ 12/05/2004 00:02 : wrote Raul Miller : I don't think you understand what copyright law allows you to do in the absence of explicit permission. As of USC 17, I don't, granted, by as of Leis 9.609/98 and 9.610/98 (Brazilian computer programs law, and author's rights law, respectively, and case law), *I* *do*: you can make any copies necessary in the course of the normal use of the computer program (or else the license would have to regulate copies from CD to HD, from HD to SDRAM, from SDRAM to cache L2, from cache L2 to cache L1, from cache L1 to instruction register, and so on...) Different tangent. In the paladium gcc tangent, it was section 2 that would not have been followed. Which item would not have been followed? -- br,M
Re: Draft Debian-legal summary of the LGPL
Branden Robinson wrote: On Tue, May 11, 2004 at 10:06:31PM +0200, Andreas Barth wrote: Hi, though LGPL is quite OLD, AFAICS there is no summary. To put it on the web pages, I wrote one: Debian-legal has concluded that the LGPL (Library Gnu Public License) v2 and LGPL (Lesser Gnu Public License) v2.1 is a DFSG-free license. The licenses are included on every debian system in /usr/share/common-licenses, so I ommited the full reference I think your intentions are noble, but I don't think we should do this. Not because the LGPL doesn't deserve a summary, but because it hasn't been done right. The entire license needs to be posted and carefully scrutinized. For that matter, the same applies to the currently-posted summary of the GPL. At the moment, the summary just states that the GPL passes the DFSG because it is explicitly listed in DFSG 10. It would be highly preferable to compare the GPL against DFSG 1-9 as if 10 wasn't there, as a consistency check: we don't want 10 to act as an exception to the rest of the DFSG, only as an example of some licenses that pass the rest of the DFSG. Furthermore, it might be wise if we only attempt to adjudicate licenses that are brought to us for consideration. I'm not sure we should go on hunts for licenses to audit ourselves; to do so might damage the impression of impartiality that we should attempt to cultivate and live up to. Agreed, except that we should, at some point, review and summarize all existing licenses used for software in Debian. - Josh Triplett
GPL: for this list's review and pleasure
Massa's little trying-to-be-comprehensive study about the GPL.
(C) Humberto Massa 2004
This essay is hereby licensed to the reader, granting full rights of
modification and redistribution, provided (1) every derived work
maintain my copyright notice, (2) the original title is mentioned in
every derived work and (3) every derived work is distributed under this
same license.
THE THING
Rights granted from an author to an licensee when the former licenses
under the GPL some work to the latter or to a redistributing third
party, who then passes it on to the licensee:
1. making verbatim copy of source code (§ 1, caput, You may...),
SUBJECT TO carrying along the copyright notice, disclaimer, and a copy
of the license, (provided...) SUBJECT TO not imposing any further
restrictions on the recipients' excercise of the rights the license
grants to him (§ 6, You may not impose...)
2. distributing everything covered by [1] above (You may copy and
distribute...)
3. charging a fee for the physical copy (§ 1, paragraph, You may
charge...)
4. offer warranty protection for a fee (you may at your option...)
5. modifying any portion of the program THUS making a derived work, (§
2, caput, You may modify...), SUBJECT TO causing modified files to
carry notices of changing (§ 2, (a), You must...) AND IF there is an
interactive announcement with copyright notice and/or disclaimer in the
original work, your derived work MUST print the said announcement (§ 2,
(c), If the modified...)
6. distributing any derived works covered by [5] above, (§ 2, (b), You
must cause any work...) SUBJECT TO licensing your modifications to all
third parties under the GPL (to be licensed...)
7. licensing under any license you want parts of your modifications
covered by [5] (and [6]) above (§ 2, 1st paragraph, If
identifiable...), THOSE PARTS which can be reasonably considered
independent and separate works in themselves, i.e., not derived works
from the original work; SUBJECT TO distributing such parts separately
(But when you...)
8. aggregating in the same storage or distribution medium non-derived
works under other, unspecified, licenses (§ 2, 3rd paragraph, In
addition, mere aggregation...)
9. copy the original work in executable or object code form, (§ 3,
caput, You may copy...), SUBJECT TO: accompanying it with the source
(§ 3, (a), ...it with the complete... OR offering to send the source
for a non-profit charge valid for 3 years (§ 3, (b), ...it with a
written...) OR IF you received the program in executable/object code
form AND are redistributing it non-commercially, accompanying it with
the information as to the referred offer you received (§ 3, (c), ...it
with the information...) OR IF the executable/object code is being
distributed by accessing and copying from a determinated place, is
offered access to the source code from the same place (§3, 2nd
paragraph, If distribution...)
10. apply the terms of [9] to modified/derived works covered by [5] and
[6] (§3, caput, (or a work based on it, under section 2))
11. disclaim warranties on your derived works, as they are disclaimed in
the text of the GPL.
ALL THIS RIGHTS ARE SUBJECT TO: no conditions being imposed to the
licensee that contradicts the conditions of the GPL (the SUBJECT TO
clauses here and in [1] to [11] above) or that excuses some of the
conditions (§ 7, caput, If, as a consequence...)
WHY IS THE REST OF THE GPL NOT IN THE STUDY?
- §§ 1, 2, 3 are covered
- § 4 talks about how the GPL terminates itself
- § 5 explains why and in which circunstances the licensee is accepting
the terms of the license
- § 6 is covered; the license transfer clause is indicated in the
heading of the study items; the no more restrictions clause is here
AND IT INVALIDATES LICENSES THAT COMBINE THE GPL WITH MORE
RESTRICTIONS; all works such licensed are undistributable by anyone
but the original copyright holder
- § 7, caput, is covered
- § 7, 1st paragraph is a balance of section clause
- § 7, 2nd paragraph and 3rd paragraph are explanations
- § 8 gives the original work copyright holder the ability to add ONLY
ONE TYPE OF RESTRICTION in combination with the GPL: the geographic
restriction, SUBJECT BY there is already a restriction on the
distribution of the work for the part of the restricted countries
- § 9 and paragraphs say you can license your work GPL version X or
later
- § 10 explain how to proceed to combine different-licensed works
- §§ 11 and 12 are the warranty disclaimer
QUICK ALGORITHMIC APPROACH TO READING THE GPL AND THIS STUDY:
bool can_i_do(something) {
if( copyright_law_grants_me_the_right_of(something) )
return true;
if( is_in_rights_granted_from_1_to_11_above(something)
the_SUBJECT_TO_clauses_are_satisfied_by(something) )
return true;
return false;
}
2004.May.12 @ Brasil, MG, Belo Horizonte
Re: copyrightable vs. copyrighted
On Wed, 12 May 2004, Måns Rullgård wrote: What about works by the CIA? They're certainly not copyrighted... Is copyright irrelevant to classified material? Well, considering that unauthorized distribution of copyrighted material is either a misdemeanor or a felony, and according to my consp^Wgovernment manual, unauthorized distribution of top secret compartmentalized material is a black heli^W^Wtreasonable offense, I'd say yes. Don Armstrong -- It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject? -- Robert Fisk http://www.donarmstrong.com http://rzlab.ucr.edu
breezy
Denis Hutton,` The [EMAIL PROTECTED] will all0w you to receive all the [EMAIL PROTECTED] that you 0rder with your remote contr0l,* payperviews,XXX-movies,sp0rt events,special-events%,RND_SYB http://www.8009hosting.com/cable/ koenigsberg ,crewmen ,ira ,yea .
Re: The draft Position statement on the GFDL
On Wed, May 12, 2004 at 11:32:59AM -0300, Humberto Massa wrote: You have at least half a point here. Derived works... are you implying that if you integrate gcc better with Palladium you will make the new-gcc a derived work of Palladium? That is specifically the kind of work I wanted to talk about. Palladium is a secondary issue -- a place holder -- and was mentioned because of some vaporware claims about it, not because of anything specific and concrete. Brazilian copyright law (9610/98) definition of derived work: the work achieved by some transformation of the original work, but is a novel intellectual creation in (and by) itself. Is new-gcc result of a transformation on palladium? no, I don't think so. (Remember Brazilian law is strongly influenced by Berne convention, and similar terms are in copyright law in various other jurisdictions of Debian interest). I'm specifically talking [well, trying to talk] about works which would be a transformation on palladium. -- Raul
Re: The draft Position statement on the GFDL
On Tue, May 11, 2004 at 05:37:51PM -0400, Glenn Maynard wrote: The GPL doesn't care what kinds of changes you make (with very limited exceptions, such as the license blurb). @ 11/05/2004 20:32 : wrote Raul Miller : Only if the resulting work (including the implementation of the support for those keywords) is distributable under the terms of the GPL. On Wed, May 12, 2004 at 11:42:45AM -0300, Humberto Massa wrote: Now it's me... I can't find *this* in the GPL at all. What I can find is, if you modify, you should 2 /caput/, 2(a), 2(b), AND 2(c)... Section 2 allows you to make copies under the terms of section 1, which requires an appropriate license. The GPL has some specific requirements on licenses. The work as a whole would included GPL licensed software. And, just about everything you do with a computer involves making copies. [Yes, I'm aware that some copyright laws make special provisions for some of these copies -- but that's not a license issue.] -- Raul
Re: The draft Position statement on the GFDL
Raul Miller wrote: (Deep attributions snipped in previous messages) You can combine gcc and metafont and make a new compiler; you can even make a script that combines them, apply some patch to the combination, and compiles the result to get to your invention; what you can't do is to redistribute the resulting binary nor the resulting source. Perhaps there's some part of the GPL that gives this permission which I've overlooked? If so, please quote this. section 2: 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: And how would this part of the terms of Section 1 be satisfied in this case: ...provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License.. By your words this case above, are you referring to the above-quoted discussion of combining gcc and metafont? Based on your next (quoted below) paragraph, I must assume you are. What does keeping copyright notices, warranty disclaimers and references to this license have to do with combining GCC and metafont? Are you suggesting that no possible combination of GCC and metafont can be labeled with conspicuous and appropriate notices? Alternatively, how are you combining gcc and metafont without making a copy of the software which combines gcc and metafont? Section 2 grants you a license to create derivative works. While not explicitly granting permission to copy (just copy, not copy and distribute), without that permission, there can be no derivative works. Since the entire point of the GPL is to encourage derivative works, any reading of the GPL which does not allow derivative works is clearly erroneous. Let's see, eliminating the irrelevant (to our discussion) parts: [[ 2,/caput/ ]] You may modify; you may copy such modifications with all rights we waived in section 1; provided [[ 2, a ]] you mark the files as Slow down, are you saying section 1 is irrelevant, or that you've satisfied its terms? The terms of section 1 are satisfied by conspicuously and appropriately keeping certain notices intact. I said: You can modify gcc, combining it with metafont (as long as you don't eliminate 2,c announcements -- which AFAIR gcc does not have); If you can put appropriate copyright notices on it, sure. I'm not sure how you're going to so this, but I'm sure you'll clear that up for me. Change line 1 of gcc/src/main.c to #include metafont/includes/includeme.h. That's a (rather trivial) combination of the two programs. All of the requirements for section 2 are met (as long as you don't distribute the resulting combined work). All of the requirements for permission for section 1 are also met. --Joe
Re: The draft Position statement on the GFDL
Raul Miller wrote: On Wed, May 12, 2004 at 03:25:16AM +0100, Henning Makholm wrote: No. If I create any variation of the context, then the statement immediately stops being true when placed in the variated context. Except that you can easily create varied contexts where the statement is true. Here's another example of how this sentence that bothers you so much can be made to be true: send the FSF $1 dollar for their permission to print the book. No. That would have nothing to do with the factual correctness of the claim that the FSF publishes copies. That also has several solutions -- become a part of the FSF, or provide a disclaimer describing the issue. None of those solve the problem of making the license Free. That said, is this statement one that's in use on any books provided by the FSF? I'd be much happier discussing this statement if I could read it. From the GCC manual at http://gcc.gnu.org/onlinedocs/gcc/ : This file documents the use of the GNU compilers. Published by the Free Software Foundation 59 Temple Place - Suite 330 Boston, MA 02111-1307 USA Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc. 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 the Invariant Sections being GNU General Public License and Funding Free Software, the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the section entitled GNU Free Documentation License. (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. - Josh Triplett
Re: The draft Position statement on the GFDL
Raul Miller wrote: (Deep attributions snipped in previous messages) You can combine gcc and metafont and make a new compiler; you can even make a script that combines them, apply some patch to the combination, and compiles the result to get to your invention; what you can't do is to redistribute the resulting binary nor the resulting source. Perhaps there's some part of the GPL that gives this permission which I've overlooked? If so, please quote this. section 2: 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: And how would this part of the terms of Section 1 be satisfied in this case: ...provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License.. On Wed, May 12, 2004 at 09:42:42AM -0600, Joe Moore wrote: By your words this case above, are you referring to the above-quoted discussion of combining gcc and metafont? Yes. Based on your next (quoted below) paragraph, I must assume you are. What does keeping copyright notices, warranty disclaimers and references to this license have to do with combining GCC and metafont? The license on GCC specifically disallows copy rights when the work as a whole includes portions licensed under the metafont license. Are you suggesting that no possible combination of GCC and metafont can be labeled with conspicuous and appropriate notices? Yes -- well... not without some exceptional effort (for example: changing the license on metafont might make an appropriate notice possible). Alternatively, how are you combining gcc and metafont without making a copy of the software which combines gcc and metafont? Section 2 grants you a license to create derivative works. While not explicitly granting permission to copy (just copy, not copy and distribute), without that permission, there can be no derivative works. Since the entire point of the GPL is to encourage derivative works, any reading of the GPL which does not allow derivative works is clearly erroneous. This looks like a quantifier issue. The GPL is designed to encourage the creation of derivative works, but that does not include derivative works where GPL copyright is not granted to everyone. Let's see, eliminating the irrelevant (to our discussion) parts: [[ 2,/caput/ ]] You may modify; you may copy such modifications with all rights we waived in section 1; provided [[ 2, a ]] you mark the files as Slow down, are you saying section 1 is irrelevant, or that you've satisfied its terms? The terms of section 1 are satisfied by conspicuously and appropriately keeping certain notices intact. This doesn't answer the question. I said: You can modify gcc, combining it with metafont (as long as you don't eliminate 2,c announcements -- which AFAIR gcc does not have); If you can put appropriate copyright notices on it, sure. I'm not sure how you're going to so this, but I'm sure you'll clear that up for me. Change line 1 of gcc/src/main.c to #include metafont/includes/includeme.h. That's a (rather trivial) combination of the two programs. All of the requirements for section 2 are met (as long as you don't distribute the resulting combined work). Where's the appropriate copyright notice which you are supposed to prominently include? [Aside: I will agree that some copyright law allows this sort of thing -- basically making it not a copyright issue. But that's not a part of the license.] -- Raul
Re: The draft Position statement on the GFDL
That also has several solutions -- become a part of the FSF, or provide a disclaimer describing the issue. On Wed, May 12, 2004 at 11:09:01AM -0700, Josh Triplett wrote: None of those solve the problem of making the license Free. Correct -- at the other end of this thread were some criticisms I had made on the factual accuracy of a document discussing GFDL issues. That said, is this statement one that's in use on any books provided by the FSF? I'd be much happier discussing this statement if I could read it. ... Josh Triplett quotes: Copies published by the Free Software Foundation raise funds for GNU development. Ah, thank you. Since this statement is conditional (it talks about the disposition of funds for the case where copies are sold by the FSF), I think it's pretty clear that it's accurate even before any copies have been sold by anyone. This means much of my previous commentary in this thread was rather pointless. -- Raul
Re: The draft Position statement on the GFDL
@ 12/05/2004 14:36 : wrote Raul Miller : In Brazilian copyright+computer_programs law, you can make as many copies as necessary to use some software. That's specific to that jurisdiction, not a part of a license. I said it in other post: Brazilian law is modelled closed on the Berne convention; possibly other jurisdictions have similar dispositions. And how would this part of the terms of Section 1 be satisfied in this case: ...provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License.. Alternatively, how are you combining gcc and metafont without making a copy of the software which combines gcc and metafont? Why would you want to do that? Let's see, step-by-step: 1. I get gcc's sources; 1. (a) I have a valid license to it; 2. I get metafont sources; 2. (a) I also have a valid license to this; -- up to this point, no license violation 3. I make modifications to gcc and to metafont, taking care of : 3. (a) not removing any copyright (C) notices -- they are already there, I don't need to put them, I received gcc under the terms of the GPL, with the notices, and the disclaimer (as to satisfy GPL#1); 3. (b) marking the changed files as changed as to satisfy GPL#2, 'a'; 3. (c) gcc does not have the announcement in GPL#2, 'c', so nothing else is required; 3. (d) I will take appropriate similar precautions stated in metafont's license (OPL?) in making the modifications to metafont's files; -- up to this point, no license violation 4. I will write my files needed to integrate both, taking all the necessary precautions 3 a-d above. Notice that probably my files (unless completely unrelated) are derived works both of metafont and of gcc. -- no license violation. 5. I will diff the sources from the resulting program with the original sources -- no license violation. 6. I will write a script that like this: mkdir ~/metagcc; chdir ~/metagcc wget $PATH_TO_GCC_SOURCES tar xzvf $GCC_SOURCES wget $PATH_TO_METAFONT_SOURCES tar xzvf $METAFONT_SOURCES patch -p1 ../../metagcc.patch make all test install clean -- no license violation End of story. Let's see, eliminating the irrelevant (to our discussion) parts: [[ 2,/caput/ ]] You may modify; you may copy such modifications with all rights we waived in section 1; provided [[ 2, a ]] you mark the files Slow down, are you saying section 1 is irrelevant, or that you've satisfied its terms? I had said that its terms were already satisfied. If you can put appropriate copyright notices on it, sure. I'm not sure how you're going to so this, but I'm sure you'll clear that up for me. Did I? -- br,M
Re: The draft Position statement on the GFDL
Raul Miller wrote: I said: You can modify gcc, combining it with metafont (as long as you don't eliminate 2,c announcements -- which AFAIR gcc does not have); If you can put appropriate copyright notices on it, sure. I'm not sure how you're going to so this, but I'm sure you'll clear that up for me. Change line 1 of gcc/src/main.c to #include metafont/includes/includeme.h. That's a (rather trivial) combination of the two programs. All of the requirements for section 2 are met (as long as you don't distribute the resulting combined work). Where's the appropriate copyright notice which you are supposed to prominently include? In exactly the same place(s) that it is in gcc. In the source files, in the output from --version, etc. --Joe
Re: The draft Position statement on the GFDL
That's specific to that jurisdiction, not a part of a license. On Wed, May 12, 2004 at 03:11:20PM -0300, Humberto Massa wrote: I said it in other post: Brazilian law is modelled closed on the Berne convention; possibly other jurisdictions have similar dispositions. And to some degree, any jurisdiction must have some provisions for implicitly approved copies, or it's not meaningful to distribute contemporary proprietary copyrighted computer programs. But some people have made claims that there are certain things we require of the license (such as the complete absence of restrictions on the right to create derivative works), regardless of the law. Alternatively, how are you combining gcc and metafont without making a copy of the software which combines gcc and metafont? Why would you want to do that? Perhaps I'm building a just-in-time compiler for some rendering environment. Let's see, step-by-step: 1. I get gcc's sources; 1. (a) I have a valid license to it; 2. I get metafont sources; 2. (a) I also have a valid license to this; -- up to this point, no license violation 3. I make modifications to gcc and to metafont, taking care of : 3. (a) not removing any copyright (C) notices -- they are already there, I don't need to put them, I received gcc under the terms of the GPL, with the notices, and the disclaimer (as to satisfy GPL#1); 3. (b) marking the changed files as changed as to satisfy GPL#2, 'a'; Here's where you start running into problems: GPL#2 requires you satisfy GPL#1 for the modified work, which now includes stuff you do not have the right to put under GPL's terms. The subsequent steps you've proposed do not rectify this issue. Alternatively you've not yet created a work combining both, but when you do reach that point you'll still have this issue: ... 4. I will write my files needed to integrate both, taking all the necessary precautions 3 a-d above. Notice that probably my files (unless completely unrelated) are derived works both of metafont and of gcc. -- no license violation. What are the appropriate license notices you've placed? How do they satisfy the GPL requirements about the license on the work as a whole? And then there's the copies you would need to make for test and debug purposes... Of course, if this is done in a jurisdiction where copyright isn't required for these copies then there is no issue. Also, until the author(s) of gcc do not care to act on this case then you are not going to be subject to penalties for infringement. But that's not because the GPL has granted copyright for this case. -- Raul
Re: The draft Position statement on the GFDL
On Wed, May 12, 2004 at 10:18:04AM -0600, Joe Moore wrote: In exactly the same place(s) that it is in gcc. In the source files, in the output from --version, etc. Has metafont been put under the GPL? I hadn't realized that. In that case, I need to find another example. Unfortunately, I'm having network problems right now, so have limited search capabilities. -- Raul
Re: The draft Position statement on the GFDL
Humberto Massa wrote: 1. I get gcc's sources; 1. (a) I have a valid license to it; 2. I get metafont sources; 2. (a) I also have a valid license to this; -- up to this point, no license violation 3. I make modifications to gcc and to metafont, taking care of : 3. (a) not removing any copyright (C) notices -- they are already there, I don't need to put them, I received gcc under the terms of the GPL, with the notices, and the disclaimer (as to satisfy GPL#1); 3. (b) marking the changed files as changed as to satisfy GPL#2, 'a'; 3. (c) gcc does not have the announcement in GPL#2, 'c', so nothing else is required; 3. (d) I will take appropriate similar precautions stated in metafont's license (OPL?) in making the modifications to metafont's files; -- up to this point, no license violation 4. I will write my files needed to integrate both, taking all the necessary precautions 3 a-d above. Notice that probably my files (unless completely unrelated) are derived works both of metafont and of gcc. -- no license violation. 5. I will diff the sources from the resulting program with the original sources This diff is a derived work of your program and the original sources. -- no license violation. 6. I will write a script that like this: mkdir ~/metagcc; chdir ~/metagcc wget $PATH_TO_GCC_SOURCES tar xzvf $GCC_SOURCES wget $PATH_TO_METAFONT_SOURCES tar xzvf $METAFONT_SOURCES patch -p1 ../../metagcc.patch metagcc.patch is a derived work of your metagcc, which is a derived work of both gcc and metafont, so you cannot distribute metagcc.patch unless it satisfies the terms of gcc's license and metafont's license. Even if that is not the case, wouldn't this script constitute contributory infringement? make all test install clean -- no license violation End of story. - Josh Triplett
Re: GPL: for this list's review and pleasure
I have made some changes: -- begin version 2 Massa's little trying-to-be-comprehensive study about the GPL. © Humberto Massa 2004 This essay is hereby licensed to the reader, granting full rights of modification and redistribution, provided every derived work of it does: (1) maintain my copyright notice intact and positioned near to the top of the text AND (2) mentions the original title AND (3) is distributed under this same license. THE THING Rights granted from an author to an licensee when the former licenses under the GPL some work to the latter or to a redistributing third party, who then passes it on to the licensee: 1. making verbatim copy of source code (#1, caput, You may...), SUBJECT TO carrying along the copyright notice, disclaimer, and a copy of the license, (provided...) SUBJECT TO not imposing any further restrictions on the recipients' excercise of the rights the license grants to him (#6, You may not impose...) 2. distributing everything covered by [1] above (#1, caput, You may copy and distribute...) 3. charging a fee for the physical copy (#1, paragraph, You may charge...) 4. offer warranty protection for a fee (you may at your option...) 5. modifying any portion of the work THUS making a derived work, (#2, caput, You may modify...), SUBJECT TO causing modified files to carry notices of changing (#2, 'a', You must...) AND IF there is an interactive announcement with copyright notice and/or disclaimer in the original work, your derived work MUST print the said announcement (#2, 'c', If the modified...) 6. distributing any derived works covered by [5] above, (#2, 'b', You must cause any work...) SUBJECT TO licensing your modifications to all third parties under the GPL (to be licensed...) 7. licensing under any license you want parts of your modifications covered by [5] (and [6]) above (#2, 1st paragraph, If identifiable...), THOSE PARTS which can be reasonably considered independent and separate works in themselves, i.e., not derived works from the original work; SUBJECT TO distributing such parts separately (But when you...) 8. aggregating in the same storage or distribution medium non-derived works under other, unspecified, licenses (#2, 3rd paragraph, In addition, mere aggregation...) 9. copy the original work in executable or object code form, (#3, caput, You may copy...), SUBJECT TO: accompanying it with the source (#3, 'a', ...it with the complete...) OR offering to send the source for a non-profit charge valid for 3 years (#3, 'b', ...it with a written...) OR IF you received the work in executable/object code form AND are redistributing it non-commercially, accompanying it with the information as to the referred offer you received (#3, 'c', ...it with the information...) OR IF the executable/object code is being distributed by accessing and copying from a determinated place, is offered access to the source code from the same place (#3, 2nd paragraph, If distribution...) 10. apply the terms of [9] to modified/derived works covered by [5] and [6] (#3, caput, (or a work based on it, under section 2)) 11. disclaim warranties on your derived works, as they are disclaimed in the text of the GPL. ALL THESE RIGHTS ARE SUBJECT TO: no conditions being imposed to the licensee that contradicts the conditions of the GPL (the SUBJECT TO clauses here and in [1] to [11] above) or that excuses some of the conditions (#7, caput, If, as a consequence...) WHY IS THE REST OF THE GPL NOT IN THE STUDY? - #0 just describes what is the scope of the license, or to which works it applies, and what actions it covers - ## 1, 2, 3 are covered - #4 talks about how the GPL terminates itself - #5 explains why and in which circunstances the licensee is accepting the terms of the license - #6 is covered; the license transfer clause is indicated in the heading of the study items; the no more restrictions clause is here AND IT INVALIDATES LICENSES THAT COMBINE THE GPL WITH MORE RESTRICTIONS; all works such licensed are undistributable by anyone but the original copyright holder - #7, caput, is covered - #7, 1st paragraph is a balance of section clause - #7, 2nd paragraph and 3rd paragraph are explanations - #8 gives the original work copyright holder the ability to add ONLY ONE TYPE OF RESTRICTION in combination with the GPL: the geographic restriction, SUBJECT BY there is already a restriction on the distribution of the work for the part of the restricted countries. Notice that combining additional restrictions with the GPL renders a work undistributable by anyone but the copyright holder - #9 and paragraphs say you can license your work GPL version X or later - #10 explain how to proceed to combine different-licensed works - ##
Re: The draft Position statement on the GFDL
@ 12/05/2004 15:39 : wrote Raul Miller :
But some people have made claims that there are certain things we
require of the license (such as the complete absence of restrictions
on the right to create derivative works), regardless of the law.
hmmm. In this, I side with you.
Let's see, step-by-step: 1. I get gcc's sources; 1. (a) I have a
valid license to it; 2. I get metafont sources; 2. (a) I also have
a valid license to this; -- up to this point, no license violation
3. I make modifications to gcc and to metafont, taking care of :
3. (a) not removing any copyright (C) notices -- they are already
there, I don't need to put them, I received gcc under the terms of
the GPL, with the notices, and the disclaimer (as to satisfy
GPL#1); 3. (b) marking the changed files as changed as to satisfy
GPL#2, 'a';
Here's where you start running into problems: GPL#2 requires you
satisfy GPL#1 for the modified work, which now includes stuff you do
not have the right to put under GPL's terms.
yeah, but as I did not redistribute (licensing/sublicensing) my derived
work yet, so I'm not in trouble ...
The subsequent steps you've proposed do not rectify this issue.
Alternatively you've not yet created a work combining both, but when
you do reach that point you'll still have this issue:
...
4. I will write my files needed to integrate both, taking all the
necessary precautions 3 a-d above. Notice that probably my files
(unless
completely unrelated) are derived works both of metafont and of
gcc. -- no license violation.
What are the appropriate license notices you've placed? How do they
They are not appropriate LICENSE notices, they are COPYRIGHT notices:
Copyright (C) 1991-2004 FSF
Copyright (C) 1997-2004 LaTeX whatever made metafont
Copyright (C) 2004 Humberto Massa, integration work of gcc and metafont
the result of this is undistributable, for the licenses are incompatible;
however, you can use my script at http://humbertomassa.org/makemetagcc.sh
to produce a similar copy.
All rights reserved
satisfy the GPL requirements about the license on the work as a
whole?
GPL#2(b) only applies to distribution. I'll quote it to you, again:
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
with emphasis in any work that you distribute or publish.
And then there's the copies you would need to make for test and debug
purposes...
those are ok.
Of course, if this is done in a jurisdiction where copyright isn't
required for these copies then there is no issue. Also, until the
It is not the case that copyright isn't required, is more accurately:
once you have a valid license to a piece of software, the copies
involved in its use are fair game.
author(s) of gcc do not care to act on this case then you are not
going
In some cases, in Brasil, you can be prosecuted by the State for
copyright infringement, even if the copyright holder presses no charges.
I'm sure other jurisdictions have similar cases.
to be subject to penalties for infringement. But that's not because
the GPL has granted copyright for this case.
No, that's because there is a solid limit in what the GPL can do to take
away your freedoms. It can trade freedoms it would grant you, subject to
compliance to things, but it cannot take away from you freedoms the law
give you. Quoting myself (my post -- essay -- about the GPL of today is
inspired by my need to answer you begin 100% sure of what I am talking
about):
bool can_i_do(something) {
if( copyright_law_grants_me_the_right_of(something) )
return true;
if( is_in_rights_granted_from_1_to_11_above(something)
the_SUBJECT_TO_clauses_are_satisfied_by(something) )
return true;
return false;
}
--
br,M
Re: The draft Position statement on the GFDL
@ 12/05/2004 15:44 : wrote Raul Miller : On Wed, May 12, 2004 at 10:18:04AM -0600, Joe Moore wrote: In exactly the same place(s) that it is in gcc. In the source files, in the output from --version, etc. Has metafont been put under the GPL? I hadn't realized that. In that case, I need to find another example. No, but you don't have to abide to terms of the GPL to the derived-from-non-GPL (metafont) parts. see my other answer. Unfortunately, I'm having network problems right now, so have limited search capabilities. Please, take a look at my mini-study of the GPL, on-list, so you can make any comments there and then we can apply it here. -- br,M
Re: Draft Debian-legal summary of the LGPL
Scripsit Branden Robinson [EMAIL PROTECTED] Not because the LGPL doesn't deserve a summary, but because it hasn't been done right. The entire license needs to be posted and carefully scrutinized. Well, exactly in the LGPL case we don't need to scrutinize the entire license. We can do with noticing that any work covered by the LGPL is effectively dual-licensed with pure GPL, so the freedom of the former follows from freedom of the latter. A detailed analysis of the GPL might be an interesting exercise. But I'm afraid that it has several points where our best argument that it is free is that it is explicitly grandfathered by the DFSG. One could make a good case that our historical application of the DFSG can be approximated very closely by the rule of thumb that we accept any requirements found in the GPL (or one of the other grandfathered licenses) as free, and reject every clause that goes beyond what the DFSG requires of a distributor. Of course there are a small number of buts here - most prominently (a) the explicit patch rule in the DFSG, (b) that we traditionally accept advertising clauses, but grudgingly, and (c) that we don't require licenses to offer the written promise valid for three years option if they require co-distribution of source with binaries. Furthermore, it might be wise if we only attempt to adjudicate licenses that are brought to us for consideration. I'm not sure we should go on hunts for licenses to audit ourselves; I agree that we should not try to audit licenses that do not apply to any actual or intended Debian packages. Not that it would matter much; if somebody really wanted to use http://www.debian.org/legal as a platform for a personal vendetta against a license - and he could get d-l to agree that the license is non-free - then it would be a simple matter for him to let a proxy (or pseudonym) file an ITP and formally request a summary of the license. -- Henning Makholm Hi! I'm an Ellen Jamesian. Do you know what an Ellen Jamesian is?
Re: The draft Position statement on the GFDL
@ 12/05/2004 16:12 : wrote Josh Triplett : Humberto Massa wrote: 1. I get gcc's sources; 1. (a) I have a valid license to it; 2. I get metafont sources; 2. (a) I also have a valid license to this; -- up to this point, no license violation 3. I make modifications to gcc and to metafont, taking care of : 3. (a) not removing any copyright (C) notices -- they are already there, I don't need to put them, I received gcc under the terms of the GPL, with the notices, and the disclaimer (as to satisfy GPL#1); 3. (b) marking the changed files as changed as to satisfy GPL#2, 'a'; 3. (c) gcc does not have the announcement in GPL#2, 'c', so nothing else is required; 3. (d) I will take appropriate similar precautions stated in metafont's license (OPL?) in making the modifications to metafont's files; -- up to this point, no license violation 4. I will write my files needed to integrate both, taking all the necessary precautions 3 a-d above. Notice that probably my files (unless completely unrelated) are derived works both of metafont and of gcc. -- no license violation. 5. I will diff the sources from the resulting program with the original sources This diff is a derived work of your program and the original sources. -- no license violation. 6. I will write a script that like this: mkdir ~/metagcc; chdir ~/metagcc wget $PATH_TO_GCC_SOURCES tar xzvf $GCC_SOURCES wget $PATH_TO_METAFONT_SOURCES tar xzvf $METAFONT_SOURCES patch -p1 ../../metagcc.patch metagcc.patch is a derived work of your metagcc, which is a derived work of both gcc and metafont, so you cannot distribute metagcc.patch unless it satisfies the terms of gcc's license and metafont's license. Even if that is not the case, wouldn't this script constitute contributory infringement? Only if this is the case (if I can't distribute metagcc.patch). I don't know about metagcc license (which I think is the OPL, but I'm not certain of it). And contributory infringement is an USofA-jurisdiction-specific thing, here in Brasil there is no such entity. And I'm sure it's the case in many places. My primary tought is that: not containing gcc nor metafont code, and being on its entirety of my original copyright, EMPHASIS: being entirely *my* intellectual creation, I can license metafont.patch differently, I am the sole copyright holder to it, as I can license the script, but this can be wrong. I'll think a little bit more. The script does not seem to be a derived work on any of them. Again, all this is does not apply in the case of Gentoo/OpenSSL I mentioned: 1. take a GPL'd program that uses GNUTLS. 2. make some alterations so it now is OpenSSL compatible. 3. make the thing.ebuild that will link them at a later time. But yes, you DO have a point. Or two. -- br,M
Re: The draft Position statement on the GFDL
@ 12/05/2004 16:36 : wrote Humberto Massa : metagcc.patch is a derived work of your metagcc, which is a derived work of both gcc and metafont, so you cannot distribute metagcc.patch unless it satisfies the terms of gcc's license and metafont's license. Even if that is not the case, wouldn't this script constitute contributory infringement? I changed my mind about this. No, even in the USofA, it's not contributory infringement because the script is not helping *me* to *distribute* undistributable works. It may even be undistributable by itself, or metagcc.patch can be undistributable, but having the script and the patch, an user who runs the script is *NOT* *AT* *ALL* infringing on anybody's copyrights. The user would be just repeating the steps I did _before_ I infringed by putting the patch in someplace it could get it. It can have no legal right to use the patch, but... hmm... no, I don't think there is a problem there. But yes, you DO have a point. Or two. maybe only one, but credit where it's due. -- br,M
Re: Draft Debian-legal summary of the LGPL
@ 12/05/2004 16:33 : wrote Henning Makholm : Scripsit Branden Robinson [EMAIL PROTECTED] Not because the LGPL doesn't deserve a summary, but because it hasn't been done right. The entire license needs to be posted and carefully scrutinized. Well, exactly in the LGPL case we don't need to scrutinize the entire license. We can do with noticing that any work covered by the LGPL is effectively dual-licensed with pure GPL, so the freedom of the former follows from freedom of the latter. That is right. A detailed analysis of the GPL might be an interesting exercise. But I'm afraid that it has several points where our best argument that it is free is that it is explicitly grandfathered by the DFSG. I did today (and posted here) a somewhat detailed analysis of the GPL, not really under the DFSG pov, but under a What Are My Rights pov. Someone can use it as a starting point. However, I tried to do the same of the LGPL, and is much more convoluted, and I couldn't work it out in time. Maybe tomorrow. One could make a good case that our historical application of the DFSG can be approximated very closely by the rule of thumb that we accept any requirements found in the GPL (or one of the other grandfathered licenses) as free, and reject every clause that goes beyond what the DFSG requires of a distributor. Of course there are a small number of buts here - most prominently (a) the explicit patch rule in the DFSG, (b) that we traditionally accept advertising clauses, but grudgingly, and (c) that we don't require licenses to offer the written promise valid for three years option if they require co-distribution of source with binaries. Yeah, but if they require forced co-distribution, I understand that they are considered generally non-DFSG-free. I agree that we should not try to audit licenses that do not apply to any actual or intended Debian packages. I would go further and say we should try to audit the license that apply to actual current Debian packages. Not that it would matter much; if somebody really wanted to use http://www.debian.org/legal as a platform for a personal vendetta against a license - and he could get d-l to agree that the license is non-free - then it would be a simple matter for him to let a proxy (or pseudonym) file an ITP and formally request a summary of the license. This is true. -- br,M
Re: The draft Position statement on the GFDL
Scripsit Raul Miller [EMAIL PROTECTED] On Wed, May 12, 2004 at 03:21:53AM +0100, Henning Makholm wrote: There is nothing in the GPL that forbids functional modifications to GCC to make it integrate better with the environment. Treat palladium as a meta-syntactic variable standing for an environment where reverse engineering is illegal and where proprietary code and proprietary features are present. Treat integrate better as something which specifically requires those proprietary features. OK. Still no problem with distributing the modified GCC as long as it comes with source and under the terms of the GPL. I really don't see where you are getting at. Can you explain in little words and with lots of intermediate results why you think that a GCC modified for you hypothetical environment would be non-distributable? If it is distributed with source and under the terms of the GPL, then whatever it does is by any reasonable understandning not done in a proprietary fashion. Palladium, of course, will not be released under the terms of the GPL. No, but not necessary either. Versions of GCC have been done for *many* proprietary operating systems. Many of these versions have been folded into the code that the FSF itself distributes. In neither of these cases has it been any problem that the proprietary operating system itself is not released under the terms of the GPL. Making copies of the derived work is *not* forbidden by the GPL. You mean because it's outside the scope of the GPL? No, on the contrary. Making copies of the derived work is what the GPL is all about. It exists in order to allow me to make copies of the derived (or non-derived) work. It exists to prevent other people from taking away your right to do so. However, it accomplishes this by restricting your right to make copies if you would not grant others these rights when you did so. In this case, therefore, it does not restrict my right to distribute the hypothetical Palladium GCC, because I would give the recipient the same rights as I got myself. -- Henning Makholm What has it got in its pocketses?
Re: The draft Position statement on the GFDL
Here's where you start running into problems: GPL#2 requires you satisfy GPL#1 for the modified work, which now includes stuff you do not have the right to put under GPL's terms. On Wed, May 12, 2004 at 04:09:50PM -0300, Humberto Massa wrote: yeah, but as I did not redistribute (licensing/sublicensing) my derived work yet, so I'm not in trouble ... But you made copies, and those copies weren't a part of normal use of the software. And [U.S.] copyright law says that the owner of the copyright has the exclusive right to copy the work, and to authorize copies. What are the appropriate license notices you've placed? How do they They are not appropriate LICENSE notices, they are COPYRIGHT notices: Section 1 requires the notices of license be intact. Those notices of license mean that the work as a whole must be licensed under the terms of the GPL. satisfy the GPL requirements about the license on the work as a whole? GPL#2(b) only applies to distribution. I'll quote it to you, again: What happened to the introductory part of GPL#2? And then there's the copies you would need to make for test and debug purposes... those are ok. According to copyright law, only the owner of the copyright can authorize their creation. At least, that's the way it works in the U.S. The GPL gives you permission to make them, as long as you license the resulting work properly. Of course, if this is done in a jurisdiction where copyright isn't required for these copies then there is no issue. Also, until the It is not the case that copyright isn't required, is more accurately: once you have a valid license to a piece of software, the copies involved in its use are fair game. Ah, maybe making a derived work constitutes normal use of the program? That... would be interesting. Especially with some proprietary software. -- Raul
Re: The draft Position statement on the GFDL
On Wed, May 12, 2004 at 08:55:21PM +0100, Henning Makholm wrote: I really don't see where you are getting at. Can you explain in little words and with lots of intermediate results why you think that a GCC modified for you hypothetical environment would be non-distributable? Because it incorporates functionality implemented in proprietary code. [This would be functionality you're not legally allowed to reverse engineer.] -- Raul
Re: The draft Position statement on the GFDL
Humberto Massa wrote: @ 12/05/2004 16:12 : wrote Josh Triplett : Humberto Massa wrote: 5. I will diff the sources from the resulting program with the original sources This diff is a derived work of your program and the original sources. -- no license violation. 6. I will write a script that like this: mkdir ~/metagcc; chdir ~/metagcc wget $PATH_TO_GCC_SOURCES tar xzvf $GCC_SOURCES wget $PATH_TO_METAFONT_SOURCES tar xzvf $METAFONT_SOURCES patch -p1 ../../metagcc.patch metagcc.patch is a derived work of your metagcc, which is a derived work of both gcc and metafont, so you cannot distribute metagcc.patch unless it satisfies the terms of gcc's license and metafont's license. Even if that is not the case, wouldn't this script constitute contributory infringement? Only if this is the case (if I can't distribute metagcc.patch). I don't know about metagcc license (which I think is the OPL, but I'm not certain of it). And contributory infringement is an USofA-jurisdiction-specific thing, here in Brasil there is no such entity. And I'm sure it's the case in many places. Good to know. The first point was more important anyway. I am not particularly familiar with contributory infringement, and I was simply curious if it applied here. My primary tought is that: not containing gcc nor metafont code, and being on its entirety of my original copyright, EMPHASIS: being entirely *my* intellectual creation, I can license metafont.patch differently, I am the sole copyright holder to it, as I can license the script, but this can be wrong. I'll think a little bit more. The script does not seem to be a derived work on any of them. The script is obviously not a derived work of GCC or Metafont. However, you stated that you were taking GCC and Metafont, creating a derived work from them (which you don't distribute), diffing that derived work against the original GCC and Metafont sources (creating a patch that is derived from your previous derived work of GCC and Metafont), and distributing that patch. It seems like any such patch would have to be a derived work of both GCC and Metafont. - Josh Triplett
Re: The draft Position statement on the GFDL
@ 12/05/2004 17:12 : wrote Henning Makholm : No, but not necessary either. Versions of GCC have been done for *many* proprietary operating systems. Many of these versions have been AND operating environments, too. Like Java. Like DOS/GW or whatever were those DOS 32 bit extenders. Like Windows when Windows was not an OS (Win 3.1). folded into the code that the FSF itself distributes. In neither of these cases has it been any problem that the proprietary operating system itself is not released under the terms of the GPL. Because there is none. Among folded back features, there is __far and __near pointers and other stuff. In this case, therefore, it does not restrict my right to distribute the hypothetical Palladium GCC, because I would give the recipient the same rights as I got myself. Well said. -- br,M
Re: The draft Position statement on the GFDL
On Wed, May 12, 2004 at 08:55:21PM +0100, Henning Makholm wrote: In this case, therefore, it does not restrict my right to distribute the hypothetical Palladium GCC, because I would give the recipient the same rights as I got myself. That runs into several difficulties. One of which is that [for the purpose of this hypothesis] you had to purchase the right to develop using these palladium features. -- Raul
Re: The draft Position statement on the GFDL
Because it incorporates functionality implemented in proprietary code. On Wed, May 12, 2004 at 09:41:32PM +0100, Henning Makholm wrote: It cannot do that if it is distributed with source and under the terms of the GPL. That's what I've been saying. I still don't know what you are getting at. That there are [hypothetical] cases where you can't distribute with the all the sources, let alone sources licensed under the terms of the GPL. This can happen when there is proprietary functionality which you cannot legally reverse engineer. -- Raul
Re: The draft Position statement on the GFDL
Scripsit Raul Miller [EMAIL PROTECTED] On Wed, May 12, 2004 at 08:55:21PM +0100, Henning Makholm wrote: I really don't see where you are getting at. Can you explain in little words and with lots of intermediate results why you think that a GCC modified for you hypothetical environment would be non-distributable? Because it incorporates functionality implemented in proprietary code. It cannot do that if it is distributed with source and under the terms of the GPL. Namely, in that case all the functionality it incorporates is implemented in code that is, by any sensible definition, not proprietary. I still don't know what you are getting at. -- Henning MakholmVi skal nok ikke begynde at undervise hinanden i den store regnekunst her, men jeg vil foreslå, at vi fra Kulturministeriets side sørger for at fremsende tallene og også give en beskrivelse af, hvordan man læser tallene. Tak for i dag!
Re: Draft Debian-legal summary of the LGPL
* Henning Makholm: Well, exactly in the LGPL case we don't need to scrutinize the entire license. We can do with noticing that any work covered by the LGPL is effectively dual-licensed with pure GPL, so the freedom of the former follows from freedom of the latter. Linking with GPL-incompatible libraries could mean that we can't exercise the GPL option, so it's not that simple, I think. A detailed analysis of the GPL might be an interesting exercise. But I'm afraid that it has several points where our best argument that it is free is that it is explicitly grandfathered by the DFSG. And if the GPL fails the DFSG, that's a bug in the DFSG anyway. 8-) -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, di-ve.com, hotmail.com, jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com.
Re: The draft Position statement on the GFDL
Scripsit Raul Miller [EMAIL PROTECTED] On Wed, May 12, 2004 at 08:55:21PM +0100, Henning Makholm wrote: In this case, therefore, it does not restrict my right to distribute the hypothetical Palladium GCC, because I would give the recipient the same rights as I got myself. That runs into several difficulties. I cannot see any one. One of which is that [for the purpose of this hypothesis] you had to purchase the right to develop using these palladium features. Where does your hyphotesis say that? And in which jurisdiction can the supplier of Palladium legally forbid the third party that I give my modified GCC to (and who does not have any contractual relation with the supplier) from continuing my development work? -- Henning Makholm I tried whacking myself repeatedly with the cluebat. Unfortunately, it was not as effective as whacking someone else.
Re: The draft Position statement on the GFDL
Scripsit Raul Miller [EMAIL PROTECTED] Because it incorporates functionality implemented in proprietary code. On Wed, May 12, 2004 at 09:41:32PM +0100, Henning Makholm wrote: It cannot do that if it is distributed with source and under the terms of the GPL. That's what I've been saying. You seem to have been saying so by asserting the opposite. I still don't know what you are getting at. That there are [hypothetical] cases where you can't distribute with the all the sources, let alone sources licensed under the terms of the GPL. Of course, if I make a derivation that includes code for which I do not have copyright, I will need the copyright holder's permission to distribut the result under the GPL. However, that is completely different from the GPL not allowing me to make the modifications in the first place. This can happen when there is proprietary functionality which you cannot legally reverse engineer. If I have enough source to fulfill the requirement to distrubite with source, then I do not see how reverse engineering can be relevant to the discussion. -- Henning Makholm Nemo enim fere saltat sobrius, nisi forte insanit.
Re: The draft Position statement on the GFDL
One of which is that [for the purpose of this hypothesis] you had to purchase the right to develop using these palladium features. On Wed, May 12, 2004 at 09:51:11PM +0100, Henning Makholm wrote: Where does your hyphotesis say that? I just now stated it. I had tried to make the completely proprietary nature of the functionality clear earlier, but presumably I wasn't successful. And in which jurisdiction can the supplier of Palladium legally forbid the third party that I give my modified GCC to (and who does not have any contractual relation with the supplier) from continuing my development work? If the functionality in question is interoperation with proprietary palladium features, and if everyone who has palladium has to buy into a license that says they won't try to reverse engineer those features, what would this matter? Finally, remember that I'm talking about a hypothetical vaporware palladium which probably has little to do with the palladium product which will presumably be released in real life. -- Raul
Re: The draft Position statement on the GFDL
On Wed, May 12, 2004 at 08:24:36AM -0400, Raul Miller wrote: And I explained that your logic only applied to the parts which were not licensed under the GPL -- not to the parts that are. Your counterargument doesn't make sense. DFSG#3 requires that The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. Derived works which are under the same terms as the original software must be distributable. If you combine gcc (GPL) with libsecret.so (GPL-incompatible), the result is a derived work which is not under the same terms as the license of the original software, which is a case DFSG#3 explicitly doesn't care about. I don't see how parts enters into the equation. You're free to take the GPL parts, remove the GPL-incompatible parts and distribute them again. However, when they're combined, you have a single derived work that is not available under the original terms, and DFSG#3 does not require that such a work be distributable. I feel that I'm repeating myself. If you have a counterargument, I'll have to ask you to be more explicit. If you can't be, then we may be at a dead end due to communications problems. Anyways, there's another aspect to the GPL where it imposes a requirement that modification be restricted. It requires that the license document be provided with the licensed program, and forbids modifications to the license document. I've already discussed this at length, in my posts regarding license texts vs. license terms. (And all of this is based on the premise that the DFSG is something other than a set of guidelines which d-legal interprets, and it seems to have lost all relevance to the original GFDL discussion. None of this has any bearing on the fact that the GFDL's restrictions are not Free; nit picking all versus some will not make invariant sections and cover texts any more free. Unless we can get past what appears to be a communication problem somewhere, I may drop this subthread soon in the interests of time.) -- Glenn Maynard
Re: The draft Position statement on the GFDL
On Wed, May 12, 2004 at 09:57:28PM +0100, Henning Makholm wrote: Of course, if I make a derivation that includes code for which I do not have copyright, I will need the copyright holder's permission to distribut the result under the GPL. However, that is completely different from the GPL not allowing me to make the modifications in the first place. That's not what I was addressing. I was addressing the assertion that the GPL allows any functional modifications -- that needn't be the case when the functions are proprietary. -- Raul
middleman software license conflicts with OpenSSL
[ CC to debian-legal, Middleman ITP is bug #231953 ] Hello, middleman can't be accepted into Debian because of license conflicts. Your software is licensed under GPL, but must be linked with OpenSSL. OpenSSL is not GPL licensed but under an Apache-style licence [1], and so, unfortunately, the GPL and the OpenSSL license are incompatible [2]. There is two possible solutions to solve this problem: - your software must be rewritten to use GNUTLS instead of OpenSSL, - or, your license must add an exception to the GPL which allows linking with OpenSSL. The second solution has been choosen for the hpoj Debian package [3] (and maybe others), and what I write below is totally inspired from what has been done for the hpoj package. 1. Add the attached LICENSE file to your code. This file tells that your code is GPL, with an exception which allows linking with OpenSSL. Here is the text of the exception: *** In addition, as a special exception, the copyright holders give permission to link the code of portions of this program with the OpenSSL library under certain conditions as described in each individual source file, and distribute linked combinations including the two. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify file(s) with this exception, you may extend this exception to your version of the file(s), but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. If you delete this exception statement from all source files in the program, then also delete it here. *** 2. Add to the beginning of all of your code source files this exception statement. 3. Add the attached LICENSE.OpenSSL to your source code. I'd be glad to anwser any questions about this issue. I hope we can work together so that middleman can be soon an official Debian package. Best regards, [1] http://www.openssl.org/about/ [2] http://www.gnu.org/philosophy/license-list.html [3] http://bugs.debian.org/147430 -- Cédric Delfosse, http://cedric.freezope.org Jabber ID: [EMAIL PROTECTED] /* * (c) 2002, 2003, 2004 by Jason McLaughlin and Riadh Elloumi * * 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 * is provided AS IS, WITHOUT ANY WARRANTY; without even the implied * warranty of MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, and * NON-INFRINGEMENT. See the GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, * MA 02111-1307, USA. * * In addition, as a special exception, the copyright holders give * permission to link the code of portions of this program with the * OpenSSL library under certain conditions as described in each * individual source file, and distribute linked combinations * including the two. * You must obey the GNU General Public License in all respects * for all of the code used other than OpenSSL. If you modify * file(s) with this exception, you may extend this exception to your * version of the file(s), but you are not obligated to do so. If you * do not wish to do so, delete this exception statement from your * version. If you delete this exception statement from all source * files in the program, then also delete it here. */ Certain source files in this program permit linking with the OpenSSL library (http://www.openssl.org), which otherwise wouldn't be allowed under the GPL. For purposes of identifying OpenSSL, most source files giving this permission limit it to versions of OpenSSL having a license identical to that listed in this file (LICENSE.OpenSSL). It is not necessary for the copyright years to match between this file and the OpenSSL version in question. However, note that because this file is an extension of the license statements of these source files, this file may not be changed except with permission from all copyright holders of source files in this program which reference this file. LICENSE ISSUES == The OpenSSL toolkit stays under a dual license, i.e. both the conditions of the OpenSSL License and the original SSLeay license apply to the toolkit. See below for the actual license texts. Actually both licenses are BSD-style Open Source licenses. In case of any license issues related to OpenSSL please contact [EMAIL PROTECTED] OpenSSL License --- /* * Copyright (c) 1998-2001 The OpenSSL Project. All rights reserved. * * Redistribution and use
Re: The draft Position statement on the GFDL
On Wed, May 12, 2004 at 08:24:36AM -0400, Raul Miller wrote: And I explained that your logic only applied to the parts which were not licensed under the GPL -- not to the parts that are. On Wed, May 12, 2004 at 05:02:58PM -0400, Glenn Maynard wrote: Your counterargument doesn't make sense. DFSG#3 requires that The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. Derived works which are under the same terms as the original software must be distributable. [1] When GPL'd code is contained in a larger work, the GPL will not allow distribution of the GPLed code if the larger work has some other restrictions. [2] When you distribute GPL'd code, you must distribute the GPL license text with the code and you are not allowed to distribute modified copies of that license. If you combine gcc (GPL) with libsecret.so (GPL-incompatible), the result is a derived work which is not under the same terms as the license of the original software, which is a case DFSG#3 explicitly doesn't care about. If you distribute that work, you then lose the right to distribute GPLed code even without libsecret.so. Or, more simply, you are not allowed to copy or distribute gcc under the terms of the GPL in this circumstance. Anyways, there's another aspect to the GPL where it imposes a requirement that modification be restricted. It requires that the license document be provided with the licensed program, and forbids modifications to the license document. I've already discussed this at length, in my posts regarding license texts vs. license terms. But we are still required to distribute the license text when we distribute code under the license terms. (And all of this is based on the premise that the DFSG is something other than a set of guidelines which d-legal interprets, and it seems to have lost all relevance to the original GFDL discussion. I agree that this is a complete tangent to the GFDL discussion. None of this has any bearing on the fact that the GFDL's restrictions are not Free; The GFDL came into discussion because I posted a critic of a document discussing that license. At no point did I claim that the GFDL is free -- instead I was pointing out flaws in some arguments discussing GFDL problems. -- Raul
IBM Public License (again)
Hi. I just wanted to package a piece of software and saw that it is licensed under the IBM Public License[1] (IPL). Since the license included some suspicios clauses I searched the list archives about it. The findings were confusing: - There are many discussions (e.g. [2], [3]) about the patent clause (§7, paragraph 2) but no consensus on whether it is non-free or not. - There are statements that it is free and nobody objected[4] - On debian-legal noone ever mentioned the clause (§3, last paragraph) In addition, each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the Contribution. which seems to fail the dissident test. Has the interpretation of such clauses changed in the last years or am I misunderstanding something? [1] http://www-124.ibm.com/developerworks/oss/license10.html [2] http://lists.debian.org/debian-legal/2004/01/msg5.html [3] http://lists.debian.org/debian-legal/2004/01/msg00262.html [4] http://lists.debian.org/debian-legal/2001/12/msg00141.html Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ pgpzAIfURj7du.pgp Description: PGP signature
ASL2 and artistic compatibility
It would appear that the new upstream release of libapache2-mod-perl2 has been relicensed; from the ASL 1.1 to the ASL 2.0. As has already been discussed, the ASL (both 1.1 and 2.0) and GPL are incompatible (at least, the FSF claims they are). What has previously been used w/ modperl (1 and 2, under the ASL 1.1) has been perl's Artistic license. The question is, does the change to ASL 2.0 introduce any incompatibilities with the Artistic license? Is it safe to upgrade libapache2-mod-perl2 to the latest version? As a side note, there was a d-l thread in Feb. about the Apache group and the FSF talking about resolving their disagreement regarding the patent termination clause in the ASL 2.0 rendering both licenses incompatible. Does anyone know if an agreement has been reached?
Re: IBM Public License (again)
On 2004-05-12 22:59:18 +0100 Frank Lichtenheld [EMAIL PROTECTED] wrote: I just wanted to package a piece of software and saw that it is licensed under the IBM Public License[1] (IPL). Normally, you should include the licence text. Since the license included some suspicios clauses I searched the list archives about it. The findings were confusing: - There are many discussions (e.g. [2], [3]) about the patent clause (§7, paragraph 2) but no consensus on whether it is non-free or not. To me, it seems clearly non-free because it terminates if there is legal action against IBM about patents applicable to some other software. Regardless of what I think about software patents (I hate them), why should use of this software affect independent software I may release? We don't allow licences that try to force disclosure, why should we allow ones that try to force accepting patent infringment by IBM? It's a bit tricky to map this exactly onto the DFSG, but it seems a I can't believe this is free software candidate to me. - There are statements that it is free and nobody objected[4] Your reference is odd. Maybe it is a little quiet because, in the same month as that discussion, a similar licence is already being discussed in http://lists.debian.org/debian-legal/2001/debian-legal-200112/msg00143.html The original discussions about the IBM Public License seem to be http://lists.debian.org/debian-legal/1999/debian-legal-199905/msg00117.html and http://lists.debian.org/debian-legal/1999/debian-legal-199907/msg00012.html That looks like it was at the height of Open Source mania, which may explain why the patent licence termination clause problem was missed. As the OSI famously say, Open Source has no position on whether patents are good or bad. - On debian-legal noone ever mentioned the clause (§3, last paragraph) In addition, each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the Contribution. which seems to fail the dissident test. Has the interpretation of such clauses changed in the last years or am I misunderstanding something? It depends what is meant by identify I guess. At worst, that's a lawyerbomb. Or is there something more wrong there? -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ http://www.ttllp.co.uk/ for creative copyleft computing
Re: IBM Public License (again)
Frank Lichtenheld [EMAIL PROTECTED] wrote: Hi. I just wanted to package a piece of software and saw that it is licensed under the IBM Public License[1] (IPL). Since the license included some suspicios clauses I searched the list archives about it. The findings were confusing: - There are many discussions (e.g. [2], [3]) about the patent clause (§7, paragraph 2) but no consensus on whether it is non-free or not. - There are statements that it is free and nobody objected[4] - On debian-legal noone ever mentioned the clause (§3, last paragraph) In addition, each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the Contribution. which seems to fail the dissident test. Has the interpretation of such clauses changed in the last years or am I misunderstanding something? In addition, I noticed clause 4 has an indemnification provision Therefore, if a Contributor includes the Program in a commercial product offering, such Contributor (Commercial Contributor) hereby agrees to defend and indemnify every other Contributor (Indemnified Contributor) against any losses, damages and costs (collectively Losses) arising from claims, lawsuits and other legal actions brought by a third party against the Indemnified Contributor to the extent caused by the acts or omissions of such Commercial Contributor in connection with its distribution of the Program in a commercial product offering. The obligations in this section do not apply to any claims or Losses relating to any actual or alleged intellectual property infringement. This is much more limited than the Squeak license, because it is only for commercial distributors and only for non-IP cases. It still makes me wonder, though. Regards, Walter Landry [EMAIL PROTECTED]
Bug#248782: abuse-sfx: violation of license terms
Package: abuse-sfx Version: 2.00-8 Severity: serious Justification: Policy 2.3 To view the license terms, see the copyright file: http://packages.debian.org/changelogs/pool/non-free/a/abuse-sfx/abuse-sfx_2.00-8/copyright First off, the license only grants the right to *use* the software: For purposes of this section, use means loading the Software into RAM, as well as installation on a hard disk or other storage device. After granting this right, it then proceeds to list many things that one is *not* allowed to do: You may not: modify, translate, disassemble, decompile, reverse engineer, or create derivative works based upon the Software. You agree that the Software will not be shipped, transferred or exported into any country in violation of the U.S. Export Administration Act and that you will not utilize, in any other manner, the Software in violation of any applicable law. Nowhere does it grant permission to distribute the software. I'd say it's strongly implied by the second sentence (why would they bother specifying that distributing to T7 countries is prohibited if distribution isn't permitted at all in the first place) but, according to Policy 2.3, no distribution or modification of a work is allowed without an explicit notice saying so. An even greater worry is a clause that appears to make the Project responsible for enforcing compliance with the license terms: You agree to use your best efforts to see that any user of the Software licensed hereunder complies with this Agreement. First of all, does the Project really agree to that? If not: If you fail to comply with any terms of this Agreement, YOUR LICENSE IS AUTOMATICALLY TERMINATED. And if OTOH we *do* agree to that ridiculous condition, we are already in violation of this policeman clause due to our own policy regarding the US Export Administration Act. AIUI, the resolution of the crypto-in-main issue involved implementing reverse IP lookups on the main archive[1] and having no official mirrors in the T7 countries[2], thus showing a good-faith attempt to prevent exporting software to these so-called terrorist states. Re-exportation, e.g. via a mirror not implementing similar restrictions, would pose no legal threat to Debian proper since we would no longer be the ones doing the exporting. Unfortunately, this license would have us go even further. The Project would have to actively pressure all the mirror admins to implement similar restrictions, since the current stance of leaving the decision entirely up to them would IMO be highly unlikely to count as best efforts on our part to bring them into compliance. Needless to say, I think it'd be far easier (and more moral) just to drop this package, together with anything else that has a similarly odious clause. Thoughts, comments, critiques? I very much doubt that we can continue to distribute this in light of the above, but I'd be interested to hear what others think. [1] http://lists.debian.org/debian-legal/2002/02/msg00181.html [2] http://lists.debian.org/debian-legal/2002/02/msg00176.html -- Andrew Saunders
Re: IBM Public License (again)
MJ Ray [EMAIL PROTECTED] wrote: On 2004-05-12 22:59:18 +0100 Frank Lichtenheld [EMAIL PROTECTED] wrote: I just wanted to package a piece of software and saw that it is licensed under the IBM Public License[1] (IPL). Normally, you should include the licence text. Since the license included some suspicios clauses I searched the list archives about it. The findings were confusing: - There are many discussions (e.g. [2], [3]) about the patent clause (§7, paragraph 2) but no consensus on whether it is non-free or not. To me, it seems clearly non-free because it terminates if there is legal action against IBM about patents applicable to some other software. Regardless of what I think about software patents (I hate them), why should use of this software affect independent software I may release? We don't allow licences that try to force disclosure, why should we allow ones that try to force accepting patent infringment by IBM? It's a bit tricky to map this exactly onto the DFSG, but it seems a I can't believe this is free software candidate to me. It only terminates a patent license, not a copyright license. That just makes the license effectively mute about patents (which is true of most licenses we look at). Patents were also discussed for an Intel license [1]. Regards, Walter Landry [EMAIL PROTECTED] [1] http://lists.debian.org/debian-legal/2002/02/msg00032.html
Re: IBM Public License (again)
MJ Ray wrote: On 2004-05-12 22:59:18 +0100 Frank Lichtenheld [EMAIL PROTECTED] wrote: I just wanted to package a piece of software and saw that it is licensed under the IBM Public License[1] (IPL). Normally, you should include the licence text. Since the license included some suspicios clauses I searched the list archives about it. The findings were confusing: - There are many discussions (e.g. [2], [3]) about the patent clause (§7, paragraph 2) but no consensus on whether it is non-free or not. To me, it seems clearly non-free because it terminates if there is legal action against IBM about patents applicable to some other software. Regardless of what I think about software patents (I hate them), why should use of this software affect independent software I may release? We don't allow licences that try to force disclosure, why should we allow ones that try to force accepting patent infringment by IBM? The main difference between this clause and others debian-legal has reviewed is that the IBM Public License only terminates the _patent_ licenses granted by contributors if you sue any contributor over a software patent, while other licenses terminate the _copyright_ license if you sue over a patent. This has the effect of a patent cross-license: Don't sue us over patents and we won't sue you over patents. The only circumstance under which the _copyright_ license terminates is if you sue claiming that _the program itself_ violates your software patent. This seems perfectly reasonable, and I personally believe this license is a Free Software license. The point of many Free Software licenses is to preserve the right to use, copy, modify, and distribute the software they cover. When you sue someone over the software, you are trying to stop people from using, copying, modifying, and distributing the software (or place restrictions on doing so), so it seems only fair that you should not be allowed to do so either. - On debian-legal noone ever mentioned the clause (§3, last paragraph) In addition, each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the Contribution. which seems to fail the dissident test. Has the interpretation of such clauses changed in the last years or am I misunderstanding something? It depends what is meant by identify I guess. At worst, that's a lawyerbomb. Or is there something more wrong there? From GPL 2a: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. If you interpret stating that you changed the files as requiring an identification of who you refers to (as in who exactly changed the files?), then the GPL has the same problem. I suggest that absent information to the contrary, we should simply interpret this license to mean that you must label your contributions as coming from you as opposed to other contributors, and not that you must say exactly who you are. I feel very strongly that this is a Free Software license, by both the spirit and the letter of the DFSG. - Josh Triplett
