JavaSound Was: java.sql.*

[Tor-Einar Jarnbjo <To...@Jarnbjo.de>]

Geir Magnusson Jr wrote:

> Lets discuss that here. :)  I didn't mean to ignore you - but two mail 
> machines were hard to follow.  I'm ready to join them into one, and 
> hopefully I'll stop dropping the ball :)

Ok, here are a snippet from the mail I sent you:

(Win32 partial implementation of JavaSound): 
http://jarnbjo.de/HJavaSound.zip

Installation is quite simple, just copy the following files to 
jre\lib\ext: dist/sound.jar, dist/vorbis-spi.jar
and the following files to some directory in the dll path (e.g. 
jre\bin\default): dist/sound.dll

The ant build file will build the HJavaSound Java source code and the C 
source using Borland's CBuilderX. I know it's not pretty, using hard 
coded paths etc., but it was just a quick hack to simplify the build 
process. The source code for the SPI and player are included in the 
vorbis-spi and spiplayer directories, for which no build files are 
included. Hope you don't mind that I already chose to put implementation 
specific classes in the org.apache.harmony.sound.sampled package.

Ogg/Vorbis files should now play with "java -jar dist/spiplayer.jar 
<filename>".

The Vorbis SPI for JavaSound and the SpiPlayer itself are actually parts 
of my project J-Ogg (ww.j-ogg.de), which is already released under an 
Apache-style license 
(http://www.j-ogg.de/core/main?/download-libraries.html).

Another issue with this is of course that the current VMs working with 
Harmony are not able to use Java 5 class files and implementing 
JavaSound for 1.4 and later extending it for Java 5 would be at least 
some unnecessary work. Are there any current plans for extending the VMs 
for Java 5 code?

> Which code, and what were the terms of the NDA?  The CLA is fairly 
> lightwieght.

Good questions, I honestly don't know. Working as a Java developer, I 
now and then need to trace into the original source code or take a look 
or two at the API implementation to realize why something is not working 
as I expect. As far as I can remember, I have not done this with Sun's 
JavaSound implementation. I don't have the NDA anymore, or am at least 
not able to find it, having moved around several times the last ten 
years. For working on a JavaSound implementation, it is probably 
irrelevant anyway, as JavaSound was not introduced until Java 1.3 and 
ought not to be covered by any agreement in Sun's NDA.

Tor

Re: NDA issues and acceptable use of sun source

[Leo Simons <ma...@leosimons.com>]

Thinking about this some more, it probably makes sense for Tor to contact
the software freedom law center at 

  http://www.softwarefreedom.org/
  help _at_ softwarefreedom _dot_ org

directly. Helping with this kind of stuff is an explicit part of their
mission. Everything that happens e.g. after a CLA / grant is signed is then
part of what Apache has all the right things in place for to take care of.

cheers,

Leo

Re: NDA issues and acceptable use of sun source

[Leo Simons <ma...@leosimons.com>]

On Mon, Feb 13, 2006 at 01:49:34PM +0100, Tor-Einar Jarnbjo wrote:
> Geir Magnusson Jr schrieb:
> >>>I'm not so sure - the fact that there's been that exposure under NDA 
> >>>means there can be no contribution in that area until the NDA 
> >>>problem is resolved.
> >>
> >>Which means? Do I have to solve it or are you willing to solve it?
> >
> >Geir Magnusson Jr wrote:
> >
> >Are you kidding?
> 
> Of course I am not kidding. I am willing to offer a contribution, you 
> say that an issue has to be resolved to allow that and I ask who is 
> going to do that. Do you expect from your contributors to pay for legal 
> advice to be allowed to do non-profit work for you?

I don't think there has ever been a (potential) contributor to the ASF
who has asked for monetary support and/or reimbursement to take care of
any kind of legal issue. There's certainly not an established process
for handling those requests.

But your question is phrased a little differently from how the ASF tends
to think about things. There is no-one doing non-profit work "for" the ASF,
everyone is doing it for their own reasons (usually: they enjoy it, think
its important, are paid to by a company, ..). The ASF provides a whole bunch
of stuff (like hosting, advice, oversight, legal framework) but historically
has tried to do most of that with as little money changing hands aas
possible.

The ASF does have legal counsel (quite a bit on a pro bono basis I
believe) for helping resolve these kinds of issues, but none of that
counsel is German.

Even if the ASF would be willing to pay for legal costs with regard to
figuring out your NDA situation (Really. I think we've never done that.
Never thought about it either. Probably never came up before...), the
person to take care of all the details would still be you. There is no
kind of "staff" around here that takes care of this. The entity responsible
in the end is also still you, and *you* assert you've taken care of things
properly by signing the CLA.

Me, *I* think it'd be great if sun legal would just take care of any
legal costs. I do promise to blog about it if they do :-)

