| |||||||||||||
Zacchiroli: working with FSF on Debian Free-ness assessmentZacchiroli: working with FSF on Debian Free-ness assessmentPosted Jul 4, 2012 17:41 UTC (Wed) by nijhof (subscriber, #4034)Parent article: Zacchiroli: working with FSF on Debian Free-ness assessment
Will they also be attempting to make Gnu software (plus documentation) DFSG-free?
(Log in to post comments)
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 4, 2012 18:09 UTC (Wed) by scientes (guest, #83068) [Link]
It would be great if the FSF would remove back-cover, front-cover, and invariant sections from their docs, perhaps by just removing the invariant sections that they deem particularly "special" to a publishing on their web site.
Even better, they could re-license (or dual-license) these docs under the GPL or compatible, which I (and Debian) find perfectly fine for documentation. This would allow incorporation of Docs into programs, (and potentially visa-versa)
The GPL is not fine for documentation ... Posted Jul 5, 2012 6:22 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] ... because every time it is used that way, it induces large numbers of people to violate copyright. Let's say you GPL a document, and you prepared it with LaTeX. That means LaTeX is the source code, the preferred form for modifying the work. If I give someone a PDF of the document without the LaTeX, or without a written offer, good for three years, to provide the LaTeX on request, I'm a violator. But since people don't understand that, everyone breaks the rules. Only the copyright holder has standing to sue, but some day some copyright holder of GPLed software, say Oracle, will be a jerk about it.Likewise, if you create an image with the GIMP and GPL it, a JPEG or PNG of the image does not suffice for distribution. The XCF has to be retained, and made available to any recipient of the image. That doesn't mean I would argue for the FSF's documentation licenses as they have all kinds of problems. The Creative Commons licenses are better for non-software free media.
The GPL is not fine for documentation ... Posted Jul 5, 2012 14:07 UTC (Thu) by jthill (guest, #56558) [Link] Likewise, if you create an image with the GIMP and GPL it, a JPEG or PNG of the image does not suffice for distribution. The XCF has to be retained, and made available to any recipient of the image.I think that's not true, that you can license your own work in any form on any terms. If you offer a GPL'd XCF then redistributors have to offer that as well, but if you separately or only offer a GPL'd JPEG, redistributors only need to offer that.
The GPL is not fine for documentation ... Posted Jul 6, 2012 4:43 UTC (Fri) by pbonzini (subscriber, #60935) [Link]
You can, but redistributors cannot. If they modify the XCF, they cannot distribute it as JPG alone, because it's not the preferred form for modification.
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 4, 2012 18:11 UTC (Wed) by Richard_J_Neill (subscriber, #23093) [Link]
This should be easier now than it once was. A few years ago, I'd suggest that the following problematic pieces of software were "needed" to make a desktop Linux system usable; none of them shipped by default.
1. Flash
The current state of play is much better:
1. Still needed, but increasingly replaced by HTML5.
Summary: with reasonably careful choice of hardware, it's only really the flash player that we need to worry about.
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 4, 2012 18:22 UTC (Wed) by lindi (subscriber, #53135) [Link]
2. The Java plugin was not released as free software. Instead a new plugin was written mostly from scratch. There are unfortunately still sites that don't work with this new plugin and require the non-free one.
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 4, 2012 19:06 UTC (Wed) by Otus (guest, #67685) [Link]
> 8. Libfreetype6 (with bytecode interpreter).
> [...] > Free software, just upsets certain people who believe in patents!
I though those expired?
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 4, 2012 19:16 UTC (Wed) by thedevil (subscriber, #32913) [Link]
"4. Acrobat Reader
Evince/Okular replace it."
This is a curious statement. xpdf was around forever, and evince has no
I don't know for sure if the above also applies to Okular but I suspect
Would you like to join me in fixing this situation?
https://github.com/nobrowser/spadeful
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 4, 2012 19:26 UTC (Wed) by anselm (subscriber, #2796) [Link] I don't know for sure if the above also applies to Okular but I suspect it does, with the obvious substitution of Qt for Gtk. Okular is really a pretty good PDF viewer. It used to be much more usable than Adobe Reader until Adobe Reader learned to re-load PDF files that had changed while being displayed. It does thumbnails, tables of contents and PDF forms. It does side-by-side display of pages. It's quite fast. It does selections as text or graphics. It does annotations. It has a fairly nice presentation mode. It will even read your document to you. It is in fact one of the more obvious reasons to use KDE in the first place. I use Okular every day and I'm pretty sure I haven't started Adobe Reader for three months or so – there's no need.
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 4, 2012 19:32 UTC (Wed) by thedevil (subscriber, #32913) [Link]
"Okular is really a pretty good PDF viewer."
How does it fare on the list of issues in my README?
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 4, 2012 20:30 UTC (Wed) by anselm (subscriber, #2796) [Link] I'll see whether I can answer these. I have nothing to do with the program other than as a satisfied user, though. 1. Some very common actions (such as jumping to a particular page) have no keyboard bindings. As far as I can see most of the usual actions do have keyboard bindings (usually Ctrl+Something). »Go to page« is Ctrl+g.These can be customised by the user through a reasonably obvious interface. 2. What keyboard bindings there are consist of multiple modifier keys so relief from carpal-stressing mouse handling is slight. Most of the keyboard bindings use only one modifier (Ctrl). Again, these can be customised. 3. Making the preceding points worse, tab order in the interface is inconsistent or wrong. As far as I can see the tab order looks reasonable. 4. There is no browser-like breadcrumb feature - you cannot visit a different place in the document and then return with a simple click or keystroke. Okular does that. The »go back« feature is Ctrl+Shift+Left, so it's not a »simple« keystroke, but that could be changed in about 1 minute. One might also want to add a »go back« icon to the toolbar, which again is a fairly simple customisation. 5. (A pet issue of mine) When reading a document with bookmarks, the page view and the bookmark view are not synchronized. Meaning when you go to a spot by clicking on a bookmark, then do a couple of page-up or page-down in the page window, then you switch back to the bookmark window and hit a key, you're dumped to where you started. It looks like Okular fails that one, then. It does show you where you are in the bookmarks window, though, and tracks your position among the bookmarks if you move around in the page view. Only if you hit a key in the bookmark view that moves you relative to whichever bookmark was selected last.
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 13, 2012 21:26 UTC (Fri) by JanC_ (guest, #34940) [Link] And for a recent release of Evince:1. Some very common actions (such as jumping to a particular page) have no keyboard bindings."Go to page" is Ctrl+L. Most common actions seem to have keybindings (but "common" might be a personal thing). 2. What keyboard bindings there are consist of multiple modifier keys so relief from carpal-stressing mouse handling is slight. Seems like all shortcuts require at most 1 modifier. Also, if you have physical problems, I suggest you look into the a11y configuration for your distro/desktop (as I did recently). 3. Making the preceding points worse, tab order in the interface is inconsistent or wrong.This would require more information about what you consider wrong or inconsistent, as I don't use that much (probably best as a bug report). I assume tab order is also important for e.g. blind people who have to rely on a screen reader like Orca. 4. There is no browser-like breadcrumb feature - you cannot visit a different place in the document and then return with a simple click or keystroke.There is a button for that which you can add to the toolbar. I don't know about a keystroke. 5. (A pet issue of mine) When reading a document with bookmarks, the page view and the bookmark view are not synchronized. Meaning when you go to a spot by clicking on a bookmark, then do a couple of page-up or page-down in the page window, then you switch back to the bookmark window and hit a key, you're dumped to where you started.Seems like it doesn't update the bookmark view indeed. You might want to submit a feature request bug to improve this (or provide a patch yourself).
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 5, 2012 2:05 UTC (Thu) by josh (subscriber, #17465) [Link]
I find evince significantly more comfortable than Acrobat Reader, having in the past used the latter. Also, evince handles PDF forms, which last I checked xpdf did not.
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 6, 2012 12:07 UTC (Fri) by spaetz (subscriber, #32870) [Link]
Unfortunately evince sucks when it comes to creating or reading annotations (evince only supports the popup bubble annotation type of thingy), which requires me to go back to proprietary things for making/reading annotations.
evince and GNOME Posted Jul 5, 2012 18:45 UTC (Thu) by josh (subscriber, #17465) [Link]
The comment in your repository suggests that you don't want to use or work on evince due to its GNOME dependencies. However, evince can build without any GNOME components, using only GTK+.
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 19, 2012 10:41 UTC (Thu) by philomath (guest, #84172) [Link]
xpdf is slow as molasses compared to evince.
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 5, 2012 12:56 UTC (Thu) by sionescu (subscriber, #59410) [Link]
> 4. Acrobat Reader
> Evince/Okular replace it.
I keep stumbling upon PDFs that Okular and Evince can't print while Acrobat does a very good job.
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 4, 2012 22:14 UTC (Wed) by lxoliva (subscriber, #40702) [Link]
That would be nice, for sure, but the FSF is self-consistent with its separate criteria for software and documentation, while Debian chose a single criterion for both without meeting it for either. Talk about painting oneself into a corner and then shifting the blame onto others...
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 5, 2012 6:56 UTC (Thu) by ayers (subscriber, #53541) [Link]
I believe the easiest approach to handling the GFDL issue, would be having the GNU project consider packaging the documentation in separate tarballs and Debian simply leaving those packages in 'non-free'.
If the only packages in 'non-free' would be GFDL licensed documentation (and possibly the IETF documents or similar 'non-functional' works), I could imagine advertising the 'non-free' archive would be a non-issue for the FSF.
The issue, which any combined effort should focus on, is providing free replacements of sufficient quality in 'main' for proprietary software packages in 'non-free'. And in the context of the kernel (i.e. the LWN audience) that would include finding a way to viably replace proprietary firmware, which seems to be a task, which for very obvious reasons seems infeasible... but then again, lots of seemingly infeasible feats have already been accomplished in the Free Software and Open Source movements.
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 5, 2012 8:38 UTC (Thu) by viiru (subscriber, #53129) [Link]
> I believe the easiest approach to handling the GFDL issue, would be
> having the GNU project consider packaging the documentation in separate > tarballs and Debian simply leaving those packages in 'non-free'.
I'm not sure if you are aware of this, but this is what is currently done (except that the splitting is done by Debian, not by GNU). Emacs, gcc and such already have separate packages in non-free for the non-free documentation.
> If the only packages in 'non-free' would be GFDL licensed documentation
I'm not sure how many actually used software packages non-free contains these days, at least I currently use it only for firmware and GNU documentation. I additionally use contrib for some games (Doom variants, mainly).
I don't think most of contrib is considered a problem by the FSF due to the way they consider programs and data separate concerns (this excludes the "installer for a non-free program" type packages in contrib, such as the Adobe flash plugin etc).
Zacchiroli: working with FSF on Debian Free-ness assessment Posted Jul 5, 2012 9:24 UTC (Thu) by ayers (subscriber, #53541) [Link]
> I'm not sure if you are aware of this, but this is what is currently
> done (except that the splitting is done by Debian, not by GNU). Emacs, > gcc and such already have separate packages in non-free for the non-free > documentation.
Yes, I'm aware of that, but the discussion was about collaboration and that was simply a suggestion that the split could be done by GNU so that Debian could use pristine tarballs. This might be simple way for the GNU project to contribute in the collaboration efforts.
> I'm not sure how many actually used software packages non-free contains
What I haven't been able to find is a clear definition of what is allowed in non-free and if there is a process for things to enter non-free. Of course if the Debian project does define a formal process and criteria of when project qualifies and when it should be retired, then it becomes a bit meaningless to argue that non-free should not be considered part of Debian. So defining such a process is probably contentious. The only thing I have found so far is:
> (this excludes
Once gnash/lightspark/whatever implement the 'to be defined/expected' functionality, I would wish for a process to have that installer removed from the debian archives as obsolete.
|
|||||||||||||