I think that your policy probably makes certain things more difficult.
For instance, the TS products are not supported by mainline kernels and getting the latest version to work on a TS board is a lot of work because of it. So much so that I have given up and decided to build kernel modules for the TS kernel.
Personally I think that for a hardware company it would be beneficial to open up the software that is never sold and just adds value to a product line. By open sourcing certain software you can get many more eyes on the code and improve quality which could then boost hardware sales.
For instance, if the latest kernel version would be supported on my TS-7800 board from the mainline kernel, I would have written my drivers for the PC104 bus and added two device drivers, DIO64 and ADC24. In our product, where the TS-7800 board is just a component, we need these drivers, but we do not consider the code to be part of our core software. So my drivers would have been upstreamed to the ARM arch and become instantly available to all your customers. Everyone updating my drivers, including kernel developers changing the inner kernel workings, would be improving these base drivers that are needed by my propriatary software.
Basically, by adding support for your products to the mainstream kernel and fully open sourcing your software you will be adding a lot of developers on your software team without any salary costs. It just means that someone could steal an idea for bitbanging and SPI interface on a GPIO port or something, but honestly, the source is already on a public FTP. How are you going to know if it ends up in some closed source product? Besides, most of the currently available software is not unique and well documented all over the internet.
Still, I know how corporate worlds operate. Protective of the software they make, because time was spent making it and time == money. The thing to convince the decision makers of is that the software you are not selling is better off being open source because it really is only useful on your products and the magic of open source can be that you get free updates without having to spend time, thus saving money!
Currently, company decisions and policy have limited me to use a kernel of about 3 years old. Perhaps I will try to write all required modules to include in the latest version of the kernel at some point, but realistically I do not have the time for that. Especially since I cannot use the sources you must have for the different modules, so I would have to start from scratch and I am not sure all the information I need is in datasheets.
If you open source the sources for those kernel modules, I promise you will have my time updating them to the latest version and debugging them. Of course you will have that time FREE OF CHARGE and all my changes will be made available to the public, i.e. your customers. You would still hold the copyrights to your code, just not the exclusive use rights. What a deal, because if time == money then I am offering you money, not cold hard cash, but still ;-)
This is starting to sound like a petition, huh?
Wouter Simons
Van: [ Namens Kris
Verzonden: dinsdag 14 december 2010 0:23
Aan:
Onderwerp: [ts-7000] Re: SW license
Our policy is you can do whatever you want with the code on our FTP site as long as it is used on our products.
It depends on what you are posting to, but you are right, any open source mailing list would laugh at you. We really simply put that there to get people to question why it is there.
-Kris Bahnsen
Technologic Systems
--- In ts-7000%40yahoogroups.com, Jason <> wrote:
>
> Kris,
>
> On 12/13/2010 01:15 PM, Kris wrote:
> > I would like to provide a bit of clarification. That is a license we
> > put on a large amount of our software products (if there is even a
> > license slapped on there at all). We are want to deter people from
> > using our code on products that are not ours. Since you are here and
> > asking about it, we likely have no reason to be concerned that you
> > are using it.
> >
>
> So, by posting to this mailinglist, I can bypass *all* legal notices
> found in files at ftp.embeddedarm.com and just assume GPL/BSD? Do I
> just need to show a packing slip/receipt? IANAL, but that doesn't sound
> like a lawyer has even glanced at it.
>
> I'm pretty sure if I tried to contribute code to an open source project
> listing the above as copyright history for some code I pulled from
> ftp.embeddedarm.com I'd get laughed right off the mailinglist. ;-)
>
> > We actually tend to dual-license our kernel code, GPL to the linux
> > community, and BSD to our customers specifically. This allows our
> > end customers to have proprietary aspect to their products. All of
> > the sources on our FTP site are considered to be under BSD, but only
> > when used with our products.
>
> Why not just draft up a header stating as much? It's _not_ open source,
> but at least it would be truthful.
>
> > We actually leave a big scary license
> > block in place to scare off those not using our products, and when
> > customers call up and ask we can clarify that for them.
> >
>
> It sounds like your trying to give yourselves wiggle room without paying
> to consult a lawyer. I'm just not sure what you guys are trying to
> wiggle out of... Some phantom code thief that uses playsound.c on a
> gumstix?
>
> > -Kris Bahnsen Technologic Systems
>
> As is custom with most licensing discussions, could you please use a
> company email address (! @yahoo.com) when stating the company's stance
> on licensing issues? Thanks.
>
> Jason.
>
> >
> >
> > --- In , Wouter Simons <wouter@> wrote:
> >>
> >> It is Legal to use kernel drivers with closed source drivers as
> >> long as it is defined in the module source with
> >> MODULE_LICENSE("<license>"); This is actually used quite a lot even
> >> though a closed source driver will have restrictions in how it can
> >> interact with other systems (mainly exporting symbols will not work
> >> as expected).
> >>
> >> Just think of your NVidia drivers for instance.
> >>
> >> This is particularly useful for modules that are developed in
> >> embedded environments because you may be putting proprietary code
> >> in a kernel module for your application that contains trade
> >> secrets. So allowing non-GPL code in the kernel actually
> >> facilitates using Linux in restrictive closed source commercial
> >> environments.
> >>
> >> Best regards,
> >>
> >> Wouter
__._,_.___
![]()
__,_._,___