Linux in a product

[Michael]

This may not be the exact group to post this to but I'm more likely to get
the right answer here.

Let's say I had a product idea that involved a simple motherboard and an
operating system.

I had thought that Linux was the way to go but seeing that many of the
distributions are for "non commercial" use only.

What possible ditributions of Linux should I look at for inexpensive fees or
preferably no restriction use?

This is a simple idea and want an operating system that would be easy to
learn (and not overkill).

 

[Ian Bell]

This may not be the exact group to post this to but I'm more likely to get
the right answer here.

Let's say I had a product idea that involved a simple motherboard and an
operating system.

I had thought that Linux was the way to go but seeing that many of the
distributions are for "non commercial" use only.

What possible ditributions of Linux should I look at for inexpensive fees
or preferably no restriction use?

This is a simple idea and want an operating system that would be easy to
learn (and not overkill).

There is no reason why you cannot build linux into a commercial product -
there are tens of thousands of set top boxes out there that do just that.
What you have to be careful about is modifications to source code of any
software in it.

Ian

 

[Zak]

There is no reason why you cannot build linux into a commercial product -
there are tens of thousands of set top boxes out there that do just that.
What you have to be careful about is modifications to source code of any
software in it.

In short: you must make teh source code of your product available of
parts you took from 'linux' - thus also the modifications.

As for non-commercial use: these will not be based on copyright of code
under the GPL license.

The vendor may have bundled other code with a different license, or, as
I understand it, use a logo and other trademarked items (such as their
name).

Using Linux can be free, but it still is copyrighted software: you need
to understand the license to see how to do things and what your
obligations are. And some things are not allowed.


Thomas

 

[[email protected]]

This may not be the exact group to post this to but I'm more likely to get
the right answer here.

Let's say I had a product idea that involved a simple motherboard and an
operating system.

I had thought that Linux was the way to go but seeing that many of the
distributions are for "non commercial" use only.

What possible ditributions of Linux should I look at for inexpensive fees or
preferably no restriction use?

This is a simple idea and want an operating system that would be easy to
learn (and not overkill).

No such thing really. Even the most expensive embedded linux solution
have to abide by GPL restrictions. But most of us who have done this
find GPL restrictions quite easy to live with.

Basically, if you modify linux, you must share your modifications. So
most of us don't modify linux. We just run our custom apps on top of
it. The linux source must still be distributed with the product. But
simply posting the source on a web page is enough to comply with GPL
rules.

As for your own custom app, there are no such restrictions. You own the
copyright to your own code so do with it as you please.

So, regardless how much you pay for your linux, you must still comply
with GPL rules. But as I said, nothing to be worried about.

There is a separate issue with libraries that often gets confused with
this. If you use GPL libraries in your code, then you must make your
code GPL as well and give away your source. This has nothing to do with
Linux. If you use the libraries to develop Windows applications you
will still be bound by the license of the libraries. An example of this
is the early version of GNU SASL library.

If you don't want to share your code, don't use GPL libraries. LGPL is
ok since it is less restrictive. BSD based licenses are better.

At the company I work for all our libraries are in-house. We always
re-invent the wheel just to make sure everything is legal.

 

[[email protected]]

[email protected] wrote:
What happens if, say, I use a GPL library in my s/w product? Do I have to make
the source code of the entire app available, or only that library?

GPL - Yes, you have to make your app GPL as well. This is the famous
'viral' nature of GPL.

LGPL - No, your app don't have to be GPL. Only modifications to the
library needs to be.

BSD - Do whatever you want.


The nature of GPL actually makes it impossible to write GPL plugins to
non GPL programs like Photoshop since it implies that Adobe needs to
make Photoshop GPL as well even if it's the end user who loads the
plugin. For this situation the LGPL (Lesser/Library GPL) was created.

 

[Buddy Smith]

GPL - Yes, you have to make your app GPL as well. This is the famous
'viral' nature of GPL.

Only if your app uses GPLd code. An embedded device can have GPLd
applications on it. And, you can write a non-GPL program that exec()s a
GPLd program. Now your program does NOT have to be GPL'd.

BSD - Do whatever you want.

No, the BSD license does have conditions of it's own. Namely, you have
to place a notice of some sort in the product documentation. "Public
domain" mans do whatever you want (see www.sqlite.org)

The nature of GPL actually makes it impossible to write GPL plugins to
non GPL programs like Photoshop since it implies that Adobe needs to
make Photoshop GPL as well even if it's the end user who loads the
plugin. For this situation the LGPL (Lesser/Library GPL) was created.

This is not correct. I can't write a GPL module for a non-GPL program
and use that to force the original developer's code into GPL. Just like
I can't sell your car to someone else without your permission.

It'd be perfectly fine to write a GPL'd plugin for a commercial
application, and it would not force the other developer to relicense
_their_ product. Don't be silly.

