On 22/03/14 at 15:42 +0800, Paul Wise wrote: > To the candidates, > > Some parts of the DFSG seem like they do not apply to some types of > works. In particular, items 2, 6, 7 and 8 seem to not apply to things > that are not "programs". Much of the DFSG doesn't seem to apply to > things that are not "software". > > The DFSG does not define what is meant by "software" or "programs". > The definitions of software and programs on Wikipedia does not include > things like documentation, fonts, raster images, vector images, 3D > models, web pages and so on. It isn't clear to me which kinds of > software are considered "programs" under the DFSG and which are not. > > The FTP team have been behaving as if the all of the DFSG applies to > all types of works, particularly for DFSG item 2 they require "source" > for PS/PDF documentation. > > Over the years some developers have been complained about having to > strip non-free and or sourceless files from source packages. I have > interpreted this to mean that they don't think the DFSG should apply > to the full contents of source packages. > > I believe the DFSG should ensure equality of access to works in > Debian. Thus it is my opinion that all items in the DFSG should apply > to the contents of all source and binary packages in Debian main and > that we should amend the DFSG to replace all uses of the words > "program" and "software" with "work". This would also align the > terminology in DFSG with the terminology in the SC, which now uses the > word "work". We probably also need an exception for license texts, > which are usually not modifiable. > > The Open Source Definition is derived from the DFSG and has evolved > slightly. If the DFSG were to change, we might want to adopt some of > those changes at the same time. In particular the clarifying > rationales are an interesting feature of the OSD in my opinion. > > Please share your thoughts on the SC and DFSG, in particular: > > Which items of the DFSG should apply to which types of works? First, I'm sure you are aware that this was recently discussed at length[1], and many DDs provided insightful POVs in that discussion. That's the kind of topics where the DPL can express his own opinion, but when talking to the outside world, also has a duty to at least mention the diversity of (valid) opinions inside the project. [1] https://lists.debian.org/debian-devel/2014/03/msg00190.html I think that on this issue, we should be more explicit about our motivations and goals. Providing the preferred form for modification for as much content as possible is important, because it makes it easier to fork the software if needed, which reduces the risk of the project suddenly becoming blocked by the upstream's developer unresponsiveness. So in the end, making sure that the preferred form for modification is available increases the trust we can put in a given package. So, what should we do when the preferred from for modification for a PDF or PNG cannot be found? It is hard to provide a general answer, because it's basically a risk assessment: how likely is it that the fact that the source is missing is going to be a problem? But we also need to wonder what is the best for our users. Should we remove a PDF documentation because its source has been lost? If its source has been lost, then it's easy to argue that the PDF documentation has become the new preferred basis for modication (starting with, e.g. pdftotext). > How do you currently apply the DFSG wrt your Debian packaging work? > > How do you currently determine which files in upstream source packages > are "source" and which are not? > > How do you currently deal with upstream source packages that include > generated files instead of creating them at build time? My recent packaging work has been limited to how-can-i-help and packaging-tutorial, for which I'm upstream. But as a data point, in packaging-tutorial the source for the PDF documents is provided, as well as the code to generate the figures (in tikz), and the code to update some statistics about debhelper vs cdbs vs dh. > Would you initiate or support a GR to replace uses of the words > "program" and "software" in the DFSG with "work" where appropriate? I think that a GR could be a good way to move forward on this issue, by measuring the weight of the various opinions inside the project. But there are people who care more deeply that I do about this issue, so I won't initiate a GR myself. Regarding supporting it, I'm not sure if you mean sponsoring it or just voting it above FD. But it's anyway really hard to answer without reading the exact text. Lucas
Attachment:
signature.asc
Description: Digital signature