Francesco Poli wrote:
> On Thu, 17 Apr 2008 15:27:56 +0200 Rafael Laboissiere wrote:
>
> [...]
>
>> * David Bateman <[EMAIL PROTECTED]> [2008-04-10 11:15]:
>>
> [...]
>
>> I am not a license expert and I have no idea whether including GPL code in a
>> non-GPL released documentation is okay. I think it boils down to making
>> sure the licensing conditions expressed in fixed.txi are compatible with the
>> GPL. For the debian-legal people following this thread, here are the
>> conditions:
>>
>> Copyright (C) 2004 Motorola Inc
>>
>> Permission is granted to make and distribute verbatim copies of
>> this manual provided the copyright notice and this permission notice
>> are preserved on all copies.
>>
>> Permission is granted to copy and distribute modified versions of this
>> manual under the conditions for verbatim copying, provided that the entire
>> resulting derived work is distributed under the terms of a permission
>> notice identical to this one.
>>
>> Permission is granted to copy and distribute translations of this manual
>> into another language, under the same conditions as for modified versions.
>>
>
> As I already said in this same thread[1], I think this license is
> GPL-incompatible.
>
> [1] see http://lists.debian.org/debian-legal/2008/04/msg00047.html
>
I missed this message for some reason.. Ok, having looked at it, for the
fixed toolbox the code is all copyright Motorola, and written by me
personally. The internal release documentation I have is not specific on
the documentation license and so the dual license idea is ok in that
case. The communications toolbox is different as there are multiple
authors with some code taken from GPL source files..
That being the case a GPL compatible documentation license would be a
better solution. Can you please suggest an appropriate modification of
the documentation license to make it GPL compatible. I see no issues
making this change as all of the documentation in fixed.txi and
comms.txi was written by me and I have a release from my employer for
fixed.txi, and the bits from other authors in the final PDF are all from
GPLed sources.. Therefore changing to a GPL compatible documentation
license is the easiest solution. But please suggest one.......
>
>>
>>
>>> If its only the issue of the inclusion of fixed.{texi,txi} that is the
>>> issue that is preventing the packages inclusion in debian I have no
>>> objections to including these in the package tar-ball.
>>>
>> I think that including fixed.texi should be enough, even though it is
>> derived source.
>>
>
> What do you mean "derived source"?
> Which is the preferred form for making modifications to fixed.pdf?
> Would the author prefer modifying fixed.texi or fixed.txi?
> The preferred form is the source code.
>
The source files for the documentation are the source code of the entire
package, and in particular to help strings of the functions (this can be
m-files for C++ files) and a master document fixed.txi. The script in
octave-forge mkdoc is responsible for creating a DOCSTRING file that
contains all of the help strings of the package, and then the script
mktexi takes the *.txi file together with DOCSTRINGS and replaces
instances of "@DOCSTRING(FUNCNAME)" with the corresponding functions
help string creating the file fixed.texi.. The file fixed.texi is then
the only file that is needed with texinfo, makeinfo etc that is needed
to create the final documentation in HTML, PDF or whatever other form is
desired.
As fixed.texi is a derived file, changes to it will be lost in the
documentation build process and so changes should be made to the
fixed.txi file... However, the build tools to get the fixed.texi file
include the mkdoc and mktexi scripts from the octave-forge SVN, and so
someone modifying the documentation will need those tools to rebuild..
As mkdoc and mktexi are build tools that are independent of the package
in the same way than gcc is I don't see the need to distribute them with
the package and would prefer not to. However I have included noth
fixed.texi and fixed.txi in the source packages from octave-forge itself
now.
>
>> Including fixed.txi also will not hurt, although it cannot
>> be used to build fixed.texi from the tarball alone.
>>
>
> Why not?
> Are we missing a Build-Depends, by chance?
>
Effective, but what should the Build-Depends be? Do you seriously want
to package the mkdoc/mktexi scripts seperately from octave-forge itself,
just to be able to rebuild fixed.texi on the off-chance you'll want to
do it?
Regards
D.
--
David Bateman [EMAIL PROTECTED]
Motorola Labs - Paris +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin +33 6 72 01 06 33 (Mob)
91193 Gif-Sur-Yvette FRANCE +33 1 69 35 77 01 (Fax)
The information contained in this communication has been classified as:
[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
