All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] License Problems for standalone application at u-boot
@ 2009-08-14  3:24 Peter Chen
  2009-08-14  5:42 ` Wolfgang Denk
  0 siblings, 1 reply; 10+ messages in thread
From: Peter Chen @ 2009-08-14  3:24 UTC (permalink / raw)
  To: u-boot

Dear u-boot authors,

We have a standalone application, and u-boot will supply jump address
and some services to this application.
I wonder are there any license problems (GPL or u-boot) for our
standalone application at below condition:

1. Some services which we wrote have included some u-boot header file?
2. All the services we wrote by ourselves, and not using any u-boot
source code and header file?

Currently, we are number 1 situation.

Thank you

Best Regards,
Peter Chen

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot] License Problems for standalone application at u-boot
  2009-08-14  3:24 [U-Boot] License Problems for standalone application at u-boot Peter Chen
@ 2009-08-14  5:42 ` Wolfgang Denk
  2009-08-14  6:38   ` Peter Chen
  0 siblings, 1 reply; 10+ messages in thread
From: Wolfgang Denk @ 2009-08-14  5:42 UTC (permalink / raw)
  To: u-boot

Dear Peter,

in message <1250220295.7144.18.camel@nchen-desktop> you wrote:
> 
> We have a standalone application, and u-boot will supply jump address
> and some services to this application.
> I wonder are there any license problems (GPL or u-boot) for our
> standalone application at below condition:
> 
> 1. Some services which we wrote have included some u-boot header file?
> 2. All the services we wrote by ourselves, and not using any u-boot
> source code and header file?
> 
> Currently, we are number 1 situation.

Please see the first paragraphs of the COPYING file that comes with
the U-Boot sources; this explains the GPL exception for standalone
programs.

Please let me know if you have additional questions.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The philosophy exam was a piece of cake  -  which  was  a  bit  of  a
surprise, actually, because I was expecting some questions on a sheet
of paper.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot] License Problems for standalone application at u-boot
  2009-08-14  5:42 ` Wolfgang Denk
@ 2009-08-14  6:38   ` Peter Chen
  2009-08-14  9:38     ` Wolfgang Denk
  0 siblings, 1 reply; 10+ messages in thread
From: Peter Chen @ 2009-08-14  6:38 UTC (permalink / raw)
  To: u-boot

Dear Wolfgang,

I have still some puzzled which you wrote below :

1. Does jump table means the function lists which the standalone
applications uses?

2. If the functions includes some u-boot header file, it belongs to
derived work or not?

Thank you!

 NOTE! This copyright does *not* cover the so-called "standalone"
applications that use U-Boot services by means of the jump table
provided by U-Boot exactly for this purpose - this is merely
considered normal use of U-Boot, and does *not* fall under the 
heading of "derived work".

  The header files "include/image.h" and "include/asm-*/u-boot.h"
define interfaces to U-Boot. Including these (unmodified) header
files in another file is considered normal use of U-Boot, and does
*not* fall under the heading of "derived work".

  Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the U-Boot
source code) is copyrighted by me and others who actually wrote it. 
-- Wolfgang Denk



Best Regards,
Peter Chen


On Fri, 2009-08-14 at 07:42 +0200, Wolfgang Denk wrote:

