[ECOS] Are copyright assignments detrimental to eCos?

[ECOS] Are copyright assignments detrimental to eCos?

[Øyvind Harboe]

I believe that a sluggish patch + commit process is detrimental to eCos.

Clearly copyright assignments slow things down.

Why copyright assignments at this point?

Is it an anachronism?

Why should *all* of eCos require copyright assignments?

What about other projects imported to eCos? Do they too have copyright
assignments in order? jffs2? zlib?

-- 
Øyvind Harboe
http://www.zylin.com - eCos ARM & FPGA developer kit

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Jonathan Larmour]

Øyvind Harboe wrote:
> I believe that a sluggish patch + commit process is detrimental to eCos.

Contributors need to make assignments just one time. Other projects are
plenty busy enough with their regular contributors. We don't seem to have
quite as many that stick around, but that's not the fault of the process.

> Clearly copyright assignments slow things down.
> 
> Why copyright assignments at this point?
> 
> Is it an anachronism?

Legal protection. Probably most embedded engineers have contracts that lay
down that work done by them is owned by their employer - certainly during
company time, and often outside company time too. This is more true for the
embedded space than most others because there are comparatively few
hobbyists compared to other projects - for us, the vast majority of
users/developers will be using it as part of their work.

Therefore in most cases, it is not the employee's choice whether to
contribute something - they don't own it to begin with. Many OSS projects
are treading on thin legal ice because they are accepting stuff
willy-nilly. They could have problems if just one employer turns round and
says "Hey, that's our code!". If you're lucky you can get away with
removing the code, rather than having to pay damages, although the latter
is a legal option.

For us in the embedded world, the consequences are a thousand times worse -
deployed embedded devices in the field using eCos would have to be
recalled. (For example, every Playstation 3).

A company could use this to effectively extort money. The IBM vs. SCO case
affecting Linux shows what could happen with uncertain ownership, and SCO
was very clear that they were going to charge. Luckily it worked out for
everyone. This time. People have said many times that the lack of clear
code ownership in Linux is a time-bomb.

Single ownership also sorts out GPL license enforcement. Breaking the
license on a large amount of eCos code is easy to enforce; but how about
when someone copies just bits and pieces. Functions here and there, but
breaks the GPL and doesn't distribute source. You need to be able to know
who specifically owns the copyright to those *specific* pieces of code, and
it is the authors of that code, and no-one else, who have to enforce the
license. No-one else can do it on their behalf. The FSF will of course
happily enforce the GPL for us.

> Why should *all* of eCos require copyright assignments?

All contributions at any rate.

> What about other projects imported to eCos? Do they too have copyright
> assignments in order? jffs2? zlib?

We relax it for self-contained established open source projects - in that
case it's a port of the code we're really trying to deal with, not the code
itself. It's not up to us to enforce their assignment rules. Sure, it's not
desirable, but we're forced into a corner. We certainly shouldn't make it
worse. It would be better if we had clearer explanations of licensing and
copyright affecting code. eCosCentric has been approached before to develop
a licensing management tool, but it hasn't happened yet.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
 **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv>  **
 **  April 15-17 2008, Booth 3012, San Jose McEnery Convention Center **
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Markus Schaber]

Hi, Jonathan,

Jonathan Larmour <jifl@eCosCentric.com> wrote:

> Øyvind Harboe wrote:

> > Clearly copyright assignments slow things down.
> > 
> > Why copyright assignments at this point?
> > 
> > Is it an anachronism?
> 
> Legal protection.

I understand this point, but in some legislations, a full copyright
assignment is not possible legally.

Additionally, our company has the policy that any substantial
contribution must be copy-lefted, so no-one else can make closed-source
derivates.

Copyright assignment creates a single point of failure against
closed-source derivates, weakening the copyleft. 

Spread Copyright protects against such a single point of failure. A nice
example were the latest tries to buyout linux - it is impossible to get
all the licenses of some thousand independent contributors. 

But imagine someone undermining/bribing the FSF[1], he can then legally
relicense all those GNU software which requires copyright assignment.

And RedHat specifically says that "other licenses" for eCos are
available, so any RedHat sales droid is officially aiming to be bribed
to relicense the code.

> Therefore in most cases, it is not the employee's choice whether to
> contribute something - they don't own it to begin with. Many OSS projects
> are treading on thin legal ice because they are accepting stuff
> willy-nilly. They could have problems if just one employer turns round and
> says "Hey, that's our code!". If you're lucky you can get away with
> removing the code, rather than having to pay damages, although the latter
> is a legal option.

Copyright assignment is not necessary to solve this problem, an
company official signing that the contributions are licensed under the
eCos License is enough for that.

> Single ownership also sorts out GPL license enforcement. Breaking the
> license on a large amount of eCos code is easy to enforce; but how about
> when someone copies just bits and pieces. Functions here and there, but
> breaks the GPL and doesn't distribute source. You need to be able to know
> who specifically owns the copyright to those *specific* pieces of code, and
> it is the authors of that code, and no-one else, who have to enforce the
> license. No-one else can do it on their behalf. The FSF will of course
> happily enforce the GPL for us.

I'm sure that the "right to enforce" could be transferred without
transferring the right to relicense, but IANAL.

> > Why should *all* of eCos require copyright assignments?
> 
> All contributions at any rate.

Really small contributions (obvious typo fixes etc.) aren't
copyrightable in most legislations, so no assignment should be
necessary.


Regards,
Markus

[1] Yes, I know that this is impossible, at least as long as Richard M.
Stallman leads the FSF. But we all know that every "good" institution
can turn bad after some decades, when the founders get replaced by the
next and 3rd generations.

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Jiri Gaisler]

Markus Schaber wrote:

> Additionally, our company has the policy that any substantial
> contribution must be copy-lefted, so no-one else can make closed-source
> derivates.
> 
> Copyright assignment creates a single point of failure against
> closed-source derivates, weakening the copyleft. 

I completely agree with Markus. We are hesitant to contribute our
leon2/3 port and drivers because we do not want to have closed-source
distributions (e.g. eCos Pro) using our code without contributing
back fixes or improvements. The ideal solution would be to license
the eCos code in LGPL. This would allow mixing proprietary applications
with the kernel, while force any improvements or bug fixes to be
published.

Jiri.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Alexander Neundorf]

