Skip to main content
Jump to: navigation, search

Architecture Council/Things Committers Should Know/Staging

< Architecture Council‎ | Things Committers Should Know
Revision as of 15:20, 9 December 2008 by (Talk | contribs) (Intellectual Property Due Diligence)

On this page, members of the Architecture Council assemble the notes that are sent out to committers as part of the Architecture Council/Things Committers Should Know effort, designed to arm Eclipse Committers with as much information about the Eclipse Development Process as possible.


Here are some ideas for future notices.

  • The My Foundation Portal
  • Contributing to Eclipse Corner
  • Contributing Resources
  • What is a Contribution Questionnaire?
  • What does the PMC do anyway?
  • What does the Eclipse Foundation Do?
  • Finding answers to legal questions
  • What belongs in the repository?
  • How do I contribute bundles to Orbit?
  • Aggregate your blog on planet Eclipse
  • How do I propose a new project?
  • How do I get free Eclipse Swag?
  • Getting started with CBI
  • Where I can find download statistics for my project?
  • How do I 'listen in' on Bugzilla conversations
  • How do I ensure API Compatibility in a new version
  • How do I treat dependencies to external libraries
  • How do I build a Community for my project
  • How do I encourage users to submit patches
  • How do I get useful bug reports from users
  • How do I get started with unit tests
  • How do I report a problem with Eclipse web infrastructure
  • How do I suggest an improvement to the Eclipse Foundation
  • Can I commit code that I wrote before becoming committer?
  • How do I get my Strings externalized and translated by the Community
  • Use Import-Package instead of Require-Bundle

December 2008

Intellectual Property Due Diligence

Hello Eclipse Committer. This is a first note in a new series of "Things Committers Should Know". Each month, the Architecture Council [1] sends out a short note describing some important aspect of life as an Eclipse committer. We hope that these notes are valuable and informative. For more information, please see the "Things Committers Should Know" page[2].

This month, we're going to touch briefly on Intellectual Property (IP) Due Diligence.

As an Eclipse Committer, you certainly know about IP Due diligence. But did you know that the "Eclipse Legal Process" Poster [3] (the definitive guide to the Eclipse IP Process) has been updated several times in the past year to pick up new special cases? In fact, the document is currently under review for its next iteration (see bug 256789 [4]). Did you also know that you're also required to move 3rd party dependencies [4]—whether or not they are to be included in your project's CVS/SVN repository or made accessible for download—through the IP Process?

In the coming months, we'll talk more specifically about these important resources. In the meantime, if you have any questions about the IP Due Diligence process, please ask your project leader, your PMC, or one of your project's Architecture Council mentors.

[1] [2] [3] [4] [5]


Do I need a Contribution Questionnaire?

Several of these "Things Committers Should Know" messages will deal focus on the Eclipse IP process. We'll start the series with the simplest possible scenario.

You're an Eclipse committer. You've created a contribution that provides some significant new functionality (i.e. it's more than just a couple of lines of code written as part of the ongoing development of an existing component). The new contribution was developed from scratch and you have consented to releasing it under the Eclipse Public License [2]. The contribution has been written under the supervision of the Project Management Committee (PMC), and contains no cryptography. If this describes what you've done, then a contribution questionnaire is not required; you can commit into CVS/SVN. You must record the contribution in the project's IP Log.

Here are some clarifications:

For IP due diligence purposes, the definition of contribution means any content, including code, data/metadata files, images, fonts, etc.

In this scenario, "developed from scratch" means that all content is new; no existing content from other sources has been included (i.e. no copy and paste). Further, "developed from scratch" means that the content does not rely on the IP of others. That is, the content relies only on existing

What it means for a contribution to have been developed "under the supervision of the PMC" can vary from PMC to PMC. "Supervision" could mean that the functionality provided by the contribution is described in your project plan or in an existing Bugzilla record. Alternatively, it could mean that the functionality has been openly discussed in your project's mailing list, or that the PMC has been directly informed of the ongoing work. Ultimately, you should ask your PMC how they define "supervision".

[1] [2]

Back to the top