[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [spaces-dev] SVN or CVS?
|
Bjorn Freeman-Benson wrote:
You're correct about storing our code in SVN - and I'm fine with that.
You're wrong about Spaces not being dependent on Subversive. The
Spaces tool plans to have five functions: Publish (a binary), Share
(your source), Promote (and advertise), Collaborate (via forums or
IM), and I forget the fifth one. Anyway, my idea was that when you
chose "Share", we (Spaces) would reach into the Subversive data
structures and set it all up for one: one-click set-up. But to do that
we have to depend on Subversive. The problem with that is described
below.
Perhaps I'm dense, but I still don't understand. We will develop "Share"
functionality that will allow people to share source. And of course they
should be able to do this using CVS. What does that have to do with
where we maintain the source of the Spaces project itself?
As a side note (and in my understanding, not related to where we keep
our source), I also think it's essential that we allow people to share
source using SVN. It's growing rapidly and as I said, a lot of CVS
projects are moving over. Look at Apache, Source Forge, Tigris,
Codehaus, etc. CVS is not dead, it's still very commonly used, but it is
in decline and it doesn't attract many new projects.
Apparently (and here I'm just going on what I've been told), the
Subversive client requires the use of GPLed library jars. According to
the GPL FAQ, linking to jars, even through extension points, does
trigger the viral nature of the GPL and thus the Eclipse Foundation
cannot distribute this code (the Subversive clients).
I'm just afraid that someone is making a mistake that has a profound
impact. AFAIK, both Subversive and Subclipse depend on the Apache/BSD
licensed generic SVN client library. The SVNKit (with GPL'ish license)
is just one of the implementations. It's optional. Does the other
implementation (the JavaHL) have GPL dependencies also? If the answer is
no, then next question is, can the fact that someone creates a GPL'ed
implementation of a generic API invalidate the API itself (same question
is of course valid for extension points)?
So until this IP issue is cleared up either by finding a similar
library with an acceptable license or rewriting the code or something,
the Eclipse Foundation cannot distribute the Subversive code. And thus
the Foundation's Spaces code cannot depend on the
not-able-to-be-distributed-by-the-Foundation Subversive code.
I'm afraid I'm still confused. Why are you saying that by storing our
code in SVN we make the code depend on SVN?
Where we store and maintain our code is one thing. What we support with
that code or what that code is dependent on is something else. If we
want the users to be able to see the Spaces source code, we should do
that by providing source bundles that we redistribute as features using
the update manager, not by requiring that our end users connect to our
CVS (or SVN).
When and why is it significant to the user where we keep our source?
- thomas