Gotta love open source!

LSD

Re: NDA issues and acceptable use of sun source

[Dalibor Topic <ro...@kaffe.org>]

Leo Simons wrote:

>>In absence of court decisions, there is just the possibility to draw
>>very clear lines what constitutes safe contributions and what doesn't.
> 
> 
> I disagree that this is possible. Combining intellectual property laws
> from a variety of jurisdictions with many years of open source and closed
> source history means that there is no "safe" and there is no "very clear".
> 

Not looking is a very clear, bright line. You can't infringe copyrights
on works you don't access.

When we move away from that, we have to evaluate probabilities of
infringement, and enter the world of "* enough". Whether a case is "*
enough" largely depends on the case, what access has been made, what
legal arrangements covered it, and what part of the contribution may be
covered by those legal arrangements. We can draw some rather clear "safe
enough" lines, where we can reasonably hope to persuade judges, if it
becomes necessary.

For example, if a contributor only ever looked at Sun's pre 1.0 code,
and wanted to contribute an implementation of java.util.concurrent, it'd
be hard for anyone suing us to argue that we'd infringe their copyright
on something the contributor could not have possibly accessed in pre 1.0
code, since it wasn't there in the first place. No access, no infringement.

Of course, the other party could argue that the contributor breached
some contract with them, but that's between the contributor and whoever
he has contracts with. Given the plethora of Sun's licenses for Java
technology in the past 10 years ... way too much work for anyone but the
contributor to figure out, since the actual license texts change all the
time subtly (JRL is now at 1.6, for example).

> Anyhow. I feel that Harmony should not have a policy as strict as
> Classpath ("if you ever looked at sun source, you can't contribute"). I

The major difference between the two is that Classpath does not want to
have to deal with the probabilities. Mandating that people don't look is
a pretty good way to do that, as explained above.

Otoh, Harmony needs to weigh the probabilities, if it aspires to include
runtime developers who've been exposed to sun's source, so that means
making educated guesses.

I think Geir's policy document is a pretty good one for that goal.

