Re: About Logo License
Sam Hocevar sam at zoy.org writes: FWIW, there are no plans to change the official logo licensing as far as I know. Unless someone comes up with a suggestion that complies with trademark law, it will have to remain non-free if we want it to serve the purpose it was created for. Does it serve any purpose at all currently? I'm not aware of it being used, and unless the purpose it was created for would be have an unused logo, I think, well, ... Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian/copyright and actual copyrights
Hi, Yaroslav Halchenko debian at onerussian.com writes: My questions to the list now: 1. Do we have to list all copyright holders + licenses per each piece of software distributed within a package? The opinion of the ftp-masters ist that we do have to: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=218105 or it is more of should than must (which would be in strong disagreement with my previous state of mind)? In the above bugreport (which is only important, not serious) it's treated as a should. However, that should maybe be looked at in the light of the fact that we are talking about hundreds if not thousands of files with differing licenses and a package which is at the heart of our documentation building processes (and that the bug is being worked on by willing maintainers, albeit slowly). For a package like wacom-tools, considerations might lead to serious even. Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Policy on Binary Firmware Fetching in Main (e.g. foo2zjs)
Michael Gilbert michael.s.gilbert at gmail.com writes: Stephen Gran wrote: That being said, packages that exist solely to download external non-free content have traditionally been considered contrib material. If this is just a helper script that nothing else in the package uses, it seems perfectly fine to me to keep it in main, but ship the script in examples/ or something. getweb can be considered a helper script, but it also exists solely to download non-free content. so it falls in to both of your categories. the rest of the package does not invoke getweb, but can make use of the stuff that is download given that the user has invoked the script himself or herself first. Agreed - but that still means that we can ship a package in main which contains this script. It doesn't make sense to create two new source tarballs and two packages from the same upstream source if the contrib package is much smaller than the main part. Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License discussions in Debian
Anthony Towns [EMAIL PROTECTED] wrote: On Mon, Jun 04, 2007 at 11:08:39PM +0200, Frank K?ster wrote: I think that Debian would very much benefit if there was a place (call it [EMAIL PROTECTED] or whatever) where our policy with regard to individual software's licenes could be discussed with the input of those who actually set this policy: the ftpmasters. Yes, that's the main reason for my involvement in this thread. Though it's not just ftpmasters, it's Debian developers in general; so that we don't end up with a consensus on debian-legal (or in ftpmaster) that doesn't match the views of Debian as a whole. That's true, as an ideal. In reality, you can't expect every DD or even maintainer to subscribe to -legal except when they've got a particular problem to discuss. In this case it's a pity when you finally get the impression that what you are told there neither matches the opinion of the majority of your colleagues, nor of the ftpmasters - but the ftpmasters' opinion is more insteresting for you in that case. AFAICS, that means welcoming developers who don't know the difference between subpoena and summons, not using it as a reason to ignore them completely. Definitely - if the NM process works as it should, at least every DD who entered since it's been established should have a working understanding of licensing, and that should be enough to *start* a discussion. I'm not sure, however, that this is the general attitude on -legal: I've never encountered it. Instead, I had the feeling that it was in particular directed at you, since you seemed to claim to have better understanding of the legal situation than your counterpart, and use that as an argument for your position: In which case I can well understand that the counterpart argues against this better understanding. If debian-legal isn't the place for you (and AFAIK none of the other ftpmasters is a regular), maybe we need a new start and a different format. I used to be a regular on -legal, and I'm still subscribed. My views (such as people who aren't speaking on behalf of the project shouldn't make it sound like they are...) don't seem particularly welcome though, so I tend not to bother. I don't expect that you engage in all those discussions. But I remember several cases where ftpmasters were mentioned on -legal, either in a phrase like finally, you'd have to ask the ftpmasters, or in complaints like the ftpmasters appear to have a different opinion, but we don't know why. In these cases, it would be really helpful if one of you could step up and take part in the discussion. And a mail like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350624;msg=142;att=0 is not only not-helpful-at-all, it's really discouraging to see a discussion ending like this. Well, in that particular case I'd understand if you don't answer to the bug, but the reasoning could be published elsewhere where Mr. $greps_for_his_name_on_debian_lists cannot answer easily. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
Don Armstrong [EMAIL PROTECTED] wrote: If you're going to ignore the court case, it doesn't matter to you, but if you ever plan on travelling to germany or doing business with people in germany (or live in some part of germany that isn't close enough to berlin to defend yourself there) it can be a significant cost. Not sure whether it matters anyhow, but if you live in Germany and have fear of such clauses, you'd rather buy your stuff nowhere except the local grocery or supermarket. Gerichtsstand ist $place_where_the_selling_company_is_registered is a very common clause in written german selling or service contracts, not only but in particular if you buy online. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
Anthony Towns [EMAIL PROTECTED] wrote: The debian-legal checklist: [...] In the example Don presented, of the Debian star maintainer removing some output from the Debian star package, that the star upstream claims constitutes a copyright notice, then there are the following options: [ rather long essay snipped ] Confident assertion of legal facts, with little basis, no references, and without an IANAL disclaimer, or I am a lawyer and this is legal advice, or a I am a lawyer but this does not constitute legal advice: little basis seems overly subjective to me, but besides that: Check Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
License discussions in Debian (was: discussion with the FSF: GPLv3, GFDL, Nexenta)
Anthony Towns [EMAIL PROTECTED] wrote: See, given that as an ftpmaster I'm one of the folks who actually implements the policy on what's accepted into main or not, it's not my loss at all. I think that Debian would very much benefit if there was a place (call it [EMAIL PROTECTED] or whatever) where our policy with regard to individual software's licenes could be discussed with the input of those who actually set this policy: the ftpmasters. If debian-legal isn't the place for you (and AFAIK none of the other ftpmasters is a regular), maybe we need a new start and a different format. But it's a pity that there's no way to get the ftpmasters' opinion except by trying, and no regular way at all, it seems, to get the reasons for their decisions. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
Steve Langasek [EMAIL PROTECTED] wrote: The *relevant* claim I have made is that it is inappropriate to use our GR mechanism to attempt to *decide* whether GPLed drivers cause a distribution problem. The release team, the ftp team, and I suspect even most of the kernel team have no interest in a GR that authorizes any distribution of software which it at the same time asserts is illegal. Thank you for making this claim public on this list (where it belongs). I think it's an important point, and if you've already said this to Sven some time ago in a different medium, then I understand the reactions of some people towards him. I have previously given my own understanding of why it is not a problem for us to distribute GPLed firmware blobs pending license clarifications, but I don't see any indication that Sven is interested in understanding that POV, only in tilting at strawmen; so I don't intend to lose any more time on discussing this point beyond this single clarification email. It has already clarified much, and since I personally trust you, I don't insist on your repeating the explanation. However, I'd like to point out that other people are trying to follow this discussion, too. I don't think that your previous explanation was posted to -vote, which IMHO is the relevant list for such discussions. I feel it's particularly hard this time to follow the discussion; with no other GR have there been so many this has been said elsewhere (where? IRC?) statements by so many people, without trying to sum up on a web page or similar. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
Walter Landry [EMAIL PROTECTED] wrote: Sven Luther [EMAIL PROTECTED] wrote: So, the RMs are making claims that those sourceless GPLed drivers don't cause any kind of distribution problem, while i strongly believe that the GPL clause saying that all the distribution rights under the GPL are lost if you cannot abide by all points, including the requirement for sources. When Debian distributes kernel binaries, Debian makes use of clause 3a (accompany with source code), not 3b (written offer) or 3c (pass on written offer). So source has to accompany everything, even if no one is asking. Well, I think Sven didn't make the point of disagreement clear. It is whether what in the course of the GR's has been called sourceless firmware is in fact sourceless. If I understood Anthony Towns correctly, the ftpmasters and many others want to give those drives the benefit of doubt and assume that they aren't sourceless, but are, e.g., just dumps of unnamed registers and therefore the preferred form for modification. After all, they were what was given to the kernel people when the driver was released as .c and .h files under the GPL. So the real question is whether we want to do that, whether in the particular cases there's in fact any doubt, etc. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: RE : Re: Linux Magazin Germany, affecting Debian's image?!
Radu-Cristian FOTESCU [EMAIL PROTECTED] wrote: --- Joerg Jaspert [EMAIL PROTECTED] a écrit : That was done by me for Cebit, like we did for some other years already. Well, it seems to lack the proper labeling then. -legal is the wrong list for this, there is no legal issue behind that. I thought this is not official! 1. The magazine (on the Web; I have not buyed it) didn't said it was a special CeBIT edition. But it says Debian sarge special, 2. It clearly contains packages not on the official update list. AFAIK, backports like FF1.5 and X.org are not _official_ for Sarge. it advertises explicitly that this is an updated version of sarge, after talking about Debian's conservative version policy. Do you understand german? I'm not very sure it happened to. It's for sale now, labeled sarge. No, it isn't labelled sarge. Sorry to say such things and possibly raise conflictual feelings, but do you really feel this is *right*? Even if it is not, it's off-topic on -legal. Please continue this on -project; note that I'm not subscribed there. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Rejected Package - Licence question
Andreas Fester [EMAIL PROTECTED] wrote: No, you have to remove it from the orig.tar.gz, or... - Anything else? have it relicensed. ... which means that the upstream author has to *replace* the questionable section with a reference to, for example, the GPL, right? Well, a signed e-mail, or a signed message on the release ftp server, in which the upstream author says this and that is now licensed under different terms, namely:... would do as well, if he doesn't want to make a new release soon. Does this mean that a COPYRIGHT file in the upstream package root directory does not automatically apply to *all* files of the package? Does each and every file need to contain at least a link to the licence which applies to it? I mean, this could be difficult, at least when generated files come into play... (e.g. generated html documentation which is already shipped with the upstream package). Generally, there are two options: Either every file has a license text in it (or often the short version pointing to the complete license), or there is a central file that - lists all files covered, and - the license they are under. Having both at the same time doesn't harm, of course. But I assumed that there is no central file. A COPYRIGHT file that says this software is under license FOO is not enough, because it is unclear what this software actually means. Just have a look at the last paragraph of the GPL text (How to Apply...). Or just look at your package: If there already is a central copyright file without a filelist, assuming that it provides license information for each file in the tarball would contradict the information in manual.texi. The best option would be to license the manual under the same license as the software. In principle, it's also possible to use a different license, but that only gives people trouble when making a derivative work. If upstream insists that the documentation needs a license that's specifically designed for documentation (not programs), try to persuade him of the opposite, using the arguments found in -legal archive. I think thats not an issue, he actually asked me already if I can give some hints :-) Then you should really try to persuade him to use the software's license, because only that way it's easily possible to copy strings from the manual to online docs, comments etc., and vice versa. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Rejected Package - Licence question
Ben Finney [EMAIL PROTECTED] wrote: I mean, this could be difficult, at least when generated files come into play... Generated files are, by definition, not the source code of the work; in the case of the GPL, they are not the preferred form of the work for making modifications to it. Some other license texts don't define source code, but that's still a pretty good working definition. You must ship the source files and make it possible for recipients to re-generate any non-source files needed; since you're doing that, you may as well not ship the generated files in the source package but allow them to be built from 'debian/rules'. Newly generated or not, it's a good idea to also include the license terms in the generated files, at least a pointer. This saves users from tracing the origin of some help document from the screen display to a file on the disk, to a package that installed the file, and finally to its copyright file. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: name changing clauses, again
MJ Ray [EMAIL PROTECTED] wrote: Frank =?iso-8859-1?Q?K=FCster?= [EMAIL PROTECTED] I tried to read the old discussions about the LPPL, [...] I guess you're referring to things like analysis of latest LPPL revision by Branden Robinson in June and September 2003, but you don't say. It's rather difficult to discuss things without knowing what they are. This one, and lots of other threads about the LPPL. Even then, it seems like it wasn't totally consensual about the problem. Indeed. MJ Ray said, without anyone contradicting that: [...] I wouldn't read much into that. On my screen, no-one besides you replied at all. Which can mean that nobody considers this to be a problem. So here the lesson seems to be that also filename change requirements are acceptable as long as they do not impose any relevant restrictions, with the question what's relevant depending on the individual case. I strongly argue against including irrelevant junk in a licence, as it can turn out to be lawyerbombs. Agreed, but I'm dealing with licensors who are either completely unavailable or unreachable, or not willing to understand the problem... So, get clarification/removal if you can, but if the only problem in the licence is a practically-ineffective restriction whose workaround is noted in the copyright file, I'm not going to file a serious bug over it. Yes, I guess that's the attitude I should also take myself in the cases where there's no possibility to reach/convince upstream. Except dropping the file, of course, if the restriction is *not* ineffective. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
name changing clauses, again
Hi, I'm trying to understand how to interpret DFSG clause 4, in particular under circumstances where the name of a file also encodes its purpose or usage or any other kind of API. I tried to read the old discussions about the LPPL, and it seems to me that one of the major obstacles of the old LPPL was that it required a change of filenames without any other option. So the lesson would be that it is accepted that derived *works* identify themselves under a different name, but requiring that derived works not use the original filenames is not accepted. I must say, however, that I found the old discussion hard to read, dispersed about many threads, and probably even in private mail sometimes. On the other hand, in http://article.gmane.org/gmane.linux.debian.devel.legal/26382/match=name+changing+clauses MJ Ray said, without anyone contradicting that: , | Amusingly, it's only the | filename and you can probably make an symlink or some other | alias while complying with this, so it's more comedy than a bug. ` So here the lesson seems to be that also filename change requirements are acceptable as long as they do not impose any relevant restrictions, with the question what's relevant depending on the individual case. Can you help me out? Is there any consensus in debian-legal? I'd rather get some general guidelines, otherwise I expect myself boring -legal with similar questions all the time... TIA, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX) pgpvSU08qCYy4.pgp Description: PGP signature
Re: Rejected Package - Licence question
Andreas Fester [EMAIL PROTECTED] wrote: An earlier version of the package is already in Debian and it also contains the file Manual.texi with the same copyright information, but the file was only in the source package while the new version now contains a -doc package which allows to install the manual. In other words, the non-free license was just overlooked in the old version. How can I modify the package to allow it to go in main? - Do I have to repackage the orig.tar.gz file to get completely rid of the problematic file? - Is it sufficient to remove the Manual from the -doc package? No, you have to remove it from the orig.tar.gz, or... - Anything else? have it relicensed. Also, I already contacted the upstream author, and it was not really intended to make the Manual non-free by this copyright statement; any hints how to make the manual DFSG-compliant in the future are welcome (I suppose a valid solution is to simply remove the copyright statement from the file). Err, no, that would make it undistributable even in non-free. The best option would be to license the manual under the same license as the software. In principle, it's also possible to use a different license, but that only gives people trouble when making a derivative work. If upstream insists that the documentation needs a license that's specifically designed for documentation (not programs), try to persuade him of the opposite, using the arguments found in -legal archive. If you fail, well, I fear there is currently no license for documentation that has been approved by -legal. There were rumors about some BSD documentation license, but I never saw it. Some of the CC licenses will probably be DFSG free from their next release on, but we don't know when that's going to happen. Finally there's the GFDL, which is a *bad* license, but DFSG-free by GR if the document does not include any of the GFDL's invariant section options (for the details, read the GR). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Rejected Package - Licence question
Andrew Saunders [EMAIL PROTECTED] wrote: On 7/10/06, Frank Küster [EMAIL PROTECTED] wrote: If you fail, well, I fear there is currently no license for documentation that has been approved by -legal. Actually, the MIT license[1] covers documentation: --- Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software) Well, in that sense most other software licenses cover documentation, e.g. the GPL - that was the main point of my statement. But I see no license that was specifically designed and worded to apply to documentation but not programs, as many upstream authors seem to search. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: licenses with name changing clauses
MJ Ray [EMAIL PROTECTED] wrote: =?iso-8859-1?q?Frank_K=FCster?= [EMAIL PROTECTED] While we're at it, there's a different issue in teTeX and TeXLive for which I'd like to have some advice from -legal. ukhyphen.tex has now a supposedly free license, but it has a broader renaming clause: Wow, that's arrogant, not only reserving the package's filename (arguably acceptable to ensure integrity) but the names of many possible derivatives/competitors. Amusingly, it's only the filename and you can probably make an symlink or some other alias while complying with this, so it's more comedy than a bug. Yes, it's as simple as mv ukhyphen.tex britpat.tex $EDITOR britpat.tex echo britpat.tex ukhypen.tex /usr/share/texmf-tetex/aliases Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
licenses with name changing clauses (was: license of cstex / cslatex)
Thomas Esser [EMAIL PROTECTED] wrote: I had done modifications of three files of that package and distributed the changed files using the original filename. The author told me that this violates his license. Actually, this only happened, because when reading his license the first time, I stopped as soon as I saw a reference to the GPL (and did not read the appendix). I've seen you've fixed that by uploading a new tetex-texmf tarball with the buggy, unchanged versions in them. I think an alternative would have been to rename the macro package to something like csplainfixed, install it into a different directory (adapting the necessary kpathsea variables) and keep the filenames. This would make a drop-in replacement that works... Questions: - is it valid to refer to GPL and add such severe restrictions in an appendix? I think he can use whichever license he wants, so GPL with additional restrictions are legal, too. He may have a hard time sueing you, but I guess he didn't try that. - is this a free software license in the FSF definition? No idea, but I'd assume yes. - is this license free enough to allow an inclusion of the software into debian? Yes, DFSG #4 says: , | The license may require derived works to carry a different name or | version number from the original software. (This is a compromise. The | Debian group encourages all authors not to restrict any files, source | or binary, from being modified. ` While we're at it, there's a different issue in teTeX and TeXLive for which I'd like to have some advice from -legal. ukhyphen.tex has now a supposedly free license, but it has a broader renaming clause: % if % such modifications are re-distributed, the modified % file must not be capable of being confused with the % original. In particular, this means % %(a) the filename (the portion before the extension, if any) %must not match any of : % %UKHYPH UK-HYPH %UKHYPHENUK-HYPHEN %UKHYPHENS UK-HYPHENS %UKHYPHENATION UK-HYPHENATION %UKHYPHENISATION UK-HYPHENISATION %UKHYPHENIZATION UK-HYPHENIZATION % % regardless of case, The first question is whether match is to be read as strings are equal or like in grep gave N matches. In the latter case, this is probably analogous to the PHP license forbidding this string in any name, even graphplot. I didn't follow the PHP threads, but I guess this would be non-free. However, I read it as the strings match, then I may call a derivative ukhyph1.tex or ukhyphnew.tex, and I would tend to accept this under the compromise clause of the DFSG. By the way, the other question which has been raised in the upstream mailing list is whether the person who settled this restrictive license actually has the right to do so - while he's the current maintainer, he is said to not have contributed much, the former maintainer agreed on LPPL, and originally the data were in the public domain... Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: license of cstex / cslatex
Joe Smith [EMAIL PROTECTED] wrote: Questions: - is it valid to refer to GPL and add such severe restrictions in an appendix? It is legal AFAIK (IANAL), but is relly poor form. Agreed. Also it makes the work GPL-incompatible, which kindof defeats the point of using the GPL. I also thought about this. But isn't it de-facto GPL-compatible: Once you've renamed it, you can do with it what the GPL allows and requires, just not change back the name to csplain. The latter isn't a problem with the GPL, I also am not allowed to call my GPL'ed work Mac OS X Tiger ;-). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: sharpmusique in Debian
Charles Fry [EMAIL PROTECTED] wrote: /usr/share/common-licenses). In this case, the license in question is the GNU General Public License, version 2. I see no legal reason why this is not in Debian. I do see a technical reason: no one wants to make packages, apparently, since the RFP in question is still open (345903). I realize that the license works, and I apologize for not mentioning that. I just wondered if there were any DMCA-related issues, not knowing what implication those have on Debian, inasmuch as the package was created by reverse-engineering a proprietary protocol. The xml files in the glade subdirectory, as well as the images don't have a license statement (at least not in their svn repository). Shipping a copy of the GPL in the distribution does not mean that every file is licensed under it. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: [OT] Re: Sun responds to questions on the DLJ
Josselin Mouette [EMAIL PROTECTED] wrote: Le dimanche 21 mai 2006 à 21:16 -0500, Tom Marble a écrit : sophistication in Debian technology. My point here is that I have developed the impression that Debian is more than technology... This is getting more and more true, and this is the point I find sad. [...] The essence of Debian should be free software and technical excellence. I am afraid this is no more a priority for many of us. I don't see the contradiction here. For me, Debian is about free software and technical excellence. But it would be *really* boring to do the work alone. And it would also be much less interesting to do the work in a company with traditional organization. Therefore, the fact that Debian is a social entity, too, with a particular culture, contributes to my motivation to work for it. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: PDF files and dh_compress
Please, this time, obey the Followup-to to debian-legal. Charles Plessy [EMAIL PROTECTED] wrote: However, I do not want to argue, Yes. Please. Please do not argue before you've read the discussions we already had on this. I don't expect you to find any relevant new points. and your comment about the possibility that the PDF file might contain non-free fonts also makes sense. I will not include the PDF in my package. Judging from the list of fonts included, it should be possible to replace them by similar free fonts (Helvetica instead of Arial, a better choice anyway, URW Courier instead of CourierNew, URW Times instead of TimesNewRoman. As for the public domain, I thought I was on solid ground because work made by public servants in the USA is automatically public domain. However, I realised that the Standford university where the software has been released is private (correct me if I am wrong), thus the program can not be in public domain. But it can be put into the public domain, or at least a state that's equivalent in effect. From a short look at the document and the web page, though, it looks as if there's no license at all. This means that we do not have a permission to redistribute that file (nobody has) and *must* remove it ASAP. I will document this in the copyright file, and ask the upstream author if he agrees to rephrase his statement. The existing statement for the software is perfect, no need to rephrase anything. The non-existent statement for the Documentation is the problem. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Free Art License
Nathanael Nerode [EMAIL PROTECTED] wrote: It *does* mean you would be forever required to keep updated information on where recipients can access the original artwork. (For the Mona Lisa, the answer would be The Louvre.) The freeness of this is arguable. I think it's supposed to be primarily a form of attribution or credit, and it doesn't seem unreasonable to me. However, it may be overbroad. Convince me. Perhaps keeping track of the movements of the Mona Lisa as it's sold to different museums *is* unreasonable. Especially since it could be stolen. On the other hand, it is important for a free piece of physical artwork that it be publically accessible; the one who has power over the license (the Louvre, I guess) would also have to make sure that, when it is sold, it will not end up in a private house. - The Original (the work's source or resource) : A dated example of the work, of its definition, of its partition or of its program which the originator provides as the reference for all future updatings, interpretations, copies or reproductions. (Incidentally, I have no idea what of its partition means here. Its program seems designed to refer to dance or theatre works.) I've seen partition used in a cover text of a music CD, it seems to refer to the score of music for the orchestra. It might be a false-friend like translation, in german a music score for many instruments is called partitur. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Question about translating and editing gpl document.
john skofot [EMAIL PROTECTED] wrote: Is this in violation of the gpl? No, IMHO it's one of the typical uses of the freedoms the GPL explicitly grants. Is he allowed to remove chapters and misleadingly change the title? If he has changed the document to contain more up-to-date information, wouldn't it be misleading to *keep* the title? All without and against my concensus. That's not very friendly, but friendliness is not required by the GPL. It's also how life is - most forks start with being not friendly, and many finally-not-forks which get reintegrated start that way, too. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Is distribution of the maxdb-doc package a GPL violation?
Francesco Poli [EMAIL PROTECTED] wrote: To summarize, I think that, if those documents are actually modified in MS Word Doc format by their actual maintainers, then their source code is really in MS Word Doc format. I agree. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Packages containing RFCs
Simon Josefsson [EMAIL PROTECTED] wrote: Justin Pryzby [EMAIL PROTECTED] writes: I *swear* that one of the project documents said something highly relevant, to the effect of nonfree material might be included in a package in `main' if it is well-separated, and not required for the operation of the package. I can't find it, so I'd appreciate it if someone would point it out to me .. Anyway, I'm pretty sure that it made explicit mention of RFCs and some humour files included with emacs. I think the humour files in emacs (that doesn't have a clear and free license) are being removed, so perhaps that text has gone away. Anyway, if someone knows about that text, it would be quite interesting to see where it was written and why (if at all) it has been changed. Could it be that what Justin is looking for is actually a statement that: Packages that contain *contrib* material which is well-separated and not required for the operation of the package can go into main? That one is true, I'm sure, although I can't give you a reference, either. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Is distribution of the maxdb-doc package a GPL violation?
Guido Trotter [EMAIL PROTECTED] wrote: Hi! I've been asked by the debian release team to look into this bug and see what can be done to have a successful resolution... The situation seems to be this one: 1) maxdb-doc is a package which contains some GPL licensed html manual files 2) the GPL asks for the source code (defined as: preferred form of the work for making modifications to it) to be available 3) the html files are determined to be automatically generated by a tool called SAP Html Export, and the files which originate them are not available This sounds like as if the content was in some weird format before, maybe a database with SAP frontend? If this is true, the first thing you'd do if you want to maintain *and* distribute the content as part of some software would be to export it from that database. Not only because the database is non-free, but also because it doesn't seem like a preferred form of modification if you want to edit documentation, and if you want it to be packaged in a tar.gz. If this is true, I don't see why this is necessarily missing source. Where the files exported a long time ago, and are now maintained as html files? Or are they newly exported every release? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Bug#363061: Implicit granting of rights?
Josh Triplett [EMAIL PROTECTED] wrote: No, it falls just on the wrong side; licenses can restrict the name of the *work*, as in the human-parsable name, but filenames serve as a functional component of a work. This issue came up with the previous version of the LPPL. You are right. Let's just remove it, it's obsolete cruft anyway, useful only for some hypothetical centuries-old documents. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Implicit granting of rights? (was: Bug#363061: tetex-extra: palatcm.sty is non-free)
Hi debian-legal, Ralf Stubner [EMAIL PROTECTED] wrote: On Fri, Apr 14, 2006 at 15:14 +0200, Frank Küster wrote: , | %%% Copyright (C) 1994 Aloysius G. Helminck. All rights reserved. | %%% Permission is granted to to customize the declarations in this | %%% file to serve the needs of your installation. However, no permission | %%% is granted to distribute a modified version of this file under | %%% its original name. ` That would be just on the right side of the border set by DFSG #4 (note that it's a TeX input file, so it is both source and used form), but But it doesn't even allow use - don't know whether this is implicitly granted? I would vote for implicitly granted usage rights, but IANAL. Can we in fact assume such implicit granting of rights? It seems logic to me, because there are no needs of your installation if all I may do is meditate over the contents of the file. But I'm not sure whether what seems logic to me is logic in IP law... TIA, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: MPL and Source Code
Craig Southeren [EMAIL PROTECTED] wrote: On Wed, 5 Apr 2006 12:42:49 +0300 Tzafrir Cohen [EMAIL PROTECTED] wrote: On Wed, Apr 05, 2006 at 07:29:37PM +1000, Craig Southeren wrote: On Wed, 05 Apr 2006 01:18:34 -0700 Josh Triplett [EMAIL PROTECTED] wrote: I think you have successfully argued that we can satisfy this requirement of the license, and thus we could probably legally distribute MPLed software; however, distributability only gets you as far as the non-free archive. Given that the Debian definition of free basically means GPL compatible, I never really expected anything else :) GPL-compatible as in openssh and openssl? The modified BSD license is GPL compatible, isn't it? (I know the original BSD license isn't) That doesn't matter. GPL-compatibility or copyleft ist *not* a requirement of the DFSG, not at all. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: MPL and Source Code
Craig Southeren [EMAIL PROTECTED] wrote: On Sun, 2 Apr 2006 15:22:31 -0400 Anthony DeRobertis [EMAIL PROTECTED] wrote: On Sun, Apr 02, 2006 at 08:54:53PM +1000, Craig Southeren wrote: A problem would only occur if there was a Debian release that contained source code that is is not in the SVN archive. Does this ever occur? Security updates and NMU's come to mind. I'm not sure what an NMU is, A Non-maintainer upload by some other Debian developer but why are these not put into the SVN archive? Mostly because that other Debian developer doesn't necessarily have write access to the maintainer's SVN archive. Because if it is Debian policy to distribute binaries where the source code is not guaranteed to be publically available, then yes, I think that could be a problem regardless of whether the license is MPL or GPL. We always distribute the source code; but we don't *archive* the source code after there's been a new upload with new source code. That's no problem with the GPL, but it appears to be with the MPL. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Format of the copyright file
Julian Gilbey [EMAIL PROTECTED] wrote: On Fri, Mar 31, 2006 at 05:31:11PM +0200, Frank K?ster wrote: Hi, I'm struggling with the policy requirement that the copyright and licensing information must be in one file debian/copyright, including the complete license text except for the common licenses. Note that debian/copyright is made available through means other than the package itself, eg the Package Tracking System. That's a good point. The file could probably be useful if it was: - clearly divided up by visual separators - the individual sections numbered sequentially - a table of contents at the start We already have some of this, the visual separators could be more visible... Incidentally, is the Artistic License the same as the one in /usr/share/common-licenses? No, it's a different version. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Format of the copyright file
Hi, I'm struggling with the policy requirement that the copyright and licensing information must be in one file debian/copyright, including the complete license text except for the common licenses. I'm trying to solve #218105 for tetex-base, which is a huge collection of many contributions, large and small, from different authors. I have therefore written a script that uses existing information about which files belong to which CTAN package (adapted from the TeXLive package) and about the licenses for each CTAN package in the TeX Catalogue and semi-automatically creates the copyright file from this information, after I've verified the license information in the Catalogue is correct. Even without including license texts, this leads to a huge file: http://packages.debian.org/changelogs/pool/main/t/tetex-base/tetex-base_3.0-17/tetex-base.copyright currently has 394 lines with 1737 words, on my local system I'm at 425 lines currently. And I've only verified a *small* fraction of the packages included. In my opinion the purpose of the requirement to have one copyright file is to make it easy to access this information, but I think this is all but easy if the file is a monster as tetex-base's will be, even without including the license text. I think I would serve users and developers better if I collected the license texts in a separate file, indicating in the list of packages where the license text can be found. The current lppl would add 416 lines of text, and now I've come across a package that's under a version of the artistic license (which itself looks fine to me, http://svn.debian.org/wsvn/debian-tex/tetex-src/trunk/source/latex/fancyvrb/artistic2.txt?op=filerev=0sc=0) which would add another 192 lines. Do debian-legal folks agree that in this case it is okay to violate the words of the Policy and go for a separate licenses.texts file? If you think that this is not acceptable, what else would you suggest to actually make the copyright file useful? TIA, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
how to properly specify Public Domain?
Hi, Summary: If there's a file in one of my packages that only declares to be in the public domain, do I have to contact the author and let him clarify this, or can I leave things as they are? I recall to have been told that, in order to make a piece of software free, it is not sufficient to say This file is in the public domain, but that instead one has to write something like Everybody is free to use, distribute and/or modify it. On the other hand, I have learned meanwhile that in some legislations the term Public Domain does indeed have a defined meaning. From this I would conclude that declaring something Public Domain should be sufficient, and that effectively no court could sanely assert a copyright infringement if someone used a file on that basis, even when the term doesn't have a well-defined meaning there - at least if the copyright holder is from a country where it has. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: how to properly specify Public Domain?
Patrick Herzig [EMAIL PROTECTED] wrote: Maybe this thread helps: http://lists.debian.org/debian-legal/2005/06/msg00018.html Sorry, not really (or I've missed the relevant mails). I read a lot about whether public domain licenses work as they are intended, and something about how to properly phrase them, but nothing about whether This file is in the public domain is sufficient information to say that the file is DFSG free. If there's a file in one of my packages that only declares to be in the public domain, do I have to contact the author and let him clarify this, or can I leave things as they are? The fact is that there's at least one file like this in tetex-base. And I'm not sure whether the copyright holder can still be reached. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: how to properly specify Public Domain?
JC Helary [EMAIL PROTECTED] wrote: Public domain is clearly defined in copyright law, and that should be so in any country that has any kind of copyright law. I fear there are a couple of countries that didn't obey your should. Copyright only extends to a certain period of time after which it does not exist anymore. That idea probably exists everywhere, but you can't say treat this file as if I died 70 years ago in the EU, AFAIK. And all that doesn't answer my question: Whether it's debian-legal's consensus that This file is in the public domain grants us enough rights to distribute it in main, or non-free, or not at all. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: how to properly specify Public Domain?
Don Armstrong [EMAIL PROTECTED] wrote: If you've got the time to communicate with the author to request that, it'd be good. Otherwise, I don't believe the ftpmasters are requiring this from public domain works yet. Thank you, and to Nathanael. I'll interpret that as note that down, but care for the real licensing problems first - there are plenty of them. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: License advice: LPPL with additional restrictions
MJ Ray [EMAIL PROTECTED] wrote: - You inform us that you created a changed version of the files. This is only necessary if you want to distribute it to others. Phone home clause. Take your pick from DFSG 1, 6 or whatever else you feel it breaks most. Sorry - I didn't even read so far, it seems. If I had, I'd asked differently. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Debian packaging and (possible) Eterm license violations
Ed Hill [EMAIL PROTECTED] wrote: I'm asking because the main upstream author (Michael Jennings) seems to think that the Fedora Guidelines (which are in some ways quite similar to the much-older DSC) are silly rules which discriminate against packages for no real reason: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182175 I don't know the author at all, but from his mail to this bug I don't think you can't blame him. His wording is inappropriate, but he has a point: If every single file in a source tarball has a license information, a separate LICENSE or COPYING file is nice, but not necessary at all. The other issue is a question of rpm/Fedora packaging policy which I can't comment on. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Is the GUST-FONT-NOSOURCE-LICENSE free?
Adam Borowski [EMAIL PROTECTED] wrote: On Thu, 16 Mar 2006, Frank Küster wrote: Adam Borowski [EMAIL PROTECTED] wrote: I've tried contacting Janusz Nowacki on 28 Apr 2005 and 14 Sep 2005 but received no answer. He's obviously alive, so this could be caused either by his lack of time or a mail misconfiguration somewhere on the way; anyway, I finally forgot about the issue. I have written to the three contact authors listed in antp's README.ENG earlier this week and waiting for an answer. Did you get any answer? Not yet. My old ITP for ttf-antp (#299771) is still lingering open, but as you seem to be interested in the whole GUST set, there is no point in having a separate badly-done package for just one family. I won't package anything additional; howeer the TeX task force is open to making their (Type1) fonts available to the non-TeX public (actually, Norbert joined the newly founded font team). The best idea would be separating the fonts out of tetex-base (an 80MB big package) and registering them with fontconfig. It appears that this is what you're going to do. If I'm wrong, I can correct my package, assuming that you can succeed in wresting a license statement from the authors. Having antp in X would be good as bitstream fonts lack Polish diacriticals, but having all TeX fonts usable in this way would be even better. We have indeed thought about providing the Type1 fonts in Tex for usage under X, but this is a long-term goal. Currently most of our time is spent on license issues, ways to provide users with a not-outdated TeX system for etch, and the daily work of bugs drippling in. We still hope to accomplish the big tetex-base restructuring before etch, including the fonts package for X, but I can't promise anything. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Interpreting the GFDL GR
Henning Makholm [EMAIL PROTECTED] wrote: Read in English, naturally by a native speaker, the license clearly applies restrictions against chmod, etc, and the above interpretation does not come from the license. I agree on both counts. Yet rather than taking the GR to mean that restrictions against chmod are OK in general, I think the GR says that the GFDL should not be taken to imply restrictions against chmod. If that leads to using an interpretaion that does not come from the license, then so be it - it's a lesser evil than deciding that free software does not need to be chmodable. For what it's worth, I voted for Amendment B over the original text because I am convinced that no court (at least in my legislation, I have not much knowledge of others) would rule that someone has violated the license because of chmod or similar - simply because it is the normal state in the computer world, even on Windows systems, that stuff is not-world readable. Or in other words because this restriction would make the whole license void, and that can't be what the licensor intended. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Is the GUST-FONT-NOSOURCE-LICENSE free?
Adam Borowski [EMAIL PROTECTED] wrote: Anyway, I've packaged one of the GUST fonts (antp) once. A ftpmaster (Joerg Jaspert) didn't have problems with the source; the reason for rejection was unspecified license: * CTAN says public domain * GUST's page mentions a GNU license * the embedded license field says just (C) by Polish TeX Users Group GUST I've tried contacting Janusz Nowacki on 28 Apr 2005 and 14 Sep 2005 but received no answer. He's obviously alive, so this could be caused either by his lack of time or a mail misconfiguration somewhere on the way; anyway, I finally forgot about the issue. As there's a relicensing going on, it's moot now anyway. Sorry, I mixed up antt and antp in my first mail. The license given is associated with the antt fonts, while the antp fonts don't have license information in the files on CTAN, and other license info is contradictory as you point out. I have written to the three contact authors listed in antp's README.ENG earlier this week and waiting for an answer. ANTP, at least in the version I got, has the hinting of several glyphs seriously botched; it can be easily fixed with FontForge by adjusting the glyphs or just dropping the hints. Have you told this to the authors, too? My old ITP for ttf-antp (#299771) is still lingering open, but as you seem to be interested in the whole GUST set, there is no point in having a separate badly-done package for just one family. No, I'm just verifying that every file we already have in teTeX has a proper, free license, and thus came about those two font families, antt and antp. I won't package anything additional; howeer the TeX task force is open to making their (Type1) fonts available to the non-TeX public (actually, Norbert joined the newly founded font team). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Package copyright problems
Jesse van den Kieboom [EMAIL PROTECTED] wrote: /** Copyright (c) 1992, 1995, 1996 Xerox Corporation. All rights reserved. Portions of this code were written by Stephen White, aka ghond. Use and copying of this software and preparation of derivative works based upon this software are permitted. Any distribution of this software or derivative works must comply with all applicable United States export control laws. This software is made available AS IS, and Xerox Corporation makes no warranty about the software, its performance or its conformity to any specification. Any person obtaining a copy of this software is requested to send their name and post office or electronic mail address to: Pavel Curtis Xerox PARC Coyote Hill Rd. Palo Alto, CA 94304 [EMAIL PROTECTED] */ I'm not sure how to handle this: Any person obtaining a copy of this software is requested to send their name and post office or electronic mail address to To me, that sounds like Public Domain, plus a reminder to abide by the law (which is irrelevant), plus a warranty disclaimer (which is irrelevant) plus a non-binding request for notification. I don't see any problems with inclusion in a GPL project. Also my package got rejected because it contains LGPL licenced parts, but I don't know which part that is (or is that because I use all sorts of libraries?). Any advice on the subject would be great. It seems to me as if the problems you have are not actual license incompatibilities, but an incomplete debian/copyright file, and obviously lack of knowledge (and care before the first upload) about the license status of the individual files. There's nothing special about packages that contain differently licensed parts, as long as they are compatible -you just need to clearly indicate this in the copyright file. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Is the GUST-FONT-NOSOURCE-LICENSE free?
Hi, this is an earnest question, the NOSOURCE in the name is misleading. The license can be found at ftp://tug.ctan.org/pub/tex-archive/fonts/antt/doc/fonts/antt/GUST-FONT-NOSOURCE-LICENSE.txt and is quite short: %%% This is a preliminary version, barring acceptance from the LaTeX %%% Project Team and other feedback, of the GUST Font Nosource License. %%% This licence is for use with free fonts distributed without source code, %%% e.g., fonts created with visual tools. %%% %%% For the most recent version of this license see %%% http://www.gust.org.pl/fonts/licenses/GUST-FONT-NOSOURCE-LICENSE.txt or %%% http://tug.org/fonts/licenses/GUST-FONT-NOSOURCE-LICENSE.txt % % This work may be distributed and/or modified under the % conditions of the LaTeX Project Public License, either version 1.3a % of this license or (at your option) any later version provided that % the following additional clauses will be observed: % % 1) As there is no universally relevant concept of source files, %no distinction is made between Work and Compiled Work; %hence, the relevant clauses of the %LaTeX Project Public License should be interpreted accordingly. % 2) Due to the nature of fonts, clause 6a of the LaTeX Project %Public License, version 1.3a, does not apply. A later version of %the LaTeX Project Public License may number or word this clause %differently; it is the substance that is important. % 3) It is requested, but not legally required, that derived works be %distributed only after changing the names of the fonts comprising %this work and given in the accompanying file MANIFEST.txt, and that %the files comprising the Work, as listed in MANIFEST.txt also be %given new names. Any exceptions to this request are also %given in MANIFEST.txt. % % The latest version of the LaTeX Project Public License is in % http://www.latex-project.org/lppl.txt % and version 1.3a or later is part of all distributions of LaTeX % version 2004/10/01 or later. LPPL clause 6a is just a restriction in LPPL, which is waved for works under the GUST... license, therefore the license is basically the same as LPPL granting some additional rights. Except for the source issue. The concrete example, as you might have guessed, are the ANTP fonts, which are available as PostScript Type1, TrueType and OpenType fonts. I have heard a talk of the author, Janusz Nowacki, last week at the DANTE meeting, and I got the impression that in fact he uses FontForge or a similar editor, and doesn't use its scripting facilities (much). I'll ask him again, but it seems to me that in this case the PostScript Outlines are in fact the preferred form of modification for the author, and I see no reason not to accept this as source in the sense of the DFSG, since there doesn't seem to be anything better. Consequently, the fonts would be free. What do you think? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
How to free GFDL'ed documents with existing Front Cover texts
Hi, assume a document licensed under GFDL, with no invariant sections (and ...) has a front cover text (like A GNU Manual) and a back cover text (like 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.). What should the developers do in order to make it DFSG-free (and not annoy RMS too much)? The GFDL says: , | If the Document already includes a cover text for the same cover, | previously added by you or by arrangement made by the same entity you | are acting on behalf of, you may not add another; but you may replace | the old one, on explicit permission from the previous publisher that | added the old one. | | The author(s) and publisher(s) of the Document do not by this License | give permission to use their names for publicity for or to assert or | imply endorsement of any Modified Version. ` Would a statement like If you create a derivative work of this document which is not part of a GNU project, we hereby permit you to remove the front cover text. Since the Free Software Foundation is unlikely to publish copies of your derivative work, you may also remove the back cover text. be helpful? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Free documents using non-free fonts - can they be in main?
Francesco Poli [EMAIL PROTECTED] wrote: On 05 Mar 2006 12:03:00 +0100 Claus Färber wrote: Frank Küster [EMAIL PROTECTED] schrieb/wrote: The reason for this is that building (La)TeX documentation * depends on the right number and order of commands to be executed, which one has to find by trial and error (it's very rare that authors upload Makefiles, since usually they aren't needed much) * depends on settings in local configuration files, which may differ from package author to package author and from version to version. In other words, there is no _complete_ source code for the compiled version of the documentation, which violates DFSG #2 (even without the font issue). Well, it seems so... Sorry, how do you two come to that conclusion? There's on automated build system. Whether the upstream author writes \OnlyDescription in the dtx file or in his ltxdoc.cfg does not change whether source code is available. Whether he used teTeX 2.0.2 or 3.0 doesn't, either. If it is really so difficult to figure out how to rebuild, even for knowledgeable people, then, yes, something is missing. Come on, having a comfortable, or even a sane build system isn't a prerequisite for being free. Typsetting just isn't as automatable as compiling executables with autotools. Especially if you made changes to the sources, there's no alternative to actually looking at the resulting document with your eyes and your subjective aesthetic judgement. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Free documents using non-free fonts - can they be in main?
Frank Küster [EMAIL PROTECTED] wrote: Francesco Poli [EMAIL PROTECTED] wrote: On 05 Mar 2006 12:03:00 +0100 Claus Färber wrote: Frank Küster [EMAIL PROTECTED] schrieb/wrote: The reason for this is that building (La)TeX documentation * depends on the right number and order of commands to be executed, which one has to find by trial and error (it's very rare that authors upload Makefiles, since usually they aren't needed much) * depends on settings in local configuration files, which may differ from package author to package author and from version to version. In other words, there is no _complete_ source code for the compiled version of the documentation, which violates DFSG #2 (even without the font issue). Well, it seems so... Sorry, how do you two come to that conclusion? There's on automated build system. Sorry, that should have been: There's *no* automated build system. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Free documents using non-free fonts - can they be in main?
olive [EMAIL PROTECTED] wrote: By the way is it that difficult to the package maintener to regenerate the document using free fonts? (the script texi2dvi do that nearly magically without having worrying about LaTeX rerun, makeindex, etc...) For a texinfo file, it's of course easy. For many LaTeX package documentation files, often created from dtx files, it is *that* difficult, as I already explained in this thread. I do not know the package in question but I am however confused. texi2dvi is able to compile standard latex code which are not texinfo (it look at the extension to know if it is laTeX or texinfo); you can also use the -l LaTeX option. Please care to read the older messages on that. Could you tell what the document is so that other people on this list might try. Have you tried yourself? dpkg -L tetex-doc tetex-doc-nonfree | grep /usr/share/doc/texmf Have you be in touch with the author (explaining the problem)? With some, yes. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Free documents using non-free fonts - can they be in main?
Francesco Poli [EMAIL PROTECTED] wrote: So, from the user's standpoint it's not a just comment out the \usepackage line... Rather, it's a 1. comment out the \usepackage line 2. fix the whole document so that it adapts to the free fonts 3. check if the result is acceptable, otherwise goto 2. Your claim that this is *not* a freedom issue, Honestly, I think this question is irrelevant. The binary version of the document is non-free, therefore I'll put it into tetex-docnon-free, and if we do have the sources, I'm going to put them in the same source package, even if the sources could go to contrib. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Free documents using non-free fonts - can they be in main?
Henri Sivonen [EMAIL PROTECTED] wrote: On Mar 5, 2006, at 03:06, Marco d'Itri wrote: The characters in the document are not subject to copyright. Yes, in the U.S. if all alleged computer programness of the font is gone and the glyphs are bitmapped or on paper but is that also true of embedded hinted fonts in PDF? (I thought such embedding is subject to license but foundries generally grant the permission to embed in final-form formats like PDF.) AFAIK, if a font is included completely in the PDF doucment, i.e. not subsetted, it's technically possible to extract it again (and even if it is subsetted, you just have to collect enough documents to get all glyphs). So if it is technically possible to extract and reuse the font, but forbidden by the license, this is non-free. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Free documents using non-free fonts - can they be in main?
Nathanael Nerode [EMAIL PROTECTED] wrote: I'm just going to note one important point about this whole thing. This is a main/contrib issue, *not* a main/non-free issue. Everyone agrees that the documents which use the non-free fonts are themselves free. The question is whether they depend on the non-free fonts. Are you sure? Isn't it the same as a program that contains in its sources a binary blob that's copied as-is to the executable, and the binary blob is non-free? Just that here the binary blob, i.e. the embedded fonts, is not even in the sources? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Free documents using non-free fonts - can they be in main?
Francesco Poli [EMAIL PROTECTED] wrote: Even though _you_ may not want to take the time to fix errors, it is essential for freedom that _the user_ has the tools he needs to fix errors if he so desires. He has. Just comment out the \usepackage line that changes the font, and do the correction. This is really not a freedom issue. If it's just so easy to make the document rebuildable with free fonts, why don't you do that once and for all? mode=repeat because we would have to check the new line, paragraph and page breaking still makes sense, especially in the two cases that are a PDF presentation. /mode Fixing source in order to make it actually rebuildable with the declared Build-Depends should not be left to the users... mode=repeat tetex-base does not rebuild documentation and does not Build-Depend on tetex-bin. /mode Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Free documents using non-free fonts - can they be in main?
Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Frank Küster [EMAIL PROTECTED] How do you fix errors in the document? By waiting for upstream to release a new version. Even though _you_ may not want to take the time to fix errors, it is essential for freedom that _the user_ has the tools he needs to fix errors if he so desires. He has. Just comment out the \usepackage line that changes the font, and do the correction. This is really not a freedom issue. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Free documents using non-free fonts - can they be in main?
MJ Ray [EMAIL PROTECTED] wrote: Frank K=FCster asked: Does debian-legal think that a document with a DFSG-free license and with sources available except for the embedded fonts is DFSG-free or not? I don't think a binary file follows the DFSG as a whole if it contains fonts which do not follow DFSG 2 (Source Code). That makes a 2:1 majority for is not suitable for main, and since that's my own conclusion, too, I'll accept this view. Sorry not to give the answer you wanted. Err, excuse me? The three mails by Marco, Mark and you were the first ones to give me an answer to the question I wanted answered, thank you for that. I didn't ask because I expected a is suitable for main, but just because I don't feel comfortable with legal stuff, and because I had a faint recollection that fonts are handled specially because of some special reason. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Free documents using non-free fonts - can they be in main?
Mark Rafn [EMAIL PROTECTED] wrote: Walter Landry [EMAIL PROTECTED] wrote: Also, everything in orig.tar.gz must be DFSG free. On Thu, 2 Mar 2006, Frank Küster wrote: Err, of course. That's why I ask. Does debian-legal think that a document with a DFSG-free license and with sources available except for the embedded fonts is DFSG-free or not? If the pdf includes non-free font implementations, then this is just plain non-free (and perhaps non-distributable if the source is GPL). The source will be LPPL in most cases, no problem here. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Free documents using non-free fonts - can they be in main?
olive [EMAIL PROTECTED] wrote: I think that the interpretation is that the DFSG applies to the fonts also. Indeed in this case, you cannot regenerate the same pdf file with tools from main. Quite often I agree with you that the DFSG are interpreted too strictly and does not refer the original view of Debian. But in this situation, I cannot see how a document which is not regenerable from entirely free stuff could be considered free. I agree. By the way is it that difficult to the package maintener to regenerate the document using free fonts? (the script texi2dvi do that nearly magically without having worrying about LaTeX rerun, makeindex, etc...) For a texinfo file, it's of course easy. For many LaTeX package documentation files, often created from dtx files, it is *that* difficult, as I already explained in this thread. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Free documents using non-free fonts - can they be in main?
Hi,
I'm wondering whether a document that's licensed under a DFSG-free
license, with TeX/sgml/whatever sources available and all, may use
non-free fonts. For example, the LaTeX source would contain
\usepackage{lucidabr}
and you'd be able to create the document from that source only if you
have either the commercial or otherwise non-free font installed, or you
replace/remove that line. Assuming that the original author has the
right to distribute and let re-distribute PDF files using that font
without limits, would it be okay for main to distribute the compiled
document (PDF) in the binary package, and the sources in the source
package?
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Re: Free documents using non-free fonts - can they be in main?
Bas Zoetekouw [EMAIL PROTECTED] wrote:
Hi Frank!
You wrote:
I'm wondering whether a document that's licensed under a DFSG-free
license, with TeX/sgml/whatever sources available and all, may use
non-free fonts. For example, the LaTeX source would contain
\usepackage{lucidabr}
and you'd be able to create the document from that source only if you
have either the commercial or otherwise non-free font installed, or you
replace/remove that line. Assuming that the original author has the
right to distribute and let re-distribute PDF files using that font
without limits, would it be okay for main to distribute the compiled
document (PDF) in the binary package, and the sources in the source
package?
I think not. AFAIK, the binaries in main must be built from the sources
in main, which wouldn't be possible in the case you're describing.
What's the problem with just using the normal Concrete TeX fonts?
That's not the point. In tetex-doc, we generally do *not* build the
documentation files from source, but instead use the ones included in
the orig.tar.gz, which in turn includes the author-provided versions
from CTAN. There are several reasons for that, some of which are
- tetex-base would have to build-depend on tetex-bin if we rebuild the
documentation
- we'd have to merge the upstream texmf.tar.gz (=tetex-base source
package) and texmfsrc.tar.gz (=tetex-src source package) into one
orig.tar.gz
- There's no automated way to reproduce the documentation exactly as the
author wants it, and once we would establish one, there would be no
way to detect whether a new upstream version changed that.
The reason for this is that building (La)TeX documentation
* depends on the right number and order of commands to be executed,
which one has to find by trial and error (it's very rare that
authors upload Makefiles, since usually they aren't needed much)
* depends on settings in local configuration files, which may differ
from package author to package author and from version to version.
So the author of a LaTeX package generates the documentation, looks at
it, adjusts their local configuration if necessary, and uploads the
package sources and the documentation PDF (CTAN requires this AFAIK),
but not local configuration files. I assume the CTAN admins would
reject uploads that include configuration files like ltxdoc.cfg,
because it would make CTAN's search facilities unusable for that
file.
As a consequence, you can't be sure to get the same document by simply
running pdflatex over the source file.
So, since we don't rebuild the documentation anyway, we just ensure[1]
that the files we include have a free license, and that the source is
complete.
So in the case of a document using a non-free font, it would be trivial
to free its source by simply commenting the line in the source. I'd
rather avoid that, because I think it bloats the diff.gz without adding
any value, but I wouldn't care much.
But the important question is whether we can distribute that *existing*
document in main.
Regards, Frank
Footnotes:
[1] Read: are about to ensure, see http://bugs.debian.org/345604
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
Re: Free documents using non-free fonts - can they be in main?
Walter Landry [EMAIL PROTECTED] wrote: As a consequence, you can't be sure to get the same document by simply running pdflatex over the source file. This is an excellent reason for why the documentation *should* be rebuilt. How do you know that you can make a reasonable document unless you build it yourself? If the usual dtx mantra: pdflatex package.dtx makeindex -s gind.ist makeindex -s gglo.ist -o package.gls package.glo pdflatex package.dtx runs without errors, you know that you *can* make a reasonable document, but you have not necessarily just created one. How do you fix errors in the document? As Bas wrote, all binaries must be built from source. This is one of many reasons why. This has never happened for LaTeX documentation, and nobody has ever complained. The CTAN policy has recently been amended to require (or is it still encourage?) that authors include the ready-made PDF version of the documentation exactly because of the problems with local configuration. Furthermore, we simply won't be able to do the work for all those documents: $ dlocate -L tetex-doc | egrep '\.dvi\.gz|\.pdf\.gz' |wc -l 337 at least not in a reasonable timeframe. And it still doesn't answer my question whether we can distribute documents prepared with a non-free, distributable font. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Free documents using non-free fonts - can they be in main?
Walter Landry [EMAIL PROTECTED] wrote: Also, everything in orig.tar.gz must be DFSG free. Err, of course. That's why I ask. Does debian-legal think that a document with a DFSG-free license and with sources available except for the embedded fonts is DFSG-free or not? I don't want to hear technical comments whether it is desirable or doable to rebuild the documentation, but whether it is legally possible to distribute such documents. And, just for the curious, the particular example why I came to that question is a document that is a PDF presentation. With a font change, we'd have to rework all the spacing and page breaking, and probably rather put it into contrib (or non-free if that's the only example, since we already have a package with non-free stuff but none with contrib). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Free documents using non-free fonts - can they be in main?
Frank Küster [EMAIL PROTECTED] wrote: I forgot to answer one question - please follow up to devel if you want to discuss this, since it isn't a legal issue. If the usual dtx mantra: pdflatex package.dtx makeindex -s gind.ist makeindex -s gglo.ist -o package.gls package.glo pdflatex package.dtx runs without errors, you know that you *can* make a reasonable document, but you have not necessarily just created one. How do you fix errors in the document? By waiting for upstream to release a new version. We have already enough work to do with the Debian packaging, identifying the LaTeX packages responsible for bugs that users report, contacting the maintainers etc. In some cases where the maintainers were MIA, we even helped to find a new person. But we really have no time to improve the documentation texts. If the documentation is under a DFSG-free license, the (new) maintainer is the person to do that. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Missing documentation for autoconf
Patrick Herzig [EMAIL PROTECTED] wrote: On 20/02/06, Simon Huerlimann [EMAIL PROTECTED] wrote: (...) Simon, are you trolling? Not intentionally. (...) Another reason was the following paragraph from autoconfs README.Debian: No documentation, because the Debian project has decided that the GNU FDL is not an acceptable license for documentation. If you disagree with this decision, write to [EMAIL PROTECTED] I can't do anything about it by myself, so filing bugs will do you no good. Sorry. (...) That readme seems at least borderline trolling to me. I hope that's not intentional. I hope that, too. #353833. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Missing documentation for autoconf
Simon Huerlimann [EMAIL PROTECTED] wrote: Hi I'm bitten by the removal of the autoconf documentation. I wanted to do some bugfixing in a configure.in script. But as I'm currently offline, I don't have access to the needed documentation. Well, then... No more FOSS development for today. Has nobody volunteered to package one of the three autotools doc packages in non-free? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Missing documentation for autoconf
Frank Küster [EMAIL PROTECTED] wrote: Simon Huerlimann [EMAIL PROTECTED] wrote: Hi I'm bitten by the removal of the autoconf documentation. I wanted to do some bugfixing in a configure.in script. But as I'm currently offline, I don't have access to the needed documentation. Well, then... No more FOSS development for today. Has nobody volunteered to package one of the three autotools doc packages in non-free? Err, actually autobook and autoconf-doc *are* in non-free. Simon, are you trolling? How do you explain that you would like to continue to use GFDL'ed (or OPL'ed, for that matter) documentation, but refuse to add non-free to you sources list? And how come that you would have been able to use the documentation if it was in main, even when you are offline? Do you have a CD in you pocket with a daily updated mirror of sid only on it? Or did you have it installed, but run a script that automatically removes every installed package that is also removed from the archive? Or are you just trolling? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Software license used for SHA-2 reference code
Steve Langasek [EMAIL PROTECTED] wrote: Royalty free license to copy and use this software is granted, provided that redistributed derivative works do not contain misleading author or version information. Royalty free license is also granted to make and use derivative works provided that such works are identified as derived from this work. [...] The license grants permission to use, copy, create derivative works, and redistribute. The only stipulations are that the original author be credited, and derivative works be labeled; and there's a warranty disclaimer. And when you violate the license by distributing modified versions with misleading information, you loose your right to copy and use the software. But that's not a freeness problem, I guess. I think this is clearly DFSG-compliant. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: EU antitrust is also cool
olive [EMAIL PROTECTED] wrote: Alexander Terekhov wrote: On 2/14/06, Yorick Cool [EMAIL PROTECTED] wrote: [...] First off, hello. Hello Yorick. What is your educated opinion regarding the GPL being in trouble re http://europa.eu.int/comm/competition/legislation/treaties/ec/art81_en.html? Germany (which part of the EU) has declared the GPL legal. See http://lwn.net/Articles/73848/ Germany hasn't done anything, at least nothing is described in this article. A particular german court has spoken. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: A new practical problem with invariant sections?
Adam McKenna [EMAIL PROTECTED] wrote: On Mon, Feb 13, 2006 at 10:07:21AM -0800, Thomas Bushnell BSG wrote: By contrast, if there is an invariant section written in Japanese, I cannot remove it, I cannot distribute a translation instead, I must instead simply not transmit the document *at all* if I am stuck with an ASCII-only medium. I guess you've never heard of UUENCODE. That won't help: If the device is not capable of uudecoding and displaying the resulting Japanese, the license requirement cannot be fulfilled. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: A new practical problem with invariant sections?
Adam McKenna [EMAIL PROTECTED] wrote: On Tue, Feb 14, 2006 at 09:44:33AM +0100, Frank Küster wrote: Adam McKenna [EMAIL PROTECTED] wrote: On Mon, Feb 13, 2006 at 10:07:21AM -0800, Thomas Bushnell BSG wrote: By contrast, if there is an invariant section written in Japanese, I cannot remove it, I cannot distribute a translation instead, I must instead simply not transmit the document *at all* if I am stuck with an ASCII-only medium. I guess you've never heard of UUENCODE. That won't help: If the device is not capable of uudecoding and displaying the resulting Japanese, the license requirement cannot be fulfilled. That's ridiculous. To me, it's rather sad. The requirement is not that the sections must display on every device imaginable anyway. The requirement is that the sections are preserved when the document is distributed. So how can I distribute the document on that device if I cannot include it on the device? I cannot, and hence the modifications needed to use it on that device are not allowed. Of course I can distribute the complete document and tell the owner of such a device how to create a derivative that fits on it. But then he may no longer distribute it. That's non-free. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: OFL license analysis
Mark Rafn [EMAIL PROTECTED] wrote: Mark Rafn [EMAIL PROTECTED] wrote: This discussion seems to have gone into the weeds about WHY someone would want to make a change and whether Debian is able to make such changes reasonably. On Mon, 30 Jan 2006, Frank Küster wrote: Well, only in part. A font that you can't rely on is mostly useless... I assume the you in this sentence is a hapless user of a system whose software she does not control/understand, not the person wishing to make and distribute changes to the font. Correct me if this is an incorrect reading. ACK. A license that tries to protect a user from an incompetent developer/distributor/sysadmin is going to be non-free. There's really no way around this. The only way to be free is to allow a true fork of the software, which means a dropin replacement, even if the licensor disapproves. Most existing forks *do* identify themselves as being something different. What ever happenened to the LaTex license, by the way? That had the same non-freeness. You seem to have a different opinion on this as the debian-legal people who negotiated with the LaTeX project and together developped the LPPL version 1.3. In this version, the requirement to change file names (or LaTeX package names) was dropped, probably because it was regarded as too non-free, whereas it was decided that any changed version should indicate that it was changed in the version string that is (or to some degree only will be) part of the API. Hmm. I claim that it is a mistake for Debian to consider something free if it requires binary incompatibility to distribute a modified version. Version strings are a funny edge-case, where if they're normally just human-readable information with no programmatic effect I can live with it, but when it becomes common to programmatically read them and behave differently, then it's part of the API and must be modifiable (or not) without restriction. The revised LPPL says: a. If a component of this Derived Work can be a direct replacement for a component of the Work when that component is used with the Base Interpreter, then, wherever this component of the Work identifies itself to the user when used interactively with that Base Interpreter, the replacement component of this Derived Work clearly and unambiguously identifies itself as a modified version of this component to the user when used interactively with that Base Interpreter In practice, this means that the version string displayed in the file log of a LaTeX run will be different, and that the user, or a developer of a package that uses the work, has the possibility to check for the version and act accordingly; it does of course not mean that he must do such a check. It's possible that Debian made a mistake if that's what LaTeX does with these strings. Wouldn't be the first time. I guess before we continue discussing this, we both should look up in the archives the discussion that has taken place between the LaTeX team and Debian people. It seems a clear test: if I can't distribute a changed version that can be dropped into a system without changing other software, it ain't free. You can never distribute a bugfixed version of a font with the same name (identifiers, ...) and, without changing other software, get the same system behavior. That's not a question of freeness, it's a technical problem. No, the intent is to get DIFFERENT system behavior by changing the free component, without changing other software or documents. That's the freedom I'm worried about here. Though the ability to get the same behavior is there too (perhaps a performance fix or other result-compatible implementation change), it's just a special case of the real freedom to make changes. I know, the freedom to shoot yourself into the foot. But I think it's not unreasonable to require that the user is at least notified what happened, and that can only be done by changing the identifier in an interactive dialog, or by issuing font substitution warnings in a batch run. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: OFL license analysis
Frank Küster [EMAIL PROTECTED] wrote: In practice, this means that the version string displayed in the file log of a LaTeX run will be different, and that the user, or a developer of a package that uses the work, has the possibility to check for the version and act accordingly; it does of course not mean that he must do such a check. Also note that due to the way TeX works this can, in principle, be done even without that. If you think your document should only be processed with an unchanged version of foo.sty, you can look at every macro provided *and*used*internally* by foo.sty and check whether it has been changed. Having the version number available is just more convenient... Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: OFL license analysis
Mark Rafn [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Debian decides to distribute works containing your font. The original upstream disappears. A bug is discovered in the font, and Debian needs to fix it. On Sun, 29 Jan 2006, Marco d'Itri wrote: Yes, and this is considered a feature. Usually existing documents should not break because a font is changed, even if this fixes a bug. On Sun, 29 Jan 2006, Don Armstrong wrote: The same argument applies equally well to programs. We should be intelligent enough in our fixing of bugs in fonts not to break existing documents, That's plain impossible. A bug in a font could be a wrong kerning. Kerning means the hints in the fonts that indicate that in a particular combination of letters, two adjacent letters need less (or more) space between them than their size would dictate. For example the letters VA must be shifted a little towards each other, otherwise it will look nearly like a whitespace between them. If there is such a bug in a font, changing it implies that the word-wrapping algorithm has a high chance of finding a different solution, and thus change existing documents. There's simply no solution that allows both for stable docments and for bug fixing. The lmodern fonts, for example, are still under development, and they warn the user and reserve themselves the option to change things like the kerning. But if you've got a font that is in wide use and regarded as stable, changing the kerning is a design decision and should in fact change the name under which the font is available to the user and to documents. just like we should be intelligent enough in our fixing of bugs in programs not to break existing scripts. This discussion seems to have gone into the weeds about WHY someone would want to make a change and whether Debian is able to make such changes reasonably. Well, only in part. A font that you can't rely on is mostly useless... Name-change requirements are acceptible (barely) on the package name, but not API identifiers, and that includes filenames that are part of an API. [...] What ever happenened to the LaTex license, by the way? That had the same non-freeness. You seem to have a different opinion on this as the debian-legal people who negotiated with the LaTeX project and together developped the LPPL version 1.3. In this version, the requirement to change file names (or LaTeX package names) was dropped, probably because it was regarded as too non-free, whereas it was decided that any changed version should indicate that it was changed in the version string that is (or to some degree only will be) part of the API. It seems a clear test: if I can't distribute a changed version that can be dropped into a system without changing other software, it ain't free. You can never distribute a bugfixed version of a font with the same name (identifiers, ...) and, without changing other software, get the same system behavior. That's not a question of freeness, it's a technical problem. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Please review: The OFL (Open Font License)
[EMAIL PROTECTED] (Marco d'Itri) wrote: On Jan 30, Gervase Markham [EMAIL PROTECTED] wrote: Not if they choose a different name. For a font bug-for-bug compatibility may be very important to preserve correct rendering of docuements. You do, of course, mean preserve _incorrect_ rendering of documents ;-) Yes. Well, let's say preserve rendering. A no-longer incorrect letter kerning might, via changes in line wrapping, lead to a completely incorrect page breaking, or figure placement, etc., and in consequence to a much less correct rendering. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: OFL license analysis
Don Armstrong [EMAIL PROTECTED] wrote: This exact argument can be made to apply to programs. We as distributors (or our users as users) should be able to make the determination whether it's appropriate to break compatibility to fix the bug, or keep compatibility and live with the bug. A license really has no business forcing technical decisions like that on us or our users. We've allowed a very narrow compromise to require that the name of the work itself (or its version) change, but that's it; a requirement that other parts of the work change beyond its name goes beyond DFSG §4. Well, in a sense every font file (the standard version, the italic, bold, small caps, etc versions) is a work of its own, and the complete distribution is only an aggregate work. For commercial fonts it is common that you buy each separately. Anyway: would, in your opinion, a restriction be acceptable to change either the version or, as long as there's no technical solution yet that includes this version in the API, the font name? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Creative Commons negotiations
Hi Evan, hi all, is there any public information about the progress in the talks with CC about clarification/amelioration/whatever of their licenses? TIA, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Creative Commons negotiations
Evan Prodromou [EMAIL PROTECTED] wrote: I don't have an idea of when the 3.0 license draft will be available, what other changes there may be, or pretty much where things go from here. But I do know that CC seems to take DFSG-compatibility seriously and that they're going to be open to our input. Thank you for the report; it sounds promising, but on the other hand it sounds as if talking upstream authors[1] into relicensing their documentation with a CC license will not be an option for etch. Regards, Frank [1] Of GFDL-or-other licensed documentation where use the same as for the program is not applicable -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Ironies abound
Josh Triplett [EMAIL PROTECTED] wrote:
Did we ever find concrete evidence that TeX comes with a license to
create modified versions under different names? The copyright notice
at the top of tex.web presents only the patch option, and
/usr/share/doc/tetex-bin/copyright is not of much help.
Our copyright file is a nightmare, we really *ought* to sort out which
file is under which copyright and license, and document that. I still
hope we'll manage it for etch. As for tex.web, the notice at the top is
misleading, it seems to assume that copying means that the name is
unchanged. Later in the file, it is written:
,
| If this program is changed, the resulting system should not be called
| `\TeX'; the official name `\TeX' by itself is reserved
| for software systems that are fully compatible with each other.
| A special test suite called the ``\.{TRIP} test'' is available for
| helping to determine whether a particular implementation deserves to be
| known as `\TeX' [cf.~Stanford Computer Science report CS1027,
| November 1984].
`
Some searching around led to an article The Future of TeX and
Metafont, written by Knuth, a copy of which is available at
http://www.tug.org/tex-archive/digests/tex-mag/v5.n1. From this article:
I have put these systems into the public domain so that people
everywhere can use the ideas freely if they wish.
[...]
anybody can make use of my programs in whatever way they wish, as
long as they do not use the names TeX, Metafont, or Computer Modern.
[followed by conditions for using the names based on a test suite]
The wikipedia article for TeX is also a starting point, it leads to a
different article by DEK. It's split into two pdf files, the beginning
is in http://www.tug.org/TUGboat/Articles/tb07-2/tb15gordon.pdf, the
interesting part in
http://www.tug.org/TUGboat/Articles/tb07-2/tb15knut.pdf where he also
says:
,
| All of the methods described in these books are in the public domain;
| thus anybody can freely use any of the ideas. The only thing I'm
| retaining control of is the names, TeX and METAFONT: products that go
| by this name are are obliged to conform to the standard. If any
| changes are made, I won't complain, as long as the changed systems are
| not called TeX or METAFONT.9
`
Further searching reveals several sources that indicate the American
Mathematical Society obtained a trademark on the name TeX for the
purposes of enforcing those conditions. Given the limitations on the
scope of such a trademark, I don't believe this can render the program
non-free. In the worst case, it might be necessary to expunge
non-functional references to the names before making modifications.
Do you have links or references for this trademark thingie? I read it
so many times that I tend to believe it's true, but never found and
conclusive evidence...
As far as LaTeX goes, the LPPL has been fixed, though there is still a
need to do a license audit to check for packages which add additional
restrictions.
... and for packages with non-free docs. Any help is appreciated.
Regards, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)
object code in the GPL and printed copies
Hi, since I couldn't find it in the archive, I have to ask here: Has it been discussed, and if yes to what end, whether a printed version (of a GPL'ed document) would be object code as treated in section 3, , | 3. You may copy and distribute the Program (or a work based on it, | under Section 2) in object code or executable form under the terms of | Sections 1 and 2 above provided that you also do one of the following: ` On the one hand, treating printed copies of the work just the same as any digital compiled version sounds logical and in the intent of the license. On the other hand, a book or booklet is something very different from a PDF or PostScript file, and probably more so in the view of lawyers and judges than ordinary netizens. Therefore an alternative interpretation could also be used: That paper copies of the document are not addressed at all by the license (and can therefore be more restricted by the copyright holder, like for non-commercial use only). And of course, the main concern why I ask this here: If an author intents their documentation to be as freely usable as their program (and therefore wants to license it under the program's license), but wants to restrict commercial trade of the printed version, and therefore assumes the second interpretation, would such a document qualify for Debian (main, of course)? TIA, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: GPL v3 Draft
Alexander Terekhov [EMAIL PROTECTED] wrote: Doesn't anyone outside the academic legal community harbor any suspicion that the GPL is broken? Eben Moglen has propounded specious legal theories without ever citing relevant case, statute or other legal authority supporting his stance on the validity of the GPL and his claim that it is not a(n) (invalid) contract. No idea about that, but I'd like to point out that the world is larger than just the US. A german court has stated that the GPL is valid in Germany, and that it is to be treated as a (valid) contract. Or rather as the Allgemeine Geschäftsbedingungen; if you go to a shop and buy something, not only the individual words you talk with the shopkeeper (how much is that shirt? 20 Euro Here you are) are part of the contract, but also a non-individual legalese text if it can plainly be seen at the cash desk, or if you are referred to it in an online-shop. The german original text is at http://www.jbb.de/urteil_lg_muenchen_gpl.pdf, an english translation at http://www.jbb.de/judgment_dc_munich_gpl.pdf Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: object code in the GPL and printed copies
Pedro A.D.Rezende [EMAIL PROTECTED] wrote: Alexander Terekhov wrote: Object code is a well established term. GNUspeak is irrelevant. The Copyright Act defines a computer program asa set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. 17 U.S.C. § 101. The copyright act is WRONG. A computer program can NEVER be a SET of statements or instructions..., a computer program has to understood as a SEQUENCE of statements or instructions I wouldn't be too sure that set doesn't have a different meaning to lawyers than it has to mathematicians or computer scientists. Anyway, I doubt whether sequence is correct, too - unless you redefine sequence to include conditional execution and loops. Bad laws can not change the nature of the symbolic realm, where computer programs exist. For one thing, GNUspeakers know that realm better than self-aggandizing, sophist lawmakers and lawyers. This statement is probably both right and irrelevant. We're dealing here with legal aspects of creating a Linux distribution, and therefore the language and thinking of lawyers does and should have an impact on the outcome of the discussion... Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: object code in the GPL and printed copies
Jeremy Hankins [EMAIL PROTECTED] wrote: In the end, of course, not everyone is going to agree. And frankly, I think that's the more important issue. Many people who use debian are going to assume that they don't suddenly lose the freedoms of the DFSG just because a document has been printed on paper rather than recorded on a CD. And if Debian is going to decide otherwise, it should be as big and noise-making a decision as the whole bit about documentation was -- perhaps even louder. Otherwise, I believe that we would be violating our commitments to our users. Got your point. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: object code in the GPL and printed copies
Pedro A.D.Rezende [EMAIL PROTECTED] wrote: Alexander Terekhov wrote: Object code is a well established term. GNUspeak is irrelevant. The Copyright Act defines a computer program asa set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. 17 U.S.C. § 101. The copyright act is WRONG. A computer program can NEVER be a SET of statements or instructions..., a computer program has to understood as a SEQUENCE of statements or instructions Pedro, which definition of object code should I use instead? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
License of fonts included in X.org sources (was: [tex-live] Re: Utopia fonts)
Dear debian-legal people, Ralf Stubner [EMAIL PROTECTED] wrote: It is quite odd that on the one hand Adobe says that all the rights are with the X consortion, while on the other hand there is no license information what so ever from X.org or Xfree. And some person (Han The Thanh) tried to get information from them, because he wanted to distribute a modified version, and didn't get a response for months. Do you know which person we could contact among the X.org people? Regards, Frank P.S. The fonts are excluded from xfonts-scalable-nonfree due to no license statement, but included in gsfonts-other-nonfree because of the license statement on CTAN, the origin of which is now unclear. -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: License of fonts included in X.org sources
Hi, it just occurred to me that the X strike force might be a better place to ask this: Frank Küster [EMAIL PROTECTED] wrote: Dear debian-legal people, Ralf Stubner [EMAIL PROTECTED] wrote: It is quite odd that on the one hand Adobe says that all the rights are with the X consortion, while on the other hand there is no license information what so ever from X.org or Xfree. And some person (Han The Thanh) tried to get information from them, because he wanted to distribute a modified version, and didn't get a response for months. Do you know which person we could contact among the X.org people? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: License of fonts included in X.org sources
Daniel Stone [EMAIL PROTECTED] wrote: On Tue, Oct 18, 2005 at 02:50:32PM +0200, Frank Küster wrote: Do you know which person we could contact among the X.org people? More context, please. Which fonts? In this special case, it's about the Utopia fonts gsfonts-other-6.0/putbi.pfa gsfonts-other-6.0/putb.pfa gsfonts-other-6.0/putri.pfa gsfonts-other-6.0/putr.pfa Fonts are a particularly hairy area of our licensing. If the licence information rests with 'the X consortium', then it may well still be tied up deep in the corridors of TOG, or within the old X.Org group. In any case, the current X.Org Foundation doesn't have it in any official sense, but knowing which font is a good start. Try [EMAIL PROTECTED]; some of the people from the old XC still hang around there. Well, the problem was that someone probably already did that: , Here is an excerpt from Thanh's mail ([EMAIL PROTECTED]): | | However I am not sure that I can modify them to add | vietnamese support, because I am very ignorant of | license/copyright issues | | Concerning Adobe Utopia, I did my best to try to find out | the answer, but without success: I asked people at Adobe | first and got a response saying that they have granted the | font license to X Consortium, so now only X Consortium can | grant the permission to modify these fonts. I wrote to X.Org | and got a response saying that my question is being processed | and then nothing (it was a few months ago). So I gave it up. ` This is why I asked whether anybody knows about a specific person we could contact. Or at least about a subject that might attract the people who might know. TIA, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: [Fwd: Re: mplayer, the time has come]
A Mennucc [EMAIL PROTECTED] wrote: Henning Makholm wrote: If they are in the upstream sources and free enough for us to ship in the source package, we should ship them in the source package. If mplayer is so free, so why is it so darn difficult to have it in Debian??? Calm down, you two. It seems they are not free enough (or rather, their copyright and license status is unclear). So you could just have answered: Yes, you're right. But they aren't free enough, and therefore I deleted them. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: GPL as a license for documentation: What about derived works?
MJ Ray [EMAIL PROTECTED] schrieb: =?iso-8859-1?q?Frank_K=FCster?= [EMAIL PROTECTED] wrote: please point me to an older thread if this has been discussed before, I didn't find it in the archives. Did you check http://www.gnu.org/licenses/gpl-faq.html first? I didn't find it helpful in this case. 1. The first is whether there are any established criteria by which the creation of a derived work can be distinguished from mere aggregation. http://www.gnu.org/licenses/gpl-faq.html#MereAggregation is a starting point, if you translate it to documents. I think it depends whether the first work could be replaced with an equivalent without requiring changes to the later one. Oh, thanks. This is a criterion that can be well used for documentation (as opposed to the software-centric , | depends both on the mechanism of communication (exec, pipes, rpc, | function calls within a shared address space, etc.) and the semantics | of the communication (what kinds of information are interchanged). ` AIUI, the GPL can't override copyright law and it only grants extra permissions. It doesn't take any away. A text published with no licence defaults to all rights reserved usually. Thanks, that also made things clearer to me. It sounds so obvious once someone said it... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: GPL - specifying the preferred form for modification
Nathanael Nerode [EMAIL PROTECTED] schrieb: Glenn Maynard wrote: The GPL very deliberately does not specify the preferred form for modification, and authors shouldn't do so (at least not in a legally-binding way or an attempt to interpret the GPL). Right. I think there is no harm in saying My preferred form for modification is the texinfo source, as long as it is *not* a legally-binding change. We have suggested such things to make things clearer for people who are uncomfortable and fearful about the use of the phrase source code for documentation, so as indicate that it is a meaningful phrase. We do not want such statements to act as a restriction. Yes, it was in this sense that I suggested this addition. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: GPL as a license for documentation: What about derived works?
Thank you, Andrew, Michael, MJ and Raul for your comments. I was asking this question because I got involved in a license discussion with an author who published a preliminary version of a document on a preliminary licsense, the Creative Commons Attribution-NonCommercial-ShareAlike 2.0. During the discussion, he asked for a recommendation for a free license for his text, should he wish to distribute it. He seemed to be concerned about other people making unfair use of the text (without having any real clue about what is fair use probably). And he was clearly looking for something that would bind everybody to use the same free conditions for texts based on it: He was objecting to putting it into public domain. I hope I have understood most of the things you wrote, and it seems clearer to me now what you can do, and what you can't do, by releasing a text under GPL. But still there's a lot of cruft in it that might be just confusing for an author who considers GPL for his text, or even add confusion to a possible lawsuit. Would it be possible to create something like a reduced form of the GPL, with program replaced by text, object code by typeset form, and with all the executable-specific cruft rippeed off (or replaced)? With such a license I would hope that we could convince individual authors to switch from GFDL to this GPL-doc (of course not the FSF...). Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: GPL as a license for documentation: What about derived works?
Raul Miller [EMAIL PROTECTED] wrote: On Mon, Jan 31, 2005 at 12:09:18PM +0100, Frank Küster wrote: Would it be possible to create something like a reduced form of the GPL, ... This isn't really the right forum for that. Well, hm, yes, no. Indeed the case that made me post this question dealt with a new document. But on the other hand, I have a problem as a Debian developer with existing documents in existing packages: Namely that I have to approach upstream authors and tell them We don't think the GFDL you have chosen for your document is a free license. The logical question they ask me is What else should I use as a license? Therefore, I assume that more maintainers will get to this question once sarge is released. We should be prepared and have a good answer to it. And it *might* even be that having a good answer to it will increase our chances to get FSF to relisence their stuff: It's not only about the FSF, but also about individual contributors who might put some pressure on them; and they might be more inclined to do this when they see us as a constructive participant of the discussion¹ Maybe the fsf licensing forum would be better? Do you expect that they would recommend anything else but GFDL? Or if there are differing opinions there, that there will be more than just one more flamewar about the GFDL? Furthermore, I am a Debian developer who is primarily skilled for doing my work on my packages, and who sometimes has a good relation to upstream authors. But I don't have much experience with legal considerations, and I wouldn't want to come out of such a discussion with some recommendation to an upstream author, only to find later that the license isn't approved by debian-legal - for reasons I understand, but couldn't find myself. Therefore I am asking here for advice and help. Regards, Frank ¹even if in particular their cases, the obvious alternative is the license of the documented program, GPL -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: GPL as a license for documentation: What about derived works?
MJ Ray [EMAIL PROTECTED] schrieb: =?iso-8859-1?q?Frank_K=FCster?= [EMAIL PROTECTED] wrote: Would it be possible to create something like a reduced form of the GPL, with program replaced by text, object code by typeset form, and with all the executable-specific cruft rippeed off (or replaced)? It would be possible (see GPL FAQ cited previously), but I think it's superfluous because the GPL's definition of Program is flexible enough to include documents. It might be flexible enough from a legal point of view. But then, it seems the minds of authors aren't always flexible enough. Perhaps I would have to help them bend and stretch... It's undesirable because GPL-doc would be incompatible with GPL unless you make specific provision for a LGPL-style upgrade. For real standalone documentation, I don't know wether this would be a problem in practice. Hm. I should read about compatibility of GPL'ed code with BSD or artistic licensed code. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
GPL as a license for documentation: What about derived works?
Hi, please point me to an older thread if this has been discussed before, I didn't find it in the archives. Let's assume a piece of technical documentation (standalone, i.e not part of a software package; something like selfhtml or LaTeX's lshort), is licensed under GPL, with an additional text stating what the preferred form for modification is (say, LaTeX or docbook). As I understand it, anybody can take the text and publish it as a printed book, as long as he also prints where the source code can be found (GPL clause 3.b or 3.c). If he creates a derived work - for example by extending each chapter, but keeping the structure and most of the original text - he has to license that under GPL, too (and thus provide the source code). I have two questions 1. The first is whether there are any established criteria by which the creation of a derived work can be distinguished from mere aggregation. I assume that if a book on the technical aspects of computer typesetting would include, as an appendix, a GPL'ed text on typography, this would be only aggregation. At least if typographical questions don't play a role in the rest of the text. But what if there are extensive references to specific parts of the appendix in the text? What if it is a chapter in that book? 2. I fail to find the right technical or juridical terms here, but I guess in most jurisdictions it is allowed to cite other texts, or to publish a book that discusses some text in detail (like interpretation of a poem, or detailed rebuttal of a scientific paper). In such a case, the book would not exist without prior existence of the original text. Would such a thing be regarded a derived work, and would therefore a text published under GPL impose restrictions that would not hold for a text published without a license, simply in printed form? TIA, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: GPL and command-line libraries
Wouter Verhelst [EMAIL PROTECTED] schrieb: On Tue, Nov 02, 2004 at 09:53:21PM +0100, Wesley W. Terpstra wrote: 4. Writing to debian-legal and asking for advice. Now that's a good idea. Why did you do that on debian-devel instead? s/instead/, too/ Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Blast from the Past: the LaTeX Project Public License, version 1.3
Branden Robinson [EMAIL PROTECTED] wrote: On Sun, Jul 11, 2004 at 02:38:20PM +0200, Hilmar Preusse wrote: On 11.07.04 Branden Robinson ([EMAIL PROTECTED]) wrote: Hmmm. I don't suppose it's a *huge* deal, but do you think we could ask upstream to apply the new LPPL to the existing codebase? This doesn't require anything more than an email on their part, which we could then stick in debian/copyright. Well, our upstream is TE. Most of the code is not written by him, so he doesn't really have control over these things. Take e.g. KOMA-Script: the package is explicitely linked with LPPL 1.0. If you ask Markus Kohm, he'll refuse to upgrade to the next version (at least I read some postings about this by him in dctt). Well we could put 1.3 into teTeX 2.0.2 and hope, that most of the problems will be resolved then... Er, well...it doesn't really help the package's DFSG problems if the DFSG-free version of the license isn't actually used. Also, is it the new version of the LPPL Markus Kohm doesn't want to upgrade to, or the new version of some software? I think it was established during the long, long discussions on -legal that previous versions of the LPPL were not DFSG-free. Markus does not want to upgrade the license. However, this is a kind of special problem, and I am not sure which license versions he dislikes - he is using LPPL 1.0, while the current change is from 1.2 to 1.3. Might be that we can convince him to use LPPL, or maybe LPPL with some additional restrictions for the distribution of unmodified copies (namely, only with the original documentation included). On the other hand, while I personally think KOMA-Script is an important package, quantitatively Markus' contribution is only one small part. There are probably many packages with a version X or later clause, but also many without. There are 716 directories in our texmf tree. I estimate that at most one third of them are higher-level directories, that makes nearly 500 lowest-level directories, or lets say 400 individual packages. The average number of authors per package will probably be below 2, but you can see that even if only 20% of the packages do not have a or later clause, and some use GPL or Artistic license, we would need to contact dozens of individuals, many of which have new E-mail addresses now. Sorting this out and contacting all upstream authors would take a hell lot of time. Asking them to upload a new version to CTAN instead of sending us a mail, because such a mail would be problematic wrt to DFSG clause 8, would take even more time. So much time that we will not be able to accomplish this within this year. I'm open to suggestions for how we should cope with this. I currently see three possibilities: a) release sarge without TeX packages b) find a group of about 10 people who are willing to make those upstream contacts, create a separate mailing list (debian-tetex-maint would become unusable), somehow make sure that those people are gentle to upstream authors. bb) finding the problematic cases and splitting them out as tetex-nonfree, as we had previously, would probably be faster, but still need additional people to work on it. c) Make an exception for sarge (and perhaps an other exception for a licenses-clarification-only upload into stable) Some comments on this: Option a) would not only be bitter for us, the maintainers, but also affect many other packages. apt-rdepends -r tetex-base | \ sed -e 's/.*Reverse Depends: //g' | \ sed -e 's/[[:space:]]*(.*)//g' | \ sort | uniq |wc -l gives 136. Some of this would have to be left out, too, some are meta-packages (e.g. education-*), some would need work and tweaking to take out the dependencies (e.g. font packages that provide their files both for TeX and X). Which wouldn't speed up sarge's release, either. Option b) is completely unrealistic. If anybody wants to convince me of the opposite, please start working on #218105 (but please wait until I've submitted my preliminary work I did this weekend). Option c): I think this could be regarded as a case for an exception, since it is mainly because of the timing of sarge's release in comparison to the license update and teTeX release that we currently have this situation, and that most authors chose the LPPL because they wanted a free license. I also think that if we left teTeX out of sarge we wouldn't do ourselves a favor, but rather offend sensibilities of the people you have so productively worked with to make the LPPL better, and free. I would be willing to raise this issue on -release, but not without some further input from the -legal people. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: Blast from the Past: the LaTeX Project Public License, version 1.3
Hi, thank you Branden for your comparison and all the work you folks put into this issue! Branden Robinson [EMAIL PROTECTED] wrote: Oddly, the version of the LPPL shipped in tetex-base[8] is still version 1.2, and a review of the tetex package changelog shows no new upstream release since 2.0.2.[9]. I am therefore not sure Debian is shipping anything under the new license yet. Not in the teTeX packages, perhaps in some other TeX-related package. A new teTeX release is under way, but I doubt that it will make it into sarge. On the other hand, I think many LPPL-licensed files contain a version 1.2 or later clause. I did not follow the discussion regarding the old LPPL on -legal. I know that it was regarded to be problematic, but not whether it is in fact non-free. Is there any problem with us shipping LPPL-1.2-licensed works? Do we have to sort out whether the files do have a or later clause? I hope not - I have other things to do this summer, Debian related and mostly not. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
License of Debian-specific parts in packages, generally and in particular
Hi,
in particular, tetex-base has a woeful copyright file (#218105), and
while I'm trying to resolve this, I came across the fact that some of
the Debian-specific code (maintainer scripts, templates,...) does
not have a license statement. The maintainer scripts don't even have a
proper copyright statement, i.e. one has to guess from debian/changelog
who has contributed what.
More generally, I found out that this is the case for many packages
(just a random pick: emacs21{-common}, kdebase-bin, scigraphica) have
the same deficiencies. An example for a good package is the xfree
Packages; furthermore, in xfree86-common/copyright, the copyright for
all Debian-specific contributions is assigned to SPI.
Therefore, I would like to raise some questions. If they have been
discussed before, please give me a pointer.
1. Shouldn't we add a note to the Policy (or the Developer's Reference)
that there should be a license statement for the Debian-specific
parts in debian/copyright? I think we should, and it should be a
must directive post-sarge.
2. Should we encourage maintainers and contributors to assign the
copyright to SPI, as the x people did?
3. Is there any advice on whether to put the debian-specific part under
the same license as the upstream work, or whether this does not
matter?
4. How should we proceed with old contributions? Especially if
maintainers have frequently changed, or complex patches from the BTS
have been applied, it might be hard to find out all the copyright
holders.
I think one can assume that anybody contributing code [1] to a Debian
package is willing to put it under a DFSG-free license, but one
cannot guess at all which license this should be. Therefore a
transition strategy could be made that would allow old code with
unknown or unreachable authors in the package if it is marked a such,
but require a rewrite if substantial changes have to be made anyway.
Regards, Frank
[1] at least if the code is complex enough to warrant a copyright at all.
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
Re: How long is it acceptable to leave *undistributable* files in the kernel package?
Michael Poole [EMAIL PROTECTED] wrote: [firmware as mere aggregation] Kernel copyright holders think otherwise, as do many other people. [...] A little Google shows that Yggdrasil has made such an argument: http://lists.debian.org/debian-legal/2001/04/msg00130.html Unfortunately for Mr. Richter, Linux does not seem to contain any copyright notices attributable to him or Yggdrasil before 2000. As I cited elsewhere, this is at least FOUR YEARS after firmware was included in the kernel, so he cannot fairly claim infringement. He should have known that binary firmware existed in the kernel before. Is this relevant? He contributed code to a GPL'ed project, assuming that all of the project meets the license requirements. Do you expect every contributor to check the copyright status of every file in the project? Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: Another proposed renaming for Debian/NetBSD
[EMAIL PROTECTED] (Nathanael Nerode) schrieb: Debian NotBSD ;-) Plus Debian FearBSD and Debian OvenBSD (or UponBSD?) Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: Status of new LPPL version?
Branden Robinson [EMAIL PROTECTED] schrieb: On Fri, Dec 12, 2003 at 04:09:37PM +0100, Frank Küster wrote: does anybody know what is going to happen with regard to LPPL-1.3, and in which timeline? The latest mails I found were http://lists.debian.org/debian-legal/2003/debian-legal-200306/msg00206.html (a new draft) and two analyses by Branden Robinson, with one follow-up by Frank Mittelbach. I would be glad to be pointed to some place where I can find further information on that. The actual reason why I looked for it is that I am thinking of incorporating some code from a GPL'ed LaTeX add-on package into mine, but do not want to license mine under GPL, but rather under a DFSG-free LPPL. I guess it will be much easier to convince the author to re-license his package if I can tell him that LPPL is also DFSG-free. As far as I know, the new license hasn't actually been attached to anything yet. You'd probably need to contact Frank Mittelbach for a status update. Thank you, I'll do that. Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: Bug#223819: RFA: murasaki -- another HotPlug Agent
Henning Makholm [EMAIL PROTECTED] schrieb: | The problem is that a Debian package has not the right to modify | automaticaly things under the /etc dir. That means that murasaki | itself is not allowed to write anything in /etc/murasaki/*. [...] | -From the Debian policy : | Note that a package should not modify a dpkg-handled conffile in its | maintainer scripts. Doing this will lead to dpkg giving the user | confusing and possibly dangerous options for conffile update when the | package is upgraded. That has nothing to do with what the program *itself* does to files that are *not conffiles*. But be aware that if you use dh_installdeb, all files installed in /etc will be flagged as confiles: ,dh_installdeb(1) | In V3 compatibility mode and higher, all files in the etc/ directory | in a package will auto matically be flagged as conffiles by this | program, so there is no need to list them manually in | package.conffiles. ` If there's no way to override this, one can instead copy them there in postinst. Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) schrieb: Arnoud Engelfriet [EMAIL PROTECTED] writes: But anyway, although computer programs definitely are recognized as subject to copyright in the EU, they do not fit the definition of derivative work or adaptation very well. There just is no guidance in this area. If you translate something, turn a book into a play or putting a poem to music, you can just look it up in the law. But software just isn't discussed much (other than the no-reverse-engineering-unless and one-backup-copy provisions and the like). Exactly my point. What would the equivalent of dynamic linking be? A book that says on the first page: take chapters 3 and 6 from book Foo and insert after chapter 4 in this book, then read the result. Perhaps more realistic: Exercises and solutions. An add-on book to: A.Uthor, Principles of Somethingology. An undergraduate textbook, PubLisher Inc., Someplace 2002 with chapter 10 containing the exercise: 5. The derivation of the CENTRAL FORMULA in chapter 3 (pp. 64ff) was a little simplified. With the knowledge of the Advanced anything as outlined in chapter 10, you should now be able to understand the complete derivation. a) What is the simplification in the derivation on p. 66? b) How can it be formulated correctly? Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
