|
|
Subject: Re: CLA issues Was: java.sql.* - msg#00344
List: java.harmony.devel
Tor-Einar Jarnbjo wrote:
Geir Magnusson Jr wrote:
Which code, and what were the terms of the NDA? The CLA is fairly
lightwieght.
What questions do you have for both?
I thought I better split this, to prevent the discussion from getting
too confusing. One thing I already pointed out with the Apache CLA is
that it is very biased towards US copyright law.
Well, the ASF is a US Corporation (non-profit) so those are the laws
under which we operate.
I am not a lawyer and I
really have no clue if US copyright law, German "Urheberrecht" or both
applies if I, living in Germany, am signing a contract with a US entity.
The most serious legal crash is probably section 2: "Grant of Copyright
License". First problem is, that I can't grant you anything I currently
don't have, a "copyright" on my work. The German counterpart, my
"Urheberrecht" is not transferable and any license I give to use,
redistribute, modify etc. the work may under some conditions be revoked.
Any contract diverging from these principles is in Germany legally void.
We aren't asking for a copyright transfer. You still retain any and all
copyright on the work. What you are doing is granting a license to the
work under the Apache License.
Another specific issue related to my proposed Vorbis SPI for JavaSound
donation, is if you regard third party source code to be classified as
format documentation . To be more exact, the Vorbis format specification
from the Xiph Foundation proved to contain several errors and their
attitude when me pointing it out was, that the reference decoder is the
only thing to be considered as a formal specification. This means of
course, that at least when it comes to some estimated 20-40 lines of
code, my Vorbis decoder implementation is at least "based on" the
reference decoder from Xiph, which is AFAIK released under a BSD license.
Yes, it's a BSD license. We think that's good :) We'd have no
problems, because the software that is derivative of a BSD work is yours
to license as you see fit. It's your IP.
Patent issues are also unclear to me. At this point the CLA is really
vague (§5), only demaning me to represent that my contribution is free
of any patents that "I am personally aware of". I have absolutely no
ability to judge on that, which of course fulfils, that I am not
personally aware of any claims, but depending on the contributors
knowledge on patent and license law, this paragraph lies somewhere
between meaningsless and very dependent on which country's patents and
licenses are to be considered.
Interesting. I find section 5 straightforward :
- you attest that your contributions are your original work (IOW, you
aren't contributing the work of someone else...)
- you will provide complete details of any kind of restrictions *that
you are aware of*. So this could be limits on the work because while it
is your original work, it was a work for hire - paid for and owned by
someone else. Or you implemented a patent.
If you don't know of any patents on the work, don't go looking for them.
We're not asking you to guarantee that there is no patent
encumbrance, just that if you know of any, you tell us.
geir
Was this page helpful?
Thread at a glance:
Previous Message by Date:
click to view message preview
Re: [jchevm] porting harmony classlib to JCHEVM
Weldon Washburn wrote:
I agree with most everything you said below. The Thread class is
indeed tricky. I can't look at GNU Classpath code as I am doing this
port. I want "kernel_path" to be Apache licensed and not a GPL
Not looking is certainly a safe approach, but make sure you don't
unnecessarily restrict yourself. Re-implemnting an algorithm "in your
own words" is not a copyright violation. And certainly there's less
at stake with Classpath code than e.g. looking at Sun's code.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Next Message by Date:
click to view message preview
Re: [jchevm] porting harmony classlib to JCHEVM
Geir Magnusson Jr wrote:
The state of things now is that the VM API defined by Classlib
is, well, not very well defined :-)
That's not actually true. We may be missing documentation or something,
but the Harmony Classlib VM API is a well-tested production API used by
IBM in their commercial VM offerings.
Hard to argue with that.
That's why the IBM J9 VM that was offered for evaluation purposes just
works.
My understanding from Weldon's emails is that while it's true that
Classlib runs on J9, that's true because J9 provides its own "glue" for
Classlib to make things work. To make Classlib run on any other VM,
there would still be a lot of work that needs to be done, which
fortunately Weldon is already forging ahead on (if you don't believe
me, compare the two java.lang.Thread classes I mentioned (Classpath's
and Classlib's) for example).
My comment is simply that there would be *lots* of benefits if the
bottom of this glue layer we're developing is the same as the VM API
that Classpath uses, and moreover this is actually the easiest path
to take anyway.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Previous Message by Thread:
click to view message preview
CLA issues Was: java.sql.*
Geir Magnusson Jr wrote:
Which code, and what were the terms of the NDA? The CLA is fairly
lightwieght.
What questions do you have for both?
I thought I better split this, to prevent the discussion from getting
too confusing. One thing I already pointed out with the Apache CLA is
that it is very biased towards US copyright law. I am not a lawyer and I
really have no clue if US copyright law, German "Urheberrecht" or both
applies if I, living in Germany, am signing a contract with a US entity.
The most serious legal crash is probably section 2: "Grant of Copyright
License". First problem is, that I can't grant you anything I currently
don't have, a "copyright" on my work. The German counterpart, my
"Urheberrecht" is not transferable and any license I give to use,
redistribute, modify etc. the work may under some conditions be revoked.
Any contract diverging from these principles is in Germany legally void.
Another specific issue related to my proposed Vorbis SPI for JavaSound
donation, is if you regard third party source code to be classified as
format documentation . To be more exact, the Vorbis format specification
from the Xiph Foundation proved to contain several errors and their
attitude when me pointing it out was, that the reference decoder is the
only thing to be considered as a formal specification. This means of
course, that at least when it comes to some estimated 20-40 lines of
code, my Vorbis decoder implementation is at least "based on" the
reference decoder from Xiph, which is AFAIK released under a BSD license.
Patent issues are also unclear to me. At this point the CLA is really
vague (§5), only demaning me to represent that my contribution is free
of any patents that "I am personally aware of". I have absolutely no
ability to judge on that, which of course fulfils, that I am not
personally aware of any claims, but depending on the contributors
knowledge on patent and license law, this paragraph lies somewhere
between meaningsless and very dependent on which country's patents and
licenses are to be considered.
Tor
Next Message by Thread:
click to view message preview
Re: CLA issues Was: java.sql.*
Geir Magnusson Jr wrote:
I thought I better split this, to prevent the discussion from getting
too confusing. One thing I already pointed out with the Apache CLA is
that it is very biased towards US copyright law.
Well, the ASF is a US Corporation (non-profit) so those are the laws
under which we operate.
Yes, but US laws are not the laws under which probably most of the
contributors are operating and not the laws applicable in most locations
where Apache software is being used. Copyright is a legal area where US
and British law deviate quite a lot from most other countries and
assuming or expecting that US law is relevant if it comes to a legal
dispute between e.g. a non-US contributor and a non-US software user or
a non-US owner of related intelletual rights, is IMHO rather naive.
License". First problem is, that I can't grant you anything I
currently don't have, a "copyright" on my work. The German
counterpart, my "Urheberrecht" is not transferable and any license I
give to use, redistribute, modify etc. the work may under some
conditions be revoked. Any contract diverging from these principles
is in Germany legally void.
We aren't asking for a copyright transfer. You still retain any and
all copyright on the work. What you are doing is granting a license
to the work under the Apache License.
Well, you skip the most important part, that some statements in the
paragraph are legally void in Germany, and probably most countries, not
having an Anglo-Saxon style copyright law. Most problematic are probably
the claims for an perpetual, irrevocable license and the claim for
sublicensing rights and rights to produce derivative works. I really
don't like to bother with legal regulations, but wether you or I like
it, this agreement won't hold if proven in a German court and a German
court will be responsible, if a German contributor for some reason
should decide to take legal actions against some other German entity,
which e.g. is producing, distributing or using a derivate work of the
contributor's original work. The word "German" in the last sentence may
be replaced with many other nationalities, without invalidating the
content :-/
Tor
|
|