> think that it is absurd if guys like Tor can't contribute a vorbis
> implementation (vorbis being something explicitly designed to be very
> free of legal mess, mind you) to an open source project just because 10
> years ago they looked at source code that had nothing to do with vorbis
> (which didn't exist at the time in any form!). 

The underlying issue is pretty simple: was there something he could
inadvertingly copy in the proprietary code bases he studied into his
implementation?

If no, great, we're game according to Harmony CLA rules.

If yes, it's a tough call, and needs to be checked, for example by
examining what the contributor studied, and whether those bits he
studied are similar to his contribution.

Sure, dealing with proprietary software is frustrating. People who've
entered those contracts back then surely felt that they were worthwhile
with all their consequences, though, and made those choices voluntarily.

Unfortunately, we can't help them retroactively change the consequences
of their choices: figuring out the precise legal status of their
contracts/NDAs/obligations is up to contributors, and whoever they have
contracts with to figure out.

cheers,
dalibor topic

Re: NDA issues and acceptable use of sun source

[Leo Simons <ma...@leosimons.com>]

On Mon, Feb 13, 2006 at 02:07:25AM +0000, Dalibor Topic wrote:
> There is no way the Harmony project can sort out the legal mess
> left behind Sun decisively, since any such thing would have to 
> play out in the courts, and we certainly don't want to have to 
> have to go there.

Very true.

<rant>
> In absence of court decisions, there is just the possibility to draw
> very clear lines what constitutes safe contributions and what doesn't.

I disagree that this is possible. Combining intellectual property laws
from a variety of jurisdictions with many years of open source and closed
source history means that there is no "safe" and there is no "very clear".

There is only ever "safe enough" and "clear enough". "safe enough" is
when our contributors do not have to worry about getting sued
and when its very unlikely that the ASF gets sued, or that when it is
sued, chances are it will win. "clear enough" is when our users are
also confident that they can use our software without worrying, our
developers and contributors understand what is going on, and even some
lawyer folk manage to figure it out.

The ASF has a 10 year track record of being on the right side of the "safe
enough" and "clear enough" line, as is evidenced by all the individuals
and companies contributing and/or using its software. Because the "legal
mess left behind Sun" is so big, Harmony is trying to be just a little more
on the "safe" side.

> Such lines are necessarily going to exclude more people that 
> court-tested lines would, but they have the killer feature of not
> having to go to court with Sun in order to determine them. ;)

Even going to court with Sun doesn't help make these kinds of lines all
that clear. We'd be going to court for many many years, and at the end of
all that, we'd *still* just be at "clear enough" and "safe enough".

Anyhow. I feel that Harmony should not have a policy as strict as
Classpath ("if you ever looked at sun source, you can't contribute"). I
think that it is absurd if guys like Tor can't contribute a vorbis
implementation (vorbis being something explicitly designed to be very
free of legal mess, mind you) to an open source project just because 10
years ago they looked at source code that had nothing to do with vorbis
(which didn't exist at the time in any form!). I understand that there
are some lawyers in the world who think that this is not absurd, but at
some point you should draw a very clear line around them and put up a big
sign "don't talk to these people. They've lost all sense of reality" and
get on with your life.
</rant>

- LSD

Re: NDA issues and acceptable use of sun source (was: Re: JavaSound Was: java.sql.*)

[Dalibor Topic <ro...@kaffe.org>]

Leo Simons <mail <at> leosimons.com> writes:

> If you put a notice to that effect onto your authorized contributor form
> that should probably be fine. If you can't remember what bit of the
> implementation you looked at, chances are you also don't remember what you
> saw! 

People have been successfully sued for violating copyrights of works that
they didn't mean to plagiarize, but had accessed prior to writing their own. 
See McCarthy's My Sweet Lord/He's So Fine lawsuit.

> Sun has repeatedly and publicly stated that this kind of usage should
> not "taint" a developer.

That does not necessarily mean that the developer is free to implement 
the same specs, and distribute the results under an open source license.
 
See http://lists.gnu.org/archive/html/classpath/2005-05/msg00014.html
for details.

N.B. Sun keeps updating the JRL so they may, or may not have fixed
some of the bugs I explain in that post.

> Chances are that the NDA is either
> 
>  * expired, or
>  * voided

The simplest way to know is for the contributor to check with Sun's 
legal department, since it's an agreement between him and Sun, I 
presume. If we can have that on paper, that's fine. If Sun or "the 
company owning Java after Sun collapses" ever hauls us into court, 
having a paper trail for contributions, in particular potentionally 
legally challenging ones, is a good thing.

> Since the JDK stuff is now all mostly out in the public, and most NDAs
> are effectively voided once the information they are meant to protect is
> available through other means not involving an NDA.

I'd be vary of that. What closed source licenses like JRL, SCSL, etc.
do is to partition people into two groups, one on the inside of the 
shared secret barrier, and one on the outside. If they had no intent 
to ever enforce the separation, there wouldn't be one.

If you parse the language in the SCSL carefully, it talks quite a 
bit about intellectual property rights, including trade secrets, 
and other proprietary technology licenses from the same company do 
the same. Whether partially more liberal proprietary source code 
licenses from the same source actually remove obligations from more 
restrictive ones, or keep piling requirements on top of each other, 
is very hard to say, since they are not designed to be replace 
another ... the SCSL never mentions the JRL as superceding it, for 
example. I'd be vary of guessing what the legal status is of 
someone who's bound by several such agreements and NDAs.

There is no way the Harmony project can sort out the legal mess
left behind Sun decisively, since any such thing would have to 
play out in the courts, and we certainly don't want to have to 
have to go there.

In absence of court decisions, there is just the possibility to draw
very clear lines what constitutes safe contributions and what doesn't.
Such lines are necessarily going to exclude more people that 
court-tested lines would, but they have the killer feature of not
having to go to court with Sun in order to determine them. ;)

