Simon Large wrote:
> Technically you are right, and maybe grey area was the wrong term. But
> if I have a driver which now contains no GPL code, I might have:
> 1. Started with a GPL skeleton and edited my code in its place;
> 2. Just looked at a skeleton to find out how it worked, then written
> my own code from scratch;
> 3. Read the documentation and written the driver from scratch.
>
> There is no way you can tell what I did by looking at my code, so in
> that sense it is a grey area.
>
> Simon
>
FWIW I'd like to contribute with a bit of experience from a company that
has gone through different
open source licenses and thoughts around using code under them.
GPL'ed code was ok to download and use for tools with a small warning
for the program output
clause in the GPL. LGPL pretty much the same but also for use in code as
long as we don't do anything
else but use it as a library.
Apache/BSD style licenses where ok for including the source code in
build trees etc. Attribution needed
and wasn't seen as much of a problem (3'rd party tracking file needed to
make sure no attribution was
forgotten).
Looking at TSVN (not something this company was looking into
specifically) I can see that maybe a
company would want to produce a package for say partners, or remote
sites where not only the source
code of the companys product was included, but also a complete concept
was sold that included versioning
and bug tracking, where TSVN is one small part. It's plausible to
imagine that this company would like
to make changes to TSVN, such as hard code specific things to avoid
mistakes or to force policies. E.g.
not showing 'Lock' or changing the name of TortoiseSVN menu item to
Version etc. Small or medium changes
that is company specific and pretty much nothing TSVN would ever
consider for inclusion. Maybe modifications
to software distribution would make TSVN only one component in a much
larger install file.
I think such a scenario is pretty likely and you need to think about
what in such a usage is ok and what is not.
Choose the license appropriately.
My experience was that GPL is so difficult to analyze that companies do
not really know what/how things
should be done and hence they do not wish to use software under it
unless it's very clear there are no problem.
If a misstake is made, the "punishment" of having to publically publish
the entire companys code is unacceptable.
Another thing that might be an important thing to keep in mind is
contributors. As far as I'm able to tell most
contributors do get time from there employer to do work that ends up as
contributions to open source projects.
This might not always be in the form of code, but testing and feature
suggestions as well. It would
maybe be important to make sure companies can download, change, compile
and use the source code in a
way where this will be beneficial for the company so that this,
presumably rather large group, can continue
to contribute efficiently without worrying too much about the license
issues. Remember that in a company it
might be expensive enough to just analyze weather or not a license is ok
for a certain usage that the entire
idea is skipped.
I guess Apache/BSD style license is easier to handle from a company
perspective then GPL is, and probably
invites a larger host of company based contributions. CollabNet license
is probably a good example of this.
/Nicke
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Aug 24 14:17:36 2005