[Samsung Indulge] How Samsung is continuing to violate the GPL!
The Kernel Source Saga aka How Samsung Is Continuing to Violate the GPL
As you are all aware, there are still no custom kernels or any functioning custom recoveries for this fine (despite its flaws) device - the Samsung Galaxy Indulge (specifically, the SCH-R910). We'd love to be able to say that's not the case, but it is - and will continue to be, for as long as the issues outlined below continue. Samsung has left us not just in the lurch, but completely screwed - whether it is simple incompetence, disregard for the prepaid device community, interference by MetroPCS, or flat-out malice, the outcome is the same.
The problem here is not that Samsung has not published some sort of source package. They have done at least that - enough to keep most observers happy. However, this package was broken from the start. The first package that Samsung published for the R910 included a badly-broken netfilter, which stumped our kernel experts for a good while before the decision was made to simply substitute the three pieces of netfilter from another device.
Doing this allowed our kernel developers (and myself) to compile a kernel, linked with a clean initramfs extracted from the stock kernel. In a properly-released source package, this should be enough - but it wasn't. These kernel attempts would appear to boot, but about 10-15s after completion of the boot animation, would die completely. The LTE and CDMA baseband versions, in About Phone, would display as Unknown, if one could get there quickly enough.
Three of the top Epic kernel developers, myself, and a long-time Android veteran analyzed kmsg logs (see below) and other factors, and determined that it was impossible to generate what is in the stock binary blob from the source package published by Samsung.
Warning: technical details! The following IRC log summarizes the issue:
[10:29] <@k0nane> The kernel now builds successfully - no more errors in netfilter, out of the box - but with the stock initramfs, it will exhibit the same behavior as previous builds. After boot, it will shut down within 10-15s. If there is time to get to About Phone, it will show the baseband versions as CDMA: unknown and LTE: unknown.
[10:30] <@k0nane> The modules that are built, which is not the complete set as in the stock initramfs, are /significantly/ larger than the stock copies and cannot be put in a kernel build as even with LZMA compression it will be far too large to fit in bml8.
[10:31] <@k0nane> So as before, if the solution is to use the (again, incomplete) newly-compiled modules, it's no solution at all. Thus there is still no way to build a kernel identical to the stock build.
[see logs below]
[10:36] <@k0nane> Expert analysis caught one of the anomalies:
[10:36] <@k0nane> <@Decad3nce> DRockstar: <4>[ 6.042947] [MULTIPDP][poll_thread] dpram_open failed!!
[10:36] <@k0nane> <@Decad3nce> probe never goes through
[10:36] <@k0nane> <@Decad3nce> and you fails
[10:36] <@k0nane> <@Decad3nce> :x
[10:36] <@k0nane> <@Decad3nce> what should happen (from start)
[10:36] <@k0nane> <@Decad3nce> <4>[ 6.275749] [MULTIPDP] dpram_open successd !!!!
[10:36] <@k0nane> <@Decad3nce> <3>[ 6.275770] [IDPRAM] <dpram_tty_ioctl:1718> IOCTL cmd = 0x5405
[10:36] <@k0nane> <@Decad3nce> <3>[ 6.280198] [IDPRAM] <dpram_tty_ioctl:1718> IOCTL cmd = 0x540
[10:36] <@k0nane> <@Decad3nce> which triggers phone active
[10:36] <@k0nane> <@Decad3nce> <3>[ 6.757528] [IDPRAM] <phone_active_irq_handler:2195> PHONE_ACTIVE level: LOW , phone_sync: 0
[10:36] <@k0nane> <@Decad3nce> then you have your power on, etc
[10:36] <@k0nane> <@Decad3nce> 3>[ 9.870551] [IDPRAM] dpram_phone_power_on() ...
[10:36] <@k0nane> <@Decad3nce> <3>[ 10.450069] [IDPRAM] <phone_active_irq_handler:2195> PHONE_ACTIVE level: LOW , phone_sync: 0
[10:36] <@k0nane> <@Decad3nce> <3>[ 10.457065] [IDPRAM] <phone_active_irq_handler:2195> PHONE_ACTIVE level: HIGH, phone_sync: 0
[10:36] <@k0nane> <@Decad3nce> also, not sure what this is
[10:36] <@k0nane> <@Decad3nce> <4>[ 6.042931] [MULTIPDP]filp_open() failed~!: -6
[10:36] <@k0nane> <@Decad3nce> doesn't occur in your goodlog
[10:36] <@k0nane> <@DRockstar> hmm, what could prevent the probe?
[10:36] <@k0nane> <@Decad3nce> the dpram_open failing
[10:37] <@k0nane> And to summarize that, "so from boot, goes through kernel init, then device init, then when it gets to the radio interface layer.. it dies a horrible death because of no access to dpram0"
[10:37] <@k0nane> The details should be unimportant, however, if what's provided is identical to/can produce stock (which, as we see, it cannot).
[10:39] <@k0nane> <== a comparison of stock (left) vs. compiled (right) module sizes
Source and initramfs as of these logs:
What Has Samsung Done?
I have been in contact with SamsungJohn (John Imah), Samsung's official developer representative on Twitter. On first notification of the issue, no action had been taken, and it took an RT campaign to catch Mr. Imah's eye. Approximately one week later, Mr. Imah joined me in IRC, and took note of the information above. Shortly after that, Samsung released a new source package on opensource.samsung.com. That was great - except that the only difference was an end to the out-of-the-box compile errors. Everything else about this source package was identical. The results were the same.
Within the next business day, Mr. Imah requested that I send the information to his corporate email address, as he had an "HQ team" there with him. Unfortunately, that was June 22. Mr. Imah has not responded to tweets or DMs since then, and we have been given absolutely no indication that any work has been done on this issue. The source package has not been updated again.
I have given Samsung ample notification and time to work with myself and my fellow developers to resolve this issue without a public expose. They have failed to so much as maintain the appearance of progress, let alone make any. It was, is, time for the saga to end. Samsung is hereby on notice. They, by failing to provide the source necessary to generate what is included in the stock kernel binary, are violating the General Public License.
Originally Posted by http://www.gnu.org/copyleft/gpl.html
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
- a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
- b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
- c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
- d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
- e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
How Can You Help?
Tweet, email, and otherwise contact every public-facing Samsung representative.
Tell your friends. Have them do the same.
Send a copy of this report to - the source in question is the Linux kernel, which is owned by the Free Software Foundation.
Just spread the word - until Samsung feels the heat from this (feel free to contact their legal department!) we will not see results. Development for the Indulge will continue to be held back. Only the users will suffer.