7 replies to this topic

[ZTE_SeanJacko]

Hi all

sej7278 asked "Is this the actual code and .config that was used to build the MonteCarlo/Skate/Staraddict? As this appears to be 2.6.32 with some .35 added on top and a .config (from January) that doesn't actually seem to build"

The official response is:

"The code and .config supplied is the exact code used to build the Monte Carlo. ZTE engineers handle the new configuration by merging rather than overwriting - this could explain why the modification time of the .config is January."

[ZTE_SeanJacko]

Hi all

fibblesan asked why do ZTE keep releasing code that doesn't match the kernel in the device (older code, for example). Code released for the Blade in the past has been several revisions older than a stock device. For example kernels built with the source have lag issues which do not show in stock ZTE ROMs.

The official response is:

The code released for the Skate is completely up to date. Often source code is built upon in order to optimize performance and help control cost - this optimized code is not the source code rather than the stock device code. It is not practicable to release code every time ZTE optimizes an element or changes it for an operator or a market. But ZTE always releases the appropriate source.

[ZTE_SeanJacko]

Hi all

fibblesan asked why do ZTE provide code that either doesn't build cleanly or doesn't build at all?

Here's the official response:

The source code released is the code that ZTE used to build the Skate. After extensive testing the Skate is very robust.

[flibblesan]

I merged the three threads together to make things a little tidier.

[t0mm13b]

I don't understand those responses.... does not make sense at all....

[unrandomsam]

ZTE_SeanJacko, on 23 September 2011 - 03:51 PM, said:

Hi all

fibblesan asked why do ZTE keep releasing code that doesn't match the kernel in the device (older code, for example). Code released for the Blade in the past has been several revisions older than a stock device. For example kernels built with the source have lag issues which do not show in stock ZTE ROMs.

The official response is:

The code released for the Skate is completely up to date. Often source code is built upon in order to optimize performance and help control cost - this optimized code is not the source code rather than the stock device code. It is not practicable to release code every time ZTE optimizes an element or changes it for an operator or a market. But ZTE always releases the appropriate source.

From the GPL FAQCan I put the binaries on my   Internet server and put the source on a different Internet   site?Yes.  Section 6(d) allows this.  However, you must provide     clear instructions people can follow to obtain the source, and you     must take care to make sure that the source remains available for     as long as you distribute the object code.

I want to distribute an extended   version of a GPL-covered program in binary form.  Is it enough to   distribute the source for the original version?No, you must supply the source code that corresponds to the binary. Corresponding source means the source from which users can rebuild the same binary.

  Part of the idea of free software is that users should have access to the source code for *the programs they use*.  Those using your version should have access to the source code for your version.

  A major goal of the GPL is to build up the Free World by making sure that improvement to a free program are themselves free.  If you release an improved version of a GPL-covered program, you must release the improved source code under the GPL.

I want to distribute   binaries, but distributing complete source is inconvenient.  Is it ok if   I give users the diffs from the “standard” version along with   the binaries?This is a well-meaning request, but this method of providing the source doesn't really do the job.

  A user that wants the source a year from now may be unable to get the proper version from another site at that time.  The standard distribution site may have a newer version, but the same diffs probably won't work with that version.

  So you need to provide complete sources, not just diffs, with the binaries.

Can I make binaries available   on a network server, but send sources only to people who order   them?If you make object code available on a network server, you have     to provide the Corresponding Source on a network server as well.     The easiest way to do this would be to publish them on the same     server, but if you'd like, you can alternatively provide     instructions for getting the source from another server, or even a     version control system.  No matter what     you do, the source should be just as easy to access as the object     code, though.  This is all specified in section 6(d) of GPLv3.

  The sources you provide must correspond exactly to the binaries. In particular, you must make sure they are for the same version of the program—not an older version and not a newer version.

(Emphasis mine).


ZTE's GPL compliance is a mockery of the license.

"The code released for the Skate is completely up to date. Often source  code is built upon in order to optimize performance and help control  cost - this optimized code is not the source code rather than the stock  device code. It is not practicable to release code every time ZTE  optimizes an element or changes it for an operator or a market. But ZTE  always releases the appropriate source." is total garbage each GPL component should be provided exactly as distributed. (Just tar up the build directory and upload it to the same place).

The skate source is definately incomplete also (I suspect because of broadcom netfilter changes some files are not supplied in that case the binaries are not redistributable - kernel modules are a grey area but source patches (to the kernel are not).

And its not just the kernel that is GPL'ed

If you look at e.g what Motorola does

e.g

http://sourceforge.n...motorola/files/

or

http://sourceforge.n...motorola/files/

At least they make an effort to provide at least all of the GPL components for the major releases.

bluez etc is also GPL'ed and they is also LGPL'ed libraries that need to be redistributed (e.g glib) and also your object to allow linking with a newer version of glib.

(I really don't see the difficulty of uploading the source to the same place the binaries are - doesn't even have to be easy to use).

Or just provide an external read only mirror of your kernel subversion (Or set it to build dated tarballs).

Perhaps half an hours work.

[sej7278]

t0mm13b, on 23 September 2011 - 05:17 PM, said:

I don't understand those responses.... does not make sense at all....

that's because they're all BS

[t0mm13b]

sej7278, on 28 September 2011 - 09:06 PM, said:

that's because they're all BS

Yeah, of course, its total wacko and crazy.

For such a corporation with loads of money through profit by way of the community here, through the little people like you and me, with our word-of-mouth campaign, to their friends, relatives and families a lá "The Blade is kick-ass, hacker friendly" etc and to be treated like sh!t.

Its as if telling us to shut-up and take the code that is half baked and not work 100% properly and making a flagrant mockery of the legalities surrounding open-source and GPL.

In fairness, they as in ZTE, should be down on their knees, giving the community a nice big wet slobbery kiss on our backsides for them to tweet about "handset sales exceeded their expectations" and also that made their sales/profit enjoyable.