[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Retaining History for incoming EE4J Projects

OK; though I must say that I for one have ported histories (even
between VCSes, even combining and dividing project histories) many,
many times and rarely had to spend more than on hour or two to do it
(for normal projects it's generally around 10 minutes' work).  Even my
insane script which mirrored the wacky OpenJDK "forest", merging it
all into a flat Git tree, wasn't all _that_ complex, so I have a
really hard time accepting this argument.

On Mon, Jan 15, 2018 at 9:47 AM, Mike Milinkovich
<mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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



-- 
- DML