[FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

Carl Eugen Hoyos ceffmpeg at gmail.com
Sun May 12 03:55:57 EEST 2019


Am So., 12. Mai 2019 um 02:51 Uhr schrieb Pedro Arthur <bygrandao at gmail.com>:
>
> Em sáb, 11 de mai de 2019 às 20:26, James Almer <jamrial at gmail.com> escreveu:
> >
> > On 5/11/2019 8:08 PM, Carl Eugen Hoyos wrote:
> > > Am So., 12. Mai 2019 um 01:00 Uhr schrieb Lynne <dev at lynne.ee>:
> > >>
> > >> May 11, 2019, 11:08 PM by ceffmpeg at gmail.com:
> > >>
> > >>> Am Sa., 11. Mai 2019 um 14:41 Uhr schrieb Lynne <> dev at lynne.ee <mailto:dev at lynne.ee>> >:
> > >>>
> > >>>>
> > >>>> May 10, 2019, 8:59 PM by >> ceffmpeg at gmail.com <mailto:ceffmpeg at gmail.com>>> :
> > >>>>
> > >>>>> Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> >> dev at lynne.ee <mailto:dev at lynne.ee>>>  <mailto:>> dev at lynne.ee <mailto:dev at lynne.ee>>> >> >:
> > >>>>>
> > >>>>>>
> > >>>>>> May 10, 2019, 4:14 PM by >> >> dev at lynne.ee <mailto:dev at lynne.ee>>>  <mailto:>> dev at lynne.ee <mailto:dev at lynne.ee>>> >>> :
> > >>>>>>
> > >>>>>>> Patch updated again.
> > >>>>>>> Made some more cleanups to the transforms, the tables and the main context.
> > >>>>>>> API changed again, now the init function populates the function pointer for transform.
> > >>>>>>> I decided that having a separate function would encourage bad usage (e.g. calling
> > >>>>>>> the function every time before doing a transform rather than storing the pointer) when
> > >>>>>>> we're trying to avoid the overhead of function calls.
> > >>>>>>> Also adjusted file names to match the API.
> > >>>>>>>
> > >>>>>>
> > >>>>>> Forgot to change an include, new patch attached.
> > >>>>>>
> > >>>>>
> > >>>>> If I understand the commit message correctly, some of the code
> > >>>>> in the new file you are adding comes from other parts of FFmpeg.
> > >>>>> I am surprised that there is no copyright claim on the top of this
> > >>>>> new file.
> > >>>>> Is there none on top of the files you took the code from?
> > >>>>>
> > >>>>
> > >>>> The project isn't consistent with updating nor putting copyright headers on files so
> > >>>> I'd rather keep the headers clean. Commit messages and authors are the only way to
> > >>>> know who authored what.
> > >>>>
> > >>>
> > >>> I don't think this is correct, but that is not the question: Copyright
> > >>> law is (at least here)
> > >>> very clear, if somebody put his name on top of the file, you must not remove it,
> > >>> especially not when moving code from one file into another.
> > >>>
> > >>
> > >> "Here"? You're probably referring to some county's laws, those don't apply universally,
> > >> especially not to the internet.
> > >> Either way, that rule hasn't really been respected despite the major refactoring that has
> > >> happened in the past so I don't see why it has to be respected now.
> > >
> > > Please point me to the commit you indicate so I can fix this (claimed) copyright
> > > violation.
> > >
> > >> The only parts I didn't rewrite are the power of two FFT, which I can NIH in a week if
> > >> necessary, and in fact lately with the research papers I've recently read I'm thinking
> > >> I should.
> > >
> > > Why don't you simply copy the copyright statement from the file where you copied
> > > it from instead (if there is one)?
> > > Wouldn't that be much quicker than this email exchange?
> > >
> > > Carl Eugen
> >
> > The commit message already states it takes parts of lavc's fft
> > implementation, and the git story can't be rewritten, so authorship is
> > known or can be easily figured out. Could we please focus on technical
> > matters instead of wasting time in a back and forth about stuff like this?
> >
>
> Not saying this is the case, but if one interprets it as copying the
> code, adding more code, removing some parts, and removing the
> copyrights previously present it is clearly violating the license.
> It seems wise to include copyrights from original code in the file.

Except if there never was a copyright notice in the original file.

Carl Eugen


More information about the ffmpeg-devel mailing list