[ECOS] Project ideas for graduate course

[ECOS] Project ideas for graduate course

[Rohit]

Hi All,
    I am a computer science graduate from India and i would like to do
my graduate project work on eCos but i am new to eCos world. Will you
please suggest me some good ideas that i can start thinking about ??
Any information about this will be highly appreciated. Links to
existing but unfinished projects would also be fine.


Thanks,
Rohit

-- 
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] Project ideas for graduate course

[Mike Arthur]

Try comparing the features another RTOS has which eCos lacks.  RTEMS
is another open source RTOS that has some features that would be nice
to see in eCos:

http://www.rtems.com/wiki/index.php/RTEMSFeatures

A few of the features I'd like to see are RPC, NFS, a syslog client,
and the ability to dynamically link in modules.  You could port code
over from other systems for the first three items.  You'll want to
check the license on any code you port though.

Hope this helps,
Mike



On 7/30/07, Rohit <will.u.tellmemore@gmail.com> wrote:
> Hi All,
>     I am a computer science graduate from India and i would like to do
> my graduate project work on eCos but i am new to eCos world. Will you
> please suggest me some good ideas that i can start thinking about ??
> Any information about this will be highly appreciated. Links to
> existing but unfinished projects would also be fine.
>
>
> Thanks,
> Rohit
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>

-- 
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] Project ideas for graduate course

[Rohit]

Thanks a lot  for your suggestion. I would go through what you have
suggested and let you guys know what i select out of these(or
something different). More suggestions are still welcome though.


On 7/30/07, Mike Arthur <arth2219@gmail.com> wrote:
> Try comparing the features another RTOS has which eCos lacks.  RTEMS
> is another open source RTOS that has some features that would be nice
> to see in eCos:
>
> http://www.rtems.com/wiki/index.php/RTEMSFeatures
>
> A few of the features I'd like to see are RPC, NFS, a syslog client,
> and the ability to dynamically link in modules.  You could port code
> over from other systems for the first three items.  You'll want to
> check the license on any code you port though.
>
> Hope this helps,
> Mike
>
>
>
> On 7/30/07, Rohit <will.u.tellmemore@gmail.com> wrote:
> > Hi All,
> >     I am a computer science graduate from India and i would like to do
> > my graduate project work on eCos but i am new to eCos world. Will you
> > please suggest me some good ideas that i can start thinking about ??
> > Any information about this will be highly appreciated. Links to
> > existing but unfinished projects would also be fine.
> >
> >
> > Thanks,
> > Rohit
> >
> > --
> > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> >
> >
>

-- 
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] Project ideas for graduate course

[Andrew Lunn]

On Tue, Jul 31, 2007 at 01:04:43PM +0530, Rohit wrote:
> Thanks a lot  for your suggestion. I would go through what you have
> suggested and let you guys know what i select out of these(or
> something different). More suggestions are still welcome though.


How much effort do you think you can give to the project?

RPC and NFS will be a lot of work, i guess too much work.
A syslog client seems a lot more reasonable.

Another idea would be to look at adding raw sockets to the TCP/IP
stack and then maybe BPF/libpcap. Using RAW sockets is something that
comes up every so often. The code was taken out of the stack when it
was ported to eCos. I don't think it will be too hard to put it back
in again and write some test programs, etc.

   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] Project ideas for graduate course

[Klaas Gadeyne]

On Tue, 31 Jul 2007, Andrew Lunn wrote:
[...]
> Another idea would be to look at adding raw sockets to the TCP/IP
> stack and then maybe BPF/libpcap. Using RAW sockets is something that
> comes up every so often. The code was taken out of the stack when it
> was ported to eCos. I don't think it will be too hard to put it back
> in again and write some test programs, etc.

FWIW, the eCos port of the EtherCAT master library <http://ethercatmaster.berlios.de/>
would probably benefit from such raw socket support (and it would give
you a test case :-)

Best regards,

Klaas


-- 
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] Project ideas for graduate course

[Andrew Lunn]

