Start now. Prove the value of Rules.

There may not be complete consensus on these definition in the Business Rules space.  But here are my definitions:
- Business Rules:  Atomic units of business policy captured in a declarative non-programming manner.  Atomic meaning that they cannot be broken down into more granualar business policies.  Declarative meaning that they must be specified as "What Not How!":  What the business policies are as opposed to how they are to be processed.  Non-programming meaning accessible or transparent to business people.  Procedural programming skills shouldn't be required to capture business rules.  Here's an example of a declarative business rule:
> Informal specification:  Order total is computed by summing all its line item subtotals.
> Formal declarative specification:  Order.total = Order.item.subtotal -> sum
> Formal procedural specification: 
   Integer i
   Decimal tmp = 0
   For i = 1 to Order.item.size()
      tmp += Order.item[i].subtotal
   Next i
   Order.total = tmp
As you can see a procedural specification is simply programming.  Declarative business rules languages should not include flow control constructs such as while loops, for loops, etc.  This is because iteration across data elements must be controlled and performed by the rule engine.  Also the order of execution of rules should be controlled by the rule engine.  These two levels of control allow the rule engine to optimize the execution of the business rules for performance.  This is somewhat tantamount to SQL in RDBMS.  SQL is a semi-declarative language that is business friendly and allows the RDBMS optimizing compiler to figure out the most efficient means of processing the query in the database.
Furthermore, a purely declarative approach to business rules authring has the added benefit of allowing the rules to be automatically anaylzed for correctness:  completeness analysis, conflict analysis, endless loop analysis, etc.  This is important because traditional blackbox testing does not lend itself to achieving the highest level of quality, paricularly in real time.  Business rule changes may need to be deployed within minutes or hours and cannot require days or weeks of testing.  Automated white box analysis and testing is one of the big advantages of a declarative approach to rules.  Sophisticated tools can be used to aid the rule author in identifying and resolving logical flaws in their rules without requiring exhaustive and comprehensive blackbox testing.
- Business Rules Engine:  It is basically any execution environment which can process declarative business rules.  It's conceivable for business rules to be mapped to SQL and processed by an RDBMS for example meaning that the RDBMS could act like a rules engine. 
An inference engine is one type of engine that can be used for processing of business rules.  Some business rules products that have inference engines are ILOG, Fair Isaac Blaze Advisor (originally NeuronData), Jess, Drools, etc.  Inference engines weren't designed to be business rule engines.  They were designed for expert systems which had very different design criteria than business rule engines.  As a result, inference engine architectures, and their numerous pattern matching algorithms (e.g. RETE, TREAT, etc.), tend to scale well with increasing rule base size/complexity but not so well with increasing data size/complexity.  Once the expert systems space fell short of its lofty promises, many of the inference engine vendors searched for another business use case for their technology and eventually discovered business rules.  Business rules are declarative and inference engines, in their pure form, are declarative.  It seemed like a perfect match.  These vendors then spent the next decade making business rule engine and inference engine synonymous.  They tried to convince the market that you can't have business rules without an inference engine.  Corticon was the first vendor that challenged this conventional wisdom and many others followed suit.
For a more in-depth discussion of rule engines, please see another RulesWorld forum topic by me entitled "Sequential Business Rules - An oxymoron!". 
- Business Rules Management System (BRMS) - A BRMS is a tier of enterprise architecture which supports capturing, automating, reusing, analyzing, and enhancing business policies as business rules.  It must support the full rules development lifecycle.  A rule repository is generally required to manage the lifecycle.  There are two classes of BRMSs:
> Those that consider individual business rules as the unit of reuse and analysis.  Most traditional BRMSs such as ILOG and Fair Isaac Advisor fall in this camp.
> Those that consider business decisions as the unit of reuse and analysis.  Corticon falls in this camp.  We believe that individual business rules much like individual lines of Java code don't do anything.  A set of rules collectively implement a business decision and the decisions are the units of analysis and reuse, not individual rules.
- Rule IDE: Integrated Development Environments (IDEs) have traditionally been used for procedural programming.  But many rule vendors have adopted many of the features of IDEs for rules.  But 3GL IDE tools such as debuggers with breakpoints don't apply to a declarative business rules languages without forcing the rule engine to be more procedural and basterdizing the business rules approach.  This is analygous to using debuggers to debug SQL queries!  It is, however, possible to have a rule editor that is used in an IDE without making the rule language and methodology procedural. 
- Rule Editor: This is the metaphor used for authoring rules.  There have been numerous different metaphors used by rule vendors.  These include simple text editors, decision tables, decision trees, etc.  Each metaphor tends to have its own strenths and weaknesses.  But aside from text editors, most other metaphors tend to have limitations in what categories of business decisions they can be used to author rules for.  The only fully comprehensive rule authoring metaphor which can be used for modeling all categories of business decisions is the Corticon Rulesheet which is a patented extended decision table metaphor.  The beauty of the Corticon Rulesheet is that it allows the rule author to visualize logical connections across rules which tend to be obscured by many other metaphors.  The Rulesheet also lends itself beautifully to logical analysis of the rules since it can display the results of conflict and completeness checks to the rule author in a very intuitive manner.
Hope this helps.