> Dear Peter,
> 
> in message <1250220295.7144.18.camel@nchen-desktop> you wrote:
> > 
> > We have a standalone application, and u-boot will supply jump address
> > and some services to this application.
> > I wonder are there any license problems (GPL or u-boot) for our
> > standalone application at below condition:
> > 
> > 1. Some services which we wrote have included some u-boot header file?
> > 2. All the services we wrote by ourselves, and not using any u-boot
> > source code and header file?
> > 
> > Currently, we are number 1 situation.
> 
> Please see the first paragraphs of the COPYING file that comes with
> the U-Boot sources; this explains the GPL exception for standalone
> programs.
> 
> Please let me know if you have additional questions.
> 
> Best regards,
> 
> Wolfgang Denk
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot] License Problems for standalone application at u-boot
  2009-08-14  6:38   ` Peter Chen
@ 2009-08-14  9:38     ` Wolfgang Denk
  2009-08-17  2:00       ` Peter Chen
  0 siblings, 1 reply; 10+ messages in thread
From: Wolfgang Denk @ 2009-08-14  9:38 UTC (permalink / raw)
  To: u-boot

Dear Peter Chen,

In message <1250231900.7144.40.camel@nchen-desktop> you wrote:
> 
> 1. Does jump table means the function lists which the standalone
> applications uses?

The "jump table provided by U-Boot exactly for this purpose" is the
list of functions exported through the "include/_exports.h" header
file.

Only these functions are available from standalone programs without
linking against any of the U-Boot provided libraries. If your program
links and runs fine using only these functions then you are free to
license your standalone application whatever you like; if you need to
link against any of the U-Boot libraries then you must release your
code under GPL.

> 2. If the functions includes some u-boot header file, it belongs to
> derived work or not?

Well, the file "COPYING" explicitly mentions the header files where
the situations is clear:

>   The header files "include/image.h" and "include/asm-*/u-boot.h"
> define interfaces to U-Boot. Including these (unmodified) header
> files in another file is considered normal use of U-Boot, and does
> *not* fall under the heading of "derived work".

The fact that these files are explicitly mentioned *not* to make yoru
code a Derived Work should make clear that all other header files do,
or at least might do, so you better not include these in a standalone
application you don't intend to release under GPL. If you do, you
better check with your legal department, and rely on what they tell
you. Note that I just wouldn't do that.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I have a theory that it's impossible to prove anything, but  I  can't
prove it.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot] License Problems for standalone application at u-boot
  2009-08-14  9:38     ` Wolfgang Denk
@ 2009-08-17  2:00       ` Peter Chen
  2009-08-17  8:03         ` Wolfgang Denk
  0 siblings, 1 reply; 10+ messages in thread
From: Peter Chen @ 2009-08-17  2:00 UTC (permalink / raw)
  To: u-boot


Thanks, Wolfgang.
I still have same questions want to confirm.

On Fri, 2009-08-14 at 11:38 +0200, Wolfgang Denk wrote:

> Dear Peter Chen,
> 
> In message <1250231900.7144.40.camel@nchen-desktop> you wrote:
> > 
> > 1. Does jump table means the function lists which the standalone
> > applications uses?
> 
> The "jump table provided by U-Boot exactly for this purpose" is the
> list of functions exported through the "include/_exports.h" header
> file.
> 

    At my situation, the standalone program is hardware independent.
And the u-boot supplies hardware interfaces according to different
platforms.
Like at u-boot/board/myboard/myboard.c, there are a function lists
struct, and the address
of this struct will transfer to standalone program. 

Is it free to license at below situation:
The function list which is defined at u-boot/board/myboard/myboard.c,
and all functions in this list
only uses functions at include/_exports.h and some of user-defined
functions.

Or Need I to export my functions at include/_exports.h? At my standalone
application only uses address of
functions at function list, not the name of function, so It doesn't need
to include include_exports.h.

> Only these functions are available from standalone programs without
> linking against any of the U-Boot provided libraries. If your program
> links and runs fine using only these functions then you are free to
> license your standalone application whatever you like; if you need to
> link against any of the U-Boot libraries then you must release your
> code under GPL.
> 

We would like to release our u-boot under GPL, but standalone
application includes some IP properties code, so 
we want to close it.

> > 2. If the functions includes some u-boot header file, it belongs to
> > derived work or not?
> 
> Well, the file "COPYING" explicitly mentions the header files where
> the situations is clear:
> 
> >   The header files "include/image.h" and "include/asm-*/u-boot.h"
> > define interfaces to U-Boot. Including these (unmodified) header
> > files in another file is considered normal use of U-Boot, and does
> > *not* fall under the heading of "derived work".
> 
> The fact that these files are explicitly mentioned *not* to make yoru
> code a Derived Work should make clear that all other header files do,
> or at least might do, so you better not include these in a standalone
> application you don't intend to release under GPL. If you do, you
> better check with your legal department, and rely on what they tell
> you. Note that I just wouldn't do that.
> 
> Best regards,
> 
> Wolfgang Denk
> 


