Use of the Calligra name

[todd rme]

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.

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.

-Todd