On Thursday 03 April 2008, Jiri Gaisler wrote:
> Markus Schaber wrote:
> > Additionally, our company has the policy that any substantial
> > contribution must be copy-lefted, so no-one else can make closed-source
> > derivates.
> >
> > Copyright assignment creates a single point of failure against
> > closed-source derivates, weakening the copyleft.
>
> I completely agree with Markus. We are hesitant to contribute our
> leon2/3 port and drivers because we do not want to have closed-source
> distributions (e.g. eCos Pro) using our code without contributing
> back fixes or improvements. The ideal solution would be to license

So GPL or LGPL would be ok for you ?

> the eCos code in LGPL. This would allow mixing proprietary applications
> with the kernel, while force any improvements or bug fixes to be
> published.

Well, and it would enforce that company ship their firmware as object files or 
relinkable static libraries, so that this together with the LGPL part (eCos 
then) could be relinked to a working firmware image.
I think that's not a very practical solution.

Alex



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Jiri Gaisler]

Using LGPL does not require you ship your firmware as
object files and link later. My understanding of LGPL
is that you can ship proprietary core linked with LGPL
code, without having to open-source the proprietary
code. It is only the modifications of the LGPL code
you must publish, which is exactly what we are after.

Jiri.


Alexander Neundorf wrote:

>> I completely agree with Markus. We are hesitant to contribute our
>> leon2/3 port and drivers because we do not want to have closed-source
>> distributions (e.g. eCos Pro) using our code without contributing
>> back fixes or improvements. The ideal solution would be to license
> 
> So GPL or LGPL would be ok for you ?
> 
>> the eCos code in LGPL. This would allow mixing proprietary applications
>> with the kernel, while force any improvements or bug fixes to be
>> published.
> 
> Well, and it would enforce that company ship their firmware as object files or 
> relinkable static libraries, so that this together with the LGPL part (eCos 
> then) could be relinked to a working firmware image.
> I think that's not a very practical solution.
> 
> Alex
> 
> 
> 

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Alexander Neundorf]

On Friday 04 April 2008, Jiri Gaisler wrote:
> Using LGPL does not require you ship your firmware as
> object files and link later. My understanding of LGPL
> is that you can ship proprietary core linked with LGPL
> code, without having to open-source the proprietary
> code. 

Yes, you don't have to ship your code if you link to a LGPL library.
But you have to ship your executable in such a form that the user can create a 
new version of it if he wants to use a different version of the LGPLd 
library.
This means you don't have to ship source code, but object files or a static 
library.

For desktop-applications this is different, if you link to a LGPL shared 
library you can just replace the shared library with another version and 
everything is fine.

You can have a look at the LGPL, it is written somewhere, I don't remember the 
exact words.

Alex

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Markus Schaber]

Hi, Jiri,

Jiri Gaisler <jiri@gaisler.com> wrote:

> Using LGPL does not require you ship your firmware as
> object files and link later. My understanding of LGPL
> is that you can ship proprietary core linked with LGPL
> code, without having to open-source the proprietary
> code. It is only the modifications of the LGPL code
> you must publish, which is exactly what we are after.

Please read the LGPL carefully.

You stumbled over one of the differences between the LGPL and the "GPL
with linking exception", as used by eCos or the GCC run time library,
AFAIR.


Regards,
Markus

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Jiri Gaisler]

This is getting interesting. I understand the difference
between LGPL and GPL better now, and I have found the eCos
lining exception part in the license:

// As a special exception, if other files instantiate templates or use macros
// or inline functions from this file, or you compile this file and link it
// with other works to produce a work based on this file, this file does not
// by itself cause the resulting work to be covered by the GNU General Public
// License. However the source code for this file must still be made available
// in accordance with section (3) of the GNU General Public License.


Does this mean that if we contribute some files to eCos under
this license and they end up in eCos Pro, any modifications to
them made by eCosCentric would have to be published and could be
merged back to the open version of eCos. The last sentence seems
to indicate this, I just want be sure.

I have looked at the files in eCos Pro, and majority of it has
the GPL license with the linking exception. Is there anything that
would prevent me from merging updated files from eCos Pro back
to the open CVS version?

Jiri.

Markus Schaber wrote:
> Hi, Jiri,
> 
> Jiri Gaisler <jiri@gaisler.com> wrote:
> 
>> Using LGPL does not require you ship your firmware as
>> object files and link later. My understanding of LGPL
>> is that you can ship proprietary core linked with LGPL
>> code, without having to open-source the proprietary
>> code. It is only the modifications of the LGPL code
>> you must publish, which is exactly what we are after.
> 
> Please read the LGPL carefully.
> 
> You stumbled over one of the differences between the LGPL and the "GPL
> with linking exception", as used by eCos or the GCC run time library,
> AFAIR.
> 
> 
> Regards,
> Markus
> 

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Jiri Gaisler]

Markus Schaber wrote:

>> I have looked at the files in eCos Pro, and majority of it has
>> the GPL license with the linking exception. Is there anything that
>> would prevent me from merging updated files from eCos Pro back
>> to the open CVS version?
> 
> AFAICS, no, given that you legally received your copy of eCos Pro.

eCoscentric provides a free eCos Pro kit for the Nios processor,
which anyone can download. This would mean that all GPL files in
the kit are free to be merged with the open CVS. Or is there some
other catch ...?

Jiri.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Alex Schuilenburg]

Jiri Gaisler wrote:
> Markus Schaber wrote:
>
>> Additionally, our company has the policy that any substantial
>> contribution must be copy-lefted, so no-one else can make closed-source
>> derivates.
>>
>> Copyright assignment creates a single point of failure against
>> closed-source derivates, weakening the copyleft. 
>
> I completely agree with Markus. We are hesitant to contribute our
> leon2/3 port and drivers because we do not want to have closed-source
> distributions (e.g. eCos Pro) using our code without contributing
> back fixes or improvements. 
eCosPro is certainly not closed source and most of the code is under the 
same GPL+ex license as eCos.  Everyone who receives eCosPro receives the 
full source code.  Sure, we provide additional functionality under a 
different source license with our eCosPro distributions, but there is 
nothing wrong in earning a buck from our work. Also, GPL+ex code always 
stays GPL+ex. There is no way we or anyone else can ship the code under 
any other license. Any contribution of yours would stay open source 
whatever - we and the community would welcome your contribution.

I'm also intrigued by your attitude regarding contributions. Do you also 
withhold contributions if the code could be used by some evil regime or 
for some purpose which you don't agree with? In fact every commercial 
company that uses eCos more than likely makes money from it because they 
don't have to pay license fees or royalties, and not many contribute 
anything back. That is one of the things about free open source - you 
don't have much control of how people use your contributions.

As for eCosCentric not contributing fixes or improvements, that is 
incorrect. Mixed in with the various bug fixes we contribute, you will 
also find enhancements such as PPP, SPI, I2C, flash v2, etc.


