Community
Participate
Working Groups
The Eclipse legal team is concerned that there are potential IP issues surrounding the EDP/EPL split in JGit/EGit and we've been trying to think up a solution. As it sits right now, there are potential issues around licensing of committer contributions. Commits into the repository are either under the EPL, or the EDL depending on which tree a committer is writing to. The potential for confusion here is a potential exposure. Also, it is difficult for an adopter of JGit to understand the source of the IP independent of the EGit piece. The easiest thing for us to do is to split EGit into two separate subprojects. From the EGit project point of view, I don't think that too much changes. i.e. you can keep the website, newsgroups, mailing lists, bugzilla, build, etc. the same as they are today. I am assuming that you have a natural division between EGit and JGit in the SCM. Specifically, that there are separate directories for each. If not, is this something that you can relatively easily do? From our point of view, we'd like to create two projects in the Foundation database: technology.egit.egit and technology.egit.jgit with corresponding "components" in IPZilla. We may need to try and do better with the "technology.egit.egit" name. In the process, we'd also wind up creating two different unix groups for the project committers: one for each of egit and jgit. By having these separate, your committers can create CQs against the "right" component. This will make generating an IP Log easier, and will make it easier to manage what's being used by what. By having separate unix groups we can have finer control over who is contributing what and under what license. There is some additional administrative overhead associated with this. Each of the new subprojects would have it's own entry in the portal and be responsible for maintaining it's own project data. A lot of that data, like project plans, can be shared; but it will still need to be supplied. This split may also result in some requirement for extra "piggyback" CQs in the case where both EGit and JGit are using the same third-party library. Further, by separating the project, new committer elections will have to be separate for EGit, JGit, and the parent. You may see this as a positive as it allows for a finer level of control of who has commit rights to what. This is a mistake made by the EMO during the project creation that we'd like to fix. With this bug, I invite the community to take the opportunity to understand what is happening and contribute (thereby satisfying the "openness and transparency" requirements) without having to go through the rigors of a restructuring review.
(In reply to comment #0) > The easiest thing for us to do is to split EGit into two separate subprojects. +1. Anything to make the IP process easier, its difficult as it is. > I am assuming that you have a natural division between EGit and JGit in the > SCM. Specifically, that there are separate directories for each. We already have a natural split of the repository, EGit in one directory and JGit in another. Actually, they are in two separate Git repositories with different histories. > From our point of view, we'd like to create two projects in the Foundation > database: technology.egit.egit and technology.egit.jgit with corresponding > "components" in IPZilla. We may need to try and do better with the > "technology.egit.egit" name. I can't say I have a better name than "technology.egit.egit" and "technology.egit.jgit". Repeating git in the egit.jgit name looks ugly, but repeating egit twice is worse. > In the process, we'd also wind up creating two > different unix groups for the project committers: one for each of egit and > jgit. When this split happens I think we want to just carry the current project committers into both groups. I see no reason to segment the committer community at this time.
(In reply to comment #1) > I can't say I have a better name than "technology.egit.egit" and > "technology.egit.jgit". Repeating git in the egit.jgit name looks ugly, but > repeating egit twice is worse. How about we create a new "Git Tools" container project? Then we move technology.egit to technology.gittools.egit and technology.gittools.jgit? Since you don't really use Subversion anyway, changing what you have in that repository should be low-impact on the community. > When this split happens I think we want to just carry the current project > committers into both groups. I see no reason to segment the committer > community at this time. And we make you the PL on both, right? Sounds like the rudiments of a plan. I've changed my mind about the restructuring review. I think we should do one. I'll take care of building the documentation. Let me know how you feel about the name suggestion and I'll run it past Janet to make sure it has legal legs.
(In reply to comment #2) > (In reply to comment #1) > > I can't say I have a better name than "technology.egit.egit" and > > "technology.egit.jgit". Repeating git in the egit.jgit name looks ugly, but > > repeating egit twice is worse. > > How about we create a new "Git Tools" container project? Then we move > technology.egit to technology.gittools.egit and technology.gittools.jgit? +1. > Since > you don't really use Subversion anyway, changing what you have in that > repository should be low-impact on the community. True. We can actually just scrap the current SVN repositories and create new ones from scratch under the new names. There's effectively only 2 relevant commits, the initial CQs, which are also easily recreatable from our Git history. > > When this split happens I think we want to just carry the current project > > committers into both groups. I see no reason to segment the committer > > community at this time. > > And we make you the PL on both, right? Yes. Though I'd love to eventually sell^Whand off PL on EGit to someone else, right now I think folks just want to be committers and avoid the overhead the PL hat carries with it. > I've changed my mind about the restructuring review. I think we should do one. > I'll take care of building the documentation. Hey, if you are going to build the documentation, that's like 90% of the work needed for a restructuring review, so great, I can't argue with that. :-)
(In reply to comment #0) > The Eclipse legal team is concerned that there are potential IP issues > surrounding the EDP/EPL split in JGit/EGit and we've been trying to think up a > solution. You probably meant EDL/EPL split ... > As it sits right now, there are potential issues around licensing of > committer contributions. Commits into the repository are either under the EPL, > or the EDL depending on which tree a committer is writing to. The potential > for confusion here is a potential exposure. Also, it is difficult for an > adopter of JGit to understand the source of the IP independent of the EGit > piece. I also sometimes felt that I have to be cautious not to unconciously cross the license borderline, doing the split will help making this more explicit. (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > I can't say I have a better name than "technology.egit.egit" and > > > "technology.egit.jgit". Repeating git in the egit.jgit name looks ugly, but > > > repeating egit twice is worse. > > > > How about we create a new "Git Tools" container project? Then we move > > technology.egit to technology.gittools.egit and technology.gittools.jgit? > +1 > > > When this split happens I think we want to just carry the current project > > > committers into both groups. I see no reason to segment the committer > > > community at this time. +1 > > And we make you the PL on both, right? > > Yes. Though I'd love to eventually sell^Whand off PL on EGit to someone else, > right now I think folks just want to be committers and avoid the overhead the > PL hat carries with it. +1 > > I've changed my mind about the restructuring review. I think we should do one. > > I'll take care of building the documentation. > > Hey, if you are going to build the documentation, that's like 90% of the work > needed for a restructuring review, so great, I can't argue with that. :-) thanks for doing the paper work :-)
(In reply to comment #2) > > How about we create a new "Git Tools" container project? Then we move > technology.egit to technology.gittools.egit and technology.gittools.jgit? Since Why don't we call the container project just "git". Having subprojects technology.git.egit and technology.git.jgit is for me the least annoying repetition-containing name.
(In reply to comment #5) > Why don't we call the container project just "git". Having subprojects > technology.git.egit and technology.git.jgit is for me the least annoying > repetition-containing name. + 1. This is exactly what came immediately to my mind.
(In reply to comment #5) > Why don't we call the container project just "git". Having subprojects > technology.git.egit and technology.git.jgit is for me the least annoying > repetition-containing name. I'm concerned about what the the name "Git" implies. (e.g. that the Git project itself is being developed here). There may also be some trademark issues (IANAL). What we're really building is tools for Git, so I believe that "Git Tools" is the best possible choice. FWIW, it really only affects the short names of the subprojects, the bundle and package namespaces will be unchanged by any of this.
+1 for the single container (as per older thoughts on thread http://dev.eclipse.org/mhonarc/lists/egit-dev/msg00071.html). As long you can make this convenient with IP process, etc. (In reply to comment #7) > I'm concerned about what the the name "Git" implies. (e.g. that the Git project > itself is being developed here). There may also be some trademark issues > (IANAL). What we're really building is tools for Git, so I believe that "Git > Tools" is the best possible choice. I agree that this is an issue. That's why we made the original "org.aspectj" and "org.eclipse.ajdt" split, to indicate that the latter was IDE support for AspectJ, not AspectJ itself.
> I'm concerned about what the the name "Git" implies. (e.g. that the Git project > itself is being developed here). There may also be some trademark issues ok, that argument I understand. If we have trademark issues here we should find another name. > (IANAL). What we're really building is tools for Git, so I believe that "Git > Tools" is the best possible choice. Somehow "tools for Git" sounds misleading to me? For me this sounds like we are building something which requires something else (e.g. some installation of git besides eclipse, some other plugin providing the real git). To be concrete: I would think as somebody sitting on the windows box that I have to have to install the windows-git (e.g.g msysgit) before I can make use of "Tools for git". But that's not correct. We are building one implementation of parts of the git standards (git protocol, git commands, git persistency (file system structure)). In the end that's a standalone implementation of a version control system and not a tool upon something else.
I have marked this bug as depending on Bug 278901. Our IPZilla currently does not include "3-deep" projects (e.g. technology.gittools.egit). There is little real value in making this change until we can have "3-deep" egit/jgit projects represented in IPZilla.
(In reply to comment #10) > I have marked this bug as depending on Bug 278901. Our IPZilla currently does > not include "3-deep" projects (e.g. technology.gittools.egit). There is little > real value in making this change until we can have "3-deep" egit/jgit projects > represented in IPZilla. I don't agree with the dependency you have identified. These seem like completely separate issues to me. I think we should continue to set these sub-projects up and get the necessary legal paperwork in place for them to move forward. IPZilla bugs for each subproject would be entered at the second tier for the time being until we resolve whether IPZilla will be expanded to support 3 or more tiers.
I need some consensus on a container project name before we can move ahead with the restructuring. I understand now why "Git Tools" is not palatable. I am concerned that we might get into trademark issues (or, at very least, confusion with the git-scm project), with "Git". How about "Git at Eclipse", short name "git@eclipse"? I'm not in love with it, and I'm not sure if our processes will choke on the '@' sign, but it seems doable. I am looking at this effort as that of fixing something we screwed up. I see no value in doing any kind of formal review. I just want to "git" this done (sorry for that). Sharon, technically, we can just rename the existing technology.egit and technology.jgit projects in the database; I'd rather do this than create new entries in the db if we can avoid it. Is there anything wrong with this approach from the POV of your process? i.e. committer paperwork and such? I assume that the git@eclipse project doesn't really need a website or any of its own resources. It will be represented in the portal and will need to have some minimal information provided, but will otherwise just be a convenient organizational piece. Short version: the NPPR will be simple for this project. Sharon, webmaster: Does anything else need to be done to make this happen?
(In reply to comment #12) > I need some consensus on a container project name before we can move ahead with > the restructuring. I understand now why "Git Tools" is not palatable. I am > concerned that we might get into trademark issues (or, at very least, confusion > with the git-scm project), with "Git". How about "Git at Eclipse", short name > "git@eclipse"? I'm not in love with it, and I'm not sure if our processes will > choke on the '@' sign, but it seems doable. AFAIK there is no trademark on "Git". But I do want to avoid confusion with the canonical C based implementation. "git@eclipse" is weird. It might be the best name we have come up with though. If we do that, I'd say we just always refer to it as "git@eclipse", and never as "Git at Eclipse". Hopefully it doesn't break any tools...
Would the following suggestion work for everyone using the technology umbrella: Technology.egit to remain as it was originally created to represent egit content solely licensed EPL. No change to DB or Ipzilla records. It has its own seperate repository. We could then create a new sub project under Technology for jgit. Jgit would receive its own database and ipzilla records with its own repository to represent the jgit content which is solely licensed EDL. An NPPR would be required to kick off this process for technology.jgit. The NPPR should include the same committers as originally indicated on the proposal for egit. Once the committers are processed and Webmaster sets up any infrastructure required, we would then be able to move the jgit CQs from tech.egit to tech.jgit and continue to process them. Assuming there are no restrictions on the dev process side, does this sound reasonable? Sharon
For completeness, the hypothetical new "JGit" project would just use the already-existing Git-based repository on egit.eclipse.org (so no new repository is required). The JGit and EGit projects can share the same project plan, website, mailing lists, newsgroups, forums, whatever. Or they can have distinct ones. Whatever works best. Is there any reason why we need to have a difficultly-named umbrella project?
(In reply to comment #15) > For completeness, the hypothetical new "JGit" project would just use the > already-existing Git-based repository on egit.eclipse.org (so no new repository > is required). The JGit and EGit projects can share the same project plan, > website, mailing lists, newsgroups, forums, whatever. Or they can have distinct > ones. Whatever works best. > > Is there any reason why we need to have a difficultly-named umbrella project? No. Robin and I both look at JGit as a separate project from EGit. Maybe the mistake here is, we didn't offer two projects to Eclipse, we only offered one, and tried to drag JGit along on the side. What probably makes the most sense is to just split JGit off into its own project under the Technology umbrella, as if we'd brought two separate unrelated projects to the foundation...
(In reply to comment #13) > "git@eclipse" is weird. It might be the best name we have come up with though. > If we do that, I'd say we just always refer to it as "git@eclipse", and never > as "Git at Eclipse". Hopefully it doesn't break any tools... It's a good point, Shawn. I'm fairly certain this will break some tools if we have to refer to it internally as *.git@eclipse and not *.gitateclipse . Regular expressions are definitely enforcing only [a-z-.] . Of course you can name the project whatever you want, but the internal coding we use (which is shown in some places) would have to exclude the @ sign.
Shawn, please complete an NPPR [1] for a new technology.jgit project. On behalf of the EMO, I am waiving the requirement for a second proposal period and creation review. A second "JGit", project should have been created at the outset and this action will correct that oversight. It is my opinion that the technology.jgit project *must* be created to enable JGit development to follow the EDP. Further, it is my opinion that the project, the project's committers, the community, and the eco-system will not be provided with any value by a formal proposal and creation/move review. Please set the project name to "technology.jgit", the top-level project to "technology.jgit". Please also provide a committer list that is a subset of the current set of EGit committers (please do not add any new committers at this point). If you wish to have additional mailing lists, Bugzilla components, or what-not, please feel free to specify that information. Please let Webmaster know, via a comment on this bug, if you want to use the same website for the JGit and EGit projects. For completeness... Webmaster,this project does not need a new CVS or SVN repository. Once the provisioning is complete, please inform Sharon Corbett of the CQs that need to move from EGit to JGit. Please let me know if you require any assistance in making any of this happen. Thanks, Wayne [1] http://www.eclipse.org/projects/project_provisioning_request.php
(In reply to comment #18) > Shawn, please complete an NPPR [1] for a new technology.jgit project. Done. > Please also provide a committer list that is a subset of the > current set of EGit committers (please do not add any new committers at this > point). Done. I actually left off Mik Kersten (only on EGit to do Mylyn integration) and Mykloa Nikishov (committer election is still pending, and most of his work has been in EGit so that's actually where I wanted him anyway at this point in time). > If you wish to have additional mailing lists, Bugzilla components, or what-not, > please feel free to specify that information. Please let Webmaster know, via a > comment on this bug, if you want to use the same website for the JGit and EGit > projects. I think we want to reuse the EGit website for JGit.
(In reply to comment #19) > (In reply to comment #18) > > Please let Webmaster know, via a > > comment on this bug, if you want to use the same website for the JGit and EGit > > projects. > > I think we want to reuse the EGit website for JGit. I take that back, we really do need a different website for JGit. People get confused about how JGit is different from EGit as it is. Part of the point of this project split is to highlight that JGit is special, and special considerations might be taking place.
Restructuring is complete, JGit project has had infrastructure configured.
