One
point that this brings up is the issue of software license. Eclipse and the CDT
are under
the
CPL license, and any code that is commited to the eclipse CVS repository is
implicitely
assumed to be "given" to the project under this
license. I bring this up because when discussing
external source being put in to the repository, there
are a couple of extra things to keep in mind.
As a
refresher, let me go through some simple scenarios/rules for licensing (I'm not
a lawyer,
so
this is my understanding of how things work. I've cc'ed John Duimovich on this
and
he may
have additional comments):
- When
becoming a commiter on Eclipse, any code you provide is provided under the
terms
-
Eclipse now has a requirement on the header to put on source files (see the
eclipse
project charter web page). This requirement is somewhat
new (a lot of the source
in the
Eclipse tree has not explicit mention of the CPL).
- It
is also assumed that the code provided is unencumbered by any other
licenses
- An
example of this is when QNX donated our source to Eclipse (back in June), it was
all
donated under the CPL license. The act of checking it in to dev.eclipse.org
indicated
our
acceptance of the CPL.
- In
keeping with that example, one of the files in our source (the "CPLUSPLUS.jj"
parser
javaCC
source file) was under a license that was incompatible with the CPL. Thus,
we
did
not (and could not) commit that file to the CDT CVS
repository.
A
couple of points to take away from this:
- We
need to start putting the right license headers in our new
source
files (it will take a while for us to go back and update all
of the
existing source)
- In
the case of 3rd-party code (or derivatives) being added to the CDT, we have
to be very
careful about licensing. The example of OpenC++ is a
good testcase; if any of the
original source (the Parser class) or a derivative work
(as opposed to a rewrite) is to go
into
the CDT repository, then we first have to ensure that the OpenC++
license is
compatible with the CPL license (looking at
the
license, I don't know -- we will need some legal
help on this).
I know
the latter may seem somewhat complicated and cumbersome, but I'd rather
we
go
through the pain up-front. Doug, if you'd like,
I'll coordinate with John D. to have someone
take a
look at the OpenC++ license; I can also take on those activities in the
future.
Cheers,
Sebastien
-----Original Message----- From:
Schaefer, Doug [mailto:dschaefer@xxxxxxxxxxxx] Sent: Tuesday, December
17, 2002 10:56 PM To: 'cdt-core-dev@xxxxxxxxxxx' Subject:
RE: [cdt-core-dev] Open C++ Parser
Done. I called
the branch NewParser1 since there really isn't very much left of the Open C++
parser other than most of the grammar. They still deserve the copyright
notice for the Parser class, however. I'll put the new work in the
source folder 'newparser' so you can easily find it. This will happen
over the next few days as we clean up our prototype to make it more
presentable. It should be under the tree for Christmas
;-)
Doug
Schaefer
Senior Staff Software
Engineer
Rational - the software development
company
Ottawa (Kanata), Ontario,
Canada
-----Original
Message----- From: Schaefer,
Doug [mailto:dschaefer@xxxxxxxxxxxx] Sent: Tuesday, December 17, 2002 9:39
PM To:
'cdt-core-dev@xxxxxxxxxxx' Subject: RE: [cdt-core-dev] Open C++
Parser
That's a great idea, Alain. I'll give it a
shot.
Doug Schaefer Senior Staff Software Engineer Rational - the software development
company Ottawa
(Kanata), Ontario, Canada
-----Original Message----- From: Alain Magloire [mailto:alain@xxxxxxx] Sent: Tuesday, December 17, 2002 7:38
PM To:
cdt-core-dev@xxxxxxxxxxx Subject: Re: [cdt-core-dev] Open C++
Parser
> > Hey all, > > > > We're having a lot of fun here porting the Open
C++ parser to Java for > potential use in the CDT. We've started
parsing some basic things like > stdio.h and performance up until now seems to be
reasonable. >
>
>
> However,
before we get too far, people on the conference call on Monday
> mentioned they had
experience with the Open C++ parser and were willing to
> share that with us.
If you were one of those persons, could you please drop
> us a line. I have
made some changes to make the parser do what we want > including: our own handwritten
scanner that also handles pre-processor > directives, using exceptions for backtracking,
replacing the Ptree with our > own JDT-like AST, amongst other minor
changes. In the end, we're really > only using the grammar and the strategy of
handwriting the parser. And it > seems to be working although there is a lot of
testing that needs to go > on... >
I would propose, if that can make things easier for
you, to make a branch, openc-cpp or something.
This would be a developement
branch. Then we can merge it back or not.
_______________________________________________
cdt-core-dev mailing
list cdt-core-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/cdt-core-dev
|