| Re: [jakarta.ee-spec.committee] Code-First IP flow? |
|
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. 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. If you are worried about a patent claim from an unrelated 3rd
party, there's nothing anyone can do to prevent 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. 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. 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. |