Molle Bestefich wrote:
>Nicklas Norling wrote:
>>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
>What you're talking about sounds to me as 're-labeling'.
>Eg. take somebody else's work and slap your own product name on it.
>I hope you're not suggesting that that is something we would want :-).
I wasn't suggesting that, I was thinking of TSVN as a minor part in a
larger package of software
where attribution is still present. Considering how rich and mature TSVN
is I don't really see anyone
going off and creating something mind boggling new and then releasing it
under their own name without
the source. What feature would that be? It would probably be easy enough
to re implement without the
code for it anyway.
>>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.
>There's also the possibility of stopping distribution of the product, no?
>Perhaps release it later without the included GPL source?
Both would be a disaster, also when a baby is born... It won't go back
in easily ;)
>>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.
>There's no issue here (I think).. Anyone can download a GPL project and
>modify and use it any way they see fit. You only have to provide the
>source code for your modifications if you start publishing your derivative.
As it turned out it was difficult to draw the borders what needed to be
under GPL and not. This analysis
process and the risks involved of you "guessed" wrong turned out to be
reason enough not to use GPLed
code for anything else but pure tools.
I think there is a significant difference between TSVN and e.g. Linux or
svn. TSVN to me is kind of mature
in that it pretty much does all it needs to do and is very much defined
by the library (svn) it wraps. Modifications
to it would probably be pretty specific, like I wrote above, limited to
configuration, packaging etc. I don't
see the acute need for assuring that such code is made public since it
would be of little to no value for the
community. The important stuff that really needs protection is what's
Linux or svn on the other side have a much greater potential for feature
addition that are not trivial and may
be very interesting for the public.
By demanding that companies make public their changes to the software
they may have to disclose sensitive
information such as hardcoded server names, specific work procedures
etc. that could be seen as a competitive
edge. Such disclosure would certainly mean TSVN won't be used.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Aug 24 16:32:00 2005