> The ideal solution would be to license
> the eCos code in LGPL. This would allow mixing proprietary applications
> with the kernel, while force any improvements or bug fixes to be
> published. 
Neither the eCos GPL nor the LGPL force any code to be published. It 
requires that you make the sources available to any code recipient who 
requests it and even allows you to make a nominal charge to cover costs 
for providing the code. Some organisations just choose to publish the 
code to avoid dealing with such requests.  To reiterate something said 
earlier, the LGPL requires object code redistribution which could be a 
limiting factor for some commercial middleware. GPL+x is IMO the best 
solution for commercial use of eCos.


Later Jiri Gaisler also wrote:
>
>
> Markus Schaber wrote:
>
>>> I have looked at the files in eCos Pro, and majority of it has
>>> the GPL license with the linking exception. Is there anything that
>>> would prevent me from merging updated files from eCos Pro back
>>> to the open CVS version?
>>
>> AFAICS, no, given that you legally received your copy of eCos Pro.
>
> eCoscentric provides a free eCos Pro kit for the Nios processor,
> which anyone can download. This would mean that all GPL files in
> the kit are free to be merged with the open CVS. Or is there some
> other catch ...?
You cannot contribute something which you do not own, namely the 
copyright, irrespective of what license the code is distributed under 
(GPL, LGPL, GPL+ex).




>
> Jiri.
>
-- Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited
Tel:  +44 1223 245571                     Barnwell House, Barnwell Drive
Fax:  +44 1223 248712                             Cambridge, CB5 8UU, UK
www.ecoscentric.com             Reg in England and Wales, Reg No 4422071

 **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv>  **
 **     April 15-17 2008, Booth 3012, San Jose Convention Center      **
  


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Markus Schaber]

Hi, Alex,

Alex Schuilenburg <alexs@ecoscentric.com> wrote:

> eCosPro is certainly not closed source and most of the code is under the 
> same GPL+ex license as eCos.  Everyone who receives eCosPro receives the 
> full source code.  Sure, we provide additional functionality under a 
> different source license with our eCosPro distributions, but there is 
> nothing wrong in earning a buck from our work.

I fully agree here.

> Also, GPL+ex code always 
> stays GPL+ex. There is no way we or anyone else can ship the code under 
> any other license. Any contribution of yours would stay open source 
> whatever - we and the community would welcome your contribution.

That does not hold true in case of FSF-Style copright assignments. I
don't know the eCos assignment clauses exactly, but the FSF-Style
assignments allow the FSF to relicense the code under every license
they want. The official reason is that they can update the code to
newer GPL releases, and that works well as long as the FSF stays on the
"good" side.


And, while I'm nit-picking, one could always remove the linker
exception, redistributing the whole under plain GPL. :-)


> I'm also intrigued by your attitude regarding contributions. Do you also 
> withhold contributions if the code could be used by some evil regime or 
> for some purpose which you don't agree with? In fact every commercial 
> company that uses eCos more than likely makes money from it because they 
> don't have to pay license fees or royalties, and not many contribute 
> anything back. That is one of the things about free open source - you 
> don't have much control of how people use your contributions.

Yes, you don't have much control. Using copylefted licenses is one way
to retain a little of those control. And copyright assignmend
undermines that copyleft, at least for one privileged institution.

That's the policy of logix-tt, for "substantial" contributions, and not
necessarily my personal one.

> Neither the eCos GPL nor the LGPL force any code to be published. It 
> requires that you make the sources available to any code recipient who 
> requests it and even allows you to make a nominal charge to cover costs 
> for providing the code. Some organisations just choose to publish the 
> code to avoid dealing with such requests.

When nitpicking, putting the sourcecode on a public server alone would
not fulfil the exact worded requirements of GPL V2 (at least when the
binary was distributed another way), but in practice, it fulfilled the
spirit of the GPL, and I know of no case where somebody complained.
This was fixed in GPL V3.

> > eCoscentric provides a free eCos Pro kit for the Nios processor,
> > which anyone can download. This would mean that all GPL files in
> > the kit are free to be merged with the open CVS. Or is there some
> > other catch ...?
> You cannot contribute something which you do not own, namely the 
> copyright, irrespective of what license the code is distributed under 
> (GPL, LGPL, GPL+ex).

This is the policy of the eCos maintainers, they won't accept anything
into the open CVS without copyright assignment.

Of yourse, you could take the burden and fork your own eCos tree, where
you can include anything you want (given that you don't violate the
licenses). LLVM is going this way, and EGCS was going it some time ago.
But it's always a big burden, and small projects like eCos should not
get lost in divergence.

Regards,
Markus

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Markus Schaber]

Hi, Markus,

Markus Schaber <schabi@logix-tt.com> wrote:

> That does not hold true in case of FSF-Style copright assignments. I
> don't know the eCos assignment clauses exactly,

I just was told that the eCos copyright assignment is not to RedHat
or eCosCentric, but to the FSF.

That falsifies my statements about the RedHat sales droids, I presume,
although there are still the "for other licenses, contact RedHat"
statements scattered over the web and source.


Regards,
Markus

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Andrew Lunn]

> I just was told that the eCos copyright assignment is not to RedHat
> or eCosCentric, but to the FSF.
> 
> That falsifies my statements about the RedHat sales droids, I presume,
> although there are still the "for other licenses, contact RedHat"
> statements scattered over the web and source.

Yes, that statement is slowly being eradicated. When ever i touch a
file i tend to remove it. At some point we will wholesale remove the
rest, but that means touching nearly every file, so it is a big change
to CVS. So this is likely to happen at the same time we change the
Copyright notice to FSF which again needs to touch every file in the
repository.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Markus Schaber]

Hi, Andrew,

Andrew Lunn <andrew@lunn.ch> wrote:

> > I just was told that the eCos copyright assignment is not to RedHat
> > or eCosCentric, but to the FSF.
> > 
> > That falsifies my statements about the RedHat sales droids, I presume,
> > although there are still the "for other licenses, contact RedHat"
> > statements scattered over the web and source.
> 
> Yes, that statement is slowly being eradicated. When ever i touch a
> file i tend to remove it. At some point we will wholesale remove the
> rest, but that means touching nearly every file, so it is a big change
> to CVS. So this is likely to happen at the same time we change the
> Copyright notice to FSF which again needs to touch every file in the
> repository.

One of that statements is:
| For information on obtaining alternative licences for JFFS2, see 
| http://sources.redhat.com/jffs2/jffs2-licence.html