On the other hand, it would be strange to release a module as GPL...LGPL
is more appropriate.

ttyl,

--buddy

 

[Joel Kolstad]

This is not correct. I can't write a GPL module for a non-GPL program
and use that to force the original developer's code into GPL.

I think the OP meant that _Adobe_ would have a hard time writing GPL modules
for Photoshop without someone claiming that they then had to release the
source code for Photoshop. Is that not the case?

On the other hand, it would be strange to release a module as GPL...LGPL
is more appropriate.

There are people out there who actively try to dissuade people from using the
LGPL. I really believe that some of them would rather that software not be
written at all (even if it's given away freely) than to not have access to the
source code.

There a pretty silly (IMO) thread over on eHam.net about how the death of the
author of some popular (freely distributed) software package has somehow
harmed its users due to the guy's estate not being willing to hand over its
source code (rumor has it they actually shredded his CDs and printouts!).
Seems they're kinda looking a gift horse in the mouth there... Unlike the
ideal world where the author would have GPL'd the software and "the community
at large" would continue development, I think the real world runs more along
the lines of (1) the author might have never written the program if it had to
be GPL'd in the first place and (2) even if it had been, there's probably less
than a 1% chance that anyone else would have continued its development.

The people I admire most are the ones who are pro-free software (and other
forms of intellectual property) but not simultaneously anti-commercial
software/IP.

---Joel Kolstad

 

[Ian Bell]

I think the OP meant that _Adobe_ would have a hard time writing GPL
modules for Photoshop without someone claiming that they then had to
release the
source code for Photoshop. Is that not the case?

No.

Ian

 

[Buddy Smith]

I think the OP meant that _Adobe_ would have a hard time writing GPL modules
for Photoshop without someone claiming that they then had to release the
source code for Photoshop. Is that not the case?

If Adobe wanted to, they could release plugins with a dual license: Use
this with photoshop, or use the GPL. At that point, anyone else who
wanted to load those plugins in their applications would have to make
their applications GPL'd. So in that case, it would make sense.

There's a lot of dual licensing that goes on, especially when the GPL
gets involved.

tyl,

--buddy

 

[[email protected]]

Only if your app uses GPLd code. An embedded device can have GPLd
applications on it. And, you can write a non-GPL program that exec()s a
GPLd program. Now your program does NOT have to be GPL'd.

Read the question I answered.

This is not correct. I can't write a GPL module for a non-GPL program
and use that to force the original developer's code into GPL. Just like
I can't sell your car to someone else without your permission.

It'd be perfectly fine to write a GPL'd plugin for a commercial
application, and it would not force the other developer to relicense
_their_ product. Don't be silly.

On the other hand, it would be strange to release a module as GPL...LGPL
is more appropriate.

You can obviously write GPL plugins for non GPL programs physically.
Nobody's there to physically stop you. But it makes the legality of
using the plugin very complex. Lets analyse this a bit.

GPL states that any code which links to GPL'd code must be made GPL as
well.
You write a Photoshop plugin and GPL it.
Therefore, the end user must agree to your license (GPL) in order to
use your software unless you say otherwise.
This means, to comply with your conditions to use your plugin,
Photoshop must be GPL. It obviously is not so your plugin immediately
invalidates its own license.
But wait, GPL makes exceptions on code not meant for distribution. So
you can use the combination - Photoshop + GPL plugin as long as they
are not distributed together.
But GPL also has strict definitions of what distribution means. And you
have to make sure you adhere to those.

My point is, yes it can be done if you want, but why release code with
such confusing and conflicting licensing when you really should be
using LGPL?

 

[Ian Bell]

Read the question I answered.




You can obviously write GPL plugins for non GPL programs physically.
Nobody's there to physically stop you. But it makes the legality of
using the plugin very complex. Lets analyse this a bit.

GPL states that any code which links to GPL'd code must be made GPL as
well.
You write a Photoshop plugin and GPL it.
Therefore, the end user must agree to your license (GPL) in order to
use your software unless you say otherwise.
This means, to comply with your conditions to use your plugin,
Photoshop must be GPL. It obviously is not so your plugin immediately
invalidates its own license.

Wrong, because your code links to Photoshop not the other way round.

Ian

 

[[email protected]]

There is no way that the GPL can force a violator to open his/her source
code against his/her will. Thus the "viral" nature of the GPL is mostly a
myth.

If the violator had widely distributed GPL code without a valid
license, the choice might come down to a huge copyright infringement
judgement, or a settlement built around opening the source to achieve
licensing compliance.

If they refused to settle and the infringement judgement exceeded the
value of infringer's other assets, it's possible the plantiff might be
awarded ownership of whatever copyrights the infringer did have, if
such a plantiff were a GPL-promoter they would probably take it and
re-release the product in full compliance with the GPL. Unless the
product has enough unique new value to justify removing and replacing
the GPL code, it's unlikely that selling it to a third party would
raise the necessary cash to settle the judgement.

 

[[email protected]]

Wrong, because your code links to Photoshop not the other way round.

Read GPL. By definitions in GPL Photoshop links to your code since it
is the one 'loading' the plugin.

 

[[email protected]]

Read GPL. By definitions in GPL Photoshop links to your code since it
is the one 'loading' the plugin.

It can't be quite that simple.

Say I have a GPL application running on a machine with a proprietary
OS, windowing system, and window manager. If I launch the GPL
application by selecting it from a window manager menu and it is then
loaded and executed, how is this fundamentally different from a plugin
for a special purpose "image processing operating system" like
photoshop?

There has to be a dividing line somewhere... published API's or
something. But couldn't a plugin interface be published? It seems to
get down to a semantic argument over what is operation system vs
application, compared to what is application vs plugin...

 

[Joel Kolstad]

There has to be a dividing line somewhere... published API's or
something.

Having to define this dividing line is one of the reasons many companies are
leery of using GPLd software!

One easy to define dividing line would be whether or not the code of the GPLd
software runs in the same process space as that of the caller -- this way it's
OK for a proprietary Windows manager to invoke the GPLd code, and for
something like Photoshop you could cleanly setup up something like a mail slot
RPC interface between the two, although any form of 'direct call' interface
wouldn't cut it.

Photoshop most likely uses a COM interface to its plug-ins... anyone know for
sure? Depending on how the threading model of the COM component is set-up,
though, the plug-in may run in or out of process which makes this all kinda
murky...

 

[Ian Bell]

Read GPL. By definitions in GPL Photoshop links to your code since it
is the one 'loading' the plugin.

Wrong again. This is exactly the same as Open Office reading a text file and
there is no requirement to make your text file open source.

Ian

 

[[email protected]]

Wrong again. This is exactly the same as Open Office reading a text file and
there is no requirement to make your text file open source.

Ian

Ian, have you read through the GPL license? A document is not
'executing code'. GPL only covers executable code. The definition of
'linking' loosely tranlated is calling a function in a library/file.
Parsing a file is not covered. That's why it's OK to develop non-GPL
scripts that runs on GPL'd intrepreters.

Also, GPL allows using non-GPL plugin/library/dll in GPL'd code, not
the other way around. So your example should be reading a GPL'd
document in Microsoft Word.

But as Joel Kolstad replied earlier, even this is already dealt with by
the GPL license. It's allowed to use a GPL *code* (not just a document
or script) with a non-GPL application as long as they both don't run in
the same process space. For example it's OK to use a GPL database with
your code as long as they communicate via pipes, TCP etc.