cheers,
dalibor topic

Re: NDA issues and acceptable use of sun source (was: Re: JavaSound Was: java.sql.*)

[Dalibor Topic <ro...@kaffe.org>]

Leo Simons <mail <at> leosimons.com> writes:

> Since the JDK stuff is now all mostly out in the public, and most NDAs
> are effectively voided once the information they are meant to protect is
> available through other means not involving an NDA.

Missing the cue by just a few days, Sun Microsystems proudly unveiled a new
license to go with the 1.6 "Mustang" beta, and it contains the following,
explicit talk about trade secrets, and confidentiality agreements that seems to
fit the recently discussed NDA issues perfectly like a fist a glove:

"7.0 CONFIDENTIAL INFORMATION 
7.1 For purposes of this Agreement, "Confidential 
Information" means: (i) business and technical 
information and any source code or binary code, which 
Sun discloses to Licensee related to Licensed 
Software; (ii) Licensee's feedback based on Licensed 
Software; and (iii) the terms, conditions, and 
existence of this Agreement."

7.1.(iii) is the Mustang Fight Club rule:
The first rule of the Mustang licensee club: you don't talk about the Mustang
licensee club.

Fortunately, I have not accepted the license, so I can make fun of it.

"[...] Licensee's obligations 
regarding Confidential Information will expire no less 
than five (5) years from the date of receipt of the 
Confidential Information, except for Sun source code 
which will be protected in perpetuity."

A perpetual NDA on the included Sun source code with each purchase, yum.

"Licensee agrees 
that Licensed Software contains Sun trade secrets."

Et voila, explicit acknowledgement of trade secrets.

Taken from http://java.sun.com/javase/6/jdk-6-beta-license.txt

As long as Sun Microsystems believes to have some trade secrets in there, that
are worthy of such draconian measures, I don't think it's wise to assume that
NDAs with Sun have become invalid without proof to the contrary. 

The 1.6 beta license has a lot of other nice, comical gems, and is a wonderful
piece in the finest tradition of the earlier works from the same software
license publishing house. Use with care, avoid excessive exposure, etc.

cheers,
dalibor topic

Re: NDA issues and acceptable use of sun source

[Geir Magnusson Jr <ge...@pobox.com>]

Tor-Einar Jarnbjo wrote:
> Geir Magnusson Jr schrieb:
> 
>>>
>>>> I'm not so sure - the fact that there's been that exposure under NDA 
>>>> means there can be no contribution in that area until the NDA 
>>>> problem is resolved.
>>>
>>>
>>> Which means? Do I have to solve it or are you willing to solve it?
>>
>> Geir Magnusson Jr wrote:
>>
>> Are you kidding?
> 
> Of course I am not kidding. I am willing to offer a contribution, you 
> say that an issue has to be resolved to allow that and I ask who is 
> going to do that. Do you expect from your contributors to pay for legal 
> advice to be allowed to do non-profit work for you?

