[kde-community] Using software created by KDE and KDE-related communities/companies for KDE infrastructure

[Ben Cooksley]

On Wed, Sep 17, 2014 at 2:38 AM, Thomas Pfeiffer
<thomas.pfeiffer at kde.org> wrote:
> On Tuesday 16 September 2014 16:31:23 Ingo Klöcker wrote:
>> I'm replying to Aaron's and Thomas's message.
>>
>> > On Monday 15 September 2014 16:24:55 Aleix Pol wrote:
>> > > - Kollab: This was already discussed recently in this list, it
>> > > doesn't seem feasible to offer a Kollab instance to the membership
>> > > (let alone the whole community) so I don't think we want to depend
>> > > on it. That said, We might want to ensure we have all the tools to
>> > > use the standards we can rely on, then ensure Kollab is capable to
>> > > interact with them, given it's one of the few platforms we could
>> > > have a say.
>>
>> On Monday 15 September 2014 20:11:32 Thomas Pfeiffer wrote:
>> > Given that Kolab will power the whole of Munich administration soon, I
>> > wonder why it wouldn't work for the - big, but still tiny compared to
>> > that - KDE community, but I am not an admin (I really should
>> > establish the IANAA and IANAD acronyms), so I may totally miss the
>> > difference. Would it require massive server or bandwidth resources
>> > which we don't have?
>>
>> No, the problem is not technical, but legal. If we (resp. the KDE e.V.
>> as our legal representative) would host a Kolab instance then the KDE
>> e.V. would most likely become an email provider (according to German
>> law). And being an email provider in Germany comes with lots of legal
>> requirements and responsibilities.
>
> Oh damn, legalities... So what's the difference between an organization using
> a groupware internally and an email provider, from the legal perspective?
> Read: Could we restrict the access to an account on our server in a way that
> would not legally make us an email provider?

>From what I recall, if we offered it solely only to members of the eV
then we were able to escape the email provider provisions. Someone
from the board can comment more clearly on that.

>
>> On Monday 15 September 2014 20:04:45 Aaron J. Seigo wrote:
>> > I'm sure we can work sth out with Kolab Systems.
>>
>> Not sure what you mean. AFAIK, nothing needs to be worked out with Kolab
>> Systems. We need to get the ball rolling, not Kolab Systems.
>>
>> If we want to use MyKolab.com: About 3 months ago Georg Greve has sent a
>> message to the KDE e.V. mailing list (sorry, this list is restricted to
>> KDE e.V. members) with a special offer for KDE people who want to use
>> Kolab Systems' MyKolab.com.
>
> While the MyKolab special offer is greatly appreciated, it would not help us
> as an organization, because we'd still not have shared calendars or a
> centralized address book.
>
>> OTOH, if we want to host our own Kolab instance (which we probably do
>> not want to do because see above) then I don't see what needs to be
>> worked out with Kolab Systems.
>
> Well, maybe them helping us to set up Kolab on our infrastructure in case we
> have difficulties with that.

Please bear in mind that I last assessed it a while ago.

Half the issue is that Kolab is extremely complex software. If
something were to go wrong, diagnosing the issue, let alone fixing it
could be a very difficult issue. And we are dealing with people's
email here.

In addition, their Debian packages are not signed and contain defects
which make the installed Kolab stillborn (as you can't add users).
I suspect Kolab is supported under one distribution only: RHEL. All
other parts of our core infrastructure are powered exclusively by
Debian or Ubuntu, which will create a familiarity difference for
Sysadmin.

And I won't mention the dependency chain of Kolab....

Thanks,
Ben

> _______________________________________________
> kde-community mailing list
> kde-community at kde.org
> https://mail.kde.org/mailman/listinfo/kde-community