These are not my definitions but GPL's.

Again, my point is if you want to develop a dll/plugin for a commercial
application you should be using LGPL.

 

[Ian Bell]

Ian, have you read through the GPL license? A document is not
'executing code'. GPL only covers executable code. The definition of
'linking' loosely tranlated is calling a function in a library/file.
Parsing a file is not covered. That's why it's OK to develop non-GPL
scripts that runs on GPL'd intrepreters.

Do you understand the difference between loading and linking?

Ian

 

[[email protected]]

Do you understand the difference between loading and linking?

How would you classify dynamic linking?

Or going the other way, what about registering a callback function to
respond to events from the host application, window manager, or OS ?

 

[[email protected]]

Do you understand the difference between loading and linking?

As an engineer, yes. A plugin is not simply loaded in the same manner
as a document. A document is simply parsed - no subroutine call is made
into code in the document. By subroutine call the GPL recognises only
machine language calling, not interpreting scripts. Simple loading of
an image into does not 'link' into that image. However, when the image
them gets 'executed' by the CPU, it must be done somehow by a
subroutine call even if it is indirectly by function pointers. The GPL
classifies this as linking, in this case dynamic linking. A plugin is
simply a library/dll that the programs first checks if it exists before
linking. Unlike hardcoded libraries the program still works even if the
plugin doesn't exist. The program doesn't even need to know in advance
the names of the plugin since it knows where all plugins are located
and simply scan through the directory.

This situation is just a bit more complicated if we are talking about
intrepreted languages. But that's another story..

Note that if you read GPL carefully there is a workaround for people
like me who still want to use GPL'd code in a commercial product
without making my own code GPL. Simply write another simple wrapper
application which acts as a 'server' of the GPL functions. This simple
application can harmlessly be GPL'd since it doesn't contain any
business logic. Then connect the two via external means: pipes, TCP/IP,
RPC, mailboxes, etc.. On a good operating system with very fast
messaging such as QNX, this is almost as good as calling the function
directly.