Re: RFS: git2cl
Dmitry Smirnov wrote:
> 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.
Not binary, but generated from a source. PDFs can be edited in a text
editor too, but if they were generated from a TeX file, the GPL would
give you the right to ask for that source file (the "preferred form of
the work for making changes in it" [1]).
[1] http://www.gnu.org/licenses/gpl-faq.html#GPLOtherThanSoftware
> 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.
Of course formatting is significant, and no one is asking you to replace
a carefully handcrafted HTML file with a generated one; README.html is
already generated from README upstream, so there's no loss there.
> 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.
Using a tool to convert one format to another does not create a new
copyright; there's no creativity involved. Just like converting a JPEG
to PNG does not give you any rights over the PNG.
> 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.
If you published your text under a free license, you explitly granted
this right to anyone, so there's not much you can do about it. But
again, in this case, no one is even trying to change the meaning of
README.html.
> 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.
But that's against the very spirit of free software. Why even bother
compiling software if upstream provides binaries then?
> 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.
As I said already, I don't see any copyright issues in this case. And
since README.html is already a generated file upstream, I don't see what
accidental changes could occur.
> 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.
If you go there, users should not be allowed to use custom CSS in their
browser, or change the font size, or resize the window, etc. Formatting
is not content (we're not talking about adding commas, or breaking
paragraphs, that's different, but merely changing margins, font size,
color, etc.---none of which has an impact on the meaning).
> 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.
It _is_ the date when the document was last generated, and _not_ when it
was written; there's a :Date: header in asciidoc for that. If you feel
it's important, get upstream to use it (they could also use :Revision:).
That date is clearly not _content_ (as you keep saying changing it would
be like altering the document's content), it's not even present in the
source file.
Changing a copyright date is illegal, so that's a completely different
matter.
> 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.
No assumptions are being made, README.html was generated from README
using asciidoc 8.2.7.
> It may be the case that upstream manually typed the document.
It isn't. They didn't modify the generated output in any way; here's a
diff:
--- a/README.html
+++ b/README.html
@@ -385,7 +385,7 @@ consider switching from CVS to GIT for my projects.</p></div>
</div>
<div id="footer">
<div id="footer-text">
-Last updated 2008-08-27 12:42:17 CEST
+Last updated 2011-12-06 13:44:53 CEST
</div>
</div>
</body>
> 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.
What excuses are left now?
Cheers,
--
Benoît Knecht
Reply to: