[Tfug] GPL Worthless?

Bexley Hall bexley401 at yahoo.com
Sat Sep 8 21:12:04 MST 2012


Hi John,

--- On Sat, 9/8/12, John Hubbard <ender8282 at yahoo.com> wrote:

> > E.g., I chased down the first link at the first link that you
> > posted -- the most recent source for the kindle fire
> > (Kindle_src_6.3.1_user_4107720.tar.gz).  In the tarball, I found
> > ~150 images for which the sources are not available.
> 
> By images to you mean compiled binaries?  If so could
> you be more specific.  On a cursory search I found
> hundreds of compiled binaries:
> e.g. ./tools/busybox/init/mesg.o: ELF 32-bit LSB
> relocatable, ARM, version 1 (SYSV), not stripped
> but all of the ones that I bothered to look at had a
> corresponding ".c" file.  I certainly didn't check them
> all but the handful that I did seemed OK.

No, those are "objects".  I'm talking about *images* (i.e.,
complete "programs" presented as "pure data"):

kernel/android-2.6.35/firmware/atmsar11.HEX
kernel/android-2.6.35/firmware/bnx2x-e1-5.2.13.0.fw.ihex
kernel/android-2.6.35/firmware/bnx2x-e1h-5.2.13.0.fw.ihex
kernel/android-2.6.35/firmware/intelliport2.bin.ihex
kernel/android-2.6.35/firmware/mts_cdma.fw.ihex
kernel/android-2.6.35/firmware/mts_edge.fw.ihex
kernel/android-2.6.35/firmware/mts_gsm.fw.ihex
kernel/android-2.6.35/firmware/ti_3410.fw.ihex
kernel/android-2.6.35/firmware/ti_5052.fw.ihex
kernel/android-2.6.35/firmware/tr_smctr.bin.ihex
kernel/android-2.6.35/firmware/whiteheat.HEX
kernel/android-2.6.35/firmware/whiteheat_loader.HEX
kernel/android-2.6.35/firmware/whiteheat_loader_debug.HEX
kernel/android-2.6.35/firmware/3com/3C359.bin.ihex
kernel/android-2.6.35/firmware/3com/typhoon.bin.ihex
kernel/android-2.6.35/firmware/acenic/tg1.bin.ihex
kernel/android-2.6.35/firmware/acenic/tg2.bin.ihex
kernel/android-2.6.35/firmware/adaptec/starfire_rx.bin.ihex
kernel/android-2.6.35/firmware/adaptec/starfire_tx.bin.ihex
kernel/android-2.6.35/firmware/advansys/3550.bin.ihex
kernel/android-2.6.35/firmware/advansys/38C0800.bin.ihex
kernel/android-2.6.35/firmware/advansys/38C1600.bin.ihex
kernel/android-2.6.35/firmware/advansys/mcode.bin.ihex
kernel/android-2.6.35/firmware/av7110/bootcode.bin.ihex
kernel/android-2.6.35/firmware/bnx2/bnx2-mips-06-5.0.0.j6.fw.ihex
kernel/android-2.6.35/firmware/bnx2/bnx2-mips-09-5.0.0.j15.fw.ihex
kernel/android-2.6.35/firmware/bnx2/bnx2-rv2p-06-5.0.0.j3.fw.ihex
kernel/android-2.6.35/firmware/bnx2/bnx2-rv2p-09-5.0.0.j10.fw.ihex
kernel/android-2.6.35/firmware/bnx2/bnx2-rv2p-09ax-5.0.0.j10.fw.ihex
kernel/android-2.6.35/firmware/cis/3CCFEM556.cis.ihex
kernel/android-2.6.35/firmware/cis/3CXEM556.cis.ihex
kernel/android-2.6.35/firmware/cis/COMpad2.cis.ihex
kernel/android-2.6.35/firmware/cis/COMpad4.cis.ihex
kernel/android-2.6.35/firmware/cis/DP83903.cis.ihex
kernel/android-2.6.35/firmware/cis/LA-PCM.cis.ihex
kernel/android-2.6.35/firmware/cis/MT5634ZLX.cis.ihex
kernel/android-2.6.35/firmware/cis/NE2K.cis.ihex
kernel/android-2.6.35/firmware/cis/PCMLM28.cis.ihex
kernel/android-2.6.35/firmware/cis/PE-200.cis.ihex
kernel/android-2.6.35/firmware/cis/PE520.cis.ihex
kernel/android-2.6.35/firmware/cis/RS-COM-2P.cis.ihex
kernel/android-2.6.35/firmware/cis/SW_555_SER.cis.ihex
kernel/android-2.6.35/firmware/cis/SW_7xx_SER.cis.ihex
kernel/android-2.6.35/firmware/cis/SW_8xx_SER.cis.ihex
kernel/android-2.6.35/firmware/cis/tamarack.cis.ihex
kernel/android-2.6.35/firmware/cpia2/stv0672_vp4.bin.ihex
kernel/android-2.6.35/firmware/cxgb3/ael2005_opt_edc.bin.ihex
kernel/android-2.6.35/firmware/cxgb3/ael2005_twx_edc.bin.ihex
kernel/android-2.6.35/firmware/cxgb3/ael2020_twx_edc.bin.ihex
kernel/android-2.6.35/firmware/cxgb3/t3b_psram-1.1.0.bin.ihex
kernel/android-2.6.35/firmware/cxgb3/t3c_psram-1.1.0.bin.ihex
kernel/android-2.6.35/firmware/cxgb3/t3fw-7.4.0.bin.ihex
kernel/android-2.6.35/firmware/dabusb/bitstream.bin.ihex
kernel/android-2.6.35/firmware/dabusb/firmware.HEX
kernel/android-2.6.35/firmware/dsp56k/bootstrap.bin.ihex
kernel/android-2.6.35/firmware/e100/d101m_ucode.bin.ihex
kernel/android-2.6.35/firmware/e100/d101s_ucode.bin.ihex
kernel/android-2.6.35/firmware/e100/d102e_ucode.bin.ihex
kernel/android-2.6.35/firmware/edgeport/boot.H16
kernel/android-2.6.35/firmware/edgeport/boot2.H16
kernel/android-2.6.35/firmware/edgeport/down.H16
kernel/android-2.6.35/firmware/edgeport/down2.H16
kernel/android-2.6.35/firmware/edgeport/down3.bin.ihex
kernel/android-2.6.35/firmware/emi26/bitstream.HEX
kernel/android-2.6.35/firmware/emi26/firmware.HEX
kernel/android-2.6.35/firmware/emi26/loader.HEX
kernel/android-2.6.35/firmware/emi62/bitstream.HEX
kernel/android-2.6.35/firmware/emi62/loader.HEX
kernel/android-2.6.35/firmware/emi62/midi.HEX
kernel/android-2.6.35/firmware/emi62/spdif.HEX
kernel/android-2.6.35/firmware/ess/maestro3_assp_kernel.fw.ihex
kernel/android-2.6.35/firmware/ess/maestro3_assp_minisrc.fw.ihex
kernel/android-2.6.35/firmware/kaweth/new_code.bin.ihex
kernel/android-2.6.35/firmware/kaweth/new_code_fix.bin.ihex
kernel/android-2.6.35/firmware/kaweth/trigger_code.bin.ihex
kernel/android-2.6.35/firmware/kaweth/trigger_code_fix.bin.ihex
kernel/android-2.6.35/firmware/keyspan/mpr.HEX
kernel/android-2.6.35/firmware/keyspan/usa18x.HEX
kernel/android-2.6.35/firmware/keyspan/usa19.HEX
kernel/android-2.6.35/firmware/keyspan/usa19qi.HEX
kernel/android-2.6.35/firmware/keyspan/usa19qw.HEX
kernel/android-2.6.35/firmware/keyspan/usa19w.HEX
kernel/android-2.6.35/firmware/keyspan/usa28.HEX
kernel/android-2.6.35/firmware/keyspan/usa28x.HEX
kernel/android-2.6.35/firmware/keyspan/usa28xa.HEX
kernel/android-2.6.35/firmware/keyspan/usa28xb.HEX
kernel/android-2.6.35/firmware/keyspan/usa49w.HEX
kernel/android-2.6.35/firmware/keyspan/usa49wlc.HEX
kernel/android-2.6.35/firmware/keyspan_pda/keyspan_pda.HEX
kernel/android-2.6.35/firmware/keyspan_pda/xircom_pgs.HEX
kernel/android-2.6.35/firmware/korg/k1212.dsp.ihex
kernel/android-2.6.35/firmware/matrox/g200_warp.H16
kernel/android-2.6.35/firmware/matrox/g400_warp.H16
kernel/android-2.6.35/firmware/myricom/lanai.bin.ihex
kernel/android-2.6.35/firmware/ositech/Xilinx7OD.bin.ihex
kernel/android-2.6.35/firmware/qlogic/1040.bin.ihex
kernel/android-2.6.35/firmware/qlogic/12160.bin.ihex
kernel/android-2.6.35/firmware/qlogic/1280.bin.ihex
kernel/android-2.6.35/firmware/qlogic/isp1000.bin.ihex
kernel/android-2.6.35/firmware/qlogic/sd7220.fw.ihex
kernel/android-2.6.35/firmware/r128/r128_cce.bin.ihex
kernel/android-2.6.35/firmware/radeon/R100_cp.bin.ihex
kernel/android-2.6.35/firmware/radeon/R200_cp.bin.ihex
kernel/android-2.6.35/firmware/radeon/R300_cp.bin.ihex
kernel/android-2.6.35/firmware/radeon/R420_cp.bin.ihex
kernel/android-2.6.35/firmware/radeon/R520_cp.bin.ihex
kernel/android-2.6.35/firmware/radeon/R600_me.bin.ihex
kernel/android-2.6.35/firmware/radeon/R600_pfp.bin.ihex
kernel/android-2.6.35/firmware/radeon/RS600_cp.bin.ihex
kernel/android-2.6.35/firmware/radeon/RS690_cp.bin.ihex
kernel/android-2.6.35/firmware/radeon/RS780_me.bin.ihex
kernel/android-2.6.35/firmware/radeon/RS780_pfp.bin.ihex
kernel/android-2.6.35/firmware/radeon/RV610_me.bin.ihex
kernel/android-2.6.35/firmware/radeon/RV610_pfp.bin.ihex
kernel/android-2.6.35/firmware/radeon/RV620_me.bin.ihex
kernel/android-2.6.35/firmware/radeon/RV620_pfp.bin.ihex
kernel/android-2.6.35/firmware/radeon/RV630_me.bin.ihex
kernel/android-2.6.35/firmware/radeon/RV630_pfp.bin.ihex
kernel/android-2.6.35/firmware/radeon/RV635_me.bin.ihex
kernel/android-2.6.35/firmware/radeon/RV635_pfp.bin.ihex
kernel/android-2.6.35/firmware/radeon/RV670_me.bin.ihex
kernel/android-2.6.35/firmware/radeon/RV670_pfp.bin.ihex
kernel/android-2.6.35/firmware/radeon/RV710_me.bin.ihex
kernel/android-2.6.35/firmware/radeon/RV710_pfp.bin.ihex
kernel/android-2.6.35/firmware/radeon/RV730_me.bin.ihex
kernel/android-2.6.35/firmware/radeon/RV730_pfp.bin.ihex
kernel/android-2.6.35/firmware/radeon/RV770_me.bin.ihex
kernel/android-2.6.35/firmware/radeon/RV770_pfp.bin.ihex
kernel/android-2.6.35/firmware/sb16/alaw_main.csp.ihex
kernel/android-2.6.35/firmware/sb16/ima_adpcm_capture.csp.ihex
kernel/android-2.6.35/firmware/sb16/ima_adpcm_init.csp.ihex
kernel/android-2.6.35/firmware/sb16/ima_adpcm_playback.csp.ihex
kernel/android-2.6.35/firmware/sb16/mulaw_main.csp.ihex
kernel/android-2.6.35/firmware/sun/cassini.bin.ihex
kernel/android-2.6.35/firmware/tehuti/bdx.bin.ihex
kernel/android-2.6.35/firmware/tigon/tg3.bin.ihex
kernel/android-2.6.35/firmware/tigon/tg3_tso.bin.ihex
kernel/android-2.6.35/firmware/tigon/tg3_tso5.bin.ihex
kernel/android-2.6.35/firmware/ttusb-budget/dspbootcode.bin.ihex
kernel/android-2.6.35/firmware/vicam/firmware.H16
kernel/android-2.6.35/firmware/yam/1200.bin.ihex
kernel/android-2.6.35/firmware/yam/9600.bin.ihex
kernel/android-2.6.35/firmware/yamaha/ds1e_ctrl.fw.ihex
kernel/android-2.6.35/firmware/yamaha/ds1_ctrl.fw.ihex
kernel/android-2.6.35/firmware/yamaha/ds1_dsp.fw.ihex
kernel/android-2.6.35/firmware/yamaha/yss225_registers.bin.ihex

