Re: [udig-dev] JCommon 1.0.16 Questions from IP review

[Jody Garnett <jody.garnett@xxxxxxxxx>]

So we got a bit more information: "The original files in question were authored by a person who cannot be traced

and we have some indication [1] determining applicable license may not be

possible."

[1] http://preciseinfo.org/Convert/Articles_Java/Package_Experts/Java-Package-Experts-080805094824.html

Reading that link (which appears to be scraped from a mailing list in order to show ads) shows a search for Nobuo Tamemasa not being successful.

A bit more research makes it look like Nobuo placed code examples on www.codeguru.com 

- https://subversion.assembla.com/svn/yanproject/Jars/jcommon-0.5.6/source/com/jrefinery/ui/BevelArrowIcon.java

 * This class (and also SortButtonRenderer) is based on original code by Nobuo Tamemasa (version

 * 1.0, 26-Feb-1999) posted on www.codeguru.com.

Feedback from the internet indicates the code is "open source" but does not really have a license and thus is open only in the sense you can read it, not in the sense you can add it to your own software.

- http://www.jfree.org/jcommon/api/src-html/org/jfree/ui/SortButtonRenderer.html

- https://subversion.assembla.com/svn/yanproject/Jars/jcommon-0.5.6/source/com/jrefinery/ui/BevelArrowIcon.java

The best example is from a site that gathered up Nobuo's examples since they have become "hard to find" on the internet.

- http://alvinalexander.com/java/swing/tame/

- http://alvinalexander.com/java/swing/tame/table/SortButtonRenderer.java.shtml

I am going to feed this bit of research back to the CQ ticket. But I am not really sure if I am helping or hindering, I would prefer to talk to the JCommon team and see if they have a bead on this stuff.

Jody

www.codeguru.com

Jody Garnett

On Tue, Jun 17, 2014 at 5:11 PM, Jody Garnett <jody.garnett@xxxxxxxxx> wrote:

Thanks Wayne I will wait for more information from the IP team ... perhaps after Luna release.

We keep getting stuck on these ones, my concern is we do not have the resources to implement any workaround(s) the IP team appears to expect. We spent six months figuring out a viable workaround for distributing the uDig application with JAI binaries for example.

Perhaps I am reading their expectations incorrectly.

--

Jody

Jody Garnett

On Tue, Jun 17, 2014 at 12:25 AM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:

Hi Jody.

The nature of the problem is not clear from the CQ. I assume that they were not able to confirm provenance of the file, or that there is some sort of copy and paste problem. It's probably best to avoid guessing.

Based on the discussion that I see here, the answer back to the IP Team is no: these classes are required and cannot be excluded. I'd finish that response with something along the lines of "What is the nature of the problem? What are our options?"

In the event that you can remove the files, you then need to represent the approved content somehow. You can just remove the offending files from the JAR and put that JAR directly into your project Git, or some other handy location for build. Alternatively, you can import just the source code for the approved parts and build the JAR yourself as part of your build script. Whatever makes the most sense for you and the team technically.

But before we get to that point, let's try to get a little more information out of the IP Team.

HTH,

Wayne

On 06/16/2014 05:32 AM, Jody Garnett wrote:

Suppose I may as well ask Wayne as our mentor.

Wayne I am unsure how to respond to an IP request to remove several files from a dependent library. What is the usual way to approach these kind of requests?

Jody Garnett

On Mon, Jun 16, 2014 at 7:24 PM, Jody Garnett <jody.garnett@xxxxxxxxx> wrote:

So I am not quite sure how to respond, I guess I best ask what is wrong with this classes and if the jfreechart team has been contacted :(

Note forking would not necessarily help, if something was wrong with how those classes was required. Well I suppose we could fork, fix those three (basically rewrite) and submit a patch.

I am not sure what the benefit of rewriting an interface is - okay enough discouragement from me I will try and learn more.

Jody Garnett

On Mon, Jun 16, 2014 at 6:29 PM, andrea antonello <andrea.antonello@xxxxxxxxx> wrote:

Question from review of JCommon 1.0.16:

From CQ7581:

Would like to understand if the project can exclude the following files from the jar:

org/jfree/ui/SortButtonRenderer.java

org/jfree/ui/BevelArrowIcon.java

org/jfree/ui/SortableTableHeaderListener.java

So how about it? Not sure what is up with those three files, the SortableTableHeaderListener interface sounds like it would be embedded pretty deep and may break something if not included. 

My understanding is we use JCommon as a requirement for JFreeChart?

Definitey, that one is a jcommons from the jfreechart project. I do not think that we are able to just pull out a few classes. Apart of the fact that then we would have to fork it. 

Andrea

 

Jody Garnett

_______________________________________________
udig-dev mailing list
udig-dev@xxxxxxxxxxxxxxxx
https://locationtech.org/mailman/listinfo/udig-dev

_______________________________________________
udig-dev mailing list
udig-dev@xxxxxxxxxxxxxxxx
https://locationtech.org/mailman/listinfo/udig-dev

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects