[rancid] Rancid 3.0 License Change

[Jeffrey Ollie]

I was just looking at some of the changes in Rancid 3.0 alpha and I saw
that this clause was added to the license:

+## 6. Parties packaging or redistributing RANCID MAY NOT distribute altered
+## versions of the etc/rancid.types.base file nor alter how this file is
+## handled. The purpose of this condition is to help keep our support
+## costs down.

This change makes Rancid non-Free and could be problematic for
distributions that package Rancid. I know that in particular it will be a
problem for Fedora.

[heasley]

Post by Jeffrey Ollie
I was just looking at some of the changes in Rancid 3.0 alpha and I saw
+## 6. Parties packaging or redistributing RANCID MAY NOT distribute altered
+## versions of the etc/rancid.types.base file nor alter how this file is
+## handled. The purpose of this condition is to help keep our support
+## costs down.
This change makes Rancid non-Free and could be problematic for
distributions that package Rancid. I know that in particular it will be a
problem for Fedora.

It is still free; you still pay nothing to us, no one is bound by this clause
from modifying it for their own use, and it does not prevent parties from
creating packages.

Furthermore, I'd consider expanding that clause to the entire contents of the
lib directory for the same goal. The clause does not prevent anyone from
distributing a modified version of etc/rancid.types.conf and wouldnt prevent
the addition of other libraries to the lib directory; providing a path around
the clause, but still maintaining the goal.

I think the goal is clear. I spend too much time providing support and
recognize that a few on the rancid-discuss list help significantly; the time
of neither is free. I foresee modifications described to be a potential
rathole that I wish to avoid.

That said, I'm open to suggestions to achieve that goal in a different
manner.

[Jeffrey Ollie]

Post by heasley

Post by Jeffrey Ollie
I was just looking at some of the changes in Rancid 3.0 alpha and I saw
+## 6. Parties packaging or redistributing RANCID MAY NOT distribute altered
+## versions of the etc/rancid.types.base file nor alter how this file is
+## handled. The purpose of this condition is to help keep our support
+## costs down.
This change makes Rancid non-Free and could be problematic for
distributions that package Rancid. I know that in particular it will be a
problem for Fedora.

It is still free; you still pay nothing to us, no one is bound by this clause
from modifying it for their own use, and it does not prevent parties from
creating packages.

Yes, it's still "free as in beer" but not "free as in speech".

Post by heasley
I think the goal is clear. I spend too much time providing support and
recognize that a few on the rancid-discuss list help significantly; the time
of neither is free. I foresee modifications described to be a potential
rathole that I wish to avoid.

Yes, I saw the comments in the source and understand your goal and can
sympathize. I just wanted you to be aware of the repercussions.

Personally, I think that having Rancid available in distributions
would make support easier because everything would get installed in
the right place and all the dependencies would get installed as well.

[Alan McKinnon]

Post by heasley

Post by Jeffrey Ollie
I was just looking at some of the changes in Rancid 3.0 alpha and I saw
+## 6. Parties packaging or redistributing RANCID MAY NOT distribute altered
+## versions of the etc/rancid.types.base file nor alter how this file is
+## handled. The purpose of this condition is to help keep our support
+## costs down.
This change makes Rancid non-Free and could be problematic for
distributions that package Rancid. I know that in particular it will be a
problem for Fedora.

It is still free; you still pay nothing to us, no one is bound by this clause
from modifying it for their own use, and it does not prevent parties from
creating packages.
Furthermore, I'd consider expanding that clause to the entire contents of the
lib directory for the same goal. The clause does not prevent anyone from
distributing a modified version of etc/rancid.types.conf and wouldnt prevent
the addition of other libraries to the lib directory; providing a path around
the clause, but still maintaining the goal.
I think the goal is clear. I spend too much time providing support and
recognize that a few on the rancid-discuss list help significantly; the time
of neither is free. I foresee modifications described to be a potential
rathole that I wish to avoid.
That said, I'm open to suggestions to achieve that goal in a different
manner.

You're not obliged to support anything you don't want to, and I feel you
are well within your rights (and the bounds of common decency) to say
upfront you will answer questions iff rancid.types.base is untouched
from as-shipped.

