Hi Arno, I think while you might be right in general, in this case you're missing the point. First of all, I agree that binary packages should be rebuilt. But I disagree to classify upstream documentation in HTML as binary. As we're all know, HTML is a form of source, it is very human readable/editable. But that's not my point. In this case, I see no reasons to regenerate upstream HTML whatsoever and I have number of reasons not to do so. When you answer my concerns, you only reply to the least important argument completely leaving my primary reasons alone. Specifically regarding git2cl there are reasons not to regenerate upstream HTML. From merely technical side it is pointless as we will get almost the same output. But from legal point of view this 'almost' could be very important. Imagine if during regeneration we loose something significant. For text document, including HTML, formatting may be significant. The meaning of a phrase can be easily changed with simple reformatting and therefore transformation of document may change original copyright as regenerated document would be different. Reformatting may accidentially change the meaning of a message in a text. If I publish an essay with my copyright on it I would be very much against any change, no matter how little because the editor may not understand the reason why I put dot or comma or line break and how it is affect the message. To leave some original work pristine, and ship it as is would be requirement for some work, to say the least. It is a matter of respect to the original work as well. By changing original work in any way, you're changing the copyright as well. Even if license allows it this power should be used carefully with precautions against introducing accidential change. Introducing changes to copyrighted work should be carefully considered. Regarding git2cl README.html, its transformation with asciidoc introduce inacceptable change to the text of the document. Not merely formatting, which I consider significant change, like altering the shades and/or intensity of colors in the image. The text is actually changed. This is goes beyond just regeneration of a document. Such change must be justified, explained, mentioned in change log, forwarded upstream and copyrighted. But what's the particular change is? It is the date when document is written. You may argue that it is the date when document was generated but for me and for many readers this is the date when document was published. Just like the date of the book published. Changing it would be as unethical as changing year in upstream copyright, or the date of diary record in published memoirs. This is completely unacceptable. It is a shame I must explain such trivial things. If introduced, such change is disruptive and misleading. Similarly unethical would be taking out the date of publishing which may be considered as ill alternative to changing the date in upstream document. After all, we should not be taking our ambitions to extreme and make assumptions how upstream generate the documentation they provide. It may be the case that upstream manually typed the document. If this resemble you the output of a html generator it may be a very poor excuse to modify original work merely because you can. Regards, Dmitry. On Tuesday 06 December 2011 11:25:38 Arno Töll wrote: > Hello Dmitry, > > On 03.12.2011 09:23, Dmitry Smirnov wrote: > > However I'm not too sure if introdicing another build-dependency worth > > regenerating single file merely to get almost the same file (but > > generated) as result. Not to mention the effort to implement rather > > trivial but nevertheless the change. > > Paul asked me to elaborate why you shouldn't be doing that, as I > coincidentally discussed the same argument in IRC earlier today. Note, > this is not primarily a technical decision, but a legal one. > > We require all software in main to be self-contained. That means every > binary package must be able to be reproduced by DFSG free tools in order > to be kept in main. In your case that would mean, to be actually sure > your package fulfills that requirement, you should be rebuilding the > HTML docs by using asciidoc. That might sound trivial, and in your case > it most likely is, but in some cases that's not an easy task at all. > > To keep that certainty over time it is a good idea to be rebuilding > every single bit in your package from source every time a new upload has > been made. You shouldn't worry about the build dependencies, the buildds > won't care (much). Hence, not building something from source in favor of > stuff somehow being pre-processed for a DFSG free package is a poor > trade-off. > > Finally please note, asciidoc could be cleaned of its recommends as they > aren't really qualifying for "recommends" which would make the > dependencies itself substantially smaller.
Attachment:
signature.asc
Description: This is a digitally signed message part.