I suggest asking the contributor if they would mind changing the license to Apache V2, and doing the license header things, or giving us explicit permission to do that.
-Marshall On 5/11/2013 4:06 AM, Richard Eckart de Castilho wrote: > I'll try to pick up on this, since it blocks an uimaFIT issue (UIMA-2871 - > Remove JCasGenPomFriendly in favor of jcasgen-maven-plugin). > > I have a legal question on this one. There is no SGA here. I understand > that's not necessary, because the code is under a BSD license (Category A). > > Is it valid to remove the BSD header/license statements and apply the Apache > License header to all of these files? - Probably not. > > Do we have to maintain the original license headers in the files? - Probably > yes. > > Do we add an Apache header to the existing headers? - Probably yes? > > -- Richard > > Am 25.01.2013 um 14:57 schrieb Marshall Schor <[email protected]>: > >> +1 Marshall >> On 1/25/2013 5:57 AM, Jörn Kottmann wrote: >>> Any other opinions about where the plugin should be placed? >>> If not I will go ahead and put it into the uimaj/trunk. >>> >>> Jörn >>> >>> On 01/23/2013 02:10 PM, Jörn Kottmann wrote: >>>> On 01/23/2013 01:27 PM, Richard Eckart de Castilho wrote: >>>>> Hi, >>>>> >>>>> I'd guess that the jcasgen functionality of UIMA changes rarely. Maybe put >>>>> it to the sandbox at the same level as TextMarker or uimaFIT and give it a >>>>> separate release cycle? >>>> Just because it rarely changes we do not need to give it a separate release >>>> cycle, it would only be an issue if it would be the other way around. >>>> In my opinion it should go into uimaj/trunk so it can be released as part >>>> of >>>> the UIMA SDK. Having it there will avoid the overhead of an extra >>>> release and its version is always in sync with the UIMA SDK. >>>> >>>> Jörn >
