Warning: long post. Here's a short synopsis:
o You do not have to licence your code under the GPL unless you
intend to distribute it as a package that includes GPL'd code.
o The GPL grants you the right to use and the code as you please.
You can mix GPL'd libraries and non-GPL'd code in-house or in a
bespoke application done as work for hire. This is effectively
the same situation as you are not releasing the software to third
parties as a package that includes the GPL code (i.e you can
release code of your own and the client can obtain the GPL bits
by themselves). Typically you are not actually modifying the GPL
libraries.
o Most application development work is done in-house or as bespoke
for hire work . Typically (at least in my experience) the client
usually owns the IP rights for bespoke software.
o Therefore, the GPL does not appreciably affect the relationship
between most bespoke developers (and by implication the majority
of developers oversll) and their clients as the software is
not being distributed as a package that includes the GPL software
o The GPL is problematic if (as the previous poster appears to be)
you want to distribute a non-GPL application in a package with
GPL'd libraries.
o I'm arguing that this happens with only a small minority of software
as most software (90%+ - see my previous posting) is written as
one-off custom apps where packaged distribution is not an issue.
(note: embedded software is a seperate issue and I haven't gone into
that here)
>>Nigel Campbell (DSL AK) wrote:
>> The GPL really only gets underfoot if you want to ship binary-
>> only packaged software derived from GPL'd code.
>
>No, the GPL means that if you link any non-GPL software to a GPL
>piece of software then you need to license your non-GPL software
>so it's not more restrictive than the GPL.
Nothing in the GPL prevents you from doing this in-house or as
a contractor engaged in bespoke work, nor in fact in in any
circumstances except those where you want to ship a packaged
product that includes the GPL code in the package. The one exception
to this is where the non-GPL component has licence terms that
prohibit it from being linked to GPL code (as in the case of MS's
Mobile toolkit).
What you seem to be saying is that it doesn't work for *you* as
you sell a software product you want to release under a non-GPL
compatible licence. It's reasonable to be pissed off with SAP
for changing the licence of the perl libs you worked on in ways
that cause you hassle. That does not in any way conflict with
what I said in my previous posting.
>That means that if a liberary, eg. the sapdb client lib is
>being linked to a non-GPL application then you are in violation of
>the license if you do not distribute the source for your application
>to your customers.
Again, this is germane to the case where you are shipping a shrink-
wrap application as a product. If the work is a bespoke product,
the conditions of distribution are somewhat different anyway.
What I'm saying is that the GPL is not usually a hardship for
people doing bespoke work. If you're getting a client to pay for
development of a (say) vertical-market product that you want to
go on to sell as a product, you're really in the packaged soft-
ware game anyway.
Most bespoke softare is quite specific to a client, so they have
no particular reason to on-sell or otherwise redistribute the
software. In the company I work for (a large solution provider
in the NZ market), it's standard procedure that the client owns
the IP rights for the software. This is very common (although
not universal) practice in this market. In this case, the GPL
does not materially affect the relationship as the client is free
to do what they want with the software anyway.
If you want to do something in-house, redistribution doesn't even
come into it and the GPL merely grants you the right to use and/or
modify the software as you please.
In the cases where the client is uncomfortable with the GPL, they
can just buy a non-free licence anyway. MySQL (and presumably the
upcoming MySQL-branded SAP-DB product) cost peanuts in comparison
to an even moderately-sized bespoke development job.
In the case where the software needs to be linked to non-GPL
components, the client merely needs to licence those components
seperately (which they probably need to do anyway). The GPL
doesn't prevent you from linking GPL code to non-GPL components
in-house, to quote the GPL section 0:
Activities other than copying, distribution and modification
are not covered by this License; they are outside its scope.
The act of running the Program is not restricted, and the output
from the Program is covered only if its contents constitute a
work based on the Program (independent of having been made by
running the Program). Whether that is true depends on what the
Program does.
... and section 2:
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the
Program, and can be reasonably considered independent and
separate works in themselves, then this License, and its terms,
do not apply to those sections when you distribute them as
separate works. But when you distribute the same sections as
part of a whole which is a work based on the Program, the
distribution of the whole must be on the terms of this License,
whose permissions for other licensees extend to the entire whole,
and thus to each and every part regardless of who wrote it.
What this is saying is that merely linking to libraries does not
require your work to be GPL'd unless you wish to distribute the
GPL'd components as a part of a package. It is a considerable
stretch to claim that a seperately distributed (say) web shopfront
program is in fact a modified version of a database interface library.
If a client can obtain the database manager and the web shopfront as
distinct bodies of code, they can mix and match to their heart's
delight.
I'm arguing that most development work is done on one-off jobs and
the GPL usually does not change the relationship in this sort of
work unless for some reason you want to restrict the client from
redistributing some portion of the work. There are some cases where
you might want this for bespoke work, but I would expect them to be
in a minority.
Nigel.
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general