Best Regards,
Peter Chen

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot] License Problems for standalone application at u-boot
  2009-08-17  2:00       ` Peter Chen
@ 2009-08-17  8:03         ` Wolfgang Denk
  2009-08-18  4:57           ` Peter Chen
  0 siblings, 1 reply; 10+ messages in thread
From: Wolfgang Denk @ 2009-08-17  8:03 UTC (permalink / raw)
  To: u-boot

Dear Peter Chen,

In message <1250474437.13885.23.camel@nchen-desktop> you wrote:
> 
> > > 1. Does jump table means the function lists which the standalone
> > > applications uses?
> > 
> > The "jump table provided by U-Boot exactly for this purpose" is the
> > list of functions exported through the "include/_exports.h" header
> > file.
> 
>     At my situation, the standalone program is hardware independent.
> And the u-boot supplies hardware interfaces according to different
> platforms.
> Like at u-boot/board/myboard/myboard.c, there are a function lists
> struct, and the address
> of this struct will transfer to standalone program. 

If you set up your own list of function pointers (in addition or
instead of the jump table provided by the "include/_exports.h"
header), then this is a form of linking against the U-Boot code, and
your application must be released under GPL.

> Is it free to license at below situation:
> The function list which is defined at u-boot/board/myboard/myboard.c,
> and all functions in this list
> only uses functions at include/_exports.h and some of user-defined
> functions.

Your description is really vague; it would be easier if you could
give specific code examples or such. If "some of user-defined
functions" refers to code that is covered by the GPL, then your
application must be released under GPL, too.

> Or Need I to export my functions at include/_exports.h? At my standalone
> application only uses address of
> functions at function list, not the name of function, so It doesn't need
> to include include_exports.h.

What you implement is some form of static linking.

... which technically is a stupid thing to do, as your application
will only be able to run with a very specific binary image of U-Boot.
Even rebuilding the same version of U-Boot (jut using a different
tool chain, for example) will most likely result in a U-Boot image
that cannot run your application code any more. Even worse, ther
ewill be not even a clear failure mode, instead you will execute
random code.

> We would like to release our u-boot under GPL, but standalone

Actually you have no choice; U-Boot is already covered by the GPL -
as soon as you distribute the code, you also have to fufil the
resulting requirements of the GPL.

> application includes some IP properties code, so 
> we want to close it.

This is no problem, as long as you strictly follow the rules. I think
the exception from the GPL is pretty well defined and leaves not much
room for interpretation. What you describe sounds fishy to me.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If a group of N persons implements a COBOL compiler,  there  will  be
N-1 passes. Someone in the group has to be the manager. - T. Cheatham

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot] License Problems for standalone application at u-boot
  2009-08-17  8:03         ` Wolfgang Denk
@ 2009-08-18  4:57           ` Peter Chen
  2009-08-18  8:35             ` Wolfgang Denk
  0 siblings, 1 reply; 10+ messages in thread
From: Peter Chen @ 2009-08-18  4:57 UTC (permalink / raw)
  To: u-boot




Dear Wolfgang Denk,

On Mon, 2009-08-17 at 10:03 +0200, Wolfgang Denk wrote:

> Dear Peter Chen,
> 
> In message <1250474437.13885.23.camel@nchen-desktop> you wrote:
> > 
> > > > 1. Does jump table means the function lists which the standalone
> > > > applications uses?
> > > 
> > > The "jump table provided by U-Boot exactly for this purpose" is the
> > > list of functions exported through the "include/_exports.h" header
> > > file.
> > 
> >     At my situation, the standalone program is hardware independent.
> > And the u-boot supplies hardware interfaces according to different
> > platforms.
> > Like at u-boot/board/myboard/myboard.c, there are a function lists
> > struct, and the address
> > of this struct will transfer to standalone program. 
> 
> If you set up your own list of function pointers (in addition or
> instead of the jump table provided by the "include/_exports.h"
> header), then this is a form of linking against the U-Boot code, and
> your application must be released under GPL.
> 

I am sorry, I can't understand your meaning. For example, at
"include/_exports.h"
there is an EXPORT_FUNC(printf), do the standalone application must
under GPL if
it uses printf?
Then, what does "include/_exports.h" use?

In your COPYING, it writes:
  NOTE! This copyright does *not* cover the so-called "standalone"
applications that use U-Boot services by means of the jump table
provided by U-Boot exactly for this purpose - this is merely
considered normal use of U-Boot, and does *not* fall under the 
heading of "derived work".