On Tue, Jul 31, 2007 at 11:49:58AM +0200, Klaas Gadeyne wrote:
> On Tue, 31 Jul 2007, Andrew Lunn wrote:
> [...]
>> Another idea would be to look at adding raw sockets to the TCP/IP
>> stack and then maybe BPF/libpcap. Using RAW sockets is something that
>> comes up every so often. The code was taken out of the stack when it
>> was ported to eCos. I don't think it will be too hard to put it back
>> in again and write some test programs, etc.
>
> FWIW, the eCos port of the EtherCAT master library 
> <http://ethercatmaster.berlios.de/>
> would probably benefit from such raw socket support (and it would give
> you a test case :-)

IANAL, but i would want to take a close look at the license agreement
before using this software.

Also, it is GPL, which is probably not what you want.

      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] Project ideas for graduate course

[Klaas Gadeyne]

On Tue, 31 Jul 2007, Andrew Lunn wrote:
> On Tue, Jul 31, 2007 at 11:49:58AM +0200, Klaas Gadeyne wrote:
>> On Tue, 31 Jul 2007, Andrew Lunn wrote:
>> [...]
>>> Another idea would be to look at adding raw sockets to the TCP/IP
>>> stack and then maybe BPF/libpcap. Using RAW sockets is something that
>>> comes up every so often. The code was taken out of the stack when it
>>> was ported to eCos. I don't think it will be too hard to put it back
>>> in again and write some test programs, etc.
>>
>> FWIW, the eCos port of the EtherCAT master library
>> <http://ethercatmaster.berlios.de/>
>> would probably benefit from such raw socket support (and it would give
>> you a test case :-)
>
> IANAL, but i would want to take a close look at the license agreement
> before using this software.

Me neither, but put in human words, the license agreement is there to
ensure 'derived software' (as defined in GPL) stays compatible with
the (open) EtherCAT standard and assures you won't suffer from patent
claims in case it does.

> Also, it is GPL, which is probably not what you want.

Who do you mean with 'you'? 
- IIRC the OP was asking for ideas for projects to be conducted by
graduate students, so I don't see why they would object agains the GPL.
- We (FMTC) wrote and open sourced the code
- As stated on the website, interested companies wishing to use this
   for closed products can obtain a LGPL version against a license fee.

Klaas


-- 
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] Project ideas for graduate course

[Andrew Lunn]

>> IANAL, but i would want to take a close look at the license agreement
>> before using this software.
>
> Me neither, but put in human words, the license agreement is there to
> ensure 'derived software' (as defined in GPL) stays compatible with
> the (open) EtherCAT standard and assures you won't suffer from patent
> claims in case it does.
>
>> Also, it is GPL, which is probably not what you want.
>
> Who do you mean with 'you'? - IIRC the OP was asking for ideas for projects 
> to be conducted by
> graduate students, so I don't see why they would object agains the GPL.
> - We (FMTC) wrote and open sourced the code
> - As stated on the website, interested companies wishing to use this
>   for closed products can obtain a LGPL version against a license fee.

I mean "you" as in anybody wishing to use eCos and EtherCat. The
problem is that it forces the application to be GPL. Most uses of eCos
are in commercial products. Having eCos use "GPL+exception" is
O.K. because it does not force the application to be
GPL+exception. That is what the exception is for. The application,
which contains all the IP, can remain closed. However once you make
use of this GPL code, your application becomes GPL and you have to
give the sources away. Most people using eCos would not like this.
How many open source eCos applications do you know of?

Close source application then need to use the LGPL version. However,
this i don't understand. Since it is LGPL, what is to stop a customer
buying the LGPL version and then distribute the sources under LGPL? It
seems like to me, if you are selling a version for closed source
applications you would use a closed source license to stop it being
redistributed.

The GPL code is also licensed under another license at the same time
as being GPL. This i don't understand. How can it be GPL and something
else at the same time. This is where i would want copyright lawyers to
take a close look.

     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] Project ideas for graduate course

[Klaas Gadeyne]

Hi Andrew,

