Re: mozilla thunderbird trademark restrictions / still dfsg free?
On Mon, Jan 10, 2005 at 01:13:35AM +, MJ Ray wrote: > > Because part of the Mozilla Foundation's strategy to raise enough money > > to employ people to work on the code involves leveraging the name. I > > think this is great - because it's not a model which restricts the > > freedom of the code. [...] > > You wrote this, but you claimed that it stops the default search > engine being changed away from my favourite invite spammers g**gl* > - is this a contradiction? It would seem to me that if you want to distribute a version of mozilla with a different default search, then it is reasonable to require that you do not call it mozilla or use any of their trademarks. After all, the same kind of thing is fine for TeX, LaTeX, Apache Cheers, Nick
Re: Manpages licensed under GFDL without the license text included
On Sun, Jan 09, 2005 at 04:53:25PM +0100, Florian Weimer wrote: > >> I think it's enough to add an additional notice stating that the named > >> section is reproduced in the gfdl(7) manpage, incorporated by > >> reference. > > > > I doubt that this would satisfy clause 4.H. of the G"F"DL: > > > >H. Include an unaltered copy of this License. > > > > > > Note that it says /Include/, not /Accompany with/... > > Nothing in the license says that the "Document" must be a single file > (or a single piece of paper). Bear in mind that there is nothing that then allows us to distribute the package in question except as a part of a system that includes the other data that is referred to. The fact that we have conveniently ignored this problem when dealing with the GPL and BSD licenses so far does not make it go away. The license information should be included in every individual package. We should come up with an alternative mechanism to save space, if that is what we want to do (e.g. allow packages to install the same file so long as the md5sums of the different versions match). Cheers, Nick
Re: mozilla thunderbird trademark restrictions / still dfsg free?
Gervase Markham <[EMAIL PROTECTED]> wrote: > I don't think it's as simple as that. After all, Debian has a trademark > policy, and restricts use of its trademarks, as does the Apache Group. > Is Debian's trademark policy "freedom-restricting"? [...] Yes. Why do you think it's under review? It's causing some minor silly situations when it interacts with copyrights of free software. The Apache foundation have also rumbled about naming here, IIRC. I think you're nicer, so far. > Because part of the Mozilla Foundation's strategy to raise enough money > to employ people to work on the code involves leveraging the name. I > think this is great - because it's not a model which restricts the > freedom of the code. [...] You wrote this, but you claimed that it stops the default search engine being changed away from my favourite invite spammers g**gl* - is this a contradiction? -- MJR/slef
Re: Compatibility between CC licenses and the GPL
"Michael K. Edwards" <[EMAIL PROTECTED]> wrote: > Actually, that's not entirely true. To the extent that a chunk of > published code is purely functional and lacking in "creative > expression", or meets either the "de minimis" or the "fair use" > standard of affirmative defense, it can be copied into a document > distributed on any terms you like. IANAL, etc., etc., but there is > plenty of precedent on the limits of the reach of copyright law with > regard to the functional aspect of source code. Much documentation is derived mainly from the comments in the code. In a few cases, there are actually comments in the code which are written deliberately to serve as the basis for documentation. Does the above argument about lacking in creative expression really apply? Looks like a massive lawyerbomb waiting to explode... -- MJR/slef
Re: AROS License DFSG ok?
Scripsit Florian Weimer <[EMAIL PROTECTED]> > * Henning Makholm: >> | 3.2. Availability of Source Code. >> | Any Modification which You create or to which You contribute must be >> | made available in Source Code form under the terms of this License >> | either on the same media as an Executable version or via an accepted >> | Electronic Distribution Mechanism to anyone to whom you made an >> | Executable version available; and if made available via Electronic >> | Distribution Mechanism, must remain available for at least twelve >> | (12) months after the date it initially became available, or at >> | least six (6) months after a subsequent version of that particular >> | Modification has been made available to such recipients. You are >> | responsible for ensuring that the Source Code version remains >> | available even if the Electronic Distribution Mechanism is >> | maintained by a third party. > Again, this clause is part of the MPL, which is presently considered > DFSG-free. Furthermore, it's weaker than the corresponding GPL > clause. No, it is significantly more restrictive than the corresponding GPL clause. The GPL allows me to put the the binary and the source code on my website and then later remove both. The above clause requires me to make arrangements to keep the source code for a longer period in time than the binary, and even threatens me with legal action if fire consumes the machine within the 12-month period or new ICANN rules causes my domain name to be appropriated, or whatever. This is very clearly a non-free requirement. -- Henning Makholm "Det må være spændende at bo på en kugle. Har I nogen sinde besøgt de egne, hvor folk går rundt med hovedet nedad?"
Re: Manpages licensed under GFDL without the license text included
On Sun, Jan 09, 2005 at 01:20:15PM -0500, Joey Hess wrote: > Bernhard R. Link wrote: > > Looking into sarge I found a number of manpages, that do not look > > redistributeable as they are licensed under the G"F"DL but do not > > include the full licence text needed to be distributeable. Especially > > Debian-specific ones seem to be affected due to some templates debhelper > > contained in the past. > > Debhelper has never contained "templates". He probably means dh-make. Kurt
Re: Manpages licensed under GFDL without the license text included
Bernhard R. Link wrote: > Looking into sarge I found a number of manpages, that do not look > redistributeable as they are licensed under the G"F"DL but do not > include the full licence text needed to be distributeable. Especially > Debian-specific ones seem to be affected due to some templates debhelper > contained in the past. Debhelper has never contained "templates". -- see shy jo signature.asc Description: Digital signature
Re: More mmcache concerns
Apparently the issue is starting to come up on SourceForge: http://sourceforge.net/forum/forum.php?thread_id=986362&forum_id=236228 We need to chime in now, and point out that MMCache is undistributable with a GPL license.
Re: Manpages licensed under GFDL without the license text included
On Sun, 09 Jan 2005 16:53:25 +0100 Florian Weimer wrote: > * Francesco Poli: > > > On Sun, 09 Jan 2005 15:39:47 +0100 Florian Weimer wrote: > > > >> I think it's enough to add an additional notice stating that the > >> named section is reproduced in the gfdl(7) manpage, incorporated by > >> reference. > > > > I doubt that this would satisfy clause 4.H. of the G"F"DL: > > > >H. Include an unaltered copy of this License. > > > > > > Note that it says /Include/, not /Accompany with/... > > Nothing in the license says that the "Document" must be a single file > (or a single piece of paper). Yes, but what is the "Document" then, in the present case? The whole collection of manpages on the system? If you are going to argue this, I'm afraid that *all* of them will have to be under compatible licenses... not something that I would like to have as a target, when the G"F"DL is around :-( -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpyanwj3TSa7.pgp Description: PGP signature
Re: Manpages licensed under GFDL without the license text included
* Francesco Poli: > On Sun, 09 Jan 2005 15:39:47 +0100 Florian Weimer wrote: > >> I think it's enough to add an additional notice stating that the named >> section is reproduced in the gfdl(7) manpage, incorporated by >> reference. > > I doubt that this would satisfy clause 4.H. of the G"F"DL: > >H. Include an unaltered copy of this License. > > > Note that it says /Include/, not /Accompany with/... Nothing in the license says that the "Document" must be a single file (or a single piece of paper).
Re: Manpages licensed under GFDL without the license text included
On Sun, 09 Jan 2005 15:39:47 +0100 Florian Weimer wrote: > I think it's enough to add an additional notice stating that the named > section is reproduced in the gfdl(7) manpage, incorporated by > reference. I doubt that this would satisfy clause 4.H. of the G"F"DL: H. Include an unaltered copy of this License. Note that it says /Include/, not /Accompany with/... -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpaLTz7H85bA.pgp Description: PGP signature
More mmcache concerns
On Wed, 5 Jan 2005, Elizabeth Fong wrote: >Can someone look at http://bugs.debian.org/280864 please? It is >likely we'll need legal advice to proceed. >Quick summary of the situation: >2001 to 2002? - Dmitry Stogov wrote Turck-MMCache on contract to >Turcksoft St. Petersburg >2002-12-09 - Turck-MMCache released as GPL by Turcksoft with Turcksoft >copyright notice; despite need to be linked against PHP, no license >exception provided, resulting in undistributability of binaries. >2003 - Dmitry Stogov hired by Zend; development on MMCache stops (presumably because they put him to work on Zend Optimizer, and didn't >want him contributing to a competing project) >2003-11-04 - Last release of MMCache (2.4.6) >2003-12 - Turcksoft pulls its web page offline (see >http://web.archive.org/web/*/http://www.turckware.ru for evidence) >2004-03-02 - Jonathan Oxer uploads first turck-mmcache Debian package to main >2004-11 - Turcksoft's domains expire, and Turcksoft goes completely dead. >2004-12 - eAccelerator forks from MMCache; however, license must >remain GPL (not solving our problems); in addition, copyright notice >ALTERED to remove Turcksoft and replace with Dmitry's name, possibly >resulting in copyright violation >Now, we have an undistributable codebase, due to licensing concerns, >and the holder of the copyright has gone defunct. The forked project >may be providing good code, but there are doubts about its legality, >as well as the fact that the GPL license issue still remains. >Turck-MMCache has become abandonware, but we likely still have our >hands tied by copyright law. >Jonathan Oxer: >> The big question though (and this is where legal advice may be required) >> is what happens to copyright when the copyright owner ceases to exist? >> According to copyright law the copyright for works made "for hire" >> exists for 95 years from the date of publication or 120 years from the >> date of creation, whichever is shorter. >> It's considered "work for hire" so unless he had a >> contract with Turcksoft to the contrary he is *not* the copyright >> holder. >So... I guess the question is, what _can_ we do? IANAL, but, AFAIK 1) Authorship and|or initial copyright ownership in international scope is usually determined according to the law of the country of origin. 2) Russia, like, AFAIK, many european countries does not have a legal concept of "selling" the entire copyright title. Copyright exclusive rights here may be licensed, but not "sold". 3) Russian copyright law (or civil law in general) provides no explicit way to transfer entire copyright title from one legal entity to another. And especially it does not provides a way to transfer copyright title from now-nonexistent legal entity (you even cannot grant full exclusive license if you do not exist). Copyright title may be transferred by inheritance, but inheritance is only for humans. 4) Consequently, it is not clear, what happens to the corporate copyright when copyright holder gets liquidated. There exists several legal theories. One of them, most pleasant to me, is that copyright cease to exist and work virtually falls in the public domain. Other theory (which sees a work for hire as a sort of implicit license) says that copyright goes to the author(s) of the work. Third theory claims that copyright can be sold on auction during liquidation process but, AFAIK, nobody so far really tried to do this, so it is a mostly wishful thinking and do not solve the problem anyway. 5) If corporate entity does not liquidated (according the article 61 of Russian Civil Code), but reorganised (article 57) or asquired by some other company, then copyright title goes to the latter company. 6) So, if Turcksoft is really liquidated and do not have any successors, then, depending of legal theory you prefer :-), MMCache either falls in the public domain or copyrighted by Dmitry Stogov. In both cases it seems to be sufficient to recieve needed additional permissions from Stogov. See his email in google groups.
Re: Manpages licensed under GFDL without the license text included
* Bernhard R. Link: > Looking into sarge I found a number of manpages, that do not look > redistributeable as they are licensed under the G"F"DL but do not > include the full licence text needed to be distributeable. I think it's enough to add an additional notice stating that the named section is reproduced in the gfdl(7) manpage, incorporated by reference.
Re: Manpages licensed under GFDL without the license text included
On Sun, Jan 09, 2005 at 02:26:51PM +0100, Bernhard R. Link wrote: > Mark Brown: <[EMAIL PROTECTED]> > x86info: x86info.1.gz This isn't Debian-specific since I contributed it back upstream. I've contacted upstream about relicensing it under the GPL like the rest of the package (which seems the simplest way of resolving the matter). -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
Manpages licensed under GFDL without the license text included
Looking into sarge I found a number of manpages, that do not look
redistributeable as they are licensed under the G"F"DL but do not
include the full licence text needed to be distributeable. Especially
Debian-specific ones seem to be affected due to some templates debhelper
contained in the past.
Unless someone disagrees, I'll file bugreports against those packages.
("Missing permissions to be distributeable" is serious even pre-sarge,
isn't it?)
I) Debian-specific manpages
Some packages are listed twice, one time under the author listed in the manpage
(as those are the ones that might be able to easily give additional permission
under something sane like GPL) and one time under the current maintainer of
the package. Sorted by email-address.
(note, some contain a copyright notice not visible using man, try zless instead)
Andrés Roldán <[EMAIL PROTECTED]>
mtools: tgz.1.gz
Benjamin Drieu <[EMAIL PROTECTED]>
gnuserv: dtemacs.1.gz
Eduard Bloch <[EMAIL PROTECTED]>
nvtv: nvtvd.8.gz
Mark Brown: <[EMAIL PROTECTED]>
x86info: x86info.1.gz
Chris Boyle <[EMAIL PROTECTED]>
crack-attack: crack-attack.6.gz
W. Borgert <[EMAIL PROTECTED]>
blinkd: blink.1.gz blinkd.8.gz
ethereal-dev: idl2deb.1.gz asn2deb.1.gz
snacc: berdecode.1.gz snacc-config.1.gz
ttthreeparser: ttthreeparser.1.gz
Frederic Peters <[EMAIL PROTECTED]>
ethereal-dev: idl2deb.1.gz asn2deb.1.gz
matze <[EMAIL PROTECTED]>
kbiff: kbiff.1.gz
klogik: klogik1.gz
Jean-Michel Kelbert <[EMAIL PROTECTED]>
kbiff: kbiff.1.gz
klogik: klogik1.gz
Filip Van Raemdonck <[EMAIL PROTECTED]>
mtools: tgz.1.gz
Emmanuel le Chevoir <[EMAIL PROTECTED]>
icecast-server: icecast.8.gz
Roberto Lumbreras <[EMAIL PROTECTED]>
nvtv: nvtvd.8.gz
Sylvain LE GALL <[EMAIL PROTECTED]>
headache: headache.1.gz
Colin Walters <[EMAIL PROTECTED]>
crack-attack: crack-attack.6.gz
II) non-Debian-specific manpages
The following manpages not containing the GFDL text look not Debian-specific, so
resolving this could be more complicated (or might make it necessary to include
the whole GFDL-text within the manpage).
Colin Watson <[EMAIL PROTECTED]>
Fumitoshi UKAI <[EMAIL PROTECTED]>
groff: groff_tmac.5.gz groff_out.5.gz roff_diff.7.gz
groff.7.gz roff.7.gz groff_trace.7.gz groff_mom.7.gz
ditroff.7.gz groff_char.7.gz
groff-base: troff.1.gz groff.1.gz
Christian Surchi <[EMAIL PROTECTED]>
hasciicam: hasciicam.1.gz
Hidetaka Iwai <[EMAIL PROTECTED]>
Masahito Omote <[EMAIL PROTECTED]>
m17n-docs: mconv.1.gz mdate.1.gz medit.1.gz mimx-anthy.1.gz
mimx-ispell.1.gz mview.1.gz m17n-config.1.gz
mdump.1.gz mdbDir.5.gz mdbFLT.5.gz mdbFontEncoding.5.gz
mdbFontSize.5.gz mdbFontset.5.gz mdbGeneral.5.gz
mdbIM.5.gz mdbCharsetList.5.gz mdbCodingList.5.gz
Keita Maehara <[EMAIL PROTECTED]>
manpages-ja: groff_tmac.5.gz groff.7.gz roff.7.gz
Martin Waitz <[EMAIL PROTECTED]>
oidentd: oidentd.conf.5.gz oidentd_masq.conf.5.gz oidentd.8.gz
Sergio Rua <[EMAIL PROTECTED]>
partimage: partimage.1.gz
partimage-server: partimaged.8.gz partimagedusers.5.gz
Hochachtungsvoll,
Bernhard R. Link
Why does Debian distributed firmware not need to be Depends: upon? [was Re: LCC and blobs]
On Sun, 09 Jan 2005, Marco d'Itri wrote: > On Jan 08, Josh Triplett <[EMAIL PROTECTED]> wrote: > > atmel-firmware . Would you argue that at76c503a-source should neither > > Depends: nor Recommends: atmel-firmware ? If so, why? If you changed > Yes. Read the debian-legal@ archive if you care about the details. Would even the module package built from the at76c503a-source package neither Depends: nor Recommends: atmel-firmware? I still haven't been able to understand this line of reasoning myself, since if I were to build a package foo; that needed foo-data; to work, I'd certainly include a Depends: foo-data in the package. If I didn't, I'd expect someone to file an RC bug against my package. If you wouldn't mind, sumarizing why the case of the module package built from amtel-source is has different rules for Depends: than the foo package would help me at least understand this line of reasoning.[1] [Yes, I really have read almost all of the messages in this thread, and I'm still having a hard time figuring out this line of reasoning.] Don Armstrong 1: It would also be useful if the specific cases where Depends: like this were not required when they appear to actually exists could be codified into policy. -- "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 signature.asc Description: Digital signature
Re: LCC and blobs
On Jan 08, Josh Triplett <[EMAIL PROTECTED]> wrote: > atmel-firmware . Would you argue that at76c503a-source should neither > Depends: nor Recommends: atmel-firmware ? If so, why? If you changed Yes. Read the debian-legal@ archive if you care about the details. -- ciao, Marco signature.asc Description: Digital signature
