[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is CVS free for commercial development?

From: Matthew Riechers
Subject: Re: Is CVS free for commercial development?
Date: Mon, 25 Jun 2001 14:44:37 -0400

Lan Barnes wrote:
> Matthew Riechers wrote:
> >
> > Peter Ring wrote:
> > >
> > > PS: I wonder whether a cvs client could be developed in a fashion that 
> > > would
> > > make it not subject to the terms of GPL? This might be useful for
> > > interfacing non-GPL (BSD-style absolutely-no-strings-attached or more
> > > proprietary) software to cvs repositories.
> >
> > As long as the client doesn't link directly to cvs code, you are ok. You
> > would either have to write your own code to handle the connection
> > protocol, or implement it as a simple wrapper to the cvs binary.
> >
> I fail to see why anyone would want to do that. Go to
> and read the GPL (or even better, have your lawyer read it). Yes, CVS is
> GPL and so are many of its clients, but this fact has absolutely no effect
> on the license status of any software source maintained in a CVS
> repository. So writing a new client just to be something other than GPL
> makes no sense.

Exactly. The license of the client is irrelevant, especially when it's
just a command-line wrapper. There *are* programs that fall into this
catagory (to answer Peter's original query): UltraEdit, Visual
SlickEdit, Visual Studio, etc. The licenses of the clients in these
cases are proprietary, but who cares? It doesn't have any *added value*
feature that "embraces-and-extends" CVS; it just calls a program and
captures the output in a useful way.

> {NB: IANAL, but recent stories on /. and elsewhere indicate that the
> Microsoft EULA for the .NET SDK may forbid the use of GPL software tools in
> conjunction with the SDK. If this is true and is enforceable, then using
> CVS or its GPL'ed front ends for archiving your own .NET SDK source code
> may violate your EULA.}

IANAL either... BTW, how many lawyers *are* on this list? :)

M$ seems to be trying to do an end-run around non-M$ licenses, by
bringing two otherwise disjoint things (code, storage mechanism) under
the same tool/system/license. So now I can't use my (possibly homegrown)
GPL'd [place utility here] to develop with a M$ SDK?!? This *could* have
an effect on how even simple intefaces (like the ones described above)
are handled legally. *shudder*


reply via email to

[Prev in Thread] Current Thread [Next in Thread]