Re: Artistic2?
On Friday 06 May 2005 02:28, John Goerzen wrote: Hi, I recently came across ths Artistic 2 (2.0beta5) license at: http://svn.openfoundry.org/pugs/LICENSE/Artistic-2 I couldn't find any previous reference to a DFSG discussion about it. Would it be considered DFSG-free? For reference, the version I downloaded today (2005-05-06T09:58+0200) reads: --- The Artistic License Version 2.0beta5, October 2001 Copyright (C) 2000, 2001 Larry Wall, Bradley M. Kuhn. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble This copyright license states the terms under which a given free software Package may be copied, modified and/or redistributed, while the Originator(s) maintain some artistic control over the future development of that Package (at least as much artistic control as can be given under copyright law while still making the Package open source and free software). This license is bound by copyright law, and thus it legally applies only to works which the copyright holder has permitted copying, distribution or modification under the terms of the Artistic License, Version 2.0. You are reminded that You are always permitted to make arrangements wholly outside of a given copyright license directly with the copyright holder(s) of a given Package. If the terms of this license impede your ability to make full use of the Package, You are encouraged to contact the copyright holder(s) and seek a different licensing arrangement. Definitions Package refers to the collection of files distributed by the Originator(s), and derivatives of that collection of files created through textual modification. Standard Version refers to the Package if it has not been modified, or has been modified only in ways suggested by the Originator(s). Modified Version refers to the Package, if it has been changed by You via textual modification of the source code, and such changes were not suggested by the Originator(s). Originator refers to the author(s) and/or copyright holder(s) of the Standard Version of the Package. You and Your refers to any person who would like to copy, distribute, or modify the Package. Distribution Fee is any fee that You charge for providing a copy of this Package to another party. It does not refer to licensing fees. Freely Available means that: (a) no fee is charged for the right to use the item (though a Distribution Fee may be charged). (b) recipients of the item may redistribute it under the same conditions they received it. (c) If the item is a binary, object code, bytecode, the complete corresponding machine-readable source code is included with the item. Permission for Use and Modification Without Redistribution (1) You are permitted to use the Standard Version and create and use Modified Versions for any purpose without restriction, provided that you do not redistribute the Modified Version to others outside of your company or organization. Permissions for Redistribution of the Standard Version (2) You may make available verbatim copies of the source code of the Standard Version of this Package in any medium without restriction, either gratis or for a Distribution Fee, provided that you duplicate all of the original copyright notices and associated disclaimers. At Your discretion, such verbatim copies may or may not include compiled bytecode, object code or binary versions of the corresponding source code in the same medium. (3) You may apply any bug fixes, portability changes, and other modifications made available from any of the Originator(s). The resulting modified Package will still be considered the Standard Version, and may be copied, modified and redistributed under the terms of the original license of the Standard Version as if it were the Standard Version. Permissions for Redistribution of Modified Versions of the Package as Source (4) You may modify your copy of the source code of this Package in any way and distribute that Modified Version (either gratis or for a Distribution Fee, and with or without a corresponding binary, bytecode or object code version of the Modified Version) provided that You clearly indicate what changes You made to the Package, and provided that You do at least ONE of the following: (a) make the Modified Version available to the Originator(s) of the
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thursday 07 April 2005 09:25, Jes Sorensen wrote: [snip] I got it from Alteon under a written agreement stating I could distribute the image under the GPL. Since the firmware is simply data to Linux, hence keeping it under the GPL should be just fine. Then I would like to exercise my right under the GPL to aquire the source code for the firmware (and the required compilers, starting with genfw.c which is mentioned in acenic_firmware.h) since - as far as I know - firmware is coded today in VHDL, C or some assembler and the days of hexcoding are long gone. Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
On Wednesday 30 March 2005 03:53, Raul Miller wrote: Those .h files were held to be not protected by copyright because no viable alternatives were available to interface with the system. It's hard to see how this reasoning would apply in a context where there is some viable alternative available to interface with the system. I don't know the details of the case at hand, but I remember the discussion around errno.h from the TSG fallout: The basic reasoning there was, that if one wants to implement a C stdlib an a unix-like system, a optimal errno.h would always look similar to that from ancient BSD (which most modern errno.h derive from). Since there is no way to be unixish/compatible without defining the various E* to these values, having a errno.h file with the same values is not infringing. This, I believe, can be extended to all forms of compatability: If a header file with certain contents is needed to use the interface of a library, it is no copyright infringement. To be on the safe side, this has to be interpreted very strict: Non-trivial comments and inline functions are probably not covered. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Documenting License Interpretations (was: Re: GPL for documentation ?)
On Thursday 10 March 2005 23:37, Gervase Markham wrote: Don Armstrong wrote: If there really is a source for confusion, then make an addendum to the license file explaining how the author views the GPL applying to the work. I seem to remember a very recent thread on d-l saying that this sort of thing was a pain because it meant everyone's licence was different. Documenting things which can otherwise only be guessed (What does the author thought that 'linking' means for a wordlist?) can only be positive. IIRC licenses per-se cannot be free because intent of author often is relevant too - especially in gray areas. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Documenting License Interpretations (was: Re: GPL for documentation ?)
On Thursday 10 March 2005 23:37, Gervase Markham wrote: Don Armstrong wrote: If there really is a source for confusion, then make an addendum to the license file explaining how the author views the GPL applying to the work. I seem to remember a very recent thread on d-l saying that this sort of thing was a pain because it meant everyone's licence was different. Documenting things which can otherwise only be guessed (What has the author thought that 'linking' means for a wordlist?) can only be positive. IIRC licenses per-se cannot be judged (DFSG-)free anyways because intent of author often is relevant too - especially in gray areas. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Let's stop feeding the NVidia cuckoo
On Wednesday 02 March 2005 12:28, Matthew Garrett wrote: Andrew Suffield [EMAIL PROTECTED] wrote: On Wed, Mar 02, 2005 at 12:53:34AM +, Matthew Garrett wrote: What freedom are you trying to protect by claiming that JPEGs are not adequately modifiable? Do you wish to apply this argument to all JPEGs? The freedom to modify the images to suit my purposes, of course. See http://www.fsf.org/licensing/essays/free-sw.html Right. If I create an image and only save it as a JPEG (say I've taken a picture with a digital camera and then overlayed some text on top of it), is that sufficient to satisfy DFSG 1? This has two sides: 1) Is the JPEG your source? If you e.g. have edited in the gimp, saved it as .xcf (with the text in a separate layer) probably not. If you have e.g. run it through an automated script, adding attribution (photographed by ... at ...) probably yes. 2) Do you find someone who is interested in maintaining it within Debian and does he accept the JPEG as source? Of course this example falls short of further aspects: * If a photographer adds attributions into the JPEG, what would he think if they are removed (e.g. by cropping the image)? * If the picture contains not a single line of text at the bottom but complex annotations of the picture, it seems stupid to write it directly into the JPEG. Is this worse than not using (possible superfluous) #defines for register values? Regards, Daivd -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir ber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Let's stop feeding the NVidia cuckoo
On Tuesday 01 March 2005 01:47, Henning Makholm wrote: Scripsit David Schmitt [EMAIL PROTECTED] The DFS_Guidelines_ don't need to hold up in court. Therefore they are able to say that source which is unacceptable for modification because of lack of documentation, poor programming practices, obscure language or any arbitrary criteria you might think of for unmaintainability is no service to our users They certainly _can_ say that, but I don't think they actually _do_. I took a look. The DFSG only talk about the source code. Unqualified. Probably based on the expectation, that every maintainer only packages software he feels able to properly support. I think many people (me first) often forget the greatest plus Debian has over most commercial Software Vendors: No need to pull strings in court and no marketing droids. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Let's stop feeding the NVidia cuckoo
On Monday 28 February 2005 11:16, Matthew Garrett wrote: I haven't tried to formulate a precise definition yet, but I think that the GPL's definition is stricter than we should require in general. We don't have the DFSG because they provide philosophical freedoms - we have the DFSG because they allow people to engage in practical activities. If a piece of software allows someone to assert their freedom to perform those acts without onerous restrictions, then it ought to be free from a DFSG standpoint. Bravo! That's so much better said, than I managed in my answer to Josh. The DFSG defines rights Debian needs for its users. The GPL is a permission granted by the author of a work. I think, there lies the fundamental difference. An author of a GPL'd work may believe it is funny to work through hundred different unnamed hexadecimal constants _and_ may legally license it under the GPL, because being hyper-intelligent has its priviledges. _But_ this doesn't mean that it is a good idea to bet on a project with a bus number[1] of 1. Regards, David [1] http://c2.com/cgi/wiki?BusNumber -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir ber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: GPL and command-line libraries
On Mon, Dec 06, 2004 at 12:51:34AM -0500, Anthony DeRobertis wrote: A compiler can only perform a transformation from source to object form programmed into it by its creators; it is neither an author nor capable of creativity; it can this not produce an original work of authorship or thus a derivative work. If A is derivative work of B, then the compiled form A' is probably too. If A is not a derivative work of B, then A' is not either. I seem to recall someone arguing that A' containing inlined functions from B would constitute a form of derivation. At least distributing A' would also be distributing parts compiled from B. Regards, David -- * Customer: My palmtop won't turn on. * Tech Support: Did the battery run out, maybe? * Customer: No, it doesn't use batteries. It's Windows powered. -- http://www.rinkworks.com/stupid/cs_power.shtml
Re: Copyright Question
On Tue, Dec 07, 2004 at 11:47:34AM -0800, Josh Triplett wrote: (Please note that I am not a lawyer, and this is not legal advice. The authoritative source for this information would be the actual licenses for the packages you include.) [snip] Excellent text. Could someone put this on www.d.o somewhere? Regards, David -- * Customer: My palmtop won't turn on. * Tech Support: Did the battery run out, maybe? * Customer: No, it doesn't use batteries. It's Windows powered. -- http://www.rinkworks.com/stupid/cs_power.shtml
