SMP8634/5 Public License Sourcecode Release Site

[Syabas]

Dear customers,

Sourcecode for open source modules used on the NMT is available for
download from:

http://www.networkedmediatank.com/downlo...pl/gpl.htm

[markg85]

Sorry to say but if you change a GPL source code and use it in a released product (A-100 for example) then you must release the sourcecode you changed otherwise your in gpl violation. Just pointing to the software you use and the license won't do it.

[tux99]

Very true, the published code doesn't seem at all to be enough to fullfill the GPL requirements in my opinion.
I would hate it if Syabas has to spend resources on defending themselves in a costly lawsuit, therefore I urge you to have a look at the following pages and do the necessary to make sure you fully comply with the GPL:

http://gpl-violations.org/faq/vendor-faq.html

http://www.softwarefreedom.org/resources...guide.html

[chris57]

This has been round and round a few times before:-
http://www.networkedmediatank.com/showth...hlight=GPL

Syabas:-

Thanks guys for the feedbacks on open-sourcing the firmware.

Alanh gave the most accurate explanation on the "politics" behind the
reason why only certain portion is released under GPL.

Sigma SDK consist of various GPLed modules and proprietary modules.
The GPLed modules are released to public as this is their obligation
(and ours, being the user of Sigma SDK).

It is this proprietary modules or "mrua" that is not released, which
probably is the most useful portion for most developer.

The reasons, we can only guess is to protect competitive trade
secrets versus other media processor company.
Hardware is probably just 20% of the work by these chipset company
nowadays and most of the work is in the software. They probably don't
want to give it away to the competition.

Sigma is relatively a small company if compared to the likes of
Broadcom, and being so, at least they still support small startups
like Syabas and you can see media player solution based on
Sigma chipset in the market.

Broadcom typically only deals with first-tier customers, so, even
if Syabas developers a middleware solution, it would be hardpressed
for us to make design-win with first-tier customers.

Indeed, from past experience working with Broadcom, they have
a better and easier to use SDK. Still, they are not going about
releasing it under GPL soon, for pretty much the same reason as
Sigma.

From Syabas business model point of view, we are a middleware
company and our bread-n-butter is licensing this to other
manufacturers (mostly Asia Pac nowadays, due to the CE supply
chain already moved there). So, it is tricky if not impossible for
us to run a succesful middleware business by open-sourcing
our middleware, especially some Asia Pac manufacturers have
little respect for IP rights. It is not nice to hear, but that is the truth.

That said, we've tried to be supportive of "User's Developed Apps"
by providing information and occasionally engaging the developers
directly. Some of them have been quite succesful, judging from this
thread, http://www.networkedmediatank.com/viewforum.php?f=13

Sigma is not sitting on their ass either, as they try to migrate from
the proprietary "mrua" APIs to a more open DirectFB based APIs,
however, this is really a work-in-progress.

We believe that DirectFB will open up more possibilities for the
open-source community in the future. So, keep posted :wink:

All these 'i'd hate to see Syabas having to spend money...etc' don't intimate anyone!

[tux99]

(08-26-2008 06:30 AM)chris57 Wrote:  This has been round and round a few times before:-
http://www.networkedmediatank.com/showth...hlight=GPL

Thanks for the pointer I had not seem that thread.

Quote:From Syabas business model point of view, we are a middleware
company and our bread-n-butter is licensing this to other
manufacturers (mostly Asia Pac nowadays, due to the CE supply
chain already moved there). So, it is tricky if not impossible for
us to run a succesful middleware business by open-sourcing
our middleware, especially some Asia Pac manufacturers have
little respect for IP rights. It is not nice to hear, but that is the truth.