And that page on the web says "For information on obtaining alternative
licences for JFFS2, contact Red Hat directly.".

Maybe changing that information on the website is a quick&dirty way to
break up the path of misleading statements. :-)


Regards,
Markus

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Andrew Lunn]

On Fri, Apr 04, 2008 at 12:00:42PM +0200, Jiri Gaisler wrote:
>
>
> Markus Schaber wrote:
>
>>> I have looked at the files in eCos Pro, and majority of it has
>>> the GPL license with the linking exception. Is there anything that
>>> would prevent me from merging updated files from eCos Pro back
>>> to the open CVS version?
>>
>> AFAICS, no, given that you legally received your copy of eCos Pro.
>
> eCoscentric provides a free eCos Pro kit for the Nios processor,
> which anyone can download. This would mean that all GPL files in
> the kit are free to be merged with the open CVS. Or is there some
> other catch ...?

The catch is that in order for it to be included into anoncvs, the
owner of the code has to agree and transfer the copyright to FSF. So i
cannot just pick up eCosCentric code and commit it. eCosCentric have
to agree to it as copyright owner.

   Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Jiri Gaisler]

Andrew Lunn wrote:

>>>> I have looked at the files in eCos Pro, and majority of it has
>>>> the GPL license with the linking exception. Is there anything that
>>>> would prevent me from merging updated files from eCos Pro back
>>>> to the open CVS version?
>>> AFAICS, no, given that you legally received your copy of eCos Pro.
>> eCoscentric provides a free eCos Pro kit for the Nios processor,
>> which anyone can download. This would mean that all GPL files in
>> the kit are free to be merged with the open CVS. Or is there some
>> other catch ...?
> 
> The catch is that in order for it to be included into anoncvs, the
> owner of the code has to agree and transfer the copyright to FSF. So i
> cannot just pick up eCosCentric code and commit it. eCosCentric have
> to agree to it as copyright owner.

So if I contribute code to the anoncvs, I assign the copyright to FSF.
If eCoscentric includes the code into eCos Pro, it will still bear the
FSF copyright. If they then make a bug fix, any licensee of eCos Pro
should be able to submit the fix into anoncvs, since the copyright
is still with FSF and the code is still GPL. Have I got this right?
Or do I need to assign the copyright to eCoscentric before it is
included in the eCos Pro distribution?

What I am trying to avoid is a fork of a potential contribution,
with one version in anoncvs and some other version in eCos Pro.

Jiri.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Alex Schuilenburg]

Jiri Gaisler wrote on 2008-04-04 16:11:
>
>
> Andrew Lunn wrote:
>
>>>>> I have looked at the files in eCos Pro, and majority of it has
>>>>> the GPL license with the linking exception. Is there anything that
>>>>> would prevent me from merging updated files from eCos Pro back
>>>>> to the open CVS version?
>>>> AFAICS, no, given that you legally received your copy of eCos Pro.
>>> eCoscentric provides a free eCos Pro kit for the Nios processor,
>>> which anyone can download. This would mean that all GPL files in
>>> the kit are free to be merged with the open CVS. Or is there some
>>> other catch ...?
>>
>> The catch is that in order for it to be included into anoncvs, the
>> owner of the code has to agree and transfer the copyright to FSF. So i
>> cannot just pick up eCosCentric code and commit it. eCosCentric have
>> to agree to it as copyright owner.
>
> So if I contribute code to the anoncvs, I assign the copyright to FSF.
> If eCoscentric includes the code into eCos Pro, it will still bear the
> FSF copyright. If they then make a bug fix, any licensee of eCos Pro
> should be able to submit the fix into anoncvs, since the copyright
> is still with FSF and the code is still GPL. Have I got this right?
> Or do I need to assign the copyright to eCoscentric before it is
> included in the eCos Pro distribution?
No.  You would need to assign the code to the FSF.  We (eCosCentric) are 
no longer accepting contributions.  The FSF are now the keepers of the 
eCos copyright and to whom we assign any of our eCos contributions, just 
like the rest of the eCos community.

As for submitting fixes from eCosPro to anoncvs, copyrightable fixes can 
only be submitted by the copyright holder, which we do from time to time.


>
>
> What I am trying to avoid is a fork of a potential contribution,
> with one version in anoncvs and some other version in eCos Pro.
As Andrew says, anyone can fork the code. It is GPL code after all. The 
only condition is they have to adhere to the license.

Anyway, forking is not in our interest, never mind the community's. We 
want the benefits that contributions to eCos bring, as does everyone 
else. eCosPro is not a fork, it is a superset of eCos.  See  
http://www.ecoscentric.com/ecos/ecospro.shtml

What you seem to be suggesting is that you want everyone else *but* 
eCosCentric to benefit from your potential contribution.
>
> Jiri.
>
 
-- Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited
Tel:  +44 1223 245571                     Barnwell House, Barnwell Drive
Fax:  +44 1223 248712                             Cambridge, CB5 8UU, UK
www.ecoscentric.com             Reg in England and Wales, Reg No 4422071

 **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv>  **
 **     April 15-17 2008, Booth 3012, San Jose Convention Center      **
  



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Jiri Gaisler]

Alex Schuilenburg wrote:

> Anyway, forking is not in our interest, never mind the community's. We 
> want the benefits that contributions to eCos bring, as does everyone 
> else. eCosPro is not a fork, it is a superset of eCos.  See  
> http://www.ecoscentric.com/ecos/ecospro.shtml
> 
> What you seem to be suggesting is that you want everyone else *but* 
> eCosCentric to benefit from your potential contribution.

What I am saying is that I want everyone to benefit from our contribution,
*and* from potential derivate work in form of bug fixes. Just like the
linux kernel. Everyone sees the same kernel code, while applications and
drivers can be proprietary if desired. It seems to me that insisting on
FSF copyright transfer blocks this in some way. We are still maintaining
our own ecos fork (superset), but I would rather see everything merged
to anoncvs. But I respect the policy of the anoncvs maintainers and
eCoscentric, so we will keep it as is for them time being.


Jiri.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Jonathan Larmour]

Jiri Gaisler wrote:
> Alex Schuilenburg wrote:
> 
>> Anyway, forking is not in our interest, never mind the community's. We 
>> want the benefits that contributions to eCos bring, as does everyone 
>> else. eCosPro is not a fork, it is a superset of eCos.  See  
>> http://www.ecoscentric.com/ecos/ecospro.shtml
>>
>> What you seem to be suggesting is that you want everyone else *but* 
>> eCosCentric to benefit from your potential contribution.
> 
> 
> What I am saying is that I want everyone to benefit from our contribution,
> *and* from potential derivate work in form of bug fixes. Just like the
> linux kernel.

