bring back H.261 encoding
Package: ffmpeg Severity: wishlist Version: 0.svn20080206-1 Hi, according to http://blogs.sun.com/openmediacommons/entry/oms_video_a_project_of and other resources, SUN develops a new codec called OMS, which is a royalty-free codec loosely based on the h.26x codec family. In the FAQ the question asking Why have you started from h.261? is answered with the following reply: H.261 was finalized in 1989, outside the (17-year) patent window. Key tool strategies and prior art were already established in that era. Wouldn't this mean that we are also free to ship the built-in H.261 encoder in ffmpeg packages? Cheers, Fabian -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OctDev] Clarification about PDF file license
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,
Re: [OctDev] Clarification about PDF file license
Francesco Poli wrote: On Thu, 17 Apr 2008 16:00:06 +0200 David Bateman wrote: Rafael Laboissiere wrote: [...] * David Bateman [EMAIL PROTECTED] [2008-04-10 11:15]: Just a further question, if the documentation is distributed as part of the package itself under a GPL license then the only issue is the inclusion of the fixed.texi and/or fixed.txi file within the package tar-ball. Yes, distribution of the source is a requirement of the DFSG (see item 2, http://www.debian.org/social_contract#guidelines). Then I'll add the sources to the package and it'll be in the next octave-forge release. I'd suggest adding the *.texi files as the perl scripts mkdoc and mktexi from octave-forge then won't be needed. I think it would be useful if you (David) clarified a bit how the PDF file is compiled from which source files licensed under which terms, since I am beginning to get lost in trying to follow this discussion! Sorry! :p If I understand correctly, the PDF file is a manual compiled from a .texi file, which, in its turn, is generated from a .txi file *and* from a significant number of parts extracted from some .cc files. *.cc \ |--- fixed.texi --- fixed.pdf fixed.txi -- / The .cc files are released under the GNU GPL (which one? v2 only? v2 or later? v3 only? v3 or later? ...). fixed.txi is Copyright (C) 2004 Motorola Inc and released under the license that has been quoted previously in this same thread (and is GPL-incompatible). But everything in fixed.txi is written by you (David), and you have the permission from Motorola to relicense the text as you wish. Did I get it right? [...] That is effectively correct though there is an intermediate step and a couple of octave-forge specific build tools. The complete set of steps together with the build tools are comms.txi fixed.txi --- \ | comms.texi comms.pdf *.m | fixed.texi --- fixed.pdf *.cc DOCSTRINGS / /\ /\ /\ || || || mkdoc mktexi texi2pdf where mkdoc and mktexi are perl scripts that are part of octave-forge itself. All of the *.m and *.cc files are GPL v2 or later licensed. As are mkdoc and mktexi themselves as they are derived form another script make_index that is GPL v2 or later. The *.txi files are under the license previously discussed. The Motorola release request process I went through made no specific claim on what the documentation license of the code would, just that documentation would be released together with GPL v2 or later code. Therefore under the terms of that release there is nothing to stop a change in the documentation license of fixed.txi, as it was I as an employee of Motorola who wrote this code and got the permission for the release. Isn't the above license GPL compatible? I don't think so... Then the simplest solution is to make comms.txi and fixed.txi have a GPL compatible license and be done with. If it isn't I don't think there is an issue of change the license of this and the comms.txi file to have a GPL compatible license. All text in the fixed.pdf file is mine and I have the release paper work internal that would allow me to re-release under a GPL compatible documentation license. As for comms.pdf the fixed text from comms.txi is all mine and the rest of the text is taken from the functions that are GPLed. So a GPL compatible documentation license would fixed that as well. If the situation may be described as I did above (in the If I understand correctly part), then I think you could relicense the .txi files under a GPL-compatible license and solve the issue once and for all! Exactly. But if the GFDL itself is not GPL compatible what is a GPL compatible documentation license? So if the above license isn't compatible with the GPL what is a compatible license as I see no issues in changing it to something else. [...] My usual recommendations are: * the GNU GPL itself, if you want a copyleft That is a bit of an ugly solution but at least ensures compatible licenses.. * the Expat license[1], if you don't want a copyleft on the text (but please note that the resulting PDF file would anyway be covered by the GNU GPL, because of the parts extracted from GPL'd .cc files) [1] http://www.jclark.com/xml/copying.txt Huh? I'm not sure a see a significant difference in the above license to the one the *.txi already have.. The above license doesn't require distribution of the source code with the generated PDF file, which was the original issue in this thread.. About the only difference I see with this license is that it is explicitly mentioned that you can sell copies of the manual.. D.
Re: [OctDev] Clarification about PDF file license
* David Bateman [EMAIL PROTECTED] [2008-04-18 10:35]: 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... Question to the debian-legal crowd: Would a less-constraining version of GFDL be okay in this case? There are packages in Debian for which the .info file is released under these terms: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. which are DFSG-compatible. The manual contains scraps of the function documentation strings contained in the *.el files, which are GPL'ed. One example of this is the remember-el package. If you type info remember you will see the license above and if you type: info -f remember-el.info -n 'Function Reference' then you will see the documentation strings taken from /usr/share/emacs/site-lisp/remember-el/*.el -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mined copyright with no copyright
Hi All, I'm returning with this issue :) (was busy with studies) Well, the last time i contacted Thomas Wolff about this and he replied with this: --- Hi Mauro, I confirm there was no copyright notice or file attached, just a doc file with the line Author: Michiel Huisjes. near the top. There is some discussion about Minix license to be found on the web, e.g. http://minix1.woodhull.com/faq/mxlicense.html but I would actually even assume that mined is not really part of the operating system but rather a tool written for it. If it is seems to be helpful, I could include a copy of that BSD-like copyright text somewhere in the source subdirectory, maybe included in the mined.doc file, but I wouldn't like to place it into the main directory so other distributions might see a conflict to the GPL and complain in turn... I hope this is sufficient to get a pass from the lawyer, Best regards, Thomas --- If you think this is fine, this package would be ready to be uploaded asap. So i would really like to read your opinions once again :) Regards, Mauro -- JID: [EMAIL PROTECTED] BEGIN GEEK CODE BLOCK Version: 3.12 GCM/O d-dpu$ s-:- a--a+++$ C+++ LU P+ L++ E W+++ N !o K w O !M !V PS+ PE Y+ PGP t 5– X R tv++ b- DI D++ G+ e h!h-- rr+++ y+ END GEEK CODE BLOCK
Re: Bug#476644: bring back H.261 encoding
Fabian Greffrath [EMAIL PROTECTED] writes: Package: ffmpeg Severity: wishlist Version: 0.svn20080206-1 Hi, according to http://blogs.sun.com/openmediacommons/entry/oms_video_a_project_of and other resources, SUN develops a new codec called OMS, which is a royalty-free codec loosely based on the h.26x codec family. In the FAQ the question asking Why have you started from h.261? is answered with the following reply: H.261 was finalized in 1989, outside the (17-year) patent window. Key tool strategies and prior art were already established in that era. Wouldn't this mean that we are also free to ship the built-in H.261 encoder in ffmpeg packages? Even though the spec dates from 1989, it is possible to use newer algorithms in an encoder, e.g. for motion estimation, quantisation, or any other aspect where the spec doesn't detail how values are to be computed from input data. I have no idea whether any patents are applicable to the FFmpeg H.261 encoder, but I wouldn't discount the possibility without a thorough examination. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mined copyright with no copyright
On Fri, 18 Apr 2008 13:31:47 -0300 Mauro Lizaur wrote: [...] Well, the last time i contacted Thomas Wolff Thomas, IIUC, is the current maintainer of mined but not the (sole) copyright holder. Is that correct? about this and he replied with this: --- Hi Mauro, I confirm there was no copyright notice or file attached, just a doc file with the line Author: Michiel Huisjes. near the top. There is some discussion about Minix license to be found on the web, e.g. http://minix1.woodhull.com/faq/mxlicense.html but I would actually even assume that mined is not really part of the operating system but rather a tool written for it. Hence, it seems that the relicensing does not affect mined, do I understand correctly? If it is seems to be helpful, I could include a copy of that BSD-like copyright text somewhere in the source subdirectory, maybe included in the mined.doc file, but I wouldn't like to place it into the main directory so other distributions might see a conflict to the GPL and complain in turn... I hope this is sufficient to get a pass from the lawyer, I'm not sure I quite understand this part. Is Thomas Wolff proposing to apply the 3-clause BSD license (of Minix3) to mined? We need to make sure that all the copyright holders for mined (whoever they are) agree to this (re-)licensing, in order make this happen. This issue should really be solved, since the Debian Project could be currently distributing mined without the legal permission to do so. My usual disclaimers: IANAL, TINLA, IANADD, TINASOTODP. -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp3eB6y986uT.pgp Description: PGP signature