I was not referring at all to any original Syabas software but only to the opensource GPL software that Syabas is using on the PCH (which includes any Syabas code that is based on customized GPL'ed software).
For any Syabas code that is derived or based upon GPL licensed code it is a requirement for Syabas to publish their code under the GPL too, this is not a matter of choice, if Syabas didn't do that then they would be themselves one of those "Asia Pac manufacturers [that] have
little respect for IP rights".

Quote:All these 'i'd hate to see Syabas having to spend money...etc' don't intimate anyone!

I had no intention of intimating anyone and I'm in no position to do so, I'm not a lawyer.
I'm just a (mostly) happy user of the PCH, just concerned as several manufacturers of devices that use GPL code (D-Link for example) have been successfully sued for breaching the GPL as they didn't publish all the required code.

[alanh]

Without rehashing too much of what is in the other thread (also worth reading):

- The only GPL code Sigma has actually modified is the Linux kernel itself. Sigma provides source for all of their kernel patches and I/O drivers which I believe fulfills all of Sigma/Syabase's obligations to the GPL (not sure if that link above has that or not - my connection is too slow to test - but it is available on this forum somewhere).
- DirectFB is not GPL thus it permits a binary only hardware layer implementation.
- EMHWLib/MRUA is a library that has been developed by Sigma to interface to their DSP microcode and in-turn provide a consistent interface to user apps (and other libraries that chain off it). It was and is still OS independent with both Linux and Windows CE/XPe interface layers. The Linux kernel interface only places that library in kernel space where things such as manipulating the MIPS remap regs and other operations the kernel would normally protect against can be done quickly and without a task switch. It ONLY uses the ioctl and proc interfaces which were both written long before the Linux kernel itself was GPL'd (i.e. don't apply). And the use of either doesn't qualify it as a 'derived work' in terms of GPL/LGPL. It can alternatively be compiled completely in user-space with the Sigma host CPU porting kit at a significant performance penalty.
- Supporting utilities and libraries which are GPL but not A/V specific (bash, busybox, uCLibc, etc) have not been modified for use from their original form and have been redistributed intact with their supporting GPL license declarations by Sigma.
- There seems to be a common misconception by some that the mere use of 'the Linux kernel' in an embedded system means everything else in that embedded system falls under the GPL. It does not anymore than any other enterprise company providing PC based application software solutions for other markets based on Ubuntu, Fedora, RHEL, etc. distributions. And just because something is a kernel module and runs at ring 0 doesn't make it GPL either (there are much much much bigger fish to try if that were the case).

It frustrates me as well as a smp8634 based product developer that the open-source community isn't acknowledged more. However after looking at the situation from both sides much of the blame falls directly on the open-source community itself for not providing a hardware abstraction layer that the vendors can conform too. Linux DVB, Video4Linux, ALSA, and others fit the bill nicely but the authors all GPL'd them making it impossible for Broadcom, Sigma, ST, and the other extremely competitive developers in that market to cooperate. It just seems everyone wants a world of ATIs! /shrug

If you really want to help Sigma, Syabase, and others help you, develop a parallel open-source non-GPL'd Video4Linux-'like' project for all these new nextgen A/V ASICs. I'll be more than happy to help define the interface and write and maintain the smp8634 hardware implementation! That model has worked well with nVidia/Linux and it can work here too.

[journey4712]

While not related to the politics, It seems the open source released code needs to be updated, specifically with transmission.

Transmission 1.22 as released in the firmware is not a direct compile of the available source code, but has been patched to support running a user specified script(unrar.sh). The patch applied(at a minimum) or the full post-patch source should be made available from syabas. As it stands right now i cannot compile a version of transmission 1.22 that will work like the one distributed with the firmware.


journey

[nprnncbl]

(08-28-2008 05:46 AM)alanh Wrote:  Linux DVB, Video4Linux, ALSA, and others fit the bill nicely but the authors all GPL'd them making it impossible for Broadcom, Sigma, ST, and the other extremely competitive developers in that market to cooperate.

I don't mean to cross-post, but I don't think that the GPL precludes interoperability here. For ALSA at least, and possibly for DVB and V4L (though I haven't checked), you can release a binary-only module-- you just can't develop it by using the GPL source code, and ALSA won't include it in their releases or support it.

In my brief searching, it seems V4L may have a stance similar to ALSA regarding binary modules (unsupported, but not prevented), while it appears DVB developers may be actively hostile to the idea.

[Trollslayer]

(08-28-2008 05:46 AM)alanh Wrote:  Without rehashing too much of what is in the other thread (also worth reading):

- The only GPL code Sigma has actually modified is the Linux kernel itself. Sigma provides source for all of their kernel patches and I/O drivers which I believe fulfills all of Sigma/Syabase's obligations to the GPL (not sure if that link above has that or not - my connection is too slow to test - but it is available on this forum somewhere).
- DirectFB is not GPL thus it permits a binary only hardware layer implementation.
- EMHWLib/MRUA is a library that has been developed by Sigma to interface to their DSP microcode and in-turn provide a consistent interface to user apps (and other libraries that chain off it). It was and is still OS independent with both Linux and Windows CE/XPe interface layers. The Linux kernel interface only places that library in kernel space where things such as manipulating the MIPS remap regs and other operations the kernel would normally protect against can be done quickly and without a task switch. It ONLY uses the ioctl and proc interfaces which were both written long before the Linux kernel itself was GPL'd (i.e. don't apply). And the use of either doesn't qualify it as a 'derived work' in terms of GPL/LGPL. It can alternatively be compiled completely in user-space with the Sigma host CPU porting kit at a significant performance penalty.
- Supporting utilities and libraries which are GPL but not A/V specific (bash, busybox, uCLibc, etc) have not been modified for use from their original form and have been redistributed intact with their supporting GPL license declarations by Sigma.
- There seems to be a common misconception by some that the mere use of 'the Linux kernel' in an embedded system means everything else in that embedded system falls under the GPL. It does not anymore than any other enterprise company providing PC based application software solutions for other markets based on Ubuntu, Fedora, RHEL, etc. distributions. And just because something is a kernel module and runs at ring 0 doesn't make it GPL either (there are much much much bigger fish to try if that were the case).

