Re: About Logo License
Sam Hocevar 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 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 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)
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: 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)
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: 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
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: 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: 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)
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: 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)
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: 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)
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)
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: 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: 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?
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: 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: infos about alien licenses
Wolfgang Lonien <[EMAIL PROTECTED]> wrote: > Stephen Gran wrote: >> This one time, at band camp, Matthew Palmer said: >>> On Wed, Apr 12, 2006 at 02:35:28PM +0200, Wolfgang Lonien wrote: >>>> THIS SOFTWARE IS NOT FAULT TOLERANT AND SHOULD NOT BE USED IN ANY >>>> SITUATION ENDANGERING HUMAN LIFE OR PROPERTY. >>> This is possibly problematic, depending on how you define "should". I'd >>> take it as just being a restatement of the whole "no warranty, if it breaks >>> you get to keep both pieces" thing, but it could be read as forbidding use >>> in the mentioned areas. >> >> The word 'should' has a fairly straight forward meaning in the English >> language. This does not present a problem, as far as I can see. It is >> substantively no different from the standard: >> >> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent >> permitted by applicable law. >> >> It is a disclaimer telling you they take no responsibility if you use it >> in a situation that endagers human life or property. No problem. > > Sounds good to me. Except that the reasoning is wrong, as Matthew Palmer pointed out. That's similar, but probably even more strict than the german legal "soll": "soll ist muss wenn kann". Gruß, 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: new tool - searching for example
Anthony DeRobertis <[EMAIL PROTECTED]> wrote: > Sorry for replying twice, but the LPPL (LaTeX Public Project License) > stuff --- the new version which was, in large part, driven by -legal, > would be interesting too. And probably a better starting example for his tool than the other examples, because the discussion finally came to a consensus, or at least a resolution, which is not so obvious in the GFDL case... 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=file&rev=0&sc=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)
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: 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"?
"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)
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: 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)
License advice: LPPL with additional restrictions
Hi, I just discovered that teTeX contains a LaTeX package "dinbrief" which is licensed under the LaTeX Project Public License, v. 1.1 or later - so it should be okay (1.3 (a?) is DFSG-free). However, there are some additional restrictions in the readme file. I assume that the author only wanted to explain the consequences of the LPPL, in what he thought was a less legalistic wording. Therefore I hope to be able to convince him to drop the additional restrictions (should he be reachable) - but before I do that I'd like to make sure that the additional restrictions are in fact a problem, and not only just an inconvenience, and which of them. Therefore I'd be glad if someone could have a look at these restrictions and point out the ones that are problematic. Here comes the text: It may be distributed under the terms of the LaTeX Project Public License (LPPL), as described in lppl.txt in the base LaTeX distribution. Either version 1.1 or, at your option, any later version. The latest version of this license is in http://www.latex-project.org/lppl.txt LPPL Version 1.1 or later is part of all distributions of LaTeX version 1999/06/01 or later. For error reports in case of UNCHANGED versions see readme files. Please do not request updates from us directly. Distribution is done through Mail-Servers, TeX organizations and others. If you receive only some of these files from someone, complain! Redistribution of unchanged files is allowed provided that all files listed in the corresponding package README file are distributed including this readme file. However, if these files are distributed by established suppliers as part of a complete TeX distribution, and the structure of the distribution would make it difficult to distribute the whole set of files, *those parties* are allowed to distribute only some of the files provided that it is made clear that the user will get a complete distribution-set upon request to that supplier (not me). Notice that this permission is not granted to the end user. Generation and distribution of changed versions: The generation of changed versions of the files included in the packages is allowed under the following restrictions: - You rename the file before you make any changes to it. - You acknowledge the origin of the original version in the file and keep the information that it (or a changed version) has to be distributed under the restrictions mentioned in this file. - You change the ERROR REPORT address so that we don't get error reports for files *not* maintained by us. The distribution of changed versions of the files included in the packages is allowed under the following restrictions: - You provide the user with information how to obtain the original package or, even better, distribute it with your files. - You make sure that the changed versions contain a notice that prevents others to take money for distribution or use of your files, i.e. they have to be distributed under the restrictions mentioned in this file. - You inform us that you created a changed version of the files. This is only necessary if you want to distribute it to others. *** Additionally, the readme file contains the notice: , | IMPORTANT NOTICE: | | You are not allowed to change this readme file. ` but it is not just a legal text, but also contains (rather trivial) information about how to install the package and report bugs, and a list of files in the package. Many thanks in advance, 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: 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: 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: 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)
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)
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)
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?
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?
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?
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?
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?
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?
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? 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. > Fixing source in order to make it actually rebuildable with the declared > Build-Depends should not be left to the users... tetex-base does not rebuild documentation and does not Build-Depend on tetex-bin. 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)
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?
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?
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?
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 .dtx > makeindex -s gind.ist > makeindex -s gglo.ist -o .gls .glo > pdflatex .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: 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?
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 .dtx makeindex -s gind.ist makeindex -s gglo.ist -o .gls .glo pdflatex .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?
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)
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: 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
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: 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: 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 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: 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: 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: >> 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
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)
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
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: 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)
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: 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)
Re: "object code" in the GPL and printed copies
Nathanael Nerode <[EMAIL PROTECTED]> wrote: > Indeed, an author can, to a certain extent, restrict commercial trade of the > printed version this way. A publisher can publish a printed version under > the GPL, but they have to tuck a CD with the complete source code for the > book into every copy of the book. I would say that that would have to > include all the typefaces used in the book, which would have to be under > GPL-compatible licenses; and the cover art, likewise; and even the > specifications for reproducing the binding. If they don't want to do that > (and with the current behavior of publishers, I bet most won't want to), they > need to get separate permission from the author. I was also searching for a solution like this; typefaces and cover art should "work". 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 as"a 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)
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
(BTW I'm subscribed, no need to Cc) Alexander Terekhov <[EMAIL PROTECTED]> wrote: > Object code is a well established term. GNUspeak is irrelevant. I'd still be interested in GNUspeak - is there a definition of object code as the FSF sees it? There's none in the GPL FAQ. > The Copyright Act defines a computer program as"a 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. Computer programs can be expressed in either source > code or object code. "Source code is the computer program > code as the programmer writes it, using a particular programming > language." Compendium of Copyright Office Practices, > § 321.01. Source code is a high level language that people can > readily understand. "Object code is the representation of the > program in machine language [binary] . . . which the computer > executes." Id. at § 321.02. So if we (Debian) have decided that we treat documentation alike software, the obvious way to extend this definition (and probably this is also needed for other things like elisp byte-code) that object code is also every other representation of the program [binary] that is executed or interpreted by programs on the computer. Which would mean that a printed copy would not fall under object code. And therefore the GPL would not allow distribution on paper at all. What does the law say about distributing printed copies of things (PDF files, cool pictures, whatever) that you do not have any license for - may I print a picture from any website and hang it up on the university blackboard? 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 as"a 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: 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
Jeremy Hankins <[EMAIL PROTECTED]> wrote: > Frank Küster <[EMAIL PROTECTED]> writes: > >> 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, > > Typically that's the presumption (since object code is "not source"), > but that's really a question of law rather than the DFSG (i.e., get a > lawyer if it's important to you). It's important to me as a maintainer of a Debian package with some documents licensed with non-free licenses (GFDL, CC "Attribution non-commercial blabla") - naturally I'd rather persuade the authors to relicense their documentation than remove it. But I need a thorough understanding of the problems of documentation licensing to be able to do this. And of course I can't afford a lawyer, but an opinion of a couple of people more acquainted to law stuff than I am would maybe also help. Maybe I should ask the FSF... > As for the DFSG, I don't see how a > license that did not permit distribution of paper copies could be free. > Whether it's source or object code, it's still a version of the work, > and so the freedoms of the DFSG are still important (possibly with the > string of source distribution attached). I don't think that this is entirely clear. Of course it's still a version of the work. But the DFSG (and Debian generally) are about software. It has been discussed and decided that documentation should not be treated differently from software (and agree with that), however this has always been discussed in the context of creating a Software distribution, of distributing stuff on CD's, via ftp or http, and the like - generally in digital form. I have not yet made up my mind on this, so I'm just writing down some thoughts here: - Some people view intellectual property as "bad" (unethical, hindering development, or whatever) in any field, but other Free Software people do not claim this. For them, it's rather the particular field of "computer usage", with software, documentation, and possibly hardware that makes "Freeness" so important - be it for ethical or for practical reasons - while in other fields - like arts or literature - copyright is acceptable or even welcome. Since Debian and the DFSG are about Software, we cannot assume that everybody is of the first type. - Software and its documentation is "work in progress" most of the time. While an author might be willing to release a computer-related documentation to the public in its current form, this does not imply that they in fact think the work is fit for publicaton in form of a book, which is much more static, and which many people expect to be much better proof-read, typographically optimized etc. than is usual for a documentation PDF generated from texinfo, xml or the like. Furthermore, it's often not clear from the typeset text who is responsible for which content (only available in the CVS/SVN/... log and in source files), a point that might be deemed crucial by authors who have a reputation to loose. If I start contributing to a widely used documentation project *because* I find its present state inacceptable, I'd rather not see the intermediate product published as a book with my name (among others) on it... I doubt that we would be violating the spirit of the DFSG if we allowed authors to restrict printing because of such considerations. > Generally the concern with documents goes the other way: folks want to > make sure that paper copies can be distributed in classroom environments > and the like, where source distribution might be a significant > inconvenience. That wouldn't be a problem with the GPL and a "written offer", and perhaps the concerns I raised are not important to people whom I need to persuade to switch away from the GFDL. But for people who chose some license forbidding commercial use (#345604, the license text in the initial bug report is outdated), it may be the major concern. 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: 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: 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
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: 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: > [EMAIL PROTECTED] (Frank Küster) writes: > >> [EMAIL PROTECTED] (Måns Rullgård) schrieb: >> >>> Wouldn't such a book be allowed? I can't see anything that would stop >>> it. >> >> You're probably right. I wasn't looking for something that wouldn't be >> allowed, but for something that is as close as possible as linking. It >> seems that what I invented, although it "mimicks" linking, would not be >> a derivative work in literature - or if it is, it would be allowed >> citation. > > If that analogy is indeed an appropriate one, it would imply that > dynamic linking isn't controlled by the GPL. Not that I'd mind. I guess the analogy is not appropriate... Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Status of new LPPL version?
Dear all, 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. Thank you, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
