On Jul 17, 2005, at 4:51 AM, Niclas Hedhman wrote:
AFAIK, Copyright only applies to the RIGHT to COPY. Not the RIGHT to
CREATE,
or right to implement.
It applies to all of those things listed in the quote from the
Apache license that I sent:
to reproduce, prepare Derivative Works of, publicly
display, publicly perform, sublicense, and distribute the
Work and such Derivative Works
which of course is why I included that explicitly in our license.
Now, we are first and foremost looking at a scenario, where WE look at
the
specification, READ it, and MAKE something else that behaves as what
the
Specification describes. Where is the COPY in question?
We won't copy the material provided, i.e. the specification document.
Nothing
to copy, hence no Copyrights applies.
I don't believe that is true of the suggested code donation.
In any case, if you have the specification in front of you and
you read it while typing its contents into your code, that is copying.
The only piece that are up for debate is the Java interfaces and other
standard classes which are required to fulfill the Specification. To
me, this
sounds similar to the Sun restrictions on redistribution of certain
Java
platform extensions, that Geronimo re-implements as a convenience for
the
developers and edge-users. Does Geronimo have "prior written
authorization of
Sun and its licensors" for each of the APIs re-implemented, as the
Specification Copyright notice states? (template from "JavaMail API
Design
Specification")
Yes, Sun's copyright notice explicitly grants those rights to
anyone who develops an independent implementation and passes the
official TCK, as well as additional rights to implement experiments,
both of which have been used by Geronimo. Negotiating those rights
has been 99% of our Apache activity within the JCP.
Likewise, the JSPA and the specification license contains a specific
licenses to any patents owned by the EG that are necessarily
infringed by implementations, such that we don't get screwed by
submarine patents.
In contrast, the OSGi statement contains no license and explicitly
says that the alliance companies may sue us for implementing it.
Furthermore, the members agreement only supplies OSGi the right to
sublicense to the alliance members, and thus just having OSGi
agree to redistribution is not enough.
Does that make the problem clear?
I agree that this is not "friendly". But I am not arguing about the
Membership
agreement at all. It is not ASF's concern, as it is not a member and
have not
agree to any of that. That is something between the owner of any
"imported"
codebases (such as Oscar) and the OSGi Alliance and the other members.
I am
willing to start an implementation from scratch if that is necessary.
So if
that is the your concern, Justin, then please spell that out and not
put
everything into one basket and a categorical "Every member must sign
the
ICLA.".
I said every contributor must sign the CLA. If there are no
contributors (or only one) then that should be an easy process.
Honestly, looking at your responses for TSIK and this OSGi proposal, I
am
getting mixed signals. On one side; "Don't search for problems. Let
them come
to us, and we react on it." On the other; "If we look into the
membership
agreement, that one or more individuals has with the organization that
publishes the specification, then it is *possible* that there are
parts of
that specification that are not free of patent claims."
Why is OSGi's approach different from OASIS??
The OASIS WSS approach consists of a group of companies that have
publicly stated they will provide patent licenses *if* anything
in their specs turn out to be covered by their patents. The license
specifically says
1. Each Author grants permission to OASIS and OASIS members the
right to copy, display, perform, modify and distribute the
Web Services Security ("WS-Security") draft specification and to
authorize others to do the foregoing, in any medium without fee
or royalty, for the purpose of further developing the WS-Security
specification in the WSSTC as set forth in the draft WSS TC charter.
and in particular "authorize others to do the foregoing". That is
a copyright license. It goes on to say:
2. Each Author commits to grant a non sub-licenseable,
non-transferable license to third parties, under royalty-free
and other reasonable and non-discriminatory terms and conditions,
to certain of their respective patent claims that such Author
deems necessary to implement required portokions of the
WS-Security specification, provided a reciprocal license is
granted.
which *might* be an issue *if* any of those authors did have a
necessary patent claim *and* refused to give royalty-free terms.
As far as we have been able to determine, they have no such patents
and thus we cannot possibly infringe them, nor would we be subject
to penalties if they did have patents because we asked them and
they did not say "stop".
In contrast, the OSGi approach does not grant us permission to do
anything and explicitly states that others (including members)
may sue us for infringement. We have no permission to implement
under the OSGi "approach". Therefore, we need to obtain permission,
and our standard form for doing so is the CLA.
....Roy
