These are all good questions.
I assume people have already discussed these somewhere on the Internet, where
I don't know.
When it really comes down to it, there is almost no-one to sue you if you
violate the Linux GPL license. Linus Torvalds will not likely come after you.
It may be a different story if you violate the GPL of a product backed by a
company, say Digium Inc. who makes the Asterisk PBX.
As long as you honour the "spirit" of the GPL you should be fine. And
basically that spirit is a openness and sharing. The litmus test should be,
"if we release this code can users fix its bugs?"
I'm my opinion:
---------------
I don't think you should need to release the Verilog code for the firmware of
your FPGA, even if you link the binary firmware in the kernel. But I do think
you should include the source of the C code that loads the bitstream into the
FPGA. However, it would increase your sales if you did include the Verilog
code, as students could now use the TS-7300 as a learning tool, And people
could extend the FPGA in meaningfull ways.
I don't think you should need to include UML design files with a project,
because the C code generated can easily be read and modified by users.
I don't think obfuscating your code by turning it into assembly language,
stripping the comments, or using some obfuscating application on it is in the
spirit of the GPL.
Why are Companies Afraid of Open Source?
----------------------------------------
So many companies are more concerned with their competition than they are with
their customers. A company that does everything to satisfy the need of their
customers will not need to worry about their competition!
A good example of losing focus on the customer is Commodore Computers.
Remember the Commodore 64? its the best selling computer model in history! In
the mid 1980s Commodore's advisers determined that Commodore "Owned" the
person computer market, and that nobody could take it from them. So they
switched their focus away form their customers to go after the business
marked and compete with the PC. Having abandoned their customers they soon
went out of business.
Customer wants open source! Customers want alternatives if their supplier
abandons them. Customer want to understand an modify the product quickly.
They don't want to rely on another company.
The real asset companies have is their customer base. It far easier to sell to
existing customers than to attract new ones. Happy customers promote products
via word of mouth, which is the most powerful marketing tool. Companies must
stay focused on meeting the needs of these customer as opposed to focusing on
hurting their competition. I've been considering buying a TS-7300 mostly
because I already own a TS-7200 and TS-7250. And if I bought a TS-7300 I'd
write code for it and contribute it back to the community.
Part of the reason I bought a TS board is because TS has a very open policy,
more open than most companies. It also has a great user forum. The fact that
TS releases schematics was a big plus! Its a great board to learn from, and
in return I've contributed back to the community with my SerialBlaster open
source utility.
I haven't purchased a TS-7300 because I can't learn from it. The Verilog code
for the FPGA and CPLD are not released, so I can't play with them. And no SD
code is released.
-Curtis.
On June 1, 2006 01:51 pm, Jesse Off wrote:
> This reminds me of a discussion we were having at Technologic
> Systems HQ the other day concerning GPL interpretation of what
> is "source code".
>
> For instance, lets say we created some driver in the GPL'ed kernel
> using some in-house high level proprietary UML modeling tool. When
> we click "File, create linux driver C source" out pops some machine-
> generated C source code-- probably highly obfuscated and useless to
> a kernel hacker but source code nonetheless.
>
> Now I wonder how high up the GPL licensing clauses would spread
> too? Does one have to give out the modeling tool project file since
> that is the real "source"? Its useless and may as well be
> encrypted without the in-house program so would one have to give out
> the creating program now too? How much can of that company's inner
> workings and IP be "opened up" with that simple GPL lever of
> compiling in statically the source code of a driver in the kernel
> binary?
>
> I guess what I'm getting at is can I just use "gcc -S" to generate
> an sdcard.s assembly source from our C sources, obfuscate it, and
> release that (mostly useless) assembly code under the GPL? Then we
> can compile the option statically in the kernel, allowing customers
> the convenience of not having to use an initrd and being able to
> recompile their own kernels and possibly bring the source to 2.6
> kernels. The SD card association should still be happy since none
> of their secrets can really be derived from the "source" and
> although the Linux community may not like that type of driver
> source, at least we couldn't be litigated for GPL infringment.
>
> //Jesse Off
>
>
> --- In Curtis Monroe <> wrote:
> >
> >
> > I still like the idea of a TS-7300 BIOS:
> >
> > http://groups.yahoo.com/group/ts-7000/message/2548
> >
> >
> > You can read about the TS-7300 boot sequence here:
> > ftp://ftp.embeddedarm.com/ts-arm-linux-cd/manuals/ts-7300-manual-
> rev1.1.pdf
> > Section 2.3 Boot Sequence
> >
> >
> > -Curtis.
> >
> >
> > On May 31, 2006 10:03 pm, Yan Seiner wrote:
> > > --- In "Jesse Off" <joff@> wrote:
> > > >
> > > > Currently, our MBR code (Only 446 bytes available after
> partition
> > > > table) loads in a kernel and an initrd from dedicated
> partitions on
> > > > the SD card and starts Linux. The initrd contains the FPGA
> bitstream
> > > > and the Linux driver modules for SD. These are loaded (along
> with
> > > > modules for the ethernet and serial ports) and then the initrd
> does a
> > > > pivot_root to the SD EXT2 filesystem and then frees the
> initrd. There
> > > > is no onboard flash on the TS-7300-- only SD.
> > >
> > > Jesse and Co.:
> > >
> > > I've been going through the archives regarding the TS7300 and
> this
> > > caught my eye.
> > >
> > > In my work with webcams, I came across the kernel maintainers'
> > > decision to eliminate binary blobs from kernel drivers. See for
> > > example
> > > <http://www.ussg.iu.edu/hypermail/linux/kernel/0408.3/1458.html>
> and
> > > follwoing, and <http://www.smcc.demon.nl/webcam/>.
> > >
> > > So... what follows is purely conceptual; I have no idea if it is
> > > possible and if possible if practical.
> > >
> > > Would it be possible to write the proprietary portion of the SD
> code
> > > into the FPGA, and then use a GPL kernel module to access the SD
> card
> > > via the FPGA using a published API?
> > >
> > > The kernel could boot using GPL MMC code off the SD card. Once
> the
> > > kernel is booted, it would use the FPGA SD interface. The boot
> > > process may be slower but it would be unencumbered by binary
> blobs.
> > >
> > > If this is possible, it would create a kernel-version
> independent way
> > > of accessing the SD card.
> > >
> > > Dumb? Possible? I have no idea. But I would like to run a 2.6
> > > kernel on the 7300....
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
------------------------ Yahoo! Groups Sponsor --------------------~-->
Get to your groups with one click. Know instantly when new email arrives
http://us.click.yahoo.com/.7bhrC/MGxNAA/yQLSAA/CFFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|