[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Name changes to X Applications?
From:       Mosfet <mosfet () jorsm ! com>
Date:       1999-11-06 17:00:48
[Download RAW message or body]

Erich Forler wrote:
> 
> > ... they will
> > make it virtually impossible for us to support Corel KDE users. It will
> > become a support nightmare as David mentioned.
> 
> I don't expect that many people who purchase Corel Linux will be showing up in
> the KDE support world since we're targeting a different type of user. We expect
> to support those users ourselves and are setting up the appropriate facilities to
> do so. Take a look at the list of application names I posted and I think you'll
> find most of them are obvious. Even if there is confusion, a quick look at the
> Process Manager will identify the app clearly.
>

You are expecting your customers to restrict themselves to Corel-only
mailing lists, documentation, IRC channels, and newsgroups? I don't even
know how to start replying to that one...
 
> > Even worse, since they developed all their modifications with absolutely
> > no coordination with KDE developers they managed to make a development
> > dead-end.
> 
> I've been under understanding that KDE 1.1.2 is supposed to be the last 1.x
> release. Isn't this already it's own dead end? We needed to add new features to a
> code stream that KDE wanted to freeze. Since KDE 2.0 wasn't going to be ready for
> a November release, we had to ad features to 1.x which no-one really wanted us to
> do. However, after Corel Linux 1.0 is released, the Corel engineers will be able
> to begin contributing to the KDE 2.0 code in a more usual manner.
> 

Well, it's a little late for that. In case you haven't noticed KDE2.0 is
already nearing feature completion and there won't be many new
architectural additions. As I stated before, I believe most of the code
you have written will be a dead fork because you have neglected to share
it with the project while KDE II was being developed. It's a shame.

> > ... because they absolutely refuse to release any sources of value...
> 
> This isn't true. In accordance with the generally accepted interpretation of the
> GPL and LGPL, source for all of our changes to LGPL and GPL code was sent to the
> people who received the beta.
>

After how long in development? You were developing code for KDE since
well *before* the release of KDE 1.1.2. While KDE 1.1.2 was frozen, you
still released it at the last moment legally acceptable. Now that KDE II
is nearing feature completion we are at a point when it is unlikely to
be utilized well in KDE II. The file manager has been rewritten, the
control center has been rewritten, etc... Corel participated in none of
this because they were busy developing their fork in private. 

 
> > ... and only submitted one patch that I know of - an unusable one to
> > KDE Control Center to run their proprietary modules.
> 
> All of the code for Corel Linux will be Open when it's released. There are some
> x86 Linux platform specific modules but they are not proprietary.
>

I was told that some of the code (using dlopen schemes in order to avoid
the GPL) were to be proprietary to Corel.
 
> > Upon repeated requests by application developers to see the changes they will
> > be releasing to their own code the developers are repeatedly told "No".
> 
> Under the terms of the GPL and LGPL, you are required to provide the source for
> binaries that you distribute. Until the binaries are distributed, I'm not aware
> of any part of the licenses that require you to release your source. That said,
> since we will now be able to work on the "active" 2.0 code stream rather than the
> 1.x, our development efforts can be much integrated with the rest of KDE in the
> usual manner.
>

Sure, you are not legally obliged to. I don't remember saying you were.
What I do remember saying is that Corel was developing their fork
completely in private and without consulting the original application
developers in order to maintain a competitive advantage against other
Linux distributors at the expense of KDE and other free software
projects related to KDE. 

As far as KDE 2.0 development, like I said - you missed the boat. It's
feature set is complete by now and major changes introduced by Corel or
any other author are likely to be rejected. This is what happens when
you fail to coordinate with projects.
 
> > Don't get me wrong. It's absolutely okay for both commercial and free
> > software developers to develop their code in private when you are
> > dealing with your own code. It's even okay to fork other peoples code and do it
> > entirely in private. But it's a bad decision to do with a project as large as
> > KDE, and everybody suffers.
> 
> I don't completely disagree with you but this goes to the heart of some of the
> licensing issues which have come up in the last few months. There are multiple
> interpretations of licenses (particularly some sections of the GPL). If there is
> an obligation to release code changes regardless of whether the binaries are
> released, then that requirement should be part of the source licensing terms. It
> is not currently. Under the terms of the existing licenses, Corel could have
> quietly made changes and no-one would have even heard about it until we released.
> This isn't something we wanted to do but it's allowed under the current licenses.
> Particularly when larger companies get involved in Open Source, the rules of
> participation must be clear or they won't participate and I believe companies
> have the potential to make valuable contributions to Open Source.
>

You haven't participated yet. You have forked KDE into your own "Corel"
version. That is not participation. You also haven't done anything
illegal. But Corel has acted in a way one would expect a proprietary
software company to act: By taking the fruits of other people's labors,
totally neglecting to contact them, coordinate with them, or ask their
permission to make changes, and modifying them with no regard to the
project maintaining this code. If this is how Windows based companies
are going to handle free software it would be better for them not to
participate in Linux.
 
> Erich Forler
> Product Development Manager
> Corel Linux

-- 
Daniel M. Duley - Unix developer & sys admin.
mosfet@mandrakesoft.com
mosfet@kde.org
mosfet@jorsm.com

[prev in list] [next in list] [prev in thread] [next in thread]