On Tue, 31 Jul 2007, Andrew Lunn wrote:
>>> IANAL, but i would want to take a close look at the license agreement
>>> before using this software.
>>
>> Me neither, but put in human words, the license agreement is there to
>> ensure 'derived software' (as defined in GPL) stays compatible with
>> the (open) EtherCAT standard and assures you won't suffer from patent
>> claims in case it does.
>>
>>> Also, it is GPL, which is probably not what you want.
>>
>> Who do you mean with 'you'? - IIRC the OP was asking for ideas for projects
>> to be conducted by
>> graduate students, so I don't see why they would object agains the GPL.
>> - We (FMTC) wrote and open sourced the code
>> - As stated on the website, interested companies wishing to use this
>>   for closed products can obtain a LGPL version against a license fee.
>
> I mean "you" as in anybody wishing to use eCos and EtherCat. The
> problem is that it forces the application to be GPL. Most uses of eCos
> are in commercial products. Having eCos use "GPL+exception" is
> O.K. because it does not force the application to be
> GPL+exception. That is what the exception is for. The application,
> which contains all the IP, can remain closed. However once you make
> use of this GPL code, your application becomes GPL and you have to
> give the sources away. Most people using eCos would not like this.
> How many open source eCos applications do you know of?
>
> Close source application then need to use the LGPL version. However,
> this i don't understand. Since it is LGPL, what is to stop a customer
> buying the LGPL version and then distribute the sources under LGPL? It
> seems like to me, if you are selling a version for closed source
> applications you would use a closed source license to stop it being
> redistributed.

I'm not sure (again :-) what you mean by "customer":
- a customer of FMTC that wants to sell a (closed source) product
   based on eCos + EML pays a licence fee to FMTC, obtains a LGPL
   version of EML and can create a closed source product, right?  If
   they want, they can modify the EML code [Let's call this customer
   CustomerFoo]

   Note: the LGPL version is exactly the same codebase, only provided a
   with a different license.  That code is "in the open" anyway with a
   GPL license, so why would we object against CustomerFoo
   redistributing the code.

- a customer of CustomerFoo buys a closed source product.  That's it.

> The GPL code is also licensed under another license at the same time
> as being GPL. This i don't understand. How can it be GPL and something
> else at the same time. This is where i would want copyright lawyers to
> take a close look.

As I said, IANAL either :-), the exact "wording" from the license
comes from lawyers@beckhoff.  However, as I understand it (and that
was the spirit of the license), you can consider it exactly the same
mechanism as above where you state that eCos is licensed under GPL
_plus_ exception.  EML is GPL (or LGPL) + exception too, and the
exception says that derived code should be compliant with the EtherCAT
standard (in case you distribute/sell it, that is).  So you should
consider the 2 licences as being complementary, not being something
else.

Klaas


-- 
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] Project ideas for graduate course

[Andrew Lunn]

> I'm not sure (again :-) what you mean by "customer":
> - a customer of FMTC that wants to sell a (closed source) product
>   based on eCos + EML pays a licence fee to FMTC, obtains a LGPL
>   version of EML and can create a closed source product, right?  If
>   they want, they can modify the EML code [Let's call this customer
>   CustomerFoo]
>
>   Note: the LGPL version is exactly the same codebase, only provided a
>   with a different license.  That code is "in the open" anyway with a
>   GPL license, so why would we object against CustomerFoo
>   redistributing the code.

Well, anybody can then pick up the LGPL version and avoid paying for
it! The GPL version then becomes redundant. So you might as well
distribute the LGPL version and remove the GPL version.

> - a customer of CustomerFoo buys a closed source product.  That's it.

Nope. Not quite. They buy the closed source produced, but also get a
copy of the sources to the open source parts. eg eCos and the LGPL
EtherCAT source. Plus, since you use the LGPL, you should supply the
customer with the object code files for the closes source parts. The
thing about the LGPL is that you are allowed to modify the LGPL code
and relink it with the none LGPL parts you got in object code form to
rebuild the application. This way, you can bug fix and extend the LGPL
parts.

Also, the customer is allowed to use eCos and the LGPL EtherCAT
themselves, since it is open source. They can distribute it, hack it,
do what they want under the GPL+exception and LGPL. However this is
where we might run into problems. the GPL(+exception) and LGPL is
transferable. The customer has just as many rights as the
distributor. However i suspect that the second license for the
EtherCAT is none transferable.