In this respect it's no different from the linux kernel. Someone can take 
the linux kernel, make changes and bug fixes and distribute it. And by 
virtue of the GPL the people who get any kernel binaries can get the 
source code that goes with it and all is as it should be. That doesn't 
mean they have to be posted on the linux-kernel list, nor provided to 
Linus for inclusion in the source base, and indeed many are not.

What difference do you think there is?

> Everyone sees the same kernel code, while applications and
> drivers can be proprietary if desired.

And that's what happens with eCosPro - all the source code is supplied, 
and the only bits that can't be redistributed freely are some portions we 
have written solely ourselves (not derived from public eCos sources) as 
extensions and add-ons.

For example we have an entirely new MultiMedia Filesystem. That's an 
extension we wrote ourselves, and is no different conceptually from people 
writing their own userspace filesystem on Linux (such as with FUSE). Just 
like with a FUSE filesystem an extension should be able to be 
proprietary[1]. The fact that eCos, unlike Linux, links into a single 
kernel image without such a clear kernel boundary isn't important for the 
principle of thing - that's the reason for the exception clause with the 
GPL which we have.

> It seems to me that insisting on
> FSF copyright transfer blocks this in some way. We are still maintaining
> our own ecos fork (superset), but I would rather see everything merged
> to anoncvs. But I respect the policy of the anoncvs maintainers and
> eCoscentric, so we will keep it as is for them time being.

Obviously you don't have to contribute changes either :-). But I don't 
think you need have the worry you seem to have. Anything contributed to 
eCos gets owned by the FSF, and put under the eCos GPL+exception license 
de facto forever[2]. No-one can change that (except the FSF, and as the 
creators of free software they never would). And anyone who makes fixes to 
those source files has to keep it with that license and distribute them 
under the GPL terms. Just like the Linux kernel.

Does that clear things up?

Jifl (eCosCentric hat)
[1] 
<http://fuse.sourceforge.net/wiki/index.php/FAQ#Under_what_conditions_may_I_distribute_a_filesystem_which_uses_libfusex3f.>
[2] Or equivalently anyway - because of single ownership in the FSF, we 
can change the license wording if there is a legal need. We couldn't do 
that with multiple owners - we'd need everyone's permission.
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Alex Schuilenburg]

Jiri Gaisler wrote on 2008-04-04 17:51:
>
> Alex Schuilenburg wrote:
>> Anyway, forking is not in our interest, never mind the community's. 
>> We want the benefits that contributions to eCos bring, as does 
>> everyone else. eCosPro is not a fork, it is a superset of eCos.  See  
>> http://www.ecoscentric.com/ecos/ecospro.shtml
>>
>> What you seem to be suggesting is that you want everyone else *but* 
>> eCosCentric to benefit from your potential contribution.
>
> What I am saying is that I want everyone to benefit from our 
> contribution,
> *and* from potential derivate work in form of bug fixes. Just like the
> linux kernel. Everyone sees the same kernel code, while applications and
> drivers can be proprietary if desired. It seems to me that insisting on
> FSF copyright transfer blocks this in some way. 
You are incorrect. Speak to the FSF or a copyright and licensing lawyer 
if you don't believe me. Copyright assignment in this case has nothing 
to do with what you suggest.  The copyright assignment of eCos to the 
FSF is all about protection of the code and guaranteeing that it remains 
free to all.

I don't know of *any* free open source software license that does what 
you suggest. Free Open Source licenses may force you to make the changes 
to the source code available (GPL and derivatives), but I now of none 
that force you to contribute or publish changes.

And just to give a totally hypothetical example: if all your code and 
changes are GPL+ex, there is nothing legally stopping any commercial 
organisation which legally obtains your source code from integrating 
these changes into their own source code base, add their own 
fixes/improvements and then distributing these changes as part of their 
*own* eCos distribution - as long as the license remains the same(ish - 
for the nitpickers ;-). In fact some companies make a living doing 
exactly this with other free open source projects. Of course these 
companies could not contribute your code to the FSF, since they do not 
own the copyright, but they could contribute their changes (not that the 
changes would IMHO be accepted into eCos anoncvs because the changes 
would apply to code that does not exist, so pretty pointless). These 
companies could also not prevent *you* from taking this contribution to 
eCos anoncvs and integrating it into *your* own distribution either.

I would also just like to point out that you also *cannot* then 
integrate any changes that have been published under the GPL or GPL+ex 
and integrate those changes into a non-GPL distribution.  e.g. 
Improvements to dual licensed code (e.g. GPL and a proprietary license) 
that are published under the GPL license cannot then be brought into the 
proprietary license without making all that code GPL as well (unless of 
course you held the copyright of the improved code). Think back to what 
used to happen when eCos copyright was held by Red Hat and licensed 
under the RHEPL - Red Hat could take *your* RHEPL contributions and 
relicense them under a proprietary commercial license. Ever wonder why 
eCos was relicensed under GPL+ex and the copyright contributed to the FSF?

And FAOD, *every* copyright contribution made to eCosCentric while the 
switch of eCos copyright from Red Hat to the FSF was happening has been 
contributed to the FSF, just as we said we would, and has *never* been 
published under any license other than GPL+ex nor been released as part 
of eCosPro *before* being integrated into eCos anoncvs.

> We are still maintaining
> our own ecos fork (superset), but I would rather see everything merged
> to anoncvs. But I respect the policy of the anoncvs maintainers and
> eCoscentric, so we will keep it as is for them time being.
[...]

If you claim superset rather than branch, I assume you must also be 
doing regular internal merges with anoncvs to allow your users to 
benefit from any fixes and improvements that go into the main eCos 
anoncvs source base? Do users of your own port have to contribute the 
copyright of changes or improvements to your code to you as well (to 
maintain the legal status and protection of copyright that eCos 
currently enjoys), and where are the changes published?

These are all questions you need to think about when keeping your own 
eCos tree.

Anyway, nobody is trying to force you to contribute here. I am just 
trying to show you some of the benefits contributions can make to your 
users, the community as well as yourself. Your changes and improvements 
are yours to do with as you see fit, subject to licensing of course ;-)

-- Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited
Tel:  +44 1223 245571                     Barnwell House, Barnwell Drive
Fax:  +44 1223 248712                             Cambridge, CB5 8UU, UK
www.ecoscentric.com             Reg in England and Wales, Reg No 4422071

 **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv>  **
 **     April 15-17 2008, Booth 3012, San Jose Convention Center      **


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Jiri Gaisler]