A cursory glance suggests most of these are in Intel Hex format
(makes sense as file extension is ihex!)

Taking just the first of these (arbitrarily), where are the
sources for kernel/android-2.6.35/firmware/atmsar11.HEX?
Do we even know what the sources are written in?  Are they
Verilog/VHDL files?  C?  Some particular assembler?  Or, even
some proprietary bit format to drive a custom controller or
processor??
 
> > Nor the (proprietary) tools that one would use to build those
> > sources.
> 
> They don't have to distribute their build
> infrastructure.  All that they have to distribute is
> the source.  Look at Red Hat Enterprise Linux.
> CentOS/Scientific Linux build the rhel source, but I don't
> believe that it is as simple as doing
> wget rhel6.3-src.tgz
> tar -xzv rhel6.3-src.tgz
> cd rhel6.3
> make
> it takes them a while to get things building after a new
> major release goes up.  I doubt that RH wants it to be
> too easy since they are making money selling RHEL (or is
> their product support).

No, you've missed the point.

*If* we knew what the sources for the image file
kernel/android-2.6.35/firmware/atmsar11.HEX were written in
and had access to them, how would we modify those sources
and convert them into a *new* image file (MY_atmsar11.hex)?
Are those tools even available to John Q Public, *anywhere*?

How can I figure out what *needs* to be changed in that
image file if I can't see what it represents?   How can I
instantiate those changes if I can't get the tools to
*create* it?