> > Is it free to license at below situation:
> > The function list which is defined at u-boot/board/myboard/myboard.c,
> > and all functions in this list
> > only uses functions at include/_exports.h and some of user-defined
> > functions.
> 
> Your description is really vague; it would be easier if you could
> give specific code examples or such. If "some of user-defined
> functions" refers to code that is covered by the GPL, then your
> application must be released under GPL, too.
> 

My code like belows:

typedef void (*pfn_t) (void);
pfn_t sc_gps_pfn[] = {
        LoadToMemory,
        SaveData,
        RFPowerCtrl,
        MiscConfig,
        RegisterDspInterruptHandler,
        GetPowerStatus,
        IsUserResume,
        DebugOutput,
        ReturnToBootLoader
};
int LoadToMemory(void *pDestination, unsigned int storeID, unsigned int
size)
{
}
int SaveData(unsigned int storeID, void *pSource, unsigned int size)
{}
int RegisterDspInterruptHandler(unsigned int handler)
{
        gps_intr = (pfn_t) handler;

        return 1;
}

extern void ReturnToBootLoader(unsigned int nextRtcAlarmParam); /* which
is defined at *.S file */
...

int Launch()
{
Launch_apps(sc_gps_pfn, jumpaddr); /* Launch_apps is defined at *.S
file, and it just jumps to VMA of standalone application, sc_gps_pfn is
the address for function list */
}

We want to open this code, but want to close the code which use this
function list in binary pattern.

> > Or Need I to export my functions at include/_exports.h? At my standalone
> > application only uses address of
> > functions at function list, not the name of function, so It doesn't need
> > to include include_exports.h.
> 
> What you implement is some form of static linking.
> 
> ... which technically is a stupid thing to do, as your application
> will only be able to run with a very specific binary image of U-Boot.
> Even rebuilding the same version of U-Boot (jut using a different
> tool chain, for example) will most likely result in a U-Boot image
> that cannot run your application code any more. Even worse, ther
> ewill be not even a clear failure mode, instead you will execute
> random code.
> 

The standalone application is compiled by armcc, and this bin file is
shared by WinCE and Linux bootloader.
The standalone application uses bootloader functions by address not by
name.

> > We would like to release our u-boot under GPL, but standalone
> 
> Actually you have no choice; U-Boot is already covered by the GPL -
> as soon as you distribute the code, you also have to fufil the
> resulting requirements of the GPL.
> 
> > application includes some IP properties code, so 
> > we want to close it.
> 
> This is no problem, as long as you strictly follow the rules. I think
> the exception from the GPL is pretty well defined and leaves not much
> room for interpretation. What you describe sounds fishy to me.
> 
> Best regards,
> 
> Wolfgang Denk
> 


