Mike Milinkovich wrote on 05/30/2018 07:44 PM:
Bill,
Nothing you have said here is incorrect, but I think that it
is pushing the definition of IP perfection too far.
More detail below.
On 2018-05-30 7:21 PM, Bill Shannon wrote:
Before
the specification is created (approved?), can we have more than
one implementation of the API? If the first implementation has
patent IP, an independent implementation won't have rights to
that patent IP without a specification to license the IP, right?
An independent implementation of a new spec, or revisions to a
current one based on such open source contributions would be
based on APIs created by contributions to an open source
project. Let's assume that the projects in question are licensed
under either the APACHE-2.0 or EPL-2.0 licenses.
For there to be an infringement claim against an independent
implementation based on a source code contribution to either an
Apache or Eclipse project, the original contributor would have
to claim that the patent licenses in those open source licenses
did not cover the APIs in question. I am sure that lawyers can
tell you that it's possible. I am pretty sure that it has never
happened, and it is highly unlikely that it ever will.
When I argue about this sort of thing with Oracle legal, they're
never swayed by "but that will never happen"! :-)
If you are worried about a patent claim from an unrelated 3rd
party, there's nothing anyone can do to prevent that.
I'm not worried about that.
So
if Apache CXF updates the Eclipse JAX-RS API project before
proposing a JAX-RS specification update, the Eclipse Jersey
project might not be able to implement that updated API without
infringing the Apache CXF IP.
The only way that CXF could update the Eclipse JAX-RS API project
would be to make contributions to that project under the EPL-2.0
license. Although not perfect, I don't see the basis of a lawsuit
or alleged infringement based on an EPL-2.0 implementation derived
from an EPL-2.0-licensed API contribution. Possible? Sure.
Plausible? Meh.
A more formal way to handle this might be to put the API JAR
maintenance in the same project as the specification document
itself, and only evolve the JAR files as the specification
document evolves. This means that a participant would have to make
the changes, and the patents held by all of the participants would
be essential claims and therefore contributed.
Would they be "contributed" even before a specification is formally
proposed to include those changes? Does any update to the javadocs
(for example) count as a contribution to a spec, even before the
spec is formally proposed?
It
seems like we should encourage there to be multiple
implementations of a new or updated spec, to ensure that the new
APIs work as expected. Doesn't that mean we need a spec
proposal corresponding to those updates before they're
made, through which the IP will flow to the implementations?
Personally, I don't think so. Again, it is possible to construct
possible, but highly implausible, bad scenarios.
As long as all the lawyers are happy with the IP flow in this case,
I suppose I'm happy.
One thing that I really want to avoid is the mumbling that was
sometimes heard in the (JCP) past about whether an open source
implementation can be even started before the specification is
complete, since the patents aren't licensed until the spec was
complete.
Yes, I understand that we need to close that loophole. I assumed we
would close that loophole by making the IP available as soon as the
spec is started. Making the IP available before the spec is even
started seems trickier, but if the lawyers can figure out how to
make that work, great!
|
