Re: [ee4j-community] Retaining History for incoming EE4J Projects

[reza_rahman <reza_rahman@xxxxxxxxx>]

I agree we really need to try to focus on moving things forward quickly, even if it means making some short term reasonable sacrifices like the history. Most people outside of core committers really won't care much about this I suspect.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------

From: Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>

Date: 1/15/18 10:47 AM (GMT-05:00)

To: ee4j-community@xxxxxxxxxxx

Subject: Re: [ee4j-community] Retaining History for incoming EE4J Projects

I never said that this was a legal issue. It is not. Real time, effort, 
and resources are required to move the history and everyone wants to 
focus their energies on creating the future not dragging along the past.

The history will be publicly maintained where it is currently located.

On 2018-01-15 9:20 AM, David Lloyd wrote:
> IANAL, and this is my personal opinion (not necessarily that of my
> employer), but I have been doing OSS development for a long time now,
> and I've never even heard of any possible legal theory that would
> prevent history from being imported, even if there's a relicense.
> AFAIK you don't have to relicense the entire history (that's bananas);
> you're just relicensing the current version.
>
> If for example a given project (like this one) has been GPL licensed
> for its entire span of existence, then I'm pretty sure that given the
> entire _basis_ of the GPL, it's perfectly fine to redistribute the
> history.  In fact I'd say that in my personal opinion, redistributing
> the history is much truer to the _spirit_ of this license.
>
> As for the relicensing itself, only the lines in the _current version_
> are being relicensed, so it seems obvious to me that only the
> contributors of the lines of code that are in the version being
> relicensed would have to give consent to relicense it.  But in order
> to make this determination, the entire history of every file has to be
> examined _anyway_ (git blame is unfortunately not sufficient to the
> task).  From a practical perspective, it's probably safest to assume
> that every historical contributor would have to give consent unless it
> could be shown that all of a user's specific contributions are, by
> whatever legal standard, irrelevant.
>
> In other words, without a specific and complete legal explanation, I
> think everyone is 100% right to complain about this.  It's complete
> nonsense AFAICT.  The sources have _already_ been made GPL.
>
> On Sun, Jan 14, 2018 at 9:19 AM, Mrinal Kanti <mrinal.kanti@xxxxxxxxx> wrote:
>> When the older versions are removed, we may also lose track of the initial
>> contributors. Given the fact that earlier versions were released under GPLv2
>> (with CE) and newer versions can also be used under EPL, doesn't that
>> require consent from ALL initial contributors? I assume that Oracle would
>> have cleared all license related issues but want to know if it would suffice
>> for indemnification should the need ever arise in future. Do we have any
>> provision for tracking initial contributor consent publicly, just to be on
>> the safe side?
>>
>> -Mrinal
>>
>> On Sun, Jan 14, 2018 at 8:44 PM, Mike Milinkovich
>> <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>> Arjan,
>>>
>>> The work involved in vetting the code is definitely part of it. The other
>>> is that the license on this code is changing as part of moving to the
>>> Eclipse Foundation. Quite reasonably, no one wants to go to the bother of
>>> re-licensing history.
>>>
>>> Mike Milinkovich
>>> +1.613.220.3223
>>> mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
>>>
>>> On Jan 14, 2018, at 9:32 AM, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
>>>
>>> Hi,
>>>
>>> I of course hoped to see history as well, but my guess would be the reason
>>> being is that it's a lot of work to vet say 12k revisions (in say Mojarra)
>>> then it's to vet 1 revision. Older revisions may have copyrights and
>>> artefacts in them that latter revisions removed.
>>>
>>> That said, for some newer projects (Soteria comes to mind) the history
>>> should be clean already.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>> On Sun, Jan 14, 2018 at 1:07 PM, Markus KARG <markus@xxxxxxxxxxxxxxx>
>>> wrote:
>>>> Why is it impossible to retain the history? I mean, in what way is _some_
>>>> historic commit any different to the _latest_ commit?
>>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>> -Markus
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: ee4j-community-bounces@xxxxxxxxxxx
>>>> [mailto:ee4j-community-bounces@xxxxxxxxxxx] On Behalf Of Bill Shannon
>>>> Sent: Sonntag, 14. Januar 2018 02:52
>>>> To: EE4J community discussions; John D. Ament
>>>> Subject: Re: [ee4j-community] Retaining History for incoming EE4J
>>>> Projects
>>>>
>>>>
>>>>
>>>> Sorry, no, we're not able to retain the history.
>>>>
>>>>
>>>>
>>>> John D. Ament wrote on 01/13/2018 11:10 AM:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I'd like to know, is it possible to retain the history of projects moving
>>>> into EE4J?  The JSON-P project was imported, but it was imported without
>>>> history.  Yes, we can still see the history at
>>>> https://github.com/javaee/jsonp but I was kind of hoping these projects
>>>> coming in would retain the history behind the changes.
>>>>
>>>>
>>>>
>>>> John

_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community