> It isn't in the big companies interest to make it too easy
> for anyone to reproduce their work.  They are trying to
> SELL something and don't want to give away more than they
> have to.  That doesn't stop CentOS/SL from building the
> RHEL source, and giving away the binaries.

The GPL's goal isn't to allow you to *reproduce* their
work but, rather, to allow you to *modify* their work!
It's easy to reproduce what they have done.  But, with
*only* the above, it is impossible to *modify* their work!
 
> I'm sorry if the big companies only goal isn't to make your
> life easy.  They are trying to sell a product. 

Sure!  And are saving several hundreds of thousands of dollars
of development and maintenance costs!  The GPL says, "in
return, you will provide these same advantages to those who
come *after* you" (in the development chain)

> For the vast majority of the population that product
> (software or software+hardware) is a black box.  For a
> few people, the insides of the box can be examined.  In
> some cases even modified.  Be happy that you can even
> look inside of the box.  Thank the GPL for that. 

Other licenses let you look inside the box.  Even *commercial*
(fee based) ones!

> The fact that you are even discussing the ability to
> view/modify source is a result of the GPL being used for the
> Linux Kernel, and the original GNU tools and countless other
> projects.

Free licenses existed long before the GPL came along.
 
> > [How many of those are specific to *just* the Kindle Fire is unknown
> > as there is nothing that tells me what the Fire uses -- I'm not
> > going to wade through a hierarchy of Makefiles just to see]
> > 
> > How do I reap the benefits the GPL intends for me if it *legally*
> > allows this much functionality to be locked away from me?  That
> > I can neither inspect, repair or enhance??
> 
> Not true.  You can write makes files, and/or create
> your own proprietary build system.  Additionally you
> can take all of the GPL code, and install it on different
> hardware and write your own firmware to replace that
> provided.  You still have all of the benefits that the
> GPL provides.  You might wish that the GPL made them
> give you something that you could trivially tweak and bend
> to your will but it doesn't.  It encourages that, but
> it doesn't require that.  OTOH upstream shouldn't have
> much trouble comparing their derived source with the
> original and incorporating it if they so choose.