I expect contributors to understand their legal situation and represent 
it clearly and openly to the community.  There is no way I or anyone 
else here can figure out what kind of NDA you are under.

If you are comfortable that the NDA you signed could not have any 
bearing on the code you want to contribute, because of the fact that the 
area in which you contribute didn't exist at the time of the NDA and 
therefore couldn't be covered, than that seems like a reasonable 
explanation to me and there should be no problem.


geir

Re: NDA issues and acceptable use of sun source

[Tor-Einar Jarnbjo <To...@Jarnbjo.de>]

Geir Magnusson Jr schrieb:

>>
>>> I'm not so sure - the fact that there's been that exposure under NDA 
>>> means there can be no contribution in that area until the NDA 
>>> problem is resolved.
>>
>>
>> Which means? Do I have to solve it or are you willing to solve it?
>
> Geir Magnusson Jr wrote:
>
> Are you kidding?

Of course I am not kidding. I am willing to offer a contribution, you 
say that an issue has to be resolved to allow that and I ask who is 
going to do that. Do you expect from your contributors to pay for legal 
advice to be allowed to do non-profit work for you?

Tor

Re: NDA issues and acceptable use of sun source

[Geir Magnusson Jr <ge...@pobox.com>]

Tor-Einar Jarnbjo wrote:
> Geir Magnusson Jr wrote:
> 
>> I'm not so sure - the fact that there's been that exposure under NDA 
>> means there can be no contribution in that area until the NDA problem 
>> is resolved.
> 
> Which means? Do I have to solve it or are you willing to solve it?

Are you kidding?

> It is 
> of course silly of me not to keep legal agreements I have signed, but as 
> Leo pointed out, is Sun not anymore requiring an NDA for other people to 
> get access to the JDK source code.


> 
>> If what you were exposed to under the NDA has no tie to what you are 
>> offering, then the NDA is irrelevant for this.  For other things, you 
>> still have a problem, but if you've never seen Sun code in and around 
>> the sound API, then you are fine. 
> 
> I do of course not remember anything of any source code I had in my 
> hands ten years ago. I even quite often forget in the afternoon what I 
> did before lunch. I am not sure however, if Sun's lawyers believe that 
> and I rather don't want to find out.
> 
> Tor
> 
> 

Re: NDA issues and acceptable use of sun source

[Tor-Einar Jarnbjo <To...@Jarnbjo.de>]

Geir Magnusson Jr wrote:

> I'm not so sure - the fact that there's been that exposure under NDA 
> means there can be no contribution in that area until the NDA problem 
> is resolved.

Which means? Do I have to solve it or are you willing to solve it? It is 
of course silly of me not to keep legal agreements I have signed, but as 
Leo pointed out, is Sun not anymore requiring an NDA for other people to 
get access to the JDK source code.

> If what you were exposed to under the NDA has no tie to what you are 
> offering, then the NDA is irrelevant for this.  For other things, you 
> still have a problem, but if you've never seen Sun code in and around 
> the sound API, then you are fine. 

I do of course not remember anything of any source code I had in my 
hands ten years ago. I even quite often forget in the afternoon what I 
did before lunch. I am not sure however, if Sun's lawyers believe that 
and I rather don't want to find out.

Tor

Re: NDA issues and acceptable use of sun source

[Geir Magnusson Jr <ge...@pobox.com>]