Best Regards,
Peter Chen

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot] License Problems for standalone application at u-boot
  2009-08-18  4:57           ` Peter Chen
@ 2009-08-18  8:35             ` Wolfgang Denk
  2009-08-18  9:50               ` Peter Chen
  0 siblings, 1 reply; 10+ messages in thread
From: Wolfgang Denk @ 2009-08-18  8:35 UTC (permalink / raw)
  To: u-boot

Dear Peter Chen,

In message <1250571462.6548.21.camel@nchen-desktop> you wrote:
> 
> > > > The "jump table provided by U-Boot exactly for this purpose" is the
> > > > list of functions exported through the "include/_exports.h" header
> > > > file.
...
> > If you set up your own list of function pointers (in addition or
> > instead of the jump table provided by the "include/_exports.h"
> > header), then this is a form of linking against the U-Boot code, and
> > your application must be released under GPL.
> 
> I am sorry, I can't understand your meaning. For example, at

I'm close to give up. I try to as explicit as possible, and I see no
room for interpretation left, yet you still try to argument.

> "include/_exports.h"
> there is an EXPORT_FUNC(printf), do the standalone application must
> under GPL if
> it uses printf?

No. As explained several times before, the "jump table [is]  provided
by  U-Boot  exactly  for  this purpose", with "this purpose" being to
allow for closed source, proprietary code.

printf() gets exported through the jump table interface, so this is OK
to use in proprietary code.

> Then, what does "include/_exports.h" use?

It uses a list of functions (resp. function pointers) we consider  OK
to be used in closed source applications.

> In your COPYING, it writes:
>   NOTE! This copyright does *not* cover the so-called "standalone"
> applications that use U-Boot services by means of the jump table
> provided by U-Boot exactly for this purpose - this is merely
> considered normal use of U-Boot, and does *not* fall under the 
> heading of "derived work".

Indeed. And I explained this several times before.

> > > Is it free to license at below situation:
> > > The function list which is defined at u-boot/board/myboard/myboard.c,
> > > and all functions in this list
> > > only uses functions at include/_exports.h and some of user-defined
> > > functions.
> > 
> > Your description is really vague; it would be easier if you could
> > give specific code examples or such. If "some of user-defined
> > functions" refers to code that is covered by the GPL, then your
> > application must be released under GPL, too.
> > 
> 
> My code like belows:
> 
> typedef void (*pfn_t) (void);
> pfn_t sc_gps_pfn[] = {
>         LoadToMemory,
>         SaveData,
>         RFPowerCtrl,
>         MiscConfig,
>         RegisterDspInterruptHandler,
>         GetPowerStatus,
>         IsUserResume,
>         DebugOutput,
>         ReturnToBootLoader
> };

OK, so you are setting up a table of your  own  functions.  You  need
this  table only if you link the code containing these functions with
the U-Boot binary - and you do so  most  probably  because  the  code
calls into other U-Boot provided functions.

> We want to open this code, but want to close the code which use this
> function list in binary pattern.

You probably have no choice here. If your code that provides the list
of functions above is linked with U-Boot, you *must* release it under
GPL. No matter if you want or not - if you release your code at all,
it is GPLed.

And your list of functions above thus accesses GPLed  code  which  is
NOT  part  of include/_exports.h. So the GPL exception does NOT apply
to any code that references functions from  this  list,  i.  e.  your
standalone application must be released under GPL, too.

> > What you implement is some form of static linking.
...
> The standalone application is compiled by armcc, and this bin file is
> shared by WinCE and Linux bootloader.
> The standalone application uses bootloader functions by address not by
> name.

That does not matter. Accessing a function by address still means you
are linking against the code (in a stupid way, btw). Your standalone
application has to be released under GPL.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A quarrel is quickly settled when deserted by one party; there is  no
battle unless there be two.                                  - Seneca

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot] License Problems for standalone application at u-boot
  2009-08-18  8:35             ` Wolfgang Denk
@ 2009-08-18  9:50               ` Peter Chen
  2009-08-18 11:08                 ` Wolfgang Denk
  0 siblings, 1 reply; 10+ messages in thread
From: Peter Chen @ 2009-08-18  9:50 UTC (permalink / raw)
  To: u-boot


Dear Wolfgang Denk,


On Tue, 2009-08-18 at 10:35 +0200, Wolfgang Denk wrote:

