Re: Ongoing Firefox (and Thunderbird) Trademark problems
On Wed, 15 Jun 2005 02:16:18 -0400 Eric Dorland <[EMAIL PROTECTED]> wrote: > * Marco d'Itri ([EMAIL PROTECTED]) wrote: > > On Jun 15, Eric Dorland <[EMAIL PROTECTED]> wrote: > > > > > > It's an important part in evaluating the balance between the > > > > priorities of our users and free software... > > > And where do we strike that balance in this case? I think gaining > > > more freedom for our users is the best thing in the long run. > > > Sure, there will be shorter term pain, but we need to take the > > > long view. > > I'm here to build the best free OS, not to collect the most liberal > > trademarks. If a trademark license allows us to ship the software > > the way we want and there are no practical problems in removing > > trademark references if it were ever needed then I think it's > > obvious that we would do a disservice to our users by removing from > > Debian such a widely know trademark without a good reason. > > Well the whole issue is I don't believe we're allowed to ship the > software the way we want. We would be compromising our principles by > doing so. > > > There are good reasons for a trademark license to be restrictive and > > I believe that the MF made a good case about their one, so I do not > > think that it's important for users to have the permission to use it > > however they want. The code is still free no matter how it is > > branded so this is not an issue of software freedom, at best this is > > a marketing issue. > > I never asked them to give users permission to use it however they > want. But their current permissions are too restrictive. > >From the discussions on this thread, it is your last statement that has not been accepted by everyone here, myself included ;-) 1. If the tradmark restrictions, combined with the license, require that we not use the term Firefox in identifying their product of that name, then we do that, even though we all agree it is stupid. Those who can't find the product in Debian will find it at the Mozilla site (I have some Debian machines that are running Firefox in this fashion) 2. Examine the purpose of a trademark in the first place. The intent is for the specific name to be identified with the specific product. The fact that Debian uses the Mozilla and Firefox trademarks to properly identify the products delivered tells me that we are using their trademarks correctly. If one of our end user's took the Mozilla packages and reworked them to be the desktop, with links into every other piece of software in the system, and then tried to distribute this product under the Mozilla/Firefox trademarks that would represent a gross violation of their trademark. (for which Debian would have no reaponsibility BTW) As a counter example, one of the Knoppix based "live CD" distributions (Either Morphix or Byzantine, I can't remember which) has the desktop actually be the browser. But, of course, they don't call it mozilla or firefox, or use any of the trademarks, so they have followed the rules as well. I guess, from what I've said above, I believe that the current state of affairs in Debian is consistant with the letter of the licensing of that software, and consistant with the spirit of their tradmark usage document. Changing the names of these packages to contain neither the substring "mozilla" nor the substring "firefox" would, in fact, hurt both Debian and Mozilla, not to mention what it does to the maintainer's morale. Luck, Dwarf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Thu, 2 Jun 2005 00:25:01 -0400
Joey Hess <[EMAIL PROTECTED]> wrote:
> (To answer the thread leader, I consider Ubuntu to be more and more of a
> fork and less and less a derivative distribution. If Ubuntu doesn't
> start to re-converge with Debian significantly after sarge is released,
> and we end up with two sets of X.org packaging, etc, then I will give up
> and just consider it purely a fork.)
>
>
>From the first CD I installed, I realized it was a fork...and a disapointing
one at that. (Pretty desktop on live CD didn't install from installation CD,
but the fact that their archives only hold their limited package set, found
on the CDs, made it apparent that they were a separate distro, based on
Debian but not necessarily compatible with Debian.)
Knoppix is much better about using Debian packages and adding configuration
integration of a much wider range of Debian packages. as well as installing
on hard drive ready to modify and upgrade. (Although these days I'm using
Bonzi to install Debian, with great success. The autoconfiguration of USB
is quite useful, almost as good as DLS{another Debian derivative})
However, the coolest thing I have seen that uses Debian is the NOKIA 770
Wi-Fi tablet available in September of this year. Their argument for using
Debian was that apt-get would keep the machine upgraded for life. Yes, their
"Internet Tablet 2005 sofware edition" is probably a fork, the implication
on Hack-a-Day is that other packages and applications can be added to this
machine. Their own web site doesn't say a thing about Debian, but their
developers site (maemo.org makes it clearer under "Building and installing
Debian packages"). This could be a fun hack, and the solution to some
hardware problems I have been trying to resolve ;-)
Luck,
Dwarf
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Sat, 04 Jun 2005 19:16:50 +0200 Daniel Holbach <[EMAIL PROTECTED]> wrote: > Hello Dale, > > Am Samstag, den 04.06.2005, 11:29 -0400 schrieb Dale C. Scheetz: > > >From the first CD I installed, I realized it was a fork...and a > > >disapointing > > one at that. (Pretty desktop on live CD didn't install from installation CD, > > but the fact that their archives only hold their limited package set, found > > on the CDs, made it apparent that they were a separate distro, based on > > Debian but not necessarily compatible with Debian.) > > this is not quite true. The CD only holds packages from the "main" > component, but there are "Universe", "Multiverse" (the non-free section) > and "restricted" as well. > When using apt-get on a system installed from the installation CD (not the live CD) apt-get points to the Ubuntu archives, which only contain a very limited subset of Debian's main archives. I had limited success in pointing apt at a real Debian archives and getting additional packages to install. This is why I said it looked like a fork from the biginnig. This is a "desktop" distribution with a specific philosphy that dictates looking at global configuration of packages in a different way than the Debian developers may... > Apart from that, I really can't see this as an indication for a fork. Even as a fork, there are useful ideas to be gleaned from them, and their open source policy seems to make that possible, dispite the technical problems... > Luck, Dwarf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More on icons for packages
Thank you for documenting my tour of the documents ;-) While it looks like my original posting was a complaint about how hard it was to find anythin on icons, my larger point was that there is only information on icons in the menu documentation and it is specific to the menu system, but icons are used in other venues like on gnome panels and DSL even puts them on the desktop. When I looked a several packages to see how they did it the results were variable. Some folks put icons in /usr/share/package-name/icons and some even refer to them in their menu files (from what you said below these would be bugs). As a user I find it ... inconvenient to have to search many different possibilities in order to find a suitable icon for a gnome panel. It seems to me that it would be more consistant to declare that all icons should go into /usr/share/pixmaps even though most of them are png format and not xpm. It might be better to reserve /usr/share/pixmaps specifically for menu icons in xpm format and create /usr/share/icons for png gif and jpeg icon images. BTW the Gimp puts icons, logo and splash-screen in /usr/share/gimp/images but it also puts a wilber icon in /usr/share/pixmaps (their logo is cute ;-) The gnome panel scales the image provided to fit the panel, so there are advantages to creating a more detailed icon that maintains that detail when shrunk to fit. Is it worth while trying to get some general icon policy established or am I straigning at gnats? Luck, Dwarf On Mon, 24 Jan 2005 23:24:45 -0600 Manoj Srivastava <[EMAIL PROTECTED] (va, manoj)> wrote: > On Sun, 23 Jan 2005 19:35:42 -0500, Dale C Scheetz <[EMAIL PROTECTED]> > said: > > > This document is only indirectly referenced in the policy manual, so > > it isn't clear how much force it has. (it could be taken as the > > mearest suggestion by the menu package maintainer) > > The Debian technical policy, section 9.6 states: > == > All packages that provide applications that need not be passed > any special command line arguments for normal operation should > register a menu entry for those applications, so that users of > the `menu' package will automatically get menu entries in their > window managers, as well in shells like `pdmenu'. > > Menu entries should follow the current menu policy. > > The menu policy can be found in the `menu-policy' files in the > `debian-policy' package. It is also available from the Debian > web mirrors at `/doc/packaging-manuals/menu-policy/ > (http://www.debian.org/doc/packaging-manuals/menu-policy/)'. > > Please also refer to the _Debian Menu System_ documentation that > comes with the `menu' package for information about how to > register your applications and web documents. > == > > So, not following the menu policy would be a "normal" bug. > > It should also be noted that the menu policy is packaged in > the same package that the Debian Technical policy is, so one may > infer that policy certainly thinks that menu policy has some weight. > > manoj > -- > Moe: What did you give your wife for Valentine's Day? Joe: The usual > gift -- she ate my heart out. > Manoj Srivastava <[EMAIL PROTECTED]> > <http://www.debian.org/%7Esrivasta/> 1024D/BF24424C print 4966 F272 > D093 B493 410B 924B 21BA DABB BF24 424C > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More on icons for packages
On Wed, 26 Jan 2005 08:15:38 +0100 (CET) Andreas Tille <[EMAIL PROTECTED]> wrote: > On Tue, 25 Jan 2005, Dale C. Scheetz wrote: > > > It might be better to reserve /usr/share/pixmaps specifically for menu > > icons in xpm format and create /usr/share/icons for png gif and jpeg > > icon images. > Why not putting all icons (xpm, png, ...) into /usr/share/pixmaps and just > use the XPMs for menu and the other for anything else? > At least I think that we are bound to /usr/share/pixmaps at least to > support fredesktop.org standards for the Gnome / KDE icons. If the maintainer > does not provide any PNG but has created an xpm it wold definitely not > hurt in this location. Perhaps a problem for the user would be if there > would be two icons with a similar look (XPM and PNG). > When I looked briefly at the freedesktop standard for Gnome and KDE icons I thought it specified /usr/share/icons and, sure enough there be icons here. There is a lot more stucture here to. /usr/share/icons/Default and others that I looked at have subdirectories ranging from 12x12 up to 192x192 but the contents seems to be specialized to gnome pieces-parts. (the more I look the more complicated it gets...) > Thus it might be even better to define a policy the following way: > >1. Put all XPMs for the use in Debian-Menu into > /usr/share/menu/pixmaps >2. Put all PNGs (and others) into /usr/share/pixmaps if they are > intended for applications which follow freedesktop.org specification I don't really see a need for the split. All menu icons should be xpm so any other icons are for some other purpose. >3. Put a symlink > ln -s /usr/share/menu/pixmaps/.xpm /usr/share/pixmaps > if there is no PNG or whatever icon for this application to support > both Debian-Menu and freedesktop.org These kinds of solutions lead to extra detail in package management and, of course see above ;-) >4. File bug report or even create automagically via mogrify icons in > /usr/share/menu/pixmaps/ if there are icons in /usr/share/pixmaps > but the maintainer did not provide a XPM following the menu policy > spcification. > What package would be responsible for this mogrification? > > Is it worth while trying to get some general icon policy established or > > am I straigning at gnats? > Would the skecth of a policy above make sense to you? > Simplify, simplify, simplify ;-) Luck, Dwarf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More on icons for packages
On Thu, 27 Jan 2005 09:52:48 +0100 Tim Dijkstra <[EMAIL PROTECTED]> wrote: > On Wed, 26 Jan 2005 20:18:39 -0500 > "Dale C. Scheetz" <[EMAIL PROTECTED]> wrote: > > > > Thus it might be even better to define a policy the following way: > > > > > >1. Put all XPMs for the use in Debian-Menu into > > > /usr/share/menu/pixmaps > > >2. Put all PNGs (and others) into /usr/share/pixmaps if they are > > > intended for applications which follow freedesktop.org > > > specification > > > > I don't really see a need for the split. All menu icons should be xpm > > so any other icons are for some other purpose. > > I think the point is we don't want to be stuck we xpm till eternity. > Especially because we have window/desktop managers that support better > formats like png or svg for example and programs supplying them. > My point was that it doesn't matter that this location is reserved for menu icons. There is no reason not to put other icons there as well, since all menu icons are xpm there should be no confusion. There is nothing in the menu spec that says only menu icons can go in this location. (in any case icons other than xpm in /usr/share/pixmaps is already the case) When and if xpms are no longer used for menus there will still be a need for icons in some format and this has become the defacto location. (I realize that the very name pixmaps implies xpm but as an abreviation for pixel maps it could refer to any mapping of pixels, not just xpm... My complaint was about the many and varied locations in which you might find an icon. Creating multiple locations one for this sort, another for a different sort is exactly the situation that now exists with some packages putting them in /usr/share/package-name/icons and all its variations, some in /usr/share/pixmaps and other locations I have yet to discover. I am assuming that the icons I find in /usr/share/icons are either gnome or KDE graphics elements. (my machines only have gnome icons here as I don't use KDE) Well, this turned out longer than I expected ;-) Luck, Dwarf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Adding Icons to Spider
I have recently created an icon for the spider program and I have several implimentation questions. 1. Am I permitted to place an icon in /usr/share/pixmaps? What is the practice with subdirectories under pixmaps? (I did RTFM so if I just missed it please give me a reference) 2. When you add some programs to the gnome panels their icons are automaticaly associated with the properties, while with others you have to go looking for an appropriate icon in /usr/share/pixmaps. (btw is there yet another repository for images?) how do I impliment an automatic icon so that when the program gets added to the panel the icon is there? This is my first posting to the list using Sulfeed so if there are any formatting problems please let me know. Waiting is, Dwarf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
More on icons for packages
Well, I finally found some documentation on icons in menu specifications. What it says is pretty specific and goes against what I found when I looked at actual packages. 1. the documentation says all icons go into /usr/share/pixmaps and 2. all menu icons should be 32x32 pixels and be in xpm format. But, when I looked at several packages, many put their icons in /usr/share/package-name/icons/ and very few actually use 32x32 for their size even when they are placed in /usr/share/pixmaps/. This document is only indirectly referenced in the policy manual, so it isn't clear how much force it has. (it could be taken as the mearest suggestion by the menu package maintainer) /usr/share/pixmaps has lots of png files and many images are larger than 32x32. Are these issues that should be resolved with bug reports? With regards to GNOME panel icons. The "add to panel" option now no longer offers "launcher from menu" so now with the "custom launcer" you have to hunt for your icon. The default place to look is /usr/share/pixmaps, so it would be user helpful to have all icons in that location instead of requiring a hunt through all the other possibilities when you don't find the icon you are looking for. Personally I like larger than 32x32 icons for the panel because icons are scaled to fit the panel so fairly large ones give much cleaner detail when scaled to fit. In any case I would like to see this floating document become an actual part of the policy manual. It contains the implimentation details that someone with questions really needs to see up front, not tucked away in a specific package document outside the Policy Manual. Any ideas? Waiting is, Dwarf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More on icons for packages
I understand your point about this document only applying to menus. My point was that this is the only documentation I can find on icons, and gnome has changed how it mounts programs on panels so I'm still running on empty as far as directions on proper behavior. Many of the icons that gnome has used in the past seem to reside in /usr/share/pixmaps so there seems to be some consensus on this location as a proper storage location. I've been with Debian for a long time and it seems that consistancy is our most difficult product to impliment. Lintian is a great help in this maintenance but... Thanks for the feedback. Any pointers to other docs would be useful... Luck, Dwarf On Sun, 23 Jan 2005 21:20:44 +0100 Bill Allombert <[EMAIL PROTECTED]> wrote: > On Sun, Jan 23, 2005 at 07:35:42PM -0500, Dale C. Scheetz wrote: > > Well, I finally found some documentation on icons in menu > > specifications. What it says is pretty specific and goes against what I > > found when I looked at actual packages. > > > > 1. the documentation says all icons go into /usr/share/pixmaps and > > > > 2. all menu icons should be 32x32 pixels and be in xpm format. > > 3 points: > > Your quote is an extract from the Debian menu manual > <http://www.debian.org/doc/packaging-manuals/menu.html/> > or > > > 1) this is only for icons used in menu file for the Debian menu > systems. Icons used by window managers and files managers are a completly > different business. > > 2) It says _at most_ 32x32 pixels. > > > But, when I looked at several packages, many put their icons in > > /usr/share/package-name/icons/ and very few actually use 32x32 for their > > size even when they are placed in /usr/share/pixmaps/. > > > > This document is only indirectly referenced in the policy manual, so it > > isn't clear how much force it has. (it could be taken as the mearest > > suggestion by the menu package maintainer) > > > > /usr/share/pixmaps has lots of png files and many images are larger than > > 32x32. > > > > Are these issues that should be resolved with bug reports? > > At least, they are flagged as bugs by lintian: > <http://lintian.debian.org/reports/Tmenu-icon-too-big.html> > <http://lintian.debian.org/reports/Tmenu-icon-not-in-xpm-format.html> > > I try to get as much menu related bugs as I can, but I don't get much > support. > > > With regards to GNOME panel icons. The "add to panel" option now no > > longer offers "launcher from menu" so now with the "custom launcer" you > > have to hunt for your icon. The default place to look is > > /usr/share/pixmaps, so it would be user helpful to have all icons in > > that location instead of requiring a hunt through all the other > > possibilities when you don't find the icon you are looking for. > > > > Personally I like larger than 32x32 icons for the panel because icons > > are scaled to fit the panel so fairly large ones give much cleaner > > detail when scaled to fit. > > The menu manual is only relevant for icons part of the window-managers > menu, not GNOME panel icons. > > Cheers, > -- > Bill. <[EMAIL PROTECTED]> > > Imagine a large red swirl here. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
Stuff deleted > > I have cdebootstrap do create chroots, dchroot to use them, > buildd/sbuild to test compile under true buildd conditions. Why would > I want something else? > I'm not sure I know, but now that I know about this pair, I will certainly look into it. After that, if I can answer your question, I'll get back to you ;-) I mainly wanted to say thank you, not only to Goswin, but to the rest of you who have helped to turn this list back into something readable! Thank You! Thank You! Thank You! > Debootstrap couldn't even handle dependency resolving a while back. Things change. (See above) > > MfG > Goswin Luck, Dwarf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
On Wed, 09 Aug 2006 15:44:57 +0200 Joerg Schilling <[EMAIL PROTECTED]> wrote: Stuff deleted for brevity > > > All of this, without even taking into account your brain-dead > > licensing mix between CDDL and GPL - which are intentionally > > incompatible licenses, according to Sun guys. > > If you are so braindead not to understand that this license > combination is perfectly OK, I cannot help you. It seems that I did > waste already too much time with you. A discussion only makes sense in > case that the "other side" is able/willing to understand simple > explanataions... > I have just spent the last half hour reading this thread and nowhere have I seen you give ANY explanations, simple or complex. You have simply stood on your hind legs and declared that you are right and everyone in the Debian group is wrong and evil in their intent or just plain stupid. So, can you actuall construct an explanation that does not include all the inflamitory statements you have assigned to your "opponents" here at Debian? I have been with the Debian group since very early in the project (when I joined there were about 75 of us) and while I have not agreed with every decission this group has made over the years. I DO agree that the decissions have been made in a thoughtful and deliberate manner that supports the DFSG and our goals for Software Freedom. Other proponents of Software Freedom don't always agree with us, or us with them. For me that is part and parcel of the concept of Freedom in a diverse society. If you are going to debate, it is more useful for you to provide clear points of view about the concepts being discussed. All I have seen is juvenile name calling and useless bile. Please grow up! Luck, Dwarf Sometimes known as "the voice of reason" ;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