Again, you've missed the point.  If some *considerable*
functionality is hidden inside a black box *under* the GPL'd
code, then the GPL doesn't fulfill it's intended role.

Your cell phone probably has three processors in it.  If
I gave you *all* of the code to just ONE of those processors,
I haven't done you any favors -- if what you want to "fix"/alter
is handled by one of the other two processors (and all you
can see is the memory image of that processor... perhaps not
even knowing what sort of processor it *is*!)

> > E.g., I designed a slot machine some years ago in which I used
> > several "cheap" processors to implement subsystems that allowed
> > me to offload the main processor of some of the more mundane
> > chores.  One of those tasks was driving a graphic "ticket printer".
> > The exact hardware and software protocols that the printer required
> > were embedded in that microcontroller.  I could publish the
> > source for the application yet, if I withheld the sources for that
> > *firmware*, you could never substitute a different printer.  Nor
> > change certain aspects of the "printouts".
> > 
> > Yet, I could publish the design under the GPL/LGPL even relying on
> > other libraries and subsystems that I may have dragged into the
> > project under similar terms.
> 
> That is true any license.  If the hardware (or hw+fw)
> implement a feature, you can deliver the code but the
> hardware and or firmware might not be update able  If I
> wrote an operating system that only ran on the buggy Intel
> P5 it wouldn't do floating point math correctly and there is
> nothing that anyone can do about it.  I fail to see how
> that is a short coming of the GPL.