> Dear Peter Chen,
> 
> In message <1250571462.6548.21.camel@nchen-desktop> you wrote:
> > 
> > > > > The "jump table provided by U-Boot exactly for this purpose" is the
> > > > > list of functions exported through the "include/_exports.h" header
> > > > > file.
> ...
> > > If you set up your own list of function pointers (in addition or
> > > instead of the jump table provided by the "include/_exports.h"
> > > header), then this is a form of linking against the U-Boot code, and
> > > your application must be released under GPL.
> > 
> > I am sorry, I can't understand your meaning. For example, at
> 
> I'm close to give up. I try to as explicit as possible, and I see no
> room for interpretation left, yet you still try to argument.
> 
> > "include/_exports.h"
> > there is an EXPORT_FUNC(printf), do the standalone application must
> > under GPL if
> > it uses printf?
> 
> No. As explained several times before, the "jump table [is]  provided
> by  U-Boot  exactly  for  this purpose", with "this purpose" being to
> allow for closed source, proprietary code.
> 
> printf() gets exported through the jump table interface, so this is OK
> to use in proprietary code.
> 
> > Then, what does "include/_exports.h" use?
> 
> It uses a list of functions (resp. function pointers) we consider  OK
> to be used in closed source applications.
> 
> > In your COPYING, it writes:
> >   NOTE! This copyright does *not* cover the so-called "standalone"
> > applications that use U-Boot services by means of the jump table
> > provided by U-Boot exactly for this purpose - this is merely
> > considered normal use of U-Boot, and does *not* fall under the 
> > heading of "derived work".
> 
> Indeed. And I explained this several times before.
> 
> > > > Is it free to license at below situation:
> > > > The function list which is defined at u-boot/board/myboard/myboard.c,
> > > > and all functions in this list
> > > > only uses functions at include/_exports.h and some of user-defined
> > > > functions.
> > > 
> > > Your description is really vague; it would be easier if you could
> > > give specific code examples or such. If "some of user-defined
> > > functions" refers to code that is covered by the GPL, then your
> > > application must be released under GPL, too.
> > > 
> > 
> > My code like belows:
> > 
> > typedef void (*pfn_t) (void);
> > pfn_t sc_gps_pfn[] = {
> >         LoadToMemory,
> >         SaveData,
> >         RFPowerCtrl,
> >         MiscConfig,
> >         RegisterDspInterruptHandler,
> >         GetPowerStatus,
> >         IsUserResume,
> >         DebugOutput,
> >         ReturnToBootLoader
> > };
> 
> OK, so you are setting up a table of your  own  functions.  You  need
> this  table only if you link the code containing these functions with
> the U-Boot binary - and you do so  most  probably  because  the  code
> calls into other U-Boot provided functions.
> 
> > We want to open this code, but want to close the code which use this
> > function list in binary pattern.
> 
> You probably have no choice here. If your code that provides the list
> of functions above is linked with U-Boot, you *must* release it under
> GPL. No matter if you want or not - if you release your code at all,
> it is GPLed.
> 
> And your list of functions above thus accesses GPLed  code  which  is
> NOT  part  of include/_exports.h. So the GPL exception does NOT apply
> to any code that references functions from  this  list,  i.  e.  your
> standalone application must be released under GPL, too.
> 

    The functions which in my function list are written by our own.
and do not call any other functions at original u-boot code. In that
case, 
can we add our functions to "include/_exports.h" in order to free from
GPL for our standalone application?

I checked the functions which exported in "include/_exports.h", and
their definitions are also under GPL. then why 
they can be called for closed code? If we want to add, how to do?


> > > What you implement is some form of static linking.
> ...
> > The standalone application is compiled by armcc, and this bin file is
> > shared by WinCE and Linux bootloader.
> > The standalone application uses bootloader functions by address not by
> > name.
> 
> That does not matter. Accessing a function by address still means you
> are linking against the code (in a stupid way, btw). Your standalone
> application has to be released under GPL.
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> A quarrel is quickly settled when deserted by one party; there is  no
> battle unless there be two.                                  - Seneca


Best Regards,
Peter Chen

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot] License Problems for standalone application at u-boot
  2009-08-18  9:50               ` Peter Chen
@ 2009-08-18 11:08                 ` Wolfgang Denk
  0 siblings, 0 replies; 10+ messages in thread
From: Wolfgang Denk @ 2009-08-18 11:08 UTC (permalink / raw)
  To: u-boot

Dear Peter Chen,

In message <1250589013.6208.40.camel@nchen-desktop> you wrote:
> 
>     The functions which in my function list are written by our own.
> and do not call any other functions at original u-boot code. In that
> case, 

Then just link them against your standalone application, and keep the
code outside the U-Boot image.

> can we add our functions to "include/_exports.h" in order to free from
> GPL for our standalone application?

No.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"He was so narrow minded he could see through  a  keyhole  with  both
eyes ..."

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2009-08-18 11:08 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-14  3:24 [U-Boot] License Problems for standalone application at u-boot Peter Chen
2009-08-14  5:42 ` Wolfgang Denk
2009-08-14  6:38   ` Peter Chen
2009-08-14  9:38     ` Wolfgang Denk
2009-08-17  2:00       ` Peter Chen
2009-08-17  8:03         ` Wolfgang Denk
2009-08-18  4:57           ` Peter Chen
2009-08-18  8:35             ` Wolfgang Denk
2009-08-18  9:50               ` Peter Chen
2009-08-18 11:08                 ` Wolfgang Denk

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.