Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jgit-dev] RE: [egit-dev] Rewriting JGit history and standard comment template


Your frustration shines through on these posts. Hopefully I can address a
couple of them without making matters worse.

> Its things like this that just seem f*cked up about Eclipse.  A lot
> of the processes and so forth appear to be built up to verify that X
> gets done, but they are some of the most inefficient ways to reach
> that goal.

You might be surprised to find out that I actually somewhat agree with you.
We know we have a lot of recordkeeping associated with Eclipse projects. But
virtually none of it is stuff that we EMOers invented on our own. We are
implementing Board-mandated requirements of the IP Policy. And those
policies balance quite a few different requirements from different
stakeholders. I know its small solace for you, but things have gotten a lot
better over the years. Ask the old guys how much fun it was to get started
before parallel IP for example :-(

I know Wayne Beaton is investing time into things like IP Log automation. We
don't have the resources to magically make all the pain go away, but we are
steadily and incrementally improving things.

But there is no denying that there is overhead associated with being an
Eclipse project, as opposed to (say) SourceForge or Google Code. But there
is value in being at Eclipse as well. At least there is for most projects

> Ugh.  Yes, they did.  By private email.  Apparently you can't
> disclose the preferred project header to the project's mailing list.
> Foundation might get in trouble or something.  So contributors have
> to ask on the list.  WTF happened to open and transparent?

There is nothing secret about the headers. Please feel free to share them
with this list, your wiki, whatever.

The typical reason why the IP team talks with committers on private email is
not because of secrecy, although that happens occasionally. The reason is
that they are supporting 150+ projects, and each dev list requires that you
be subscribed before you can post. (That's done to reduce spam on the
lists.) It's just impractical for us to subscribe to every single project
list in order to talk to people. And having conversations on the
all-committer list is equally bad because then people complain about

> Basically I read EMO's header request as "We are insecure about our
> position, so we have to justify our existence by making you add a
> pointless paragraph to the top of all of your source code files,
> just to prove that we can make you do it".  Never having served in
> my country's military, I have an issue with that sort of abuse of
> authority to justify one's existence.

Gosh. I've never thought about it that way. Eclipse projects have had
standard file headers for their code since even before the Eclipse
Foundation came into existence. I believe that other open source foundations
such as Apache and Mozilla follow similar practices. But if this is some
enormous burden on projects that we've just never been aware of then we
should at least look at the issue. It's always possible that we're enforcing
a valueless convention out of habit.

> Interesting side note...  The EDL is *exactly* the 3-clause BSD but
> with the University of California replaced with Eclipse Foundation.
> Under US copyright law changing 3 words into 2 words gives me
> the right to declare copyright over the larger contract?  Damn.
> I never would have tried to do that, I can't see that as being
> a tenable case of fair use, or something you can actually claim
> copyright over.  EMO's got some brass ones.

Shawn, on this one you're just plain wrong. The canonical source of open
source licenses is the Open Source Initiative at If you go
there, you will see that the "New and Simplified BSD" license[1] is, in
fact, a template. The instructions for the use of that template say, in
part: "The following is a BSD license template. To generate your own
license, change the values of OWNER, ORGANIZATION and YEAR from their
original values as given here, and substitute your own."

In other words, we used the BSD license exactly in the way it is intended to
be used. We further confirmed this with the OSI directly.


Back to the top