osdir.com
mailing list archive

Subject: Re: CLA issues Was: java.sql.* - msg#00344

List: java.harmony.devel

Date: Prev Next Index Thread: Prev Next Index


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?
Yes No
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
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by