Post by heasleyPost by Jeffrey OllieI 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.
--
Alan McKinnon
***@gmail.com