The goal of the GPL is to let you, the user/licensee, modify
the software (to add features, fix bugs, etc.) and "grow"
(evolve) the software.  If I *hide* portions of that
software by calling it firmware or slushware, then I've
seriously impacted your ability to do these things.

> The GPL also
> doesn't cure cancer or solve world hunger.  The GPL
> doesn't do everything, but it does more than many other FOSS

How does it "do more"?  What do you consider "more"?

> licenses (e.g. BSD) and is definitely better than
> proprietary licenses
> 
> > While "legal", it's just not *fair* (in my case, the entire system
> > was proprietary so it wasn't an issue).
> > 
> > The GPL ignores modern technology (by "modern", I mean techniques
> > that were in use 60 years ago and are now *commonplace*).  It
> > really only works among folks who *want* to share -- in which
> > case, I argue that it's not *needed*!
> 
> I'm sorry that the GPL doesn't make all hardware and
> software open so that you can tweak it to your hearts
> content but what would you suggest replacing it with?

I'm not suggesting anything!  What I am pointing out is
how current, *ubiquitous* technology makes teh GPL no
better than any other FOSS license.  You still rely on the
"kindness" of the licensee to facilitate the goals that
the GPL tries to address.

If you *can't*, effectively, make changes to the product/work
because licensors can *legally* hide stuff that you would need
to make those changes, then what good is the license over a
completely *closed* license?

> Doing away with the license all together doesn't sound like

Please consult the TFUG archives and tell me *where* I
suggested "doing away with the license".  Take your time.
I'm willing to wait...  ;-)

> it would make anything better.  It feels more like the
> trolling that has been going on on the LKML about dropping
> 32 bit support, or doing away with keyboard support.
> 
> RMS was eager to be able to be able to tweak and fix
> everything that he got.  But of equal importance is
> upstream being able to take improvements from downstream and
> incorporate those improvements. The spirit of the GPL is the
> former but the letter is the later. Doing away with the GPL
> will be detrimental to the later.  Even if a company
> isn't following the spirit at least upstream can still
> benefit.

You will find that the the GPL will become less and less effective
in meeting any of these goals as things move furhter away from
the desktop and onto appliance hardware -- where it is much
more common to use "custom silicon" to squeeze pennies out of
a design that doesn't need to be a "general purpose computer".
Software will be "locked away" in black boxes.  Software that
*isn't* will be more closely tied to specific products by
exploiting features only available to those products.  And,
manufacturers will get better at locking down implementations
so that you *can't* update the firmware/software.  Especially
as more and more products become "services" instead of
"devices".

And, the GPL will find itself helpless in the face of these
changes.

--don




More information about the tfug mailing list