Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[technology-pmc] Advice needed w.r.t. to Eclipse's LGPL API Policy

Hi Technology PMC,

I need a bit of advice on Eclipse's LGPL API Policy, to move forward on
these two CQs [1, 2] for SpotBugs & the SpotBugs Eclipse plugin.

Here's the deal:

- Both SpotBugs and the SpotBugs Eclipse plugin are licensed under the LGPL.

- Code Recommenders wants to distribute an Eclipse plugin that plugs
into both SpotBugs and the SpotBugs Eclipse plugin, i.e., our code would
work against the Detector API of SpotBugs and the Bug Quickfix API for
the SpotBugs Eclipse plugin.

- Both APIs are made up of not just interfaces (in the Java sense), but
also abstract and concrete classes. Plus, there is a couple of plugin
descriptor files involved (findbugs.xml, messages.xml, bugrank.txt).

I unfortunately have a bit of trouble parsing our "Policy to Consider
the Limited Usage of LGPL APIs in Eclipse Projects" [3]:

> The Eclipse Foundation Intellectual Property Policy (“IP Policy”)
> states that, in limited circumstances, there may be instances where
> Eclipse Content based on Non-Eclipse Content may be approved for 
> distribution under terms and conditions other than the Project
> License(s). In accordance with the IP Policy, this policy describes
> the processes under which the use of LGPL APIs will be considered.

The first sentence suggests to me that this is only about cases where an
Eclipse project wants to distribute Eclipse Content under the LGPL. But
the second sentence only talks about the "use of LGPL APIs".

Next, I'm not 100% sure whether our distribution would met all
conditions. Specifically:

> i) The request must solely pertain to the use of APIs made available
> under the LGPL, and not functional code

Both SpotBugs and the SpotBugs Eclipse plug-in are distributed as single
JARs each, containing both implementation classes and what I as a
programmer would consider API. As a specific examples, every SpotBugs
detector needs to implement a Java interface (Detector2, [4]), which to
me clearly constitutes API. But to pass information about any found bugs
to SpotBugs, the detector needs to create instances of a concrete class
(BugInstance, [5]) that is (at 2533 lines) rather implementation-heavy
-- even although the detector needs to call just the constructor and a
single method on it (addAnnotations, [6]).

> ii) The project must create a binding to the APIs that contains
> portions of the API, thus permitting users of the binding to leverage
> familiarity with the API.

> v) The LGPL APIs must be maintained in a separate module that will
> form the binding. The binary code for the binding must be dynamically
> linked by any modules that use it and must be accompanied with
> notices that make it clear that the file is licensed under the LGPL.
> The source code for the binding must contain notices that make it
> clear that the file is licensed under the LGPL.

Does this mean I have to create a (small) wrapper around the parts of
the SpotBugs API that we plan to use? I certainly can create a
BugInstanceBuilder API that only uses the most API-like parts of
SpotBugs, but is this intention of the above two paragraphs?

Also, how to deal with non-code API like findbugs.xml descriptor files?

I hope you can help figure out what the LGPL API Policy means for us.

Best wishes,

Andreas

[1] <https://dev.eclipse.org/mhonarc/lists/technology-pmc/msg08809.html>
[2] <https://dev.eclipse.org/mhonarc/lists/technology-pmc/msg08806.html>
[3] <https://www.eclipse.org/org/documents/LGPL_API_Policy.pdf>
[4]
<https://github.com/spotbugs/spotbugs/blob/3.1.0_RC7/spotbugs/src/main/java/edu/umd/cs/findbugs/Detector2.java>
[5]
<https://github.com/spotbugs/spotbugs/blob/3.1.0_RC7/spotbugs/src/main/java/edu/umd/cs/findbugs/BugInstance.java>
[6]
<https://github.com/spotbugs/spotbugs/blob/3.1.0_RC7/spotbugs/src/main/java/edu/umd/cs/findbugs/BugInstance.java#L808>

-- 
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940

Attachment: signature.asc
Description: OpenPGP digital signature


Back to the top