It frustrates me as well as a smp8634 based product developer that the open-source community isn't acknowledged more. However after looking at the situation from both sides much of the blame falls directly on the open-source community itself for not providing a hardware abstraction layer that the vendors can conform too. Linux DVB, Video4Linux, ALSA, and others fit the bill nicely but the authors all GPL'd them making it impossible for Broadcom, Sigma, ST, and the other extremely competitive developers in that market to cooperate. It just seems everyone wants a world of ATIs! /shrug

If you really want to help Sigma, Syabase, and others help you, develop a parallel open-source non-GPL'd Video4Linux-'like' project for all these new nextgen A/V ASICs. I'll be more than happy to help define the interface and write and maintain the smp8634 hardware implementation! That model has worked well with nVidia/Linux and it can work here too.

Unfortunately providing data to create open sourcing to the levels required would allow competitors to see some of the tradeoffs and optimisations used (and possibly more) so on video silicon this is very unlikely.

[stephenhoinhk]

Can we also have the zd1211 and rt2880 module modified source code?

[grok]

(12-02-2008 04:26 PM)Trollslayer Wrote:  Unfortunately providing data to create open sourcing to the levels required would allow competitors to see some of the tradeoffs and optimisations used (and possibly more) so on video silicon this is very unlikely.

Your point being? If one is worried about opensourcing the code "to the levels required" they shouldn't use GPL stuff anyway.

It's clear cut. You're either GPL compliant or not. In later case your right to use or distribute GPL-licensed software is terminated.

As a customer I really hope Syabas is in compliance. The opposite could get really nasty both for the company and its customers.

There is however a misconception (mentioned multiple times all over this forum and "the tinternet" in general) that just using GPL code making your entire product GPL. This is not true. What worries me is that the contents of Syabas' gpl.html page are not updated as often as the firmware is released and GPL does require that "source used to compile the exact binary" as well as "all the compilation scripts used to build it" are released. I haven't looked into the published tarballs, but I doubt I would be able to build NMT firmware image with that.

This problem has been further addressed by GPLv3. One of the projects that have been relicensed to GPLv3 is Samba. How does that comply with anti-tivoisation letter of GPLv3? Not sure, IANAL, but it's something Syabas should consult a lawyer about, just to be on the safe side.

Regards,
--
grok

---

Hi journey4712,

(08-28-2008 09:54 AM)journey4712 Wrote:  As it stands right now i cannot compile a version of transmission 1.22 that will work like the one distributed with the firmware.

That's a GPL violation, I'm afraid

---

(08-26-2008 06:30 AM)chris57 Wrote:  thread, http://www.networkedmediatank.com/viewforum.php?f=13

This link is dead. Can anyone update it?

[alanh]

I hate to call Syabas/Sigma out on this, especially after defending them in the first round of the debate..... BUT, #1 the GPL compliance page needs to be updated with the C-200 code, #2 the kernel package needs to have Sigma's applied patches and not just the stock Linux kernel distribution file, #4 there are several packages not listed on the GPL page that should be as they are distributed in binary form with the product, and #5 there is insufficient documentation supplied with the product concerning it's use of open source software and the terms of license. I'm not saying they have to give any of the SDK code, but the foundation driver patches to the kernel are certainly covered under GPL.

Syabas' is now 1 month past due on compliance. I'll give em another before bringing it to the attention of the FSF.

[lundman]

I could do with a copy of the kernel for fuse. I can do it without it, but it would be easier.

[Syabas]

New GPL site, http://www.syabas.com/gpl