Alex Schuilenburg wrote:

> Anyway, nobody is trying to force you to contribute here. I am just 
> trying to show you some of the benefits contributions can make to your 
> users, the community as well as yourself. Your changes and improvements 
> are yours to do with as you see fit, subject to licensing of course ;-)

I don't see the benefit to our users if there are two different versions
of our contribution, one in the anoncvs and one in the Pro. In such
case, I prefer to have our own fork where we have control over what
goes into our code modules and where we are able to support it.

The development model for kernels like RTEMS and linux seems more
reliable to me. There is only one code base and all testing, validation
and bug reporting is done on the same set of code. I believe this was also
the case for eCos as long as Cygnus maintained the code. Going back to
this model could in fact benefit eCos Pro, since it would create a much
larger user base for the Pro code, potentially finding more bugs and provide
more improvements. Just my 2 cents anyhow ...

Jiri.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Gary Thomas]

Jiri Gaisler wrote:
> Alex Schuilenburg wrote:
> 
>> Anyway, nobody is trying to force you to contribute here. I am just 
>> trying to show you some of the benefits contributions can make to your 
>> users, the community as well as yourself. Your changes and 
>> improvements are yours to do with as you see fit, subject to licensing 
>> of course ;-)
> 
> I don't see the benefit to our users if there are two different versions
> of our contribution, one in the anoncvs and one in the Pro. In such
> case, I prefer to have our own fork where we have control over what
> goes into our code modules and where we are able to support it.
> 
> The development model for kernels like RTEMS and linux seems more
> reliable to me. There is only one code base and all testing, validation

At least as far as Linux goes - this is malarkey.  There are more versions
of Linux out there than you could count, mostly for those platforms or
environments where the code either is not acceptable into the public
tree or simply kept back for commercial advantage.  For example, you don't
see the code for the LinkSys routers in the public tree...

> and bug reporting is done on the same set of code. I believe this was also
> the case for eCos as long as Cygnus maintained the code. Going back to
> this model could in fact benefit eCos Pro, since it would create a much
> larger user base for the Pro code, potentially finding more bugs and 
> provide
> more improvements. Just my 2 cents anyhow ...
> 
> Jiri.
> 


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Jiri Gaisler]

Gary Thomas wrote:

>> The development model for kernels like RTEMS and linux seems more
>> reliable to me. There is only one code base and all testing, validation
> 
> At least as far as Linux goes - this is malarkey.  There are more versions
> of Linux out there than you could count, mostly for those platforms or
> environments where the code either is not acceptable into the public
> tree or simply kept back for commercial advantage.  For example, you don't
> see the code for the LinkSys routers in the public tree...

All serious maintainers use the code from kernel.org. Sure, there are
derivates that goes into various products, but the major development, testing,
validation and bug reporting is done on the kernel.org sources. Same thing
with RTEMS, where the (public) CVS from rtems.org is used.

Jiri.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Gregg Levine]

On Mon, Apr 7, 2008 at 9:26 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> Jiri Gaisler wrote:
>
> > Alex Schuilenburg wrote:
> >
> >
> > > Anyway, nobody is trying to force you to contribute here. I am just
> trying to show you some of the benefits contributions can make to your
> users, the community as well as yourself. Your changes and improvements are
> yours to do with as you see fit, subject to licensing of course ;-)
> > >
> >
> > I don't see the benefit to our users if there are two different versions
> > of our contribution, one in the anoncvs and one in the Pro. In such
> > case, I prefer to have our own fork where we have control over what
> > goes into our code modules and where we are able to support it.
> >
> > The development model for kernels like RTEMS and linux seems more
> > reliable to me. There is only one code base and all testing, validation
> >
>
>  At least as far as Linux goes - this is malarkey.  There are more versions
>  of Linux out there than you could count, mostly for those platforms or
>  environments where the code either is not acceptable into the public
>  tree or simply kept back for commercial advantage.  For example, you don't
>  see the code for the LinkSys routers in the public tree...
>
>
>
> > and bug reporting is done on the same set of code. I believe this was also
> > the case for eCos as long as Cygnus maintained the code. Going back to
> > this model could in fact benefit eCos Pro, since it would create a much
> > larger user base for the Pro code, potentially finding more bugs and
> provide
> > more improvements. Just my 2 cents anyhow ...
> >
> > Jiri.
> >
> >
>
>
>  --
>  ------------------------------------------------------------
>  Gary Thomas                 |  Consulting for the
>  MLB Associates              |    Embedded world
>  ------------------------------------------------------------
>
>  --
>
>  Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>  and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>

Hello!
Until now I've been largely an observer on this one. But regarding
Gary's argument regarding the code for the LinkSys routers, there's a
very good reason why it is not publicly available, and until a few
years ago, not at all available.

The company still refuses to believe that the GPLv2 (or GPLv3) license
still applies to what they either build or make arrangements to build.

And it happens that for some items they even refused to release the
source code for a few portions, leaving it as an OCO (Object Code
Only) binary.

Which was a fact which frustrated a lot of end users of this device.

By the time the firm reached its current design strategy time-period,
they came close. Very close in fact. However they still have that
peculiar opinion of their products and the licensing methods.

And I don't know how many of you remember, but that firm only started
releasing the code under what looked to be an out of court settlement
on the issue. And please note that I am not a lawyer, just someone who
uses the eCOS code for many ideas. (And reads one too many books
taking place in a certain lawyer's time and place.)
-- 
Gregg C Levine gregg.drwho8@gmail.com
"This signature was once found posting rude
 messages in English in the Moscow subway."

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Andrew Lunn]

O.K. Now it is getting time for the IANAL and everything i say is
wrong until you hear it from a copyright lawyer...

> So if I contribute code to the anoncvs, I assign the copyright to FSF.
> If eCoscentric includes the code into eCos Pro, it will still bear the
> FSF copyright.

Correct.

> If they then make a bug fix, any licensee of eCos Pro
> should be able to submit the fix into anoncvs, since the copyright
> is still with FSF and the code is still GPL. Have I got this right?

Nope. They own the copyright to the bug fix. They have to contribute
it to FSF/anoncvs. This is why i expect eCosPro code will have both
copyright eCosCentric as well as Copyright FSF. They are stating they
own some parts of the code.

If you were to fix the bug, you could contribute it to FSF/anoncvs or
eCosCentric. If you contribute it to FSF/anoncvs, eCosCentric can then
pull it into their tree and keep the FSF copyright on your bug fix.