Leo Simons wrote:
> Vorbis is cool :-)
> 
> Thanks for thinking this stuff through and being careful about protecting
> everyone and yourself from legal mess.
> 
> IANAL. Not Legal Advice.
> 
> On Sat, Feb 11, 2006 at 12:08:20AM +0100, Tor-Einar Jarnbjo wrote:
>>> Which code, and what were the terms of the NDA?  The CLA is fairly 
>>> lightwieght.
>> Good questions, I honestly don't know. Working as a Java developer, I 
>> now and then need to trace into the original source code or take a look 
>> or two at the API implementation to realize why something is not working 
>> as I expect. As far as I can remember, I have not done this with Sun's 
>> JavaSound implementation.
> 
> If you put a notice to that effect onto your authorized contributor form
> that should probably be fine. If you can't remember what bit of the
> implementation you looked at, chances are you also don't remember what you
> saw! Sun has repeatedly and publicly stated that this kind of usage should
> not "taint" a developer.

I'm not so sure - the fact that there's been that exposure under NDA 
means there can be no contribution in that area until the NDA problem is 
resolved.

> 
>> I don't have the NDA anymore, or am at least 
>> not able to find it, having moved around several times the last ten 
>> years.
> 
> Chances are that the NDA is either
> 
>  * expired, or
>  * voided
> 
> Since the JDK stuff is now all mostly out in the public, and most NDAs
> are effectively voided once the information they are meant to protect is
> available through other means not involving an NDA.

That is a possible out.

> 
> If you want to be certain, you can probably get in touch with sun legal
> and figure out if the NDA still applies, and to what. I would hope *they*
> still have a copy somewhere...
> 
>> For working on a JavaSound implementation, it is probably 
>> irrelevant anyway, as JavaSound was not introduced until Java 1.3 and 
>> ought not to be covered by any agreement in Sun's NDA.
> 
> That sounds sensible. Based on the situation you have outlined in your
> emails, I don't think we should have a problem integrating your stuff
> and having you work on it here. I for sure will get pissed if this would
> get us into any kind of trouble and be happy to throw some ASF legal
> cycles at getting justice! :-)

If what you were exposed to under the NDA has no tie to what you are 
offering, then the NDA is irrelevant for this.  For other things, you 
still have a problem, but if you've never seen Sun code in and around 
the sound API, then you are fine.

geir

NDA issues and acceptable use of sun source (was: Re: JavaSound Was: java.sql.*)

[Leo Simons <ma...@leosimons.com>]

Vorbis is cool :-)

Thanks for thinking this stuff through and being careful about protecting
everyone and yourself from legal mess.

IANAL. Not Legal Advice.

On Sat, Feb 11, 2006 at 12:08:20AM +0100, Tor-Einar Jarnbjo wrote:
> >Which code, and what were the terms of the NDA?  The CLA is fairly 
> >lightwieght.
> 
> Good questions, I honestly don't know. Working as a Java developer, I 
> now and then need to trace into the original source code or take a look 
> or two at the API implementation to realize why something is not working 
> as I expect. As far as I can remember, I have not done this with Sun's 
> JavaSound implementation.

If you put a notice to that effect onto your authorized contributor form
that should probably be fine. If you can't remember what bit of the
implementation you looked at, chances are you also don't remember what you
saw! Sun has repeatedly and publicly stated that this kind of usage should
not "taint" a developer.

> I don't have the NDA anymore, or am at least 
> not able to find it, having moved around several times the last ten 
> years.

Chances are that the NDA is either

 * expired, or
 * voided

Since the JDK stuff is now all mostly out in the public, and most NDAs
are effectively voided once the information they are meant to protect is
available through other means not involving an NDA.

If you want to be certain, you can probably get in touch with sun legal
and figure out if the NDA still applies, and to what. I would hope *they*
still have a copy somewhere...

> For working on a JavaSound implementation, it is probably 
> irrelevant anyway, as JavaSound was not introduced until Java 1.3 and 
> ought not to be covered by any agreement in Sun's NDA.

That sounds sensible. Based on the situation you have outlined in your
emails, I don't think we should have a problem integrating your stuff
and having you work on it here. I for sure will get pissed if this would
get us into any kind of trouble and be happy to throw some ASF legal
cycles at getting justice! :-)

cheers!

Leo