AW: [eclipsefp-develop] JParser - Packaging and licensing issues

[<lfr...@in...>]

Hi Thiago,

>I have used two tools while working on JParser, they are ANTLR(1) and
>the ANTLR Eclipse Plugin (2). The first is public domain code (under
>no particular license) and the second is released under the CPL.
>
>It happens that the generated parser code has a runtime dependency
>with the antlr library. This boils down to we needing to have the
>antlr.jar library at runtime, which takes us to the real issue: how
>should we make this library available?
>
>I have thought of three choices:
>
>- The first is to package the library directly inside our plugin(s).
>There are no legal restrictions to that, since the antlr jar is public
>domain, but it doesn't seem right to bundle library code directly
>alongside our own code.
>- The other is to depend on the antlr plugin and have it provide the
>library. I don't know if there are legal restrictions here, since the
>plugin is released under CPL and I really don't know it. But there is
>on technical drawback that is the library code comes together with
>plugin code that users don't necessarily need. This will consume
>unnecessary storage and can lead to plugin interaction issues.
Right, I believe the plugin has some code that allows users to edit grammar=
s in Java files, and perhaps it has even some dependency on JDT. The latter=
 we should avoid in any case, or we would force all our users to have Java =
Development support in their Haskell IDE ;-)

The licenses are compatible. The CPL is the predecessor of the EPL and is o=
nly slightly different (there is one clause that has to do with patents). P=
lus the EPL is under control of the independent Eclipse Foundation, whereas=
 the CPL is under control of IBM. Most Eclipse plugin projects have moved f=
rom the CPL to the EPL some time ago, as has Eclipse itself. Possibly the A=
ntlr plugin will do so too in the future. SO I would have no objection to l=
ink in CPL code.

>- The last one (very similar to the second one) is to make (or find --
>maybe the one from the antlr plugin itself) an antlr plugin that will
>only provide the needed jar (just like the org.junit plugin).
It would be possible to create such a plugin ourselves, but we would have t=
o name it something like org.antlr ..., and strictly speaking, we don't hav=
e the right to do that.

So I think the best approach will be to put the antlr lib into our parser p=
lugin. The common practice is to do so, usually in a lib/ folder, and to me=
ntion that there is 3rd-party code in the User Agreement (the text that you=
 see at install time) and put a file called antlr-license.txt into the plug=
in directory so that everybody that looks at it sees where the lib comes fr=
om. Eclipse does similarly with Apache code.

If you want to do so, just let me know, and I'll update the license code in=
 the right places. (Have to go over that anyway, I suppose, because some of=
 that may have changed with integrating the Haskell code for the parser :-)

If you are interested in further reading, there is some stuff at http://ecl=
ipse.org/legal/

Ciao,
Leif

>
>I would like to listen to your opinion on that.
>
>Cheers,
>
>Thiago Arrais
>
>(1) ANTLR Parser Generator - http://www.antlr.org/
>(2) ANTLR plugin for Eclipse - http://antlreclipse.sourceforge.net/
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
>Register for a JBoss Training Course.  Free Certification Exam
>for All Training Attendees Through End of 2005. For more info visit:
>http://ads.osdn.com/?ad_idv28&alloc_id=16845&op=3Dclick
>_______________________________________________
>eclipsefp-develop mailing list
>ecl...@li...
>https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop