Re: A new practical problem with invariant sections?
On Mon, Feb 13, 2006 at 08:32:19PM +0100, Florian Weimer wrote: * Craig Sanders: there's nothing in the GFDL that prevents you from doing that. the capabilities of your medium are beyond the ability of the GFDL (or any license) to control. Uhm, the existence of the anti-DRM clause disproves this claim. The anti-DRM clause (you may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute) means that you may not use intentionaly the limitations of the device for the purpose of obstructing the user's ability to read the document. In our case there is no intention. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
On Sun, Feb 12, 2006 at 07:31:20PM -0500, Anthony DeRobertis wrote: I don't recall the following example being brought up. Thank you for this example. It was new and I liked it because it is not as abstract as most of the other examples. Let's assume a manual, written by in Japanese, with Japanese invariant sections. Someone translates this manual to English. The translator, of course, leaves the Japanese invariant section intact. Now, I'd like to download this (translated) manual and place it on a portable device I own, so I can easily read it without killing a bunch of trees. I think this is clearly a useful modification, and I think that I should be able to do this for a DFSG-free work. But, there is a problem: My portable device understands only ASCII, or maybe ISO-8859-1 if I'm lucky (at least in the US, this is pretty common). It doesn't understand UTF-8, Shift-JIS, etc. It is not technically possible to keep the Japanese invariant section. Actually I can see here two different problems. The first problem is that you are unable to install the document on your device together with the invariant sections. This however is not a real problem because you don't have to do this. I am not sure, but I suppose Craig meant this in part of the discussion. GFDL does not require from you to install the invariant sections on your device. The other problem, on the other hand, is more interesting. How can we distribute the document, respecting the requirements of GFDL, in a way that is convenient for use on your device. I can see two ways for this. The first way is to distribute the text in some encoding that supports Japanese such as UTF-8. That way on your device you will be able to read the English part of the document (which contains only ASCII characters), but the non-English part will be visible to you in that way: ã¹ãã¤ã³èªã»ãã·ã¢èªã»ãã©ã«ã¼ã·èªã»ãã«ã¬ãªã¢èªã»ãã±ããã¢èªã» ¼Â¹Ô¤¹¤ë¤È¡¢¤µ¤Þ¤¶¤Þ¤Ê¥É¥Ã¥È¥Õ¥¡¥¤¥ëÃæ¤Ëºî¤é¤ì¤ë¡¢ Ofcourse the users whose devices can read UTF-8 will be able to view the text properly. The second way to distribute the text exploits the fact that GFDL doesn't place requirements about the format of the document. There is no requirement acording to which the document must be included in only one file. There is also no requirement to use same format for the different files belonging to the document. This makes possible to distribute the document in a bundle of two parts -- the part to be installed on your device and the part that can not be read by your device. Infact the described problem is very similar to the situation when some invariant sections contains pictures. Ofcourse the plain text files can not contain inline pictures, but this doesn't mean we are unable to distribute such a document in plain text files. It is enough to distribute the text and the graphical images in separate files provided that the text includes references to the graphical file names when appropriate. Consider the HTML format -- it is text-only but can contain references to graphical images. The graphical browsers include these images inline but the text-browsers show the users only the names of the images. The user decides whether to look at the image or not. The plain-text files are similar case -- the text contains references to the images and the user decides whether to look at them or not. I believe this gives a notable, practicle reason why invariant sections are not free. I hope I managed to explain why in this interesting example the invariant sections do not deprive our rights to read, to adapt, to distribute and to improve. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: GFDL is compatible with DFSG
On Tue, Jan 24, 2006 at 12:17:24PM +0100, Wouter Verhelst wrote: Well, if you ask the people that use this man-page they will tell. Uh. You'll have to make a choice here: either the text is the entirety of _all_ manpages (in which case you can split off the invariant sections and the FDL text to different manpages, but you have to consider all of them together in order to decide what the overall subject matter is), or the text is one manpage specifically (in which case you cannot split off the invariant sections and the FDL text to different manpages, but you can consider each of them individually in order to decide what the overall subject matter is). I agree, that was confusing. We were talking for a document with short technical contents and long secondary sections. So I imagined a manual distributed in the form of man-pages where the only technical contents is the description of only one single command. Acording to the users the overall subject of that manual will be the description of the command, not the topic of the secondary sections. Most of the users will not read the secondary sections at all. If we talk about a manual describing describe more than one command, then it is easy to make the technical contents more than 50%. Note that you even have the freedom to take a license text and modify it, including any preamble such a license text might have. Not exactly. The BSD-alike licenses allow you do this but other licenses state that everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. You're referring to the GPL, right? No. That was only a remark that not all licenses allow modifications in their text. No. I meant there that I agree that the actual, practical results of a license restriction are more important than whether or not they happen to be okay according to some DFSG-guideline; but I do still think that DFSG3 requires arbitrary modifications. I don't understand what you mean. GPL does not allow arbitrary modifications. It does not make the useful types of modification impossible. I already demonstrated why we don't have to put all invariant sections and the full text of GFDL in every single GFDL-covered man-page. You failed to do so in a logically and legally sound way. Look at the following two messages from the thread The invariant sections are not forbidden by DFSG in debian-vote: http://lists.debian.org/debian-vote/2006/01/msg00262.html http://lists.debian.org/debian-vote/2006/01/msg00267.html I was specifically talking about selling printed copies. OK. Oh well. I guess it's clear you won't agree with me, and I'm fed up with the same rehash of this very same discussion that's been done for years now. It isn't getting us anywhere. I find our discussion very interesting and usefull. I agreed with some of your arguments and it seams to me that you agreed with some of my arguments. Moreover, I think I can create something like a FAQ about GFDL. Without your help and the help of other opponents I won't be able to do this. Definitely, our discussion isn't getting us nowhere and I must thank you. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed: Debian's Five Freedoms for Free Works
On 13.VI.2003 at 13:06 Branden Robinson wrote: On Fri, Jun 13, 2003 at 03:29:03PM +0300, Anton Zinoviev wrote: I'd like to mention here that FSF talks about free software and free documentation and not about free works. Well, they're the Free *Software* Foundation. Presumably, they care first and foremost about software. The same with Debian: we are (still) a software distribution. It is questionable whether we have to require these freedoms from works that are not software, nor documentation. What's questionable about it? This sort of rhetoric is FUD. My statement was that it is not our job to require freedoms from works that will never be part of Debian. For our Debian distribution the difference is not much important as we distribute only software and documentation. Not true, unless you define software and documentation so broadly that you open yourself up to exactly the same sort of ridicule that I received for calling everything in Debian main effectively software. Yes, I defined software and documentation so broadly. :) Things like the music files for frozen-bubble are neither software nor documentaiton. OK. If a music file is a part of some software, then we expect to be able to modify it. On the other hand if I am not allowed to modify some work such as music or picture, then I will miss this freedom only in case I want to use it as part of some software. Thats why I think that these 4+1 freedoms are essentially software freedoms. You are thinking only about what the software can do, and not about what the *license* might do. I can not think about a license that provides me with the first 4 freedoms, but not with the fifth. Any hints? Maybe this depends on how one interprets the first 4 freedoms? I don't think it makes sense to treat the FSF as some sort of unstable psychotic who's likely to go off and start shooting people if his every whim is not sated. It wasn't my intention to persuade this. We are free to discuss any definitions of what is free software/documentation/work. I just wanted point out that FSF always tries to make its philosophical ideas clear. If Debian differs in something, then they will make their best to educate our FS community why Debian is not right. If we try to clarify/change the definition of free software in collaboration with FSF -- that is wonderful. But otherwise let us talk about guidelines rather that about definitions. Anton Zinoviev
Re: Proposed: Debian's Five Freedoms for Free Works
On 12.VI.2003 at 16:21 Branden Robinson wrote: The Free Software Foundation promulgates, and the Debian Project generally accepts, four essential freedoms as defining Free Software. The following is an enumeration of freedoms intended to apply to non-public-domain works in general. I'd like to mention here that FSF talks about free software and free documentation and not about free works. It is questionable whether we have to require these freedoms from works that are not software, nor documentation. For our Debian distribution the difference is not much important as we distribute only software and documentation. Nevertheless there is a great philosophical difference. Do we start promoting philosophical ideas that are not directly related to our own work? I doubt there will be any benefit if we start doing this. 5) The freedom to retain privacy in one's person, effects, and data, including, but not limited to, all Works in one's possession and one's own changes to Works written by others. Yes, we should require this from all software in Debian. But I don't think it is desirable to add this to the definition of free software (and free documentation) because of this: * If some software spies me and its license disallows me to remove the bad code in it, then this won't be a free software, because I am not allowed to modify and improve it. * If the software spies me, but its license permits me to remove the bad code, then this will be bad software, but free software. I am allowed to improve it. * Debian has its guidelines rather than its definition of free software. I don't think we have any interest in more confrontation with FSF and initiate a third movement in our community (as OSI already did). Some people in FSF are too sensitive about definitions. Anton Zinoviev
Re: Do we have trademark infringements by fonts?
Hi! I wrote about this problem in [EMAIL PROTECTED] The answer (by Markus Kuhn) was: This was discussed before. None of the commercial font suppliers considers pixel fonts to be of any commercial interest whatsoever today, therefore the problem you outline remains a purely theoretical concern. Anton Zinoviev
Do we have trademark infringements by fonts?
Hi! A friend of mine has pointed me that it is very likely that many fonts have problems with trademark infringement. I suppose that some (most?) of the font names are registered, but nevertheless the free software community has made changes to the original fonts. XFree86 gives us an example for this. They have made many changes to the original fonts by Adobe, Bigelow Holmes and others; most of these changes are adding additional non latin1 characters. However a couple of years ago one font developer received the following answer from BH: To prevent possible confusion between your versions of the Cyrillic characters in the Lucida X11 fonts, and Lucida Cyrillic characters we have designed, please change the names of the Lucida bitmap fonts you have adapted and modified, to a name that cannot be confused with Lucida. -misc-yasnyj-* is fine with us. To use the Lucida name and trademark with modifications and designs not made by Bigelow Holmes would be an infringement of our trademark. It is possible that my package scalable-cyrfonts has similar problems, but I don't know how to check this. So my question is what should we do? One of the following? 1. Do nothing and use the same font names as now. 2. Do not use font names whose trademark owner has complained and use the other font names. 3. Use the font names as now, but make honest attempts to inform our users that these are not the original fonts. The whole purpose of trademarks is to protect people not to be fooled. 4. We must onw permition by the trademark owners of all fonts we distribute. We should change the names of other fonts. However it is unclear to me how to check if some name is registered or not. 5. We do not use registered trademarks in font names. I don't know what is the right legal choice, but as developer I would suggest not to choose 4, because the font names are the interface to fonts and we will come to something similar to the problems with the LaTeX license. Anton Zinoviev
Re: standard fonts and euro
On 13.V.2001 at 14:08 Branden Robinson wrote: On Sun, May 13, 2001 at 04:58:21AM -0400, Wolfgang Sourdeau wrote: I am converting all of my system to ISO-8859-15 and I notice that just the fixed font has a 8859-15. It would be great to have standard fonts such as Times, Helvetica, ... be compatible with this encoding. [...] Now, it seems that the fonts coming with XFree86 are copyrighted by Adobe. So what are the alternatives for us ? 1) All of the fonts in the xfree86 source package are freely licensed. (N.B., this is not the case with the upstream XFree86 source tarballs.) BTW, Helvetica is registered trademark. I think XFree86 must get permition to use that and other font trademarks in its modified fonts. That is problem for Debian too. For example the fonts for ISO 8859-2 in Debian don't use registered trademarks, but use aliases instead. In my opinion the free software comunity should stop using all registered trademarks, such as helvetica, times, courier, lucida, etc. Anton Zinoviev, [EMAIL PROTECTED]
Re: standard fonts and euro
On 15.V.2001 at 15:08 Miros/law Baran wrote: 15.05.2001 pisze Anton Zinoviev ([EMAIL PROTECTED]): BTW, Helvetica is registered trademark. I think XFree86 must get permition to use that and other font trademarks in its modified fonts. That is problem for Debian too. For example the fonts for ISO 8859-2 in Debian don't use registered trademarks, but use aliases instead. Because these fonts *are not* Helvetica et al. Because the vendor of these fonts doesn't have permition from the trademark holders. XFree doesn't have such permition too and thats why it is not allowed to distribute modified fonts with the same font names. It must aither distribute the original fonts or to stop using font trademarks. (The situation is somewhat similar to the LaTeX Public License.) In my opinion the free software comunity should stop using all registered trademarks, such as helvetica, times, courier, lucida, etc. Even if these have been donated by the copyright owners? I didn't mean to stop using these fonts, but to stop using their trademarks in free programs. The strings like `-adobe-helvetica-*' must not be hardcoded in free programs. I didn't mean that we must stop to use the trademarks like `Linux'. But free programs *must not depend* on that trademark. If I am not allowed to distribute an unofficicial kernel and name it `Linux' that is OK. But if free programs stop to work because my kernel is not named `Linux' that is not OK. Anton Zinoviev, [EMAIL PROTECTED]
Re: standard fonts and euro
On 15.V.2001 at 19:33 Miros/law Baran wrote: Are you sure that such modifications (adding one glyph to the bitmap font) are disallowed? I suppose them to be disallowed. The purpose of trademarks is to guarantee than the product is produced by the trademark holder. For example BH may want to add its own version of that glyph to their lucida fonts. They want to make clean that the modified fonts are not produced by them. I choosed BH as an example because they explicitly disallowed using their font trademarks (lucida) in fonts of other vendors. They stated that in a mail to one font developer. I think we must not use without permition the other trademarks (besides lucida*) too. We can not be sure that their copyright holders will not seek their rights in future. trademarks in free programs. The strings like `-adobe-helvetica-*' must not be hardcoded in free programs. This string is not trademarked. Yes, it is not a trademark. But it forces us to use the original unchanged fonts of Adobe. If we want to use some improved fonts, then we may not use naither adobe, nor helvetica in them (i.e. in fonts). There is no legal problem to use these strings in programs. But it is disallowed to claim that some program is produced by Adobe (if it isn't). I suppose that it is OK to name some software `Helvetica' if it is not font, but for fonts that is forbiden. I like the BizNet's approach better: if you must change the name, change the name, but use appropriate alias files. This does not break any configuration. Yes, but that seams to me like a temporaty hack. I have read that developers in the fonts XFree mailinglist don't want to use aliases. (And I don't like them too...) I didn't mean that we must stop to use the trademarks like `Linux'. But free programs *must not depend* on that trademark. If I am not allowed to distribute an unofficicial kernel and name it `Linux' that is OK. But if free programs stop to work because my kernel is not named `Linux' that is not OK. I think it's a bit too paranoid approach, maybe it is this evening that I just cannot grok, what you exactly mean. May I forward this discussion to Adam Twardoch, who is more competent in font issues? Certainly. Anton Zinoviev, [EMAIL PROTECTED]
Re: standard fonts and euro
On 15.V.2001 at 17:11 Mo McKinlay wrote: I didn't mean that we must stop to use the trademarks like `Linux'. But free programs *must not depend* on that trademark. If I am not allowed to distribute an unofficicial kernel and name it `Linux' that is OK. But if free programs stop to work because my kernel is not named `Linux' that is not OK. Most things look at what the kernel is called (via uname(2)) in order to determine the system. If you change it from 'Linux' to 'LinuxOS' (for example), you'll see lots of things stop working, not least config.guess and config.sub. I suppose that is not a problem. Some CPUs imitate Intels CPUs in their authentication commands. The important is that on the market they don't use the name `Intel'. I suppose I am allowed to make an unofficial kernel which uname returns Linux. I used that as an example. I wrote that free programs must not depend on trademarks. That means that free programs must not make other programs non-free. A blanket policy for trademarks based on an isolated issue (fonts) would be silly IMHO. No. The kernel was not good example, but I think it is clean that we don't want to be forced to use unmodified programs because of the trademarks. Anton Zinoviev, [EMAIL PROTECTED]
non-US bugreports
Hi! It is not unusual for bugreports to include patches. The Debian bug-tracking system is in master.debian.org and that server seams to be in USA. So what will happen if some user sends a bugreport with a patch for a package that is non-US? We do not inform users to not do so. Anton Zinoviev