>> The GPL code is also licensed under another license at the same time
>> as being GPL. This i don't understand. How can it be GPL and something
>> else at the same time. This is where i would want copyright lawyers to
>> take a close look.
>
> As I said, IANAL either :-), the exact "wording" from the license
> comes from lawyers@beckhoff.  However, as I understand it (and that
> was the spirit of the license), you can consider it exactly the same
> mechanism as above where you state that eCos is licensed under GPL
> _plus_ exception.  EML is GPL (or LGPL) + exception too, and the
> exception says that derived code should be compliant with the EtherCAT
> standard (in case you distribute/sell it, that is).  So you should
> consider the 2 licences as being complementary, not being something
> else.

Well the eCos GPL+exception gives the user more rights. This is well
accepted in the community.

The exception for the EtherCAT i think removes rights. I think it
removes the right to redistribute and the right to redistribute is the
core of the (L)GPL licenses. That is one point i would want a
copyright lawyer to look at if i were considering using EtherCAT
sources.

        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

[ECOS] Re: Project ideas for graduate course

[Grant Edwards]

On 2007-07-31, Andrew Lunn <andrew@lunn.ch> wrote:
>>> IANAL, but i would want to take a close look at the license agreement
>>> before using this software.
>>
>> Me neither, but put in human words, the license agreement is there to
>> ensure 'derived software' (as defined in GPL) stays compatible with
>> the (open) EtherCAT standard and assures you won't suffer from patent
>> claims in case it does.
>>
>>> Also, it is GPL, which is probably not what you want.
>>
>> Who do you mean with 'you'? - IIRC the OP was asking for ideas for projects 
>> to be conducted by
>> graduate students, so I don't see why they would object agains the GPL.
>> - We (FMTC) wrote and open sourced the code
>> - As stated on the website, interested companies wishing to use this
>>   for closed products can obtain a LGPL version against a license fee.
>
> I mean "you" as in anybody wishing to use eCos and EtherCat. The
> problem is that it forces the application to be GPL. Most uses of eCos
> are in commercial products. Having eCos use "GPL+exception" is
> O.K. because it does not force the application to be
> GPL+exception. That is what the exception is for. The application,
> which contains all the IP, can remain closed. However once you make
> use of this GPL code, your application becomes GPL and you have to
> give the sources away.

I'm sure Andrew probably knows this, but just to pick a nit:
under the GPL you only have to give the sources away to the
people to whom you distribute the binaries.  Merely "making
use" of GPL'ed code puts you under no obligation to distrubute
source code.  It's the act of distributing the derivitive work
that does so.  Using GPL for an in-house project (e.g. a test
station or module) would place you under no obligation to
distrubute source code to anybody.

> The GPL code is also licensed under another license at the same time
> as being GPL. This i don't understand. How can it be GPL and something
> else at the same time.

I've never seen that claim before, though I've seen plenty of
projects that are available under alternative licenses.

> This is where i would want copyright lawyers to
> take a close look.

-- 
Grant Edwards                   grante             Yow! I like the way ONLY
                                  at               their mouths move ...  They
                               visi.com            look like DYING OYSTERS


-- 
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] Project ideas for graduate course

[Klaas Gadeyne]

On Tue, 31 Jul 2007, Andrew Lunn wrote:
>> I'm not sure (again :-) what you mean by "customer":
>> - a customer of FMTC that wants to sell a (closed source) product
>>   based on eCos + EML pays a licence fee to FMTC, obtains a LGPL
>>   version of EML and can create a closed source product, right?  If
>>   they want, they can modify the EML code [Let's call this customer
>>   CustomerFoo]
>>
>>   Note: the LGPL version is exactly the same codebase, only provided a
>>   with a different license.  That code is "in the open" anyway with a
>>   GPL license, so why would we object against CustomerFoo
>>   redistributing the code.
>
> Well, anybody can then pick up the LGPL version and avoid paying for
> it! The GPL version then becomes redundant. So you might as well
> distribute the LGPL version and remove the GPL version.
>
>> - a customer of CustomerFoo buys a closed source product.  That's it.
>
> Nope. Not quite. They buy the closed source produced, but also get a
> copy of the sources to the open source parts. eg eCos and the LGPL
> EtherCAT source. Plus, since you use the LGPL, you should supply the
> customer with the object code files for the closes source parts. The
> thing about the LGPL is that you are allowed to modify the LGPL code
> and relink it with the none LGPL parts you got in object code form to
> rebuild the application. This way, you can bug fix and extend the LGPL
> parts.

