Use of the Calligra name

[Sven Langkamp]

On Wed, Dec 29, 2010 at 5:25 PM, todd rme <toddrme2178 at gmail.com> wrote:

> On Wed, Dec 29, 2010 at 10:51 AM, Cyrille Berger Skott
> <cberger at cberger.net> wrote:
> > I have added the content of my previous mail as a policy draft:
> > http://community.kde.org/Calligra/Policies/Use_of_the_Calligra_name
> >
> > Also I have been thinking about adding the following paragraph as well (I
> have
> > been thinking about this for a while, but discussion today with FC people
> > reminded me that just expressing preference does not work with
> distributions).
> >
> > In my view it is a clarification of what is already expressed in the
> "based on
> > calligra" section.
> >
> > == Binary distribution ==
> > Use of the calligra name for binary distribution is allowed for unpatched
> > version without any restriction.
> >
> > Light patched version of Calligra are still allowed to use the name, with
> the
> > condition that the patch fix a compilation error, a bug fix, and has been
> > approved for a future stable release of the Calligra branch it was
> applied to.
> > We believe that minimal patching need to be applied to Calligra, but in a
> > certain circumstances, a distribution might need to apply a patch before
> its
> > actual release.
> >
> > However, heavy patching, such as adding new feature, or patch that makes
> a
> > significant change and are not judge safe for a feature branch, would
> make the
> > resulting product fall under the derivative, and would require the need
> for a
> > different name, and the description can countains the mention "based on
> > calligra". However, if the patch add a new plugin, it is possible to keep
> > using the Calligra name, as long as it is made clear that the plugin is
> not
> > supported by the Calligra project, and not installed by default.
> >
> > The reasons behind such a restrictive policy is to ensure that users get
> the
> > Calligra experience, and also to make it easier to detect and analyse
> what
> > problems are encountered by the users.
>
> So you are saying Linux distributions cannot even fix compilation
> errors without getting approval from Calligra devs?  I cannot see any
> benefit to this particular policy, it will really slow down packaging
> considerably with no benefit to users.
>

Read again. "Light patched" version are allowed, so things like compilation
errors are ok.


> What does "new feature" mean?  Is this a totally independent feature,
> or does it include features accepted into future versions of calligra
> and backported?
>
> Have you discussed this policy with Linux distributions?  Different
> distributions have different targeted user groups and thus different
> approaches to backports and such.  I think the issue of backports
> should be up to the distributions to decide, since they know their
> targeted demographic better than we do.
>
> Does this ban the release of binary development releases?  If not, are
> people required to use one "official" development tree?  What about
> people making their own git branch, then using something like OBS to
> build binaries for it for testing?  Is this banned?  Won't this
> restrict people from testing development versions or experimental
> features?  A good example is the experimental opengl marble branch,
> which exists outside the main marble source tree but the developer is
> asking for help testing.  Under this policy, would distributions be
> banned from providing binaries of such testing versions in order to
> help the developer make the feature as good as possible?  And who
> would enforce it?  Are you going to go after individual users, or will
> you expect OBS moderators to check every version of calligra in the
> entire system to make sure it is the "correct" version.
>
> You should also think about the effects this has on development by
> distributions.  As an example, openSUSE developed KDE 4 integration
> features for firefox.  They got them working first, but they were ugly
> and not suitable for upstream.  So over time intended to clean them up
> and submit them upstream.  This does not seem to be an uncommon
> approach, but your policy would prevent it entirely.  I am concerned
> this will limit contributions from distributions.
>
> How do you plan to enforce this?  Are you really going to start suing
> linux distributions if they don't follow this policy?  The absolute
> worst thing you could do is have a restrictive policy that everyone
> ignores.  That is the best way to make people lose all respect for you
> and all of your other policies.  You either need to enforce it, or
> have a policy people are likely to follow.  Considering how much this
> policy diverges from accepted practices, and the experiences KDE had
> with distributions ignoring requests not to use KDE 4.0, I think it is
> unlikely this policy will be followed universally without strict
> enforcement.
>

Remember when Debian modified OpenSSL and created a big security hole by
that? The job of a distribution is to distribute the software. If they want
to develop the software they should do it upstream. Features that can't go
upstream because they are too ugly should not be released by distributions.
I know that some distributions like to patch (and break) software, but we
can't really prevent that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20101229/a5d233a8/attachment.htm>