On Mon, 15 Sep 2014 14:07:06 +0200 Robert Krüger <krue...@lesspain.de> wrote:
> On Mon, Sep 15, 2014 at 1:12 PM, Michael Niedermayer > <michae...@gmx.at> wrote: > > On Mon, Sep 15, 2014 at 10:26:28AM +0200, Robert Krüger wrote: > >> On Sun, Sep 14, 2014 at 5:58 PM, Michael Niedermayer > >> <michae...@gmx.at> wrote: > >> > On Sun, Sep 14, 2014 at 05:40:35PM +0200, Robert Krüger wrote: > >> >> On Sat, Sep 13, 2014 at 12:36 PM, Michael Niedermayer > >> >> <michae...@gmx.at> wrote: > >> >> > From: Baptiste Coudurier <baptiste.coudur...@gmail.com> > >> >> Just a general policy-question: will changes like this not in a > >> >> way discourage development of these features in ffmpeg under > >> >> LGPL? If someone now uses this code (e.g. mxf_parse_h264_frame) ffmpeg itself does not have license requirements (aside from being open source licenses), as we accept code from lots of people and companies, we have a few different licenses already. i guess like michael says, we prefer lgpl. but as this is a volunteer project, being volunteers, we probably wont spend time on relicense stuff unless we get paid to. > >> >> in other code they will have to make that GPL as well. In the > >> >> long run this will make life harder for library users who > >> >> cannot live with GPL. So far this hasn't been done on that they can pay for relicensing. > >> >> level, at least not in the part of code that I am watching. > >> >> AFAIR currently license borders are normally on a component > >> >> level, i.e. a certain codec, format, filter only works only > >> >> under GPL, not parts of functionality of a cocec, filter or > >> >> muxer, which I think makes it OK to track by people for whom > >> >> license matters. this extends this to a level where one would > >> >> have to know which features of a certain muxer, codec, filter > >> >> works under which license. Of course that's a project > >> >> maintainer decision. Just wanted to throw in that side of the > >> >> story, so it can be consciously taken into account or > >> >> disregarded. > >> > > >> > This isnt the first "#if CONFIG_GPL" in the code. > >> > >> Technically correct but I see only me_cmp.c and flac_dsp_init.c so > >> far and I don't know what the code does better with GPL. So far I > >> have not run into this as a library user and thus was not aware of > >> it. At least it seems to be a rare exception. I am afraid of the > >> situation it may create, if picking stuff from ffmbc and > >> introducing it via #if CONFIG_GPL becomes more common. > > > > I really think you are doing a "own goal" here > > I am not sure I understand what you mean by this. I am not trying to > hide what's my interest in this, if that's what you're referring to. > Also assuming this I am not alone in this situation, so I am bringing > this to your attention to consider as project maintainer, one of whose > goals might be to make adoption of ffmpeg in commercial > projects/software easier. I may be wrong but I interpreted vlc's move this is one of ffmpegs goals, but i dont think it is a high priority. we dont really have official priorities, but i think the unofficial list is something like this: 1. support all codecs 2. fastest support of all codecs 3. fastest support of all codecs and formats on all systems 4. have fun working on open source project 5. get paid to have fun working on open source project ... (bunch of goals not listed) ... 3144. make ffmpeg work for commercial applications easier > to relicense as much code as possible to LGPL to be motivated by that, > potentially because they thought, the project benefits from this. I sure. and i agree, that probably helped them out in some way. theres an interesting question that i thought up during the libav-ffmpeg discussion at vdd14. are we as a project going to basically go into business for ourselves ? are we going to package ffmpeg as a lib for commercial operations and sell paid support as a vendor? make a few scripts and paralellize the code a bit, fix up threading and memory management. like x264 did. kind of like vlc did (getting on ios store etc) or are we going to continue operating as volunteers and paid consultants for individual companies? i think a few devels have done similar things on their own. should we do it as a group? can we even do it as a group or are we too independent to do it? > know there is the justified impression that commercial users don't > give back enough but I am convinced that at least tons of bug reports > and samples come from people who use ffmpeg to build commercial > software. Again, this is a decision the project needs to make. I am most companies wont let samples back to us, because of copyright laws and NDA. as a maintainer of the samples repo ( samples.ffmpeg.org ) i'd say i'm not worried about getting samples from companies. yes its important to get samples from companies, but the majority of our samples are from our users and downstream users (mplayer, vlc, xine etc). again, if a company is using ffmpeg, they can pay us to get bugs fixed. which is what has happened a lot over the past and continues to happen to this day on the list. with companies asking for consultants to come fix their workflows. > just pointing out that intermixing more GPL code in core places makes > life harder for those people, which, of course, includes us. That's > why I don't think this patch is a minor thing. i agree. its not a perfect sitation. i appreciate your analysis, we need clear communication from all ffmpeg users on all subjects. thank you. i think michael listed the solutions possible, i'm trying to think of other solutions as well. > > > do you prefer if i do this work in a seperate branch outside FFmpeg > > or what do you suggest ? > > No, the last thing anyone needs is another fork. > > In this particular case, maybe asking for a bounty for adding AVCI > support in the mxf muxer could be a way. But since this is more a > general question about project policy, maybe it should be defined, if > it is not defined yet. Of course, this might mean that a certain > feature, only available in GPL code in another project like ffmbc, > could not move into some places of ffmpeg code, if the project > maintainers/devs decide that this kind of LGPL user base is important > enough to them. but i'd like to say, i'd rather have ffmbc merged (and all other forks) into ffmpeg than worry about lgpl compat. the forks may have more features we lack and i think ffmpeg users care more about features. i could be wrong, and thats why we need more opinions from commercial ffmpeg users. i only speak for myself, not the project. -compn _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