I see, you are right!  This means the LGPL license isn't suited for
that purpose. 
Note that:
- FMTC doesn't consider the EML library as one of its core products,
   that's the main reason we've put the code "out there" with a GPL
   license for free (as in free beer).
- If someone would want to use this in a closed source product (and
   hence make money out of it), the idea is they pay part of the
   development cost to obtain a non-gpl license (but indeed the LGPL
   isn't the license we want there).

> Also, the customer is allowed to use eCos and the LGPL EtherCAT
> themselves, since it is open source. They can distribute it, hack it,
> do what they want under the GPL+exception and LGPL. However this is
> where we might run into problems. the GPL(+exception) and LGPL is
> transferable. The customer has just as many rights as the
> distributor. However i suspect that the second license for the
> EtherCAT is none transferable.
>
>>> The GPL code is also licensed under another license at the same time
>>> as being GPL. This i don't understand. How can it be GPL and something
>>> else at the same time. This is where i would want copyright lawyers to
>>> take a close look.
>>
>> As I said, IANAL either :-), the exact "wording" from the license
>> comes from lawyers@beckhoff.  However, as I understand it (and that
>> was the spirit of the license), you can consider it exactly the same
>> mechanism as above where you state that eCos is licensed under GPL
>> _plus_ exception.  EML is GPL (or LGPL) + exception too, and the
>> exception says that derived code should be compliant with the EtherCAT
>> standard (in case you distribute/sell it, that is).  So you should
>> consider the 2 licences as being complementary, not being something
>> else.
>
> Well the eCos GPL+exception gives the user more rights. This is well
> accepted in the community.
>
> The exception for the EtherCAT i think removes rights. I think it
> removes the right to redistribute and the right to redistribute is the
> core of the (L)GPL licenses. That is one point i would want a
> copyright lawyer to look at if i were considering using EtherCAT
> sources.

It does not remove the right to redistribute (modified code) of EML,
as long as it stays compatible with the (open) EtherCAT standard (which I
think is not so unlogically?)

Klaas




-- 
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] Project ideas for graduate course

[Andrew Lunn]

> It does not remove the right to redistribute (modified code) of EML,
> as long as it stays compatible with the (open) EtherCAT standard (which I
> think is not so unlogically?)

And how does that work? 

Say i was to pay for a license and get the GPL source. I make a
product and sell it, distributing the source, to XYZ. XYZ then hacks
on the source and adds some features. They make a new product. They
sell there product to ABC and again distribute the source. ABC does
some more hacking, breaks compatibility and then sell a product to
FSDS.

Now only i have signed a license. However i have no control over what
people do with the GPL code. When FSDS reports the code is no longer
compatible is my license revoked even though the problem is with ABC
code? Do you take me to court, i have to take XYZ to court and XYZ has
to take ABC to court?

More questions for the copyright lawyers.....

Maybe a better way to do this is to throw away the license
agreement. Instead provide regression test cases which demonstrator
compatibility to the standard. Anybody hacking on the code should be
encouraged to run the regression tests to check they have not broken
anything. If somebody adds new features which comply to the standard,
you should ask they add more regression tests and feed back the
changes to you. You can then independently test the changes are good
and then make a new release. So long as you actively maintain and
support the code, the chances of somebody forking it are low. Now this
is what GPL is all about. And it does work. There is huge amounts of
standards compliant protocol software available under GPL or similar
licenses.

     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] Project ideas for graduate course

[Klaas Gadeyne]