> What I am trying to avoid is a fork of a potential contribution,
> with one version in anoncvs and some other version in eCos Pro.

Not possible, as far as i understand. Anybody can fork any GPL code.

What you may be able to do though is claim the code contains patents
or some other intellectual properly which needs a license and give
away a free license for code in anoncvs only and anybody who wants to
use the code outside of anoncvs needs to pay a billion dollar license
fee for the patents. This probably doesn't hold water, since how do
you define what anoncvs is.... So you definitely need to talk to a
lawyer....

    Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Andrew Lunn]

On Fri, Apr 04, 2008 at 04:01:36PM +0100, Andy Jackson wrote:
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
>   <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

Plain ASCII please, don't encrypt with HTML.

> >From an academic interest point of view, is this true for the parts
> that have been derived from existing GPL licenced files? Surely the
> whole point of the GPL is that you can't withhold a derivative work?<br>
> <br>
> &nbsp;&nbsp;&nbsp; Andy<br>

Two different things here. Making the code available and getting it
included in anoncvs. You can make eCosCentric's GPL code available,
its GPL. But for me to make it part of anoncvs i want a clear
assignment to FSF. Without that, eCosCentric might be able to sue me
for taking away their bread and butter since they own the code. Or
they could ask for license fee from people who then use the code
etc. This goes back to the question about why we need FSF to own the
code, legal protection, and the same rules apply to eCosCentric
contributed code.

    Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Andy Jackson]

Andrew Lunn wrote:
> On Fri, Apr 04, 2008 at 12:00:42PM +0200, Jiri Gaisler wrote:
>   
>> Markus Schaber wrote:
>>
>>     
>>>> I have looked at the files in eCos Pro, and majority of it has
>>>> the GPL license with the linking exception. Is there anything that
>>>> would prevent me from merging updated files from eCos Pro back
>>>> to the open CVS version?
>>>>         
>>> AFAICS, no, given that you legally received your copy of eCos Pro.
>>>       
>> eCoscentric provides a free eCos Pro kit for the Nios processor,
>> which anyone can download. This would mean that all GPL files in
>> the kit are free to be merged with the open CVS. Or is there some
>> other catch ...?
>>     
>
> The catch is that in order for it to be included into anoncvs, the
> owner of the code has to agree and transfer the copyright to FSF. So i
> cannot just pick up eCosCentric code and commit it. eCosCentric have
> to agree to it as copyright owner.
>
>   
 >From an academic interest point of view, is this true for the parts 
that have been derived from existing GPL licenced files? Surely the 
whole point of the GPL is that you can't withhold a derivative work?

    Andy


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Markus Schaber]

Hi, Andy,

Andy Jackson <andy@xylanta.com> wrote:

> > The catch is that in order for it to be included into anoncvs, the
> > owner of the code has to agree and transfer the copyright to FSF. So i
> > cannot just pick up eCosCentric code and commit it. eCosCentric have
> > to agree to it as copyright owner.
> >   
> From an academic interest point of view, is this true for the parts 
> that have been derived from existing GPL licenced files? Surely the 
> whole point of the GPL is that you can't withhold a derivative work?

This is not a question of GPL here, it's a question of anoncvs
maintainers policy. You cannot force anyone to accept code into their
CVS tree.


Regards,
Markus

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Gary Thomas]

Some different words on this whole subject - the way I see it.
I am not a lawyer - accept this as such.

Andy Jackson wrote:
> Andrew Lunn wrote:
>> On Fri, Apr 04, 2008 at 12:00:42PM +0200, Jiri Gaisler wrote:
>>  
>>> Markus Schaber wrote:
>>>
>>>    
>>>>> I have looked at the files in eCos Pro, and majority of it has
>>>>> the GPL license with the linking exception. Is there anything that
>>>>> would prevent me from merging updated files from eCos Pro back
>>>>> to the open CVS version?
>>>>>         
>>>> AFAICS, no, given that you legally received your copy of eCos Pro.
>>>>       
>>> eCoscentric provides a free eCos Pro kit for the Nios processor,
>>> which anyone can download. This would mean that all GPL files in
>>> the kit are free to be merged with the open CVS. Or is there some
>>> other catch ...?
>>>     
>>
>> The catch is that in order for it to be included into anoncvs, the
>> owner of the code has to agree and transfer the copyright to FSF. So i
>> cannot just pick up eCosCentric code and commit it. eCosCentric have
>> to agree to it as copyright owner.
>>
>>   
>  >From an academic interest point of view, is this true for the parts 
> that have been derived from existing GPL licenced files? Surely the 
> whole point of the GPL is that you can't withhold a derivative work?

First of all, there should be nothing in eCos which was derived [purely]
from a GPL environment, it has all been created either from scratch
(at Cygnus -> Red Hat, or by contribution).  Portions from other projects
are included, but still respecting their license (e.g. the FreeBSD stack)

IMO, the whole point of the GPL is about *rights*.  If I distribute
something which came from a GPL source, the recipient of that distribution
must have at least as much right to the code as I did, *including* any
changes or additions I might have made before distributing it.  The GPL
does not explicitly say that I have to give my changes back where I got
them, in fact, I can claim copyright on those changes and still distribute
them as I wish.  This is the case of code distributed by eCosCentric
(and indeed by Analogue & Micro, among others) - we've taken the public,
GPL+ex code, made changes, additions, improvements, etc.  Those who have
received distributions of such material have the right to use and change
the source code, but they don't gain ownership over it.

In the case of FSF projects, we have all agreed that whatever we contribute
into the pool becomes the property (copyright) of the FSF.  No other entity
(person, project or company) can claim ownership of such contributions, not
even the original contributor.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Are copyright assignments detrimental to eCos?

[Chris Zimman]

> Does this mean that if we contribute some files to eCos under
> this license and they end up in eCos Pro, any modifications to
> them made by eCosCentric would have to be published and could be
> merged back to the open version of eCos. The last sentence seems
> to indicate this, I just want be sure.

If eCosCentric owns the copyright, they can change the license at any time.  
If you make a contribution under GPL, I believe they still require an
assignment 
statement if it's not a standalone piece of code (please correct me if I'm
wrong here).

> I have looked at the files in eCos Pro, and majority of it has
> the GPL license with the linking exception. Is there anything that
> would prevent me from merging updated files from eCos Pro back
> to the open CVS version?

OK, this is an interesting issue, which I've thought about a lot recently.

So in the case of the tree that I have with ARM EABI support, it was derived
from an eCosPro tree.
I was considering putting parts of that code back into anon CVS, but I
thought about it for a while, 
and this is what I arrived at:

