incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <>
Subject [pulse] A lab or an incubator? Was: Lab request: Pulse
Date Wed, 24 Dec 2008 07:33:38 GMT
Hello, Bernd,
Thanks for a quick answer.

Well, we do have a working code base, that's correct. I might perceive
things as too complex having concerns about a gap between working code
and the code which can be committed to the Apache subversion. Our code
might (and likely was)  tainted by cut&pasted samples, open source
fragments and third party inclusions with unknown authors and
uncertain licensing models. If I would understand how to define
questionable code and would remove the code, then this would result in
the broken code base. There are minor issues like comments in Russian
as well.

My approach to avoid the licensing mess is writing from scratch. I
plan moving an ongoing development to Apache and envision building new
modules as pluggable APL-licensed libraries which then can be reused
by the multiple-licensed project. Another goal is to import the code
under different licenses using a build system rather then mixing all
the code in the phone code base. Such build system have to be
developed from scratch as well. That is I plan to use the labs for.

I'm CCing this letter to hoping to
attract incubationers attention to the discussion and get your opinion
whether it worth to start incubation or lab for the Pulse project, see
the project description below. I have passed Apache Harmony incubation
led by Geir, and have to admit openly that we are currently less
prepared for it than Intel and IBM were. As the first step I have to
find a anti-plagiarism tool reliable enough to detect GPL
contamination and copied samples from code guru web sites. Could
anyone share any tool which is preferably free for Apache committers?

As for JIRA usage, I mean the following problem. As I've already said,
I cannot see how to open the code for the whole project at once. Now
imagine, that bugs opened for opened components would use Apache JIRA,
bugs for closed components would use our internal Bugzilla, and some
bugs during resolution would travel between two these tracking
systems. I personally believe it would be nice to have all new bugs
stored in one place. I don't think that allowing people keeping all
bugs in JIRA would be an abuse for Apache because I don't expect heavy
bug traffic. We have 45 issues so far.

As for the binary, I got the point on careful naming. We may re-use
Harmony "snapshot build" term to name it carefully.

With best regards, Alexei

On Tue, Dec 23, 2008 at 9:55 PM, Bernd Fondermann <> wrote:
> Hi Alexei,
> Alexei Fedotov wrote:
>> Hello folks,
>> Recently I became involved in development of H.323-compatible software
>> videophone [1] based on MPL-licensed OpenH323. It is mostly the same
>> as Ekiga [2], though we hardly can join GPL-ed project due to complex
>> licensing
>> of the existing code. I have a strategic goal to expose our project
>> code under Apache license and
>> move related development to Apache. I believe that working on Apache would
>> help
>> us achieving legally clean code. As a nice side benefits goal I see
>> openness to the English-speaking world which believes that software can be
>> bought and not necessarily pirated, and providing an open alternative
>> to the closed-source solutions ranged from Skype to Tandberg and Polycom,
>> thus changing the world into being more competitive and
>> customer-friendly. I would like taking advantage of APR though staying
>> with PTLib seemed
>> to be more realistic.
> If you have an existing code base and don't start from scratch - and that's
> what I read from your mail - the Incubator seems more appropriate to me than
> Labs.
>> I believe it would be feasible providing several portable and
>> re-usable communication libraries with clean interfaces under APL as the
>> first
>> step. Well, this requires much more understanding from the fellow
>> stakeholders including developers who are not familiar with an open
>> source model. I plan to resolve patenting issues around codecs Ekiga is
>> facing
>> by providing enough modularity of the project design and keeping
>> questionable modules out of the Apache source base.
> Ok, fine.
>> I wonder what do you think about using Apache labs as a
>> launching pad for the project. It is hard to guarantee now if it would
>> be possible to expose enough code to build a self sufficient product.
> See my first comment. If you indeed start a lab (or at the Incubator), you
> don't need to say where your project will end up, finally. Just start and
> see where it takes you.
>> Some parts of our product are contaminated while others are
>> third party legacy of uncertain origin (e.g. may be contaminated as well).
>> We may only hope to concentrate enough resources to rewrite all of them.
> see first comment...
>> Another question is about bug tracking facility usage. Would it be an
>> abuse to
>> use it for all bugs related to the project even if the parts of it were
>> closed?
> You mean, transferring the whole history of issues to a JIRA? What does it
> help?
>> The last question is about proper binary placement. Is it ok to place the
>> binary
>> for those who would like to try the product on the web site of our
>> company,
>> providing references from Apache to our site? Placing the binary at Apache
>> labs
>> contradicts to no-releases labs policy.
> You can always release ASF code on your own (commercially or not). But the
> level of endorsement of the ASF is a delicate question. For example,
> releases from the Incubator need to be referred to as "in incubation".
>> Finally, how does the project name "pulse" sound for your ear? Could
>> anyone
>> suggest anything better?
> Sounds good to my ears. (But I have a lab with a really stupid name, so you
> probably want to hear more opinions on this.)
>  Bernd
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message