On Wed, 1 Aug 2007, Andrew Lunn wrote:
>> It does not remove the right to redistribute (modified code) of EML,
>> as long as it stays compatible with the (open) EtherCAT standard (which I
>> think is not so unlogically?)
>
> And how does that work?
>
> Say i was to pay for a license and get the GPL source. I make a
> product and sell it, distributing the source, to XYZ. XYZ then hacks
> on the source and adds some features. They make a new product. They
> sell there product to ABC and again distribute the source. ABC does
> some more hacking, breaks compatibility and then sell a product to
> FSDS.
>
> Now only i have signed a license. However i have no control over what
> people do with the GPL code. When FSDS reports the code is no longer
> compatible is my license revoked even though the problem is with ABC
> code? Do you take me to court, i have to take XYZ to court and XYZ has
> to take ABC to court?

The extra clause is (contrary to the GPL or other license) a
non-transferable license, that you only need to sign if you intend to
redistribute the code.  That means that, if you take the code,
alter it and use it internally, you don't even have to sign the
agreement.  If you start redistributing the code (i.e. everyone that
redistributes a modified version of EML), you need to sign the
license agreement that states that your code is conform the standard.

> More questions for the copyright lawyers.....
>
> Maybe a better way to do this is to throw away the license
> agreement. Instead provide regression test cases which demonstrator
> compatibility to the standard. Anybody hacking on the code should be
> encouraged to run the regression tests to check they have not broken
> anything. If somebody adds new features which comply to the standard,
> you should ask they add more regression tests and feed back the
> changes to you. You can then independently test the changes are good
> and then make a new release. So long as you actively maintain and
> support the code, the chances of somebody forking it are low. Now this
> is what GPL is all about. And it does work. There is huge amounts of
> standards compliant protocol software available under GPL or similar
> licenses.

Even _without_ all the license issues that would be a good thing.
However, when we first implemented EML, the EtherCAT people were still
working on conformance testing.
Also note that the extra clause is an agreement between Beckhoff and
the licensee (and FMTC has nothing to do with that agreement), that
"protects" the licensee from patent claims covering the EtherCAT
technology.

Klaas



-- 
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] Project ideas for graduate course

[Andrew Lunn]

> Even _without_ all the license issues that would be a good thing.
> However, when we first implemented EML, the EtherCAT people were still
> working on conformance testing.

Is that now finished? Is it time for version 0.2 of the code with
extra conformance testing?

> Also note that the extra clause is an agreement between Beckhoff and
> the licensee (and FMTC has nothing to do with that agreement), that
> "protects" the licensee from patent claims covering the EtherCAT
> technology.

Maybe GPLv3 is the solution. That includes patent protection as far as
i understand. 

  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] Project ideas for graduate course

[Klaas Gadeyne]

On Wed, 1 Aug 2007, Andrew Lunn wrote:
>> Even _without_ all the license issues that would be a good thing.
>> However, when we first implemented EML, the EtherCAT people were still
>> working on conformance testing.
>
> Is that now finished? Is it time for version 0.2 of the code with
> extra conformance testing?

It's been a while since I've worked on the code, but as far as I
understand from
<http://www.ethercat.org/default.asp?en/conformance.html>, the
conformance "testtool" is a (windows only) tool for testing
conformance of EtherCAT _slave_ devices only (while EML implements a master
device).

>> Also note that the extra clause is an agreement between Beckhoff and
>> the licensee (and FMTC has nothing to do with that agreement), that
>> "protects" the licensee from patent claims covering the EtherCAT
>> technology.
>
> Maybe GPLv3 is the solution. That includes patent protection as far as
> i understand.

I've had a look at it, but I didn't understand it quite wel :-( (IANAL
:-).  The patent protection cases they described seemed to be
referring to companies releasing OSS covered by patents they've
possessed themselves.  And then there is the MS/Novell deal which
might be similar to our case, but
- I don't know what the "mistakes" were MS made while making the deal
   which led to GPLv3
- We don't really have a _deal_ with the people at Beckhoff.

As a IANAL conclusion, and I can only speak for myself: IMO the
intention of the people at Beckhoff is not to hinder (at all) the
spreading of (modified versions) of open source implementations of
EtherCAT master functionality, so one shouldn't be too scared being
sued as long as one (tries to) follow the standard.

Whether the license agreement is the best way to achieve that, I
really don't know (and even less after this thread), but the lawyers
at Beckhoff seem to have thought so...

Anyway, thanks a lot for your comments!

Klaas

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