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

Sounds like a plan.

Similar to the brand name question, I think EE4J is on a rather good track. There may be compromises but if e.g. a future version of the Java EE Security API (JSR 375) may add say
"javax.security.enterprise.authentication.mechanism.oauth" next to existing packages like "javax.security.enterprise.authentication.mechanism.http" like Will and others suggested in a different thread, this should answer at least one of the two main questions the Java EE Guardians' Open Letter tries to address. And IMO the more important question from a developer perspective. The other is more relevant for legal folks or compliance teams while the package name is crucial to developers writing code for Enterprise Java

Werner


On Mon, Jan 15, 2018 at 6:00 PM, <ee4j-community-request@xxxxxxxxxxx> wrote:
Send ee4j-community mailing list submissions to
    ee4j-community@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
    https://dev.eclipse.org/mailman/listinfo/ee4j-community
or, via email, send a message with subject or body 'help' to
    ee4j-community-request@eclipse.org

You can reach the person managing the list at
    ee4j-community-owner@eclipse.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ee4j-community digest..."


Today's Topics:

 Â1. Re: Retaining History for incoming EE4J Projects (reza_rahman)


----------------------------------------------------------------------

Message: 1
Date: Mon, 15 Jan 2018 11:11:23 -0500
From: reza_rahman <reza_rahman@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Retaining History for incoming EE4J
    Projects
Message-ID: <mailman.64.1516035613.21586.ee4j-community@xxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

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@eclipse-foundation.org> 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@eclipse-foundation.org> 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@eclipse-foundation.org
>>>
>>> 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@eclipse.org
>>>> [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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20180115/eaba513c/attachment.html>

------------------------------

_______________________________________________
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


End of ee4j-community Digest, Vol 5, Issue 26
*********************************************