Talk: List of software that does not respect the Free System Distribution Guidelines

Thank you

This is a great list and what better place to collectively maintain it than LibrePlanet. I often wonder if some piece of software is free software or has some other ethical issue hidden in the details. I often try to visit the Free Software Directory but an omission there doesn't necessarily imply non-freeness. Thanks again. --Ashawley 04:08, 23 October 2009 (UTC)

Suggestion

This list could be less ambiguous if it were titled "List of software packages that do not respect meet the Free System Distribution Guidelines". I think this would be good because it changes the wording of the page to consider "unfreeness" incrementally rather then decrementally. I think this for a couple reasons:

1. Adding the word packages removes the insinuation that software in the list, and any portion of it, is completely non-free and cannot possibly be repackaged or sourced elsewhere in a compliant form. For example:
   • Texlive is only non-free on the basis of a script that can be removed. Its very plausible that this package can be build without the non-compliant portion.
2. Adding the word packages suggests that most of the entries will be about a prepackaged container of software, rather then the actual development project, or source code packages. Cases where this distinction is useful will gain visibility to source packagers like myself, and cases where the distinction isn't important won't matter with or without this change.
3. Even if most software listed here is completely non-free and couldn't possibly be repackaged or obtained elsewhere in a fully compliant form, it will become obvious in the description.
4. Even if most of the software listed here couldn't possibly be repackaged or otherwise obtained in a fully compliant form, this would give any software which could much more visibility, possibly increasing the likelihood that compliance will occur.
5. The word packages also suggests that most of these entries will be about prepackaged software, not a particular developer or development project, and about not source code packages. Again, cases where this distinction is not important will not suffer with or without this change.
6. Replacing the word respect with meet eliminates an accusatory tone.
7. The word meet also adds the connotation that the software in this list only needs to some improvements to come up to a benevolent, rather then petulant, standard. In truth, taking away the user's freedom is often justified in petulant, selfish tones. I think that saying that proprietary developers don't respect users freedom is useful in speeches promoting free software (esp. to an audience that is ostensibly comprised of users who should care about their freedom). But I think its less likely to persuade a developer of a non-compliant entry if it were seen.

K2t0f12d 03:06, 27 July 2010 (UTC)

I agree, and make the additional suggestion that the list be separated into distinct categories:

• Packages that can be made to meet the Guidelines (e.g. by removing a reference to proprietary software, a script made to operate with such, recommends proprietary addons, or some non-essential component(s) that are proprietary)
  • Perhaps another category for software that has such problems that have been resolved by a fork (i.e. icecat)?
• Packages that already have been made to meet the Guidelines (e.g. the concerns listed refer to an older version and are no longer current)
• Packages that cannot be made to meet the Guidelines (e.g. those that absolutely require proprietary software to function, contain proprietary components that cannot be removed without rendering the software unusable, or are under an unacceptable license)

As it stands now, we have a completely free IRC client that makes the list because it mentions a certain proprietary Norwegian browser by name listed alongside a shareware image viewer, a free browser that recommends proprietary extensions, Linux kernel blobs, a proprietary archiver, Canonical's proprietary software package, a free package that contains a script to operate with bitkeeper, and a free Doom-like shooter game with a copyright issue that was resolved one year ago, with the implication that these all violate the Guidelines to the same or a similar degree. I think the suggestion that xchat (which is golden except for the fact that it mentions Opera) is in the same circle of hell as is Firefox (which points out proprietary addons), or that Firefox itself is in the same circle of hell as are unrar or xv (which are themselves proprietary), is ludicrous... not to mention that ones that have fixed their problems but are still damned to hell.

It should be stated, of course, that the first and third categories are still unacceptable for inclusion into a fully free system such as Trisquel; but overall, the "fixable" ones should be delineated from the ones for which there is no hope. Something like xchat could easily be made to meet the Guidelines; but there's no reason to believe something like pvpgn or unrar could.

Adrian Malacoda 23:01, 6 October 2010 (UTC)

• I have been working a lot on this page and I agree it should be broken down into categories. This is for multiple reasons. Firstly, the page is over 32 kilobytes. The wiki software even states that if the page is over 32 kilobytes it probably should be broken down because it can cause problems for some browsers. That is just a technical reasons. The second reason is as you mentioned. For example some programs on here should be permanently removed because of what they do or their license. An example is there are one or two programs that all they do is download the proprietary nvidia/ATI drivers. There is no point in ever including those. However some had previous freedom issues which have been resolved quite a while ago like freedoom or cracklib2. Here is my proposal on how we should break the page down:

• Packages/Programs that should be removed (e.g. unrar, pvpgn) because they are non-free or their sole purpose is to install non-free stuff
• Upgrade to use a particular version (e.g. freedoom, cracklib2). These programs/packages may have had freedom issues in the past but have been resolved. The issue can be fixed by using a certain version of the program.
• Modify the package or program (e.g. xchat). These programs just need modification to meet the guidelines. They could just involve removing a reference to a non-free program. These offenses usually are not as severe as to warrant removal.
• Multiple problems/fixes (e.g. boinc/seti, openoffice.org). These programs have multiple problems or fixes. These programs/packages could have their issues fixed by a variety of ways and it is up to the distro how they want to handle it.

Hope that helps SirGrant 11:44, 9 July 2012 (EDT)

That makes sense, but it would make looking for a package less convenient if you don't know what the problem is. I've been playing for a long while with the idea of putting this list into a database with a nice front-end, like h-node or the Free Software Directory.

Advantages:

• Improves machine-readability, making it easier to derive a distro-specific blacklist.
• Makes it more usable for non-Debian based distros.
• Makes it easier to integrate with Debtags, Distromatch, Appstream etc.
• It could integrate patches that can be commonly used.

Disadvantages:

• In theory this could be a wiki page, but that doesn't scale. That means setting up a separate project, which needs infrastructure and someone to maintain it.
• It needs a database design that's flexible enough to accomodate all distros (and possibly different versions of distros).
• A greater level of detail comes at a higher maintenance cost by all involved distros.
• Distros might not want to tie their work flow to this external resource, meaning they have to maintain a second blacklist of their own (or only maintain that internal blacklist if they don't see the value in co-maintaining the common one).
• Distros need to agree exactly on what goes into the blacklist. This could also be an advantage, depending on how well the community gets along.

Samgee 06:07, 10 July 2012 (EDT)

chromium-browser

This list mentions chromium-browser as one of the "guilty" packages but fails to explain why. The diff where chromium-browser is added mentions this mailing list post, where the only mention of chromium-browser is this:

chromium has been renamed chromium-bsu (to allow chromium-browser).

The non-free Chrome has problems (absent in Chromium), though, according to this comparison.

Adrian Malacoda 00:35, 22 September 2010 (UTC)

Fixed. The referenced bug report was pretty clear IMO, though. Samgee 18:09, 23 September 2010 (UTC)