In my opinion, eCosCentric as an entity, is doing the most to help and
support eCos at the moment.
They rely on people paying them for eCosPro in order to put food on the
table.  I am in the situation
where I can do enhancements to eCos as part of my job, but it's not my
primary job, and I get paid 
either way.  I want to help the community at large, but not at the expense of
hurting eCosCentric, 
as I think that will hurt everyone in the long run.  Without eCosCentric,
there'd be nowhere to
go for eCos support when you really need it.  Sure, something else could
spring up in their place, 
but it would face all of the same issues.

In an ideal world, the publicly available eCos could have all the features of
eCosPro and people 
would still pay eCosCentric for support.  Unfortunately though, things don't
really seem to go that
way.  If people can get something entirely for free (as in beer), that's
usually the end of it.

As I understand it, they have the intention of releasing the code back into
anon CVS at some point, 
but they need to recoup their development costs on it first.  It's not an
ideal situation from all 
perspectives, but it's reality.

What I've elected to do instead is to honor a sort of gentlemen's agreement,
where I'm not releasing 
the GPL'd bits from eCosPro back into the tree.  When eCosCentric feels the
time is right, I'll let 
them do it.  This includes the enhancements that I've made.  I've contributed
them back to eCosCentric 
if they wish to include them.  I don't think their fees are in any way
egregious compared to what you'd 
pay for a commercial RTOS ($40K+ USD for a base license), so I'm happy to
continue to support them.

Anyhow, that's my $.02 on the issue.

--Chris

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Andrew Lunn]

On Fri, Apr 04, 2008 at 05:35:47AM -0400, Chris Zimman wrote:
> > Does this mean that if we contribute some files to eCos under
> > this license and they end up in eCos Pro, any modifications to
> > them made by eCosCentric would have to be published and could be
> > merged back to the open version of eCos. The last sentence seems
> > to indicate this, I just want be sure.
> 
> If eCosCentric owns the copyright, they can change the license at any time.  
> If you make a contribution under GPL, I believe they still require an
> assignment 
> statement if it's not a standalone piece of code (please correct me if I'm
> wrong here).
> 
> > I have looked at the files in eCos Pro, and majority of it has
> > the GPL license with the linking exception. Is there anything that
> > would prevent me from merging updated files from eCos Pro back
> > to the open CVS version?
> 
> OK, this is an interesting issue, which I've thought about a lot recently.
> 
> So in the case of the tree that I have with ARM EABI support, it was derived
> from an eCosPro tree.

You could contribute it back if you wanted to, but you would have to
rebase the patch to the open anoncvs tree, not eCosCentric's tree. But
in some respects it does not necessarily help you. You want the
patches in the next tree you get from eCosCentric as part of your
support contract and there is no guarantee eCosCentric will pull the
changes from the open anoncvs tree into there eCosPro tree. So you end
up contributing it to both to get the most advantage out of it.

        Andrew


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Are copyright assignments detrimental to eCos?

[Chris Zimman]

> You could contribute it back if you wanted to, but you would have to
> rebase the patch to the open anoncvs tree, not eCosCentric's tree. But
> in some respects it does not necessarily help you. You want the
> patches in the next tree you get from eCosCentric as part of your
> support contract and there is no guarantee eCosCentric will pull the
> changes from the open anoncvs tree into there eCosPro tree. So you end
> up contributing it to both to get the most advantage out of it.

That wasn't really the point I was trying to make.  I have chosen not to put
it into anon CVS at the moment because eCosCentric may want to offer it as
part of eCosPro.  I think, at some point, they will release an updated tree
for anon CVS.

If I were to release it, I would probably just fork the tree anyhow. 

--Chris

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Bart Veer]

>>>>> "Markus" == Markus Schaber <schabi@logix-tt.com> writes:

    >> > Clearly copyright assignments slow things down.
    >> > 
    >> > Why copyright assignments at this point?
    >> > 
    >> > Is it an anachronism?
    >> 
    >> Legal protection.

    Markus> I understand this point, but in some legislations, a full
    Markus> copyright assignment is not possible legally.

    Markus> Additionally, our company has the policy that any
    Markus> substantial contribution must be copy-lefted, so no-one
    Markus> else can make closed-source derivates.

    Markus> Copyright assignment creates a single point of failure
    Markus> against closed-source derivates, weakening the copyleft.

    Markus> Spread Copyright protects against such a single point of
    Markus> failure. A nice example were the latest tries to buyout
    Markus> linux - it is impossible to get all the licenses of some
    Markus> thousand independent contributors.

    Markus> But imagine someone undermining/bribing the FSF[1], he can
    Markus> then legally relicense all those GNU software which
    Markus> requires copyright assignment.

Yes, there is a theoretical risk that the FSF be taken over by some
evil empire or other. I do not know the full details of the FSF's
charter but I suspect it has built-in protection against that sort of
thing. Also, as part of the copyright assignment process the FSF
guarantees that the software will remain free. So even if there was a
hostile takeover, it would be legally rather difficult to turn any of
the assigned software proprietary or anything like that.

Spread copyright has its own risks. Suppose that the evil empire
instead "persuades" various politicians to pass some new software
copyright legislation which, as an unfortunate side effect, makes it
illegal to distribute GPL'd software. There is nothing unusual about
big companies lobbying for legislation, e.g. the music industry. In
this scenario, the FSF could tweak the GPL license for all assigned
code to work around the damaged legislation, to the best of the FSF's
lawyers abilities. Now consider a project with spread copyright like
the Linux kernel. It would be necessary to contact every contributor
and get them to agree to a licensing change. Any code where the
contributor could no longer be contacted, or refused to agree to the
change, would have to be taken out and possibly replaced. Until all
that had been sorted out nobody would be allowed to distribute the
Linux kernel.

OK, there would be legal challenges, workarounds like distributing the
kernel from another country with different laws, etc. Still, having a
central body holding the copyrights does make it a lot easier to
respond to such legal issues.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
  **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv>  **
  **  April 15-17 2008, Booth 3012, San Jose McEnery Convention Center **

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Are copyright assignments detrimental to eCos?

[Alexander Neundorf]

On Wednesday 02 April 2008, Jonathan Larmour wrote:
> Øyvind Harboe wrote:
...
> > Why should *all* of eCos require copyright assignments?
>
> All contributions at any rate.

Is it really also necessary for ecosconfig and configtool ?
They are useless without eCos and the only precompiled package I can find is 
very old and a bit buggy. Making contributing easier could help here, which 
could also include opening the host tools directories in cvs for more 
developers.

Alex

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss