You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bluesky-dev@incubator.apache.org by chen hecky <he...@gmail.com> on 2008/07/19 11:53:29 UTC
What should wo do next about the Bluesky Project?
After checking the files one by one, we find that most software library are
LGPL------they are dynamic invocation, but there are some GPL included in
our project such as fstream.h, kde/artsc/artsc.h and glib.h and so on(All
the checking is done under the Ubuntu7.10).
I know that there must be not any GPL in the project to upload to Apache.
But what should we do next? Remove the GPL
Re: Re: What should wo do next about the Bluesky Project?
Posted by Ting Peng <t....@gmail.com>.
Dear all,
most of the libs list below are called by xplayer, which we didn't plan to
submit to ASF.
On Wed, Jul 23, 2008 at 10:44 PM, 董巍 <go...@gmail.com> wrote:
> The original codes we developed xplayer are listed as follows:
>
> MPlayer
> Version: 1.0pre6
> Homepage: http://www.mplayerhq.hu/MPlayer/releases/
> License: GNU General Public License
>
> Name: FFmpeg
> Version: CVS snapshot
> Homepage: http://www.ffmpeg.org
> Directory: libavcodec, libavformat
> License: GNU Lesser General Public License, some parts GNU General
> Public
> License, GNU General Public License when combined
>
> Name: FAAD2
> Version: 2.1 beta (20040712 CVS snapshot) + portability patches
> Homepage: http://www.audiocoding.com
> Directory: libfaad2
> License: GNU General Public License
>
> Name: GSM 06.10 library
> Version: patchlevel 10
> Homepage: http://kbs.cs.tu-berlin.de/~jutta/toast.html<http://kbs.cs.tu-berlin.de/%7Ejutta/toast.html>
> Directory: libmpcodecs/native/
> License: permissive, see libmpcodecs/native/xa_gsm.c
>
> Name: liba52
> Version: 0.7.1b + patches
> Homepage: http://liba52.sourceforge.net/
> Directory: liba52
> License: GNU General Public License
>
> Name: libdvdcss
> Version: 1.2.8
> Homepage: http://developers.videolan.org/libdvdcss/
> Directory: libmpdvdkit2
> License: GNU General Public License
>
> Name: libdvdread
> Version: 0.9.3 + patches
> Homepage: http://www.dtek.chalmers.se/groups/dvd/development.shtml
> Directory: libmpdvdkit2
> License: GNU General Public License
>
> Name: libmpeg2
> Version: 0.4.0b + patches
> Homepage: http://libmpeg2.sourceforge.net/
> Directory: libmpeg2
> License: GNU General Public License
>
> Name: mpglib (part of mpg123)
> Version: 0.59s
> Homepage: http://www.mpg123.de/
> Directory: mp3lib
> License: GNU Lesser General Public License
>
> Name: LRMI - Linux Real Mode Interface
> Version: unknown, taken from svgalib
> Homepage: http://www.svgalib.org/
> Directory: osdep/lrmi.[ch]
> License: permissive, see file header
>
> Name: avifile DLL loader
> Version: 0.47 + patches + CVS updates
> Homepage: http://avifile.sourceforge.net/
> Directory: loader/
> License: GNU General Public License
>
> Name: dvbstream
> Version: 0.4.3-pre3 (cvs checkout)
> Homepage: http://www.linuxstb.org/dvbstream/
> Directory: libmpdemux
> License: GNU General Public License
>
> Name: realrtsp
> Version: xine CVS 2003/04/17 + patches
> Homepage: http://www.xinehq.de
> Directory: libmpdemux/realrtsp/
> License: GNU General Public License
>
> Name: id3edit
> Version: 1.9 + patches
> Homepage: http://id3edit.sourceforge.net/
> Directory: libmpdemux/genres.h
> License: GNU General Public License
>
> Name: matroxset
> Version: 0.3
> Homepage: ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/
> Directory: TOOLS/TVout/matroxset
> License: GNU General Public License
>
> Name: unrarlib
> Version: 0.4.0 + patches
> Homepage: http://www.unrarlib.org/
> Directory: unrarlib.[ch]
> License: GNU General Public License / UniquE RAR File Library License
>
> Name: uCIFS library
> Version: development files as of september 2004
> Homepage: http://ubiqx.org/libcifs/
> Directory: libvo/md5sum.[ch]
> License: GNU Lesser General Public License
>
--
Best regards!
Ting Peng (t.peng.dev@gmail.com)
[CN] +86-137-721-59621
Re: Re: What should wo do next about the Bluesky Project?
Posted by 董巍 <go...@gmail.com>.
The original codes we developed xplayer are listed as follows:
MPlayer
Version: 1.0pre6
Homepage: http://www.mplayerhq.hu/MPlayer/releases/
License: GNU General Public License
Name: FFmpeg
Version: CVS snapshot
Homepage: http://www.ffmpeg.org
Directory: libavcodec, libavformat
License: GNU Lesser General Public License, some parts GNU General Public
License, GNU General Public License when combined
Name: FAAD2
Version: 2.1 beta (20040712 CVS snapshot) + portability patches
Homepage: http://www.audiocoding.com
Directory: libfaad2
License: GNU General Public License
Name: GSM 06.10 library
Version: patchlevel 10
Homepage: http://kbs.cs.tu-berlin.de/~jutta/toast.html
Directory: libmpcodecs/native/
License: permissive, see libmpcodecs/native/xa_gsm.c
Name: liba52
Version: 0.7.1b + patches
Homepage: http://liba52.sourceforge.net/
Directory: liba52
License: GNU General Public License
Name: libdvdcss
Version: 1.2.8
Homepage: http://developers.videolan.org/libdvdcss/
Directory: libmpdvdkit2
License: GNU General Public License
Name: libdvdread
Version: 0.9.3 + patches
Homepage: http://www.dtek.chalmers.se/groups/dvd/development.shtml
Directory: libmpdvdkit2
License: GNU General Public License
Name: libmpeg2
Version: 0.4.0b + patches
Homepage: http://libmpeg2.sourceforge.net/
Directory: libmpeg2
License: GNU General Public License
Name: mpglib (part of mpg123)
Version: 0.59s
Homepage: http://www.mpg123.de/
Directory: mp3lib
License: GNU Lesser General Public License
Name: LRMI - Linux Real Mode Interface
Version: unknown, taken from svgalib
Homepage: http://www.svgalib.org/
Directory: osdep/lrmi.[ch]
License: permissive, see file header
Name: avifile DLL loader
Version: 0.47 + patches + CVS updates
Homepage: http://avifile.sourceforge.net/
Directory: loader/
License: GNU General Public License
Name: dvbstream
Version: 0.4.3-pre3 (cvs checkout)
Homepage: http://www.linuxstb.org/dvbstream/
Directory: libmpdemux
License: GNU General Public License
Name: realrtsp
Version: xine CVS 2003/04/17 + patches
Homepage: http://www.xinehq.de
Directory: libmpdemux/realrtsp/
License: GNU General Public License
Name: id3edit
Version: 1.9 + patches
Homepage: http://id3edit.sourceforge.net/
Directory: libmpdemux/genres.h
License: GNU General Public License
Name: matroxset
Version: 0.3
Homepage: ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/
Directory: TOOLS/TVout/matroxset
License: GNU General Public License
Name: unrarlib
Version: 0.4.0 + patches
Homepage: http://www.unrarlib.org/
Directory: unrarlib.[ch]
License: GNU General Public License / UniquE RAR File Library License
Name: uCIFS library
Version: development files as of september 2004
Homepage: http://ubiqx.org/libcifs/
Directory: libvo/md5sum.[ch]
License: GNU Lesser General Public License
Re: What should wo do next about the Bluesky Project?
Posted by bill stoddard <bi...@wstoddard.com>.
Ting Peng wrote:
> Dear all,
>
> we can all the APIs provided by the GNU/Linux releases. These API's are
> released under LGPL(like gtk,gnome,glibc,libavcodec,libavformath). That is
> enough to make our program run.
> It is not needed to make duplicate copy of these headers file in our source
> code tree. We can use dynamic link option when the program is compiled. This
> is according to my knowledge that ASF program can call LGPLed API
> dynamically.
>
That is correct. The Apache HTTP Server and Apache Portable Runtime
projects are very good references. All you need to do is include
#include lgpl_foo.h statements in your source code for the lgpl api's
you need to use. When you build the project, the build system (make,
autoconf, etc) will find the lgpl_foo.h files (provided by the linux
distribution you are building on) and create the appropriate calls in
your binary to dynamically bind to the lgpl_foo.so files. There is no
reason you need to copy lgpl header files into the bluesky project. C
programming 101 :-)
Bill
Re: Re: Re: What should wo do next about the Bluesky Project?
Posted by Ting Peng <t....@gmail.com>.
Dear all,
we can all the APIs provided by the GNU/Linux releases. These API's are
released under LGPL(like gtk,gnome,glibc,libavcodec,libavformath). That is
enough to make our program run.
It is not needed to make duplicate copy of these headers file in our source
code tree. We can use dynamic link option when the program is compiled. This
is according to my knowledge that ASF program can call LGPLed API
dynamically.
On Thu, Jul 24, 2008 at 4:35 PM, Bernd Fondermann <
bernd.fondermann@googlemail.com> wrote:
> But how do you make an executable out of your sources without making
> the headers available for the linker?
> Your project won't even compile as far as my C++ knowledge goes.
>
> Bernd
>
> On Thu, Jul 24, 2008 at 09:51, Ting Peng <t....@gmail.com> wrote:
> > Dear all,
> > Some api header files are copied to our souce code. Those are mistakes.
> In
> > fact, what we need to do is call the APIs provided by GNU/Linux Platform.
> > That is enough. I think we have made this problem a bit too complex.
> >
> > On Thu, Jul 24, 2008 at 9:51 AM, du.haipeng <du...@gmail.com>
> wrote:
> >
> >> While we were developing our project, we just included the libs which
> met
> >> our requirment. So it took us a long time to list all of them.
> >>
> >> Except XPlayer,which is based on mplayer, all the other part, components
> by
> >> components, are by ourselves.
> >>
> >> GTk for user interface.
> >>
> >> ffmpeg for audio video coding and decoding.
> >>
> >> jrtp for transmitting multi media data.
> >>
> >> artsd for sound play back.
> >>
> >> jthread to achieve multi-thread.
> >>
> >> ...............
> >>
> >> and some system apis of linux.
> >>
> >> ===We started from scratch.===
> >>
> >>
> >>
> >>
> >>
> >>
> >> du.haipeng
> >> 2008-07-24
> >>
> >>
> >>
> >> 发件人： Bernd Fondermann
> >> 发送时间： 2008-07-23 18:54:45
> >> 收件人： bluesky-dev@incubator.apache.org
> >> 抄送：
> >> 主题： Re: Re: What should wo do next about the Bluesky Project?
> >>
> >> 2008/7/23 chenwei_yi2003 <chenwei_yi2003@126.com >:
> >> > Maybe we should check the libs invoked in our Bluesky project .
> >> > For LGPL,just dynamically call it ,and this is enough ;
> >> > While for GPL,the best way to solve the problem is to substitute them
> >> with LGPL or recode such libs ourselves.
> >> >
> >> > Can this work?
> >>
> >> At first, really, you should focus on the code you actually intend to
> >> move over into the ASF repository.
> >> (The library aspect is only important after that.)
> >>
> >> I know that I can download source code from the Bluesky website. But
> >> where did _you_ actually get this code from at first (when the project
> >> started or you started to develop specific components.) Can you give
> >> URLs, please, where I can find the original code _before_ it entered
> >> the BlueSky project.
> >>
> >> If we cannot track down the origins of the code, there will be nothing
> >> going into our repository, as far as I can tell.
> >>
> >> By the way, I asked about the origins of you code multiple times now.
> >> Do you understand, what I am talking about?
> >>
> >> Bernd
> >>
> >
> >
> >
> > --
> > Best regards!
> >
> > Ting Peng (t.peng.dev@gmail.com)
> > [CN] +86-137-721-59621
> >
>
--
Best regards!
Ting Peng (t.peng.dev@gmail.com)
[CN] +86-137-721-59621
Re: Re: Re: What should wo do next about the Bluesky Project?
Posted by Bernd Fondermann <be...@googlemail.com>.
But how do you make an executable out of your sources without making
the headers available for the linker?
Your project won't even compile as far as my C++ knowledge goes.
Bernd
On Thu, Jul 24, 2008 at 09:51, Ting Peng <t....@gmail.com> wrote:
> Dear all,
> Some api header files are copied to our souce code. Those are mistakes. In
> fact, what we need to do is call the APIs provided by GNU/Linux Platform.
> That is enough. I think we have made this problem a bit too complex.
>
> On Thu, Jul 24, 2008 at 9:51 AM, du.haipeng <du...@gmail.com> wrote:
>
>> While we were developing our project, we just included the libs which met
>> our requirment. So it took us a long time to list all of them.
>>
>> Except XPlayer,which is based on mplayer, all the other part, components by
>> components, are by ourselves.
>>
>> GTk for user interface.
>>
>> ffmpeg for audio video coding and decoding.
>>
>> jrtp for transmitting multi media data.
>>
>> artsd for sound play back.
>>
>> jthread to achieve multi-thread.
>>
>> ...............
>>
>> and some system apis of linux.
>>
>> ===We started from scratch.===
>>
>>
>>
>>
>>
>>
>> du.haipeng
>> 2008-07-24
>>
>>
>>
>> 发件人： Bernd Fondermann
>> 发送时间： 2008-07-23 18:54:45
>> 收件人： bluesky-dev@incubator.apache.org
>> 抄送：
>> 主题： Re: Re: What should wo do next about the Bluesky Project?
>>
>> 2008/7/23 chenwei_yi2003 <chenwei_yi2003@126.com >:
>> > Maybe we should check the libs invoked in our Bluesky project .
>> > For LGPL,just dynamically call it ,and this is enough ;
>> > While for GPL,the best way to solve the problem is to substitute them
>> with LGPL or recode such libs ourselves.
>> >
>> > Can this work?
>>
>> At first, really, you should focus on the code you actually intend to
>> move over into the ASF repository.
>> (The library aspect is only important after that.)
>>
>> I know that I can download source code from the Bluesky website. But
>> where did _you_ actually get this code from at first (when the project
>> started or you started to develop specific components.) Can you give
>> URLs, please, where I can find the original code _before_ it entered
>> the BlueSky project.
>>
>> If we cannot track down the origins of the code, there will be nothing
>> going into our repository, as far as I can tell.
>>
>> By the way, I asked about the origins of you code multiple times now.
>> Do you understand, what I am talking about?
>>
>> Bernd
>>
>
>
>
> --
> Best regards!
>
> Ting Peng (t.peng.dev@gmail.com)
> [CN] +86-137-721-59621
>
Re: Re: Re: What should wo do next about the Bluesky Project?
Posted by Ting Peng <t....@gmail.com>.
Dear all,
Some api header files are copied to our souce code. Those are mistakes. In
fact, what we need to do is call the APIs provided by GNU/Linux Platform.
That is enough. I think we have made this problem a bit too complex.
On Thu, Jul 24, 2008 at 9:51 AM, du.haipeng <du...@gmail.com> wrote:
> While we were developing our project, we just included the libs which met
> our requirment. So it took us a long time to list all of them.
>
> Except XPlayer,which is based on mplayer, all the other part, components by
> components, are by ourselves.
>
> GTk for user interface.
>
> ffmpeg for audio video coding and decoding.
>
> jrtp for transmitting multi media data.
>
> artsd for sound play back.
>
> jthread to achieve multi-thread.
>
> ...............
>
> and some system apis of linux.
>
> ===We started from scratch.===
>
>
>
>
>
>
> du.haipeng
> 2008-07-24
>
>
>
> 发件人： Bernd Fondermann
> 发送时间： 2008-07-23 18:54:45
> 收件人： bluesky-dev@incubator.apache.org
> 抄送：
> 主题： Re: Re: What should wo do next about the Bluesky Project?
>
> 2008/7/23 chenwei_yi2003 <chenwei_yi2003@126.com >:
> > Maybe we should check the libs invoked in our Bluesky project .
> > For LGPL,just dynamically call it ,and this is enough ;
> > While for GPL,the best way to solve the problem is to substitute them
> with LGPL or recode such libs ourselves.
> >
> > Can this work?
>
> At first, really, you should focus on the code you actually intend to
> move over into the ASF repository.
> (The library aspect is only important after that.)
>
> I know that I can download source code from the Bluesky website. But
> where did _you_ actually get this code from at first (when the project
> started or you started to develop specific components.) Can you give
> URLs, please, where I can find the original code _before_ it entered
> the BlueSky project.
>
> If we cannot track down the origins of the code, there will be nothing
> going into our repository, as far as I can tell.
>
> By the way, I asked about the origins of you code multiple times now.
> Do you understand, what I am talking about?
>
> Bernd
>
--
Best regards!
Ting Peng (t.peng.dev@gmail.com)
[CN] +86-137-721-59621
Re: Re: Re: What should wo do next about the Bluesky Project?
Posted by "du.haipeng" <du...@gmail.com>.
While we were developing our project, we just included the libs which met our requirment. So it took us a long time to list all of them.
Except XPlayer,which is based on mplayer, all the other part, components by components, are by ourselves.
GTk for user interface.
ffmpeg for audio video coding and decoding.
jrtp for transmitting multi media data.
artsd for sound play back.
jthread to achieve multi-thread.
...............
and some system apis of linux.
===We started from scratch.===
du.haipeng
2008-07-24
发件人： Bernd Fondermann
发送时间： 2008-07-23 18:54:45
收件人： bluesky-dev@incubator.apache.org
抄送：
主题： Re: Re: What should wo do next about the Bluesky Project?
2008/7/23 chenwei_yi2003 <chenwei_yi2003@126.com >:
> Maybe we should check the libs invoked in our Bluesky project .
> For LGPL,just dynamically call it ,and this is enough ;
> While for GPL,the best way to solve the problem is to substitute them with LGPL or recode such libs ourselves.
>
> Can this work?
At first, really, you should focus on the code you actually intend to
move over into the ASF repository.
(The library aspect is only important after that.)
I know that I can download source code from the Bluesky website. But
where did _you_ actually get this code from at first (when the project
started or you started to develop specific components.) Can you give
URLs, please, where I can find the original code _before_ it entered
the BlueSky project.
If we cannot track down the origins of the code, there will be nothing
going into our repository, as far as I can tell.
By the way, I asked about the origins of you code multiple times now.
Do you understand, what I am talking about?
Bernd
Re: Re: What should wo do next about the Bluesky Project?
Posted by Bernd Fondermann <be...@googlemail.com>.
2008/7/23 chenwei_yi2003 <ch...@126.com>:
> Maybe we should check the libs invoked in our Bluesky project .
> For LGPL,just dynamically call it ,and this is enough ;
> While for GPL,the best way to solve the problem is to substitute them with LGPL or recode such libs ourselves.
>
> Can this work?
At first, really, you should focus on the code you actually intend to
move over into the ASF repository.
(The library aspect is only important after that.)
I know that I can download source code from the Bluesky website. But
where did _you_ actually get this code from at first (when the project
started or you started to develop specific components.) Can you give
URLs, please, where I can find the original code _before_ it entered
the BlueSky project.
If we cannot track down the origins of the code, there will be nothing
going into our repository, as far as I can tell.
By the way, I asked about the origins of you code multiple times now.
Do you understand, what I am talking about?
Bernd
Re:Re: What should wo do next about the Bluesky Project?
Posted by chenwei_yi2003 <ch...@126.com>.
Maybe we should check the libs invoked in our Bluesky project .
For LGPL,just dynamically call it ,and this is enough ;
While for GPL,the best way to solve the problem is to substitute them with LGPL or recode such libs ourselves.
Can this work?
在2008-07-22 13:30:43，"Bernd Fondermann" <be...@googlemail.com> 写道：
>On Tue, Jul 22, 2008 at 04:21, chen hecky ". We
>> only call the api in our project.
>>
>> Second, there are about 70 libraries as xxxx.h in our project.
>>
>> So, does the project conform to ASL?
>
>I don't think so, because Debian/Ubuntu contains large parts of GPL'ed
>code, as far as i know.
>
> Bernd
Re: What should wo do next about the Bluesky Project?
Posted by Bernd Fondermann <be...@googlemail.com>.
On Tue, Jul 22, 2008 at 04:21, chen hecky <he...@gmail.com> wrote:
> Ok.
>
> First, we check them in the file path of "/usr/include/"(under Ubuntu7.10).
> All these software libraries are included through "#include <xxx.h>". We
> only call the api in our project.
>
> Second, there are about 70 libraries as xxxx.h in our project.
>
> So, does the project conform to ASL?
I don't think so, because Debian/Ubuntu contains large parts of GPL'ed
code, as far as i know.
Bernd
Re: What should wo do next about the Bluesky Project?
Posted by chen hecky <he...@gmail.com>.
Ok.
First, we check them in the file path of "/usr/include/"(under Ubuntu7.10).
All these software libraries are included through "#include <xxx.h>". We
only call the api in our project.
Second, there are about 70 libraries as xxxx.h in our project.
So, does the project conform to ASL?
2008/7/22, Bernd Fondermann <be...@googlemail.com>:
>
> On Sat, Jul 19, 2008 at 13:53, chen hecky <he...@gmail.com> wrote:
> > After checking the files one by one, we find that most software library
> are
> > LGPL------they are dynamic invocation, but there are some GPL included in
> > our project such as fstream.h, kde/artsc/artsc.h and glib.h and so on(All
> > the checking is done under the Ubuntu7.10).
> >
> > I know that there must be not any GPL in the project to upload to Apache.
> > But what should we do next? Remove the GPL
>
> No, that would violate the original contributors copyrights.
>
> I would propose you tell on this list for every piece of code you are
> using where it is coming from (What is the original code and where can
> we find it?).
> Second, it would be great if you'd compile a list of all the code
> changes you made (who is the person who did the change) to this
> original code.
>
> Another completely different approach would be to start from scratch.
>
> Thanks,
>
> Bernd
>
Re: What should wo do next about the Bluesky Project?
Posted by Bernd Fondermann <be...@googlemail.com>.
On Sat, Jul 19, 2008 at 13:53, chen hecky <he...@gmail.com> wrote:
> After checking the files one by one, we find that most software library are
> LGPL------they are dynamic invocation, but there are some GPL included in
> our project such as fstream.h, kde/artsc/artsc.h and glib.h and so on(All
> the checking is done under the Ubuntu7.10).
>
> I know that there must be not any GPL in the project to upload to Apache.
> But what should we do next? Remove the GPL
No, that would violate the original contributors copyrights.
I would propose you tell on this list for every piece of code you are
using where it is coming from (What is the original code and where can
we find it?).
Second, it would be great if you'd compile a list of all the code
changes you made (who is the person who did the change) to this
original code.
Another completely different approach would be to start from scratch.
Thanks,
Bernd
Re: What should wo do next about the Bluesky Project?
Posted by chen hecky <he...@gmail.com>.
Sorry, there is a mistake!
2008/7/19, chen hecky <he...@gmail.com>:
>
> After checking the files one by one, we find that most software library are
> LGPL------they are dynamic invocation, but there are some GPL included in
> our project such as fstream.h, kde/artsc/artsc.h and glib.h and so on(All
> the checking is done under the Ubuntu7.10).
>
> I know that there must be not any GPL in the project to upload to Apache.
> But what should we do next? Remove the GPL
>
What should we do next? Remove the GPL or replace them?