Distro packagers know and understand this. When they change stuff, they
assume the burden of supporting their changes for their users, and if
you treat those changes as WONTFIX from your pov, then that's just how
it is.

The problem with the clause as it stands is not the intent, it's that
the wording goes against the grain, is just a little bit unpalatable and
is in any event un-policeable.

Rancid is essentially under a BSD license. I would suggest you stick to
that license for everything, and clearly define in the FAQ what you
personally are willing to do. The usual best solution to packaging
problems is to write the build system well in such a way the packager
finds no real benefit in fiddling around with it, and so doesn't. This
lets all of us get what we want as much as possible.

[Tom Limoncelli]

Reducing customer support costs low is an important goal. I think the
problem is that going about it via license strictions brings problems for
certain Linux distros that have rules about what can and can not be in the
licenses of software they package.

That said, there should be other ways to get the same goal:

Some suggestions:

1. Calculate a hash or checksum of the file and print a warning if it is
different. If it was an error the repackagers would also update the
checksum. If it is an innocent, "Default rancid.types.base is in use:
TRUE" (or FALSE) message they'll be less likely to want to remove it.

2. If the file has changed, the startup banner should list the version
number with an "X" appended. When people list the version number
(typically part of any service engagement) you'll immediately know if the
file was non-standard.

3. Make it significantly easier to NOT change the file. For example, add
a "conf.d" directory for people to add configs that are read after the main
file. People can insert individual files for individual models.

4. Shame the people that do change it. Set up a web page called "The
Naughty RANCID Distro list" which lists vendors that are known to have
shipped a modified file. Include a link to instructions that explain how
not to change the file.

Those are just a few thoughts.

Hope that helps,
Tom

[Paul Gear]

Post by Tom Limoncelli
Reducing customer support costs low is an important goal. I think the
problem is that going about it via license strictions brings problems
for certain Linux distros that have rules about what can and can not be
in the licenses of software they package.
1. Calculate a hash or checksum of the file and print a warning if it
is different. If it was an error the repackagers would also update the
TRUE" (or FALSE) message they'll be less likely to want to remove it.
2. If the file has changed, the startup banner should list the version
number with an "X" appended. When people list the version number
(typically part of any service engagement) you'll immediately know if
the file was non-standard.
3. Make it significantly easier to NOT change the file. For example,
add a "conf.d" directory for people to add configs that are read after
the main file. People can insert individual files for individual models.
4. Shame the people that do change it. Set up a web page called "The
Naughty RANCID Distro list" which lists vendors that are known to have
shipped a modified file. Include a link to instructions that explain
how not to change the file.
Those are just a few thoughts.

Great suggestions from Tom. I think these are much better ways to
handle the issue than in the license.

Paul

[heasley]

Post by Tom Limoncelli
Reducing customer support costs low is an important goal. I think the
problem is that going about it via license strictions brings problems for
certain Linux distros that have rules about what can and can not be in the
licenses of software they package.
1. Calculate a hash or checksum of the file and print a warning if it is
different. If it was an error the repackagers would also update the
TRUE" (or FALSE) message they'll be less likely to want to remove it.
2. If the file has changed, the startup banner should list the version
number with an "X" appended. When people list the version number
(typically part of any service engagement) you'll immediately know if the
file was non-standard.
3. Make it significantly easier to NOT change the file. For example, add
a "conf.d" directory for people to add configs that are read after the main
file. People can insert individual files for individual models.

The new version makes it easier for folks to add their own models/types.
Which hopefully will help folks update more easily too.

And, clause 6 is no longer a condition of license. if it causes problems,
we'll implement your suggestions 1 & 2.

Post by Tom Limoncelli
4. Shame the people that do change it. Set up a web page called "The
Naughty RANCID Distro list" which lists vendors that are known to have
shipped a modified file. Include a link to instructions that explain how
not to change the file.
Those are just a few thoughts.
Hope that helps,

indeed.

Post by Tom Limoncelli
Tom
--
Skype: YesThatTom
Blog: http://EverythingSysadmin.com <http://everythingsysadmin.com/>