You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by zoe slattery <zo...@googlemail.com> on 2006/02/09 11:32:30 UTC
Which applications run using Harmony classes?
I've tried to post this a couple of times from another mail account -
but it seems to go into a black hole - apologies if another two copies
turn up later :-(
I had some thoughts about running applications using Harmony classes.
Rather than just getting various applications and trying them with
Harmony I've been trying to see what classes they need.
For example, I downloaded and installed Derby then ran this:
java –verbose:class org.apache.derby.drda.NetworkServerControl start > dbc.txt
This generates a file (dbc.txt) showing all of the classes that get
loaded when Derby starts up. The format of the output is something
like this:
...
class load: java/io/BufferedOutputStream
class load: java/io/BufferedReader
class load: java/io/BufferedWriter
class load: java/io/ByteArrayInputStream
class load: java/io/ByteArrayOutputStream
class load: java/io/CharConversionException
class load: java/io/DataInput
class load: java/io/DataInputStream
...
using an IBM JRE - the format would likely be different using another
JRE. I ran a few more similar things to look at what classes get
loaded when you create tables, add rows etc. and then cat'd the class
load output into a single file. A more extensive test could be run by
using Derby unit tests.
I wrote a small perl script that extracts the names of all of the java
classes and then compares these against the API spec to generate a
final list of API classes that are used by an application. I'd be
happy to supply the perl, although it needs a bit of tidying up.
The next step would be to check how many of these exist in SVN already
- and maybe highlight the areas that we are missing? So far, the only
way I have found to get a list of files that exist in SVN is using
something like "svn list $repos_path -R", if anyone knows of a better
(faster) way I'd be happy to hear it.
Thoughts?
--
Zoe Slattery
IBM
Re: Which applications run using Harmony classes?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Answer in Perl :
#@))_!@#__;[0,1,2,]; $'{%_[$a]}
geir
Tim Ellison wrote:
> What is 'perl' ?
>
>
>
> (answers in 15 words or fewer)
>
> Tim
>
> zoe slattery wrote:
>> Finally - after a little more time than I'd thought - I have attached a
>> perl tool JIRA that takes a list of the classes that an application
>> loads (produced from java -verbose:class), compares them against the API
>> spec to filter out everything that isn't an API class, then compares the
>> list of API classes with what is currently in SVN to see what classes we
>> still need.
>>
>> Most of what I've put in JIRA is sample input, output and instructions.
>> I've only tested it on Linux.
>>
>> The sample output files that I've appended come from running Tomcat.
>>
>> Geir Magnusson Jr wrote:
>>>
>>> zoe slattery wrote:
>>>> I've tried to post this a couple of times from another mail account -
>>>> but it seems to go into a black hole - apologies if another two copies
>>>> turn up later :-(
>>>>
>>>> I had some thoughts about running applications using Harmony classes.
>>>> Rather than just getting various applications and trying them with
>>>> Harmony I've been trying to see what classes they need.
>>>>
>>>> For example, I downloaded and installed Derby then ran this:
>>>>
>>>> java –verbose:class org.apache.derby.drda.NetworkServerControl start
>>>>> dbc.txt
>>>> This generates a file (dbc.txt) showing all of the classes that get
>>>> loaded when Derby starts up. The format of the output is something
>>>> like this:
>>>>
>>>> ...
>>>> class load: java/io/BufferedOutputStream
>>>> class load: java/io/BufferedReader
>>>> class load: java/io/BufferedWriter
>>>> class load: java/io/ByteArrayInputStream
>>>> class load: java/io/ByteArrayOutputStream
>>>> class load: java/io/CharConversionException
>>>> class load: java/io/DataInput
>>>> class load: java/io/DataInputStream
>>>> ...
>>>>
>>>> using an IBM JRE - the format would likely be different using another
>>>> JRE. I ran a few more similar things to look at what classes get
>>>> loaded when you create tables, add rows etc. and then cat'd the class
>>>> load output into a single file. A more extensive test could be run by
>>>> using Derby unit tests.
>>>>
>>>> I wrote a small perl script that extracts the names of all of the java
>>>> classes and then compares these against the API spec to generate a
>>>> final list of API classes that are used by an application. I'd be
>>>> happy to supply the perl, although it needs a bit of tidying up.
>>> This is cool.
>>>
>>>> The next step would be to check how many of these exist in SVN already
>>>> - and maybe highlight the areas that we are missing?
>>> Yes!
>>>
>>>> So far, the only
>>>> way I have found to get a list of files that exist in SVN is using
>>>> something like "svn list $repos_path -R", if anyone knows of a better
>>>> (faster) way I'd be happy to hear it.
>>> Try to find a way to do it on a local checkout. We don't want to be
>>> banging the SVN repo like this. (We've been having problems lately w/
>>> people walking through the SVN repo, file after file, version after
>>> version, via the viewCVS interface. Not a good use of resources.
>>>
>>> This would be cool - I'd love to post these on the website, to let
>>> people know what they could do to help get their favorite app up and
>>> going.
>>>
>>> I wonder too if this could be combined with Gump somehow, so we can
>>> automatically test a large swatch of the "popular java app" world.
>>>
>>> geir
>>>
>>>> Thoughts?
>>>>
>>>> --
>>>> Zoe Slattery
>>>> IBM
>>>>
>>>>
>>
>
Re: Which applications run using Harmony classes?
Posted by zoe slattery <zo...@googlemail.com>.
Hi Nathan
Nathan Beyer wrote:
> Have you tried putting Xerces, Xalan and the xml-commons JARs in the
> bootclasspath? I believe the intent is to use that for the JAXP code anyway.
>
No and yes. I haven't because I wasn't actually trying to run Tomcat
with Harmony classes, I was just using the IBM SDK to see what classes
Tomcat loads (whilst doing a few basic tasks) and then work out which of
them we don't have in Harmony. You are completely right about the Xerces
and Xalan ones, I don't expect them ever to be in Harmony SVN. Perhaps I
should have taken them off the list.
The reason for looking at class loads like this is that I think it gives
us a good idea of what it's worth trying to run now and what should be
left until we have a more complete implementation. Does this make sense?
>
>> -----Original Message-----
>> From: zoe slattery [mailto:zoe.slattery@googlemail.com]
>> Sent: Monday, March 06, 2006 3:25 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: Which applications run using Harmony classes?
>>
>> I like Mark's answer best!
>>
>> Back to the subject though - I've updated the wiki (here
>> http://wiki.apache.org/harmony/Apache_Tomcat) with the list of API
>> classes that Tomcat loaded that aren't in SVN.
>>
>> Having Harmony-39 and Harmony-88 in SVN will make this list a lot
>> shorter :-).
>>
>>
>> Geir Magnusson Jr wrote:
>>
>>> Mark Hindess wrote:
>>>
>>>> On 03/03/06, Tim Ellison <t....@gmail.com> wrote:
>>>>
>>>>> What is 'perl' ?
>>>>> (answers in 15 words or fewer)
>>>>>
>>>> What you choose when you want to code something useful in 15 words or
>>>> fewer?
>>>>
>>>>
>>> A write-only, self-obfuscating programming language that relies on
>>> punctuation and side effects.
>>>
>>>
>
>
>
RE: Which applications run using Harmony classes?
Posted by Nathan Beyer <nb...@kc.rr.com>.
Have you tried putting Xerces, Xalan and the xml-commons JARs in the
bootclasspath? I believe the intent is to use that for the JAXP code anyway.
> -----Original Message-----
> From: zoe slattery [mailto:zoe.slattery@googlemail.com]
> Sent: Monday, March 06, 2006 3:25 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: Which applications run using Harmony classes?
>
> I like Mark's answer best!
>
> Back to the subject though - I've updated the wiki (here
> http://wiki.apache.org/harmony/Apache_Tomcat) with the list of API
> classes that Tomcat loaded that aren't in SVN.
>
> Having Harmony-39 and Harmony-88 in SVN will make this list a lot
> shorter :-).
>
>
> Geir Magnusson Jr wrote:
> >
> >
> > Mark Hindess wrote:
> >> On 03/03/06, Tim Ellison <t....@gmail.com> wrote:
> >>> What is 'perl' ?
> >>> (answers in 15 words or fewer)
> >>
> >> What you choose when you want to code something useful in 15 words or
> >> fewer?
> >>
> >
> > A write-only, self-obfuscating programming language that relies on
> > punctuation and side effects.
> >
Re: Which applications run using Harmony classes?
Posted by zoe slattery <zo...@googlemail.com>.
I like Mark's answer best!
Back to the subject though - I've updated the wiki (here
http://wiki.apache.org/harmony/Apache_Tomcat) with the list of API
classes that Tomcat loaded that aren't in SVN.
Having Harmony-39 and Harmony-88 in SVN will make this list a lot
shorter :-).
Geir Magnusson Jr wrote:
>
>
> Mark Hindess wrote:
>> On 03/03/06, Tim Ellison <t....@gmail.com> wrote:
>>> What is 'perl' ?
>>> (answers in 15 words or fewer)
>>
>> What you choose when you want to code something useful in 15 words or
>> fewer?
>>
>
> A write-only, self-obfuscating programming language that relies on
> punctuation and side effects.
>
Re: Which applications run using Harmony classes?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Mark Hindess wrote:
> On 03/03/06, Tim Ellison <t....@gmail.com> wrote:
>> What is 'perl' ?
>> (answers in 15 words or fewer)
>
> What you choose when you want to code something useful in 15 words or fewer?
>
A write-only, self-obfuscating programming language that relies on
punctuation and side effects.
Re: Which applications run using Harmony classes?
Posted by Mark Hindess <ma...@googlemail.com>.
On 03/03/06, Tim Ellison <t....@gmail.com> wrote:
>
> What is 'perl' ?
> (answers in 15 words or fewer)
What you choose when you want to code something useful in 15 words or fewer?
;-)
-Mark.
Re: Which applications run using Harmony classes?
Posted by Tim Ellison <t....@gmail.com>.
What is 'perl' ?
(answers in 15 words or fewer)
Tim
zoe slattery wrote:
> Finally - after a little more time than I'd thought - I have attached a
> perl tool JIRA that takes a list of the classes that an application
> loads (produced from java -verbose:class), compares them against the API
> spec to filter out everything that isn't an API class, then compares the
> list of API classes with what is currently in SVN to see what classes we
> still need.
>
> Most of what I've put in JIRA is sample input, output and instructions.
> I've only tested it on Linux.
>
> The sample output files that I've appended come from running Tomcat.
>
> Geir Magnusson Jr wrote:
>>
>>
>> zoe slattery wrote:
>>> I've tried to post this a couple of times from another mail account -
>>> but it seems to go into a black hole - apologies if another two copies
>>> turn up later :-(
>>>
>>> I had some thoughts about running applications using Harmony classes.
>>> Rather than just getting various applications and trying them with
>>> Harmony I've been trying to see what classes they need.
>>>
>>> For example, I downloaded and installed Derby then ran this:
>>>
>>> java –verbose:class org.apache.derby.drda.NetworkServerControl start
>>> > dbc.txt
>>>
>>> This generates a file (dbc.txt) showing all of the classes that get
>>> loaded when Derby starts up. The format of the output is something
>>> like this:
>>>
>>> ...
>>> class load: java/io/BufferedOutputStream
>>> class load: java/io/BufferedReader
>>> class load: java/io/BufferedWriter
>>> class load: java/io/ByteArrayInputStream
>>> class load: java/io/ByteArrayOutputStream
>>> class load: java/io/CharConversionException
>>> class load: java/io/DataInput
>>> class load: java/io/DataInputStream
>>> ...
>>>
>>> using an IBM JRE - the format would likely be different using another
>>> JRE. I ran a few more similar things to look at what classes get
>>> loaded when you create tables, add rows etc. and then cat'd the class
>>> load output into a single file. A more extensive test could be run by
>>> using Derby unit tests.
>>>
>>> I wrote a small perl script that extracts the names of all of the java
>>> classes and then compares these against the API spec to generate a
>>> final list of API classes that are used by an application. I'd be
>>> happy to supply the perl, although it needs a bit of tidying up.
>>
>> This is cool.
>>
>>>
>>> The next step would be to check how many of these exist in SVN already
>>> - and maybe highlight the areas that we are missing?
>>
>> Yes!
>>
>>> So far, the only
>>> way I have found to get a list of files that exist in SVN is using
>>> something like "svn list $repos_path -R", if anyone knows of a better
>>> (faster) way I'd be happy to hear it.
>>
>> Try to find a way to do it on a local checkout. We don't want to be
>> banging the SVN repo like this. (We've been having problems lately w/
>> people walking through the SVN repo, file after file, version after
>> version, via the viewCVS interface. Not a good use of resources.
>>
>> This would be cool - I'd love to post these on the website, to let
>> people know what they could do to help get their favorite app up and
>> going.
>>
>> I wonder too if this could be combined with Gump somehow, so we can
>> automatically test a large swatch of the "popular java app" world.
>>
>> geir
>>
>>>
>>> Thoughts?
>>>
>>> --
>>> Zoe Slattery
>>> IBM
>>>
>>>
>>
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Which applications run using Harmony classes?
Posted by zoe slattery <zo...@googlemail.com>.
Finally - after a little more time than I'd thought - I have attached a
perl tool JIRA that takes a list of the classes that an application
loads (produced from java -verbose:class), compares them against the API
spec to filter out everything that isn't an API class, then compares the
list of API classes with what is currently in SVN to see what classes we
still need.
Most of what I've put in JIRA is sample input, output and instructions.
I've only tested it on Linux.
The sample output files that I've appended come from running Tomcat.
Geir Magnusson Jr wrote:
>
>
> zoe slattery wrote:
>> I've tried to post this a couple of times from another mail account -
>> but it seems to go into a black hole - apologies if another two copies
>> turn up later :-(
>>
>> I had some thoughts about running applications using Harmony classes.
>> Rather than just getting various applications and trying them with
>> Harmony I've been trying to see what classes they need.
>>
>> For example, I downloaded and installed Derby then ran this:
>>
>> java –verbose:class org.apache.derby.drda.NetworkServerControl start
>> > dbc.txt
>>
>> This generates a file (dbc.txt) showing all of the classes that get
>> loaded when Derby starts up. The format of the output is something
>> like this:
>>
>> ...
>> class load: java/io/BufferedOutputStream
>> class load: java/io/BufferedReader
>> class load: java/io/BufferedWriter
>> class load: java/io/ByteArrayInputStream
>> class load: java/io/ByteArrayOutputStream
>> class load: java/io/CharConversionException
>> class load: java/io/DataInput
>> class load: java/io/DataInputStream
>> ...
>>
>> using an IBM JRE - the format would likely be different using another
>> JRE. I ran a few more similar things to look at what classes get
>> loaded when you create tables, add rows etc. and then cat'd the class
>> load output into a single file. A more extensive test could be run by
>> using Derby unit tests.
>>
>> I wrote a small perl script that extracts the names of all of the java
>> classes and then compares these against the API spec to generate a
>> final list of API classes that are used by an application. I'd be
>> happy to supply the perl, although it needs a bit of tidying up.
>
> This is cool.
>
>>
>> The next step would be to check how many of these exist in SVN already
>> - and maybe highlight the areas that we are missing?
>
> Yes!
>
>> So far, the only
>> way I have found to get a list of files that exist in SVN is using
>> something like "svn list $repos_path -R", if anyone knows of a better
>> (faster) way I'd be happy to hear it.
>
> Try to find a way to do it on a local checkout. We don't want to be
> banging the SVN repo like this. (We've been having problems lately w/
> people walking through the SVN repo, file after file, version after
> version, via the viewCVS interface. Not a good use of resources.
>
> This would be cool - I'd love to post these on the website, to let
> people know what they could do to help get their favorite app up and
> going.
>
> I wonder too if this could be combined with Gump somehow, so we can
> automatically test a large swatch of the "popular java app" world.
>
> geir
>
>>
>> Thoughts?
>>
>> --
>> Zoe Slattery
>> IBM
>>
>>
>
Re: CLA issues Was: java.sql.*
Posted by Leo Simons <ma...@leosimons.com>.
IANAL. This is not legal advice.
On Mon, Feb 13, 2006 at 11:59:48AM +0100, Tor-Einar Jarnbjo wrote:
> Leo Simons wrote:
>
> >I'll also request everyone tries to ensure that you do not try and
> >represent anything as legal "fact" unless its been thoroughly verified that
> >it is indeed rather certain that what is being said is undisputable. Also,
> >always try and provide as much references as possible.
> >
> The problem "root" lies back in the times when the first laws where
> written to protect intellectual property. In UK, copyright laws were
> written, which originally only regulated reproduction and publishing
> rights, while in France the laws were centered around the "droite
> d'auteur" or author's right. Later, copyright laws were only adopted in
> the countries most strongly influenced by the UK, e.g. USA and probably
> Canada, while most other countries adopted the French idea of generally
> protecting the author as a "static" owner of his intellecutal property.
> In Germany, the author's rights are so strong, that they even to some
> extend apply for works produced by an employee or as part of a paid
> assignment.
>
> The issues I'm pointing out are regulated like this in the German
> "Gesetz �ber Urheberrecht und verwandte Schutzrechte" ("Law on author's
> rights and related protective rights"):
>
> �29(1): Das Urheberrecht ist nicht �bertragbar, es sei denn, es wird in
> Erf�llung einer Verf�gung von Todes wegen oder an Miterben im Wege der
> Erbauseinandersetzung �bertragen.
>
> The author's right is not transferable, unless it is transfered to an
> inheritor in connection with the author's death.
>
> �� 41 and 42 are regulating the author's "R�ckrufsrecht" or "revokation
> right". �41 is regulating the case, in which an exclusive usage right is
> not being practised, while �42 is regulating the author's right to
> revoke a usage right, in case of "gewandelter �berzeugung", however that
> is to be translated properly to English. "Modified/changed belief or
> conviction" is a brave attempt. �42(2) regulates that the author's right
> to exercise his revokation right can not be excepted.
>
> �34 regulates the transfer of usage rights and sublicensing
> ("�bertragung von Nutzungsrechten"). Any such transfer must be agreed
> upon by the author, although it is restricted in which cases he may deny
> such transfer to take place. At least the way I interpret these
> regulations, it is not possible for the author to agree to a blanket
> sublicensing grant, as his rights depends on the exact conditions around
> the license transfer.
>
> Regulations on derivative works are spread across several paragraphs
> (��14, 23, 39, etc). As in the issue with �42, derivative works may not
> be produced or published if they are against the author's belief (which
> may change with time).
Yup, all that sounds pretty familiar, and thanks for writing it up. I
disagree with some of how you map these laws onto what is stated in the
Apache CLA, and I also don't think it necessarily results in the kinds of
problems that you are worrying about.
However, this is getting firmly off-topic for a "development" mailing list.
I'm sure we're boring everyone to death; lets take this discussion
elsewhere :-)
cheers,
Leo
Re: NDA issues and acceptable use of sun source
Posted by 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
Posted by 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: CLA issues Was: java.sql.*
Posted by Tor-Einar Jarnbjo <To...@Jarnbjo.de>.
Geir Magnusson Jr wrote:
> It's not OSS if the author can do that arbitrarily. Think about it -
> you could wait until something is really popular, and then go shake
> down every user using it...
Not necessarily the users directly, but at least the enity, which is
managing the reproduction and distribution rights. The point is to
guarantee the author an "adequate commision" if e.g. more copies of his
work are published than the author was able to expect when he granted
the original publishing license. The idea does not match very well with
free as in free beer, but this is indeed the legal situation in most
countries.
> Heh.
> Double heh.
Yes, heh.
Tor
Re: CLA issues Was: java.sql.*
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tor-Einar Jarnbjo wrote:
> Geir Magnusson Jr schrieb:
>
>> I would further argue that if the author must retain right to revoke
>> the license or have control over derivative works, then open source is
>> impossible in Germany.
>
> Obiously it is not, as long as the software users accept the potenial
> risk of having to replace the software with something else. The
> revokation right is not my interpretation, but very clearly stated in
> the law.
It's not OSS if the author can do that arbitrarily. Think about it -
you could wait until something is really popular, and then go shake down
every user using it...
>
>> Given that there is plenty of open-source activity in Germany - and
>> serious efforts - I think that we're misunderstanding something
>> fundamental about German copyright law.
>
> It is unfortunately not very uncommon that German companies have a
> policy not to use OS software at all, partly because of the unclear
> legal status and potential problems, which may arise with a legal
> dispute, partly because of other issues, e.g. not having anyone to sue
> if something goes wrong.
Heh.
> As I was working for Siemens 5-6 years ago,
> this limitiation was so strict, that we were not even allowed to use
> open source text editors (e.g. vi or Emacs) to write code, but were
> forced to use a very poor and annoying product, as there were not really
> many options when you have to find a commercial text editor for HP-UX.
Double heh.
geir
Re: CLA issues Was: java.sql.*
Posted by Tor-Einar Jarnbjo <To...@Jarnbjo.de>.
Geir Magnusson Jr schrieb:
> I would further argue that if the author must retain right to revoke
> the license or have control over derivative works, then open source is
> impossible in Germany.
Obiously it is not, as long as the software users accept the potenial
risk of having to replace the software with something else. The
revokation right is not my interpretation, but very clearly stated in
the law.
> Given that there is plenty of open-source activity in Germany - and
> serious efforts - I think that we're misunderstanding something
> fundamental about German copyright law.
It is unfortunately not very uncommon that German companies have a
policy not to use OS software at all, partly because of the unclear
legal status and potential problems, which may arise with a legal
dispute, partly because of other issues, e.g. not having anyone to sue
if something goes wrong. As I was working for Siemens 5-6 years ago,
this limitiation was so strict, that we were not even allowed to use
open source text editors (e.g. vi or Emacs) to write code, but were
forced to use a very poor and annoying product, as there were not really
many options when you have to find a commercial text editor for HP-UX.
Tor
Re: CLA issues Was: java.sql.*
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I think the best thing to do here is consult a German lawyer, or some
legal resource that has a clue about open source licensing. We aren't
going to be able to answer any of this here in a definitive way.
I will again note that for contributions made here, at the ASF, we do
not ask for copyright transfer, but simply a license to the work. (That
you have agreed to.)
I would further argue that if the author must retain right to revoke the
license or have control over derivative works, then open source is
impossible in Germany.
Given that there is plenty of open-source activity in Germany - and
serious efforts - I think that we're misunderstanding something
fundamental about German copyright law.
geir
Tor-Einar Jarnbjo wrote:
> Leo Simons wrote:
>
>> I'll also request everyone tries to ensure that you do not try and
>> represent anything as legal "fact" unless its been thoroughly verified
>> that
>> it is indeed rather certain that what is being said is undisputable.
>> Also,
>> always try and provide as much references as possible.
>>
> The problem "root" lies back in the times when the first laws where
> written to protect intellectual property. In UK, copyright laws were
> written, which originally only regulated reproduction and publishing
> rights, while in France the laws were centered around the "droite
> d'auteur" or author's right. Later, copyright laws were only adopted in
> the countries most strongly influenced by the UK, e.g. USA and probably
> Canada, while most other countries adopted the French idea of generally
> protecting the author as a "static" owner of his intellecutal property.
> In Germany, the author's rights are so strong, that they even to some
> extend apply for works produced by an employee or as part of a paid
> assignment.
>
> The issues I'm pointing out are regulated like this in the German
> "Gesetz über Urheberrecht und verwandte Schutzrechte" ("Law on author's
> rights and related protective rights"):
>
> §29(1): Das Urheberrecht ist nicht übertragbar, es sei denn, es wird in
> Erfüllung einer Verfügung von Todes wegen oder an Miterben im Wege der
> Erbauseinandersetzung übertragen.
>
> The author's right is not transferable, unless it is transfered to an
> inheritor in connection with the author's death.
>
> §§ 41 and 42 are regulating the author's "Rückrufsrecht" or "revokation
> right". §41 is regulating the case, in which an exclusive usage right is
> not being practised, while §42 is regulating the author's right to
> revoke a usage right, in case of "gewandelter Überzeugung", however that
> is to be translated properly to English. "Modified/changed belief or
> conviction" is a brave attempt. §42(2) regulates that the author's right
> to exercise his revokation right can not be excepted.
>
> §34 regulates the transfer of usage rights and sublicensing
> ("Übertragung von Nutzungsrechten"). Any such transfer must be agreed
> upon by the author, although it is restricted in which cases he may deny
> such transfer to take place. At least the way I interpret these
> regulations, it is not possible for the author to agree to a blanket
> sublicensing grant, as his rights depends on the exact conditions around
> the license transfer.
>
> Regulations on derivative works are spread across several paragraphs
> (§§14, 23, 39, etc). As in the issue with §42, derivative works may not
> be produced or published if they are against the author's belief (which
> may change with time).
>
> Tor
>
>
Re: CLA issues Was: java.sql.*
Posted by Tor-Einar Jarnbjo <To...@Jarnbjo.de>.
Leo Simons wrote:
>I'll also request everyone tries to ensure that you do not try and
>represent anything as legal "fact" unless its been thoroughly verified that
>it is indeed rather certain that what is being said is undisputable. Also,
>always try and provide as much references as possible.
>
The problem "root" lies back in the times when the first laws where
written to protect intellectual property. In UK, copyright laws were
written, which originally only regulated reproduction and publishing
rights, while in France the laws were centered around the "droite
d'auteur" or author's right. Later, copyright laws were only adopted in
the countries most strongly influenced by the UK, e.g. USA and probably
Canada, while most other countries adopted the French idea of generally
protecting the author as a "static" owner of his intellecutal property.
In Germany, the author's rights are so strong, that they even to some
extend apply for works produced by an employee or as part of a paid
assignment.
The issues I'm pointing out are regulated like this in the German
"Gesetz über Urheberrecht und verwandte Schutzrechte" ("Law on author's
rights and related protective rights"):
§29(1): Das Urheberrecht ist nicht übertragbar, es sei denn, es wird in
Erfüllung einer Verfügung von Todes wegen oder an Miterben im Wege der
Erbauseinandersetzung übertragen.
The author's right is not transferable, unless it is transfered to an
inheritor in connection with the author's death.
§§ 41 and 42 are regulating the author's "Rückrufsrecht" or "revokation
right". §41 is regulating the case, in which an exclusive usage right is
not being practised, while §42 is regulating the author's right to
revoke a usage right, in case of "gewandelter Überzeugung", however that
is to be translated properly to English. "Modified/changed belief or
conviction" is a brave attempt. §42(2) regulates that the author's right
to exercise his revokation right can not be excepted.
§34 regulates the transfer of usage rights and sublicensing
("Übertragung von Nutzungsrechten"). Any such transfer must be agreed
upon by the author, although it is restricted in which cases he may deny
such transfer to take place. At least the way I interpret these
regulations, it is not possible for the author to agree to a blanket
sublicensing grant, as his rights depends on the exact conditions around
the license transfer.
Regulations on derivative works are spread across several paragraphs
(§§14, 23, 39, etc). As in the issue with §42, derivative works may not
be produced or published if they are against the author's belief (which
may change with time).
Tor
Re: CLA issues Was: java.sql.*
Posted by Leo Simons <ma...@leosimons.com>.
Tor,
IANAL.
On Mon, Feb 13, 2006 at 01:34:15AM +0100, Tor-Einar Jarnbjo wrote:
> 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.
Just about every web hosting company out there and just about every
large software vendor out there ships or uses software licensed from the
Apache Software Foundation under the Apache License, version 2.0, which
is hence sublicensed under the Apache CLA and/or the Apache License from
the ASF its contributors. The german government is also well-known for
using a lot of ASF software!
Just about every huge software vendor out there that has employees in a
variety of countries has employees in a variety of countries which
contribute under this same CLA, often while being paid by that same company
to do so. Many of those vendors have also sent in CCLAs and or software
grants.
Some of the most skilled and knowledgeable intellectual property lawers,
both European and American, have reviewed and/or constantly review the
ASF its legal processes, documents, etc.
So, IMHO, while you certainly shouldn't trust me or my word or my opinion
to be correct when it comes to legal matters, if a document is up on
http://www.apache.org/licenses/
as "official" paperwork and is further considered "current best
practice", you should not have to worry about it being naive (even if you
should always worry about it being "right").
This is one of the major benefits of doing things under the wings of the
ASF - you get to worry just a little less about this stuff. The ASF paperwork
is about as close as you can get to a "standard", with the possible exception
of the FSF paperwork (in particular, you might be interested in
http://www.fsfeurope.org/projects/fla/fla.en.html
).
> >> 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 :-/
I don't know enough about law or legal systems to be able to dispute the
above, and I'm not going to try, but I do know that it does not match up
with what I've previously been told by a variety of people.
I believe current ASF counsel is all US-based.
I would suggest seeking legal advice from a lawyer specializing in how
open source licensing applies within German copyright law. I know there's
a lawyer or two here in The Netherlands that specialize in this kind of
licensing stuff, Germany must have some, too.
I'll also request everyone tries to ensure that you do not try and
represent anything as legal "fact" unless its been thoroughly verified that
it is indeed rather certain that what is being said is undisputable. Also,
always try and provide as much references as possible. There is enough
confusion with regard to all this legal stuff already, and we should make
sure we don't try to add to it.
cheers!
Leo
Re: CLA issues Was: java.sql.*
Posted by Tor-Einar Jarnbjo <To...@Jarnbjo.de>.
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
Re: CLA issues Was: java.sql.*
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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
Re: CLA issues Was: java.sql.*
Posted by Leo Simons <ma...@leosimons.com>.
Hi Tor-Einer,
I live in The Netherlands, which has all but identical copyright laws
to Germany. My parents live in Germany and have looked at this kind of
stuff before. I've talked to german ASF committers about legal stuff
before who have had their companies look at things.
I'm not a lawyer and this is not legal advice.
Blah Blah.
On Sat, Feb 11, 2006 at 12:47:20AM +0100, 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. 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.
Me neither, but I do know that at least the subset of international copyright
law that is common to both jurisdictions applies, which should be sufficient.
> 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.
Like Geir already mentioned, the CLA asks for a copyright license and not
a copyright transfer. This is not a problem under any law in any western
country.
I don't think the ASF CLA has ever been tested in a German court and I
somewhat doubt it ever will be. Legal departments from several German
software vendors have reviewed the CLA and then approved its signing by
their employees, which is probably as close as we can get to being "sure"
that it is "valid enough".
> 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.
This is fine. Even if you copy-pasted something like 20 lines, it is debatable
whether that's copyrightable work. Since we don't like debates, we can just
add the appropriate (copyright) notices and the like to the relevant source code
and NOTICE file(s) to comply with the BSD license.
> Patent issues are also unclear to me.
Yup, they're unclear to everyone, including most European software vendors
and the European Union. Big mess.
> 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.
Exactly. It makes big U.S. companies do a lot of work while it doesn't
cause a lot of headache for average joe hacker who hates thinking about
patents. Its by design; the main goal of clauses like this is to protect
ASF contributors and ASF users from worrying about patents.
hope this helps,
cheers,
Leo
CLA issues Was: java.sql.*
Posted by Tor-Einar Jarnbjo <To...@Jarnbjo.de>.
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
Re: NDA issues and acceptable use of sun source
Posted by 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
Posted by 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.*)
Posted by 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.*)
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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.*)
Posted by 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
JavaSound Was: java.sql.*
Posted by 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: java.sql.*
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tor-Einar Jarnbjo wrote:
> Geir Magnusson Jr wrote:
>
>> Yes, this would be the place. Sorry about that - I am in the middle
>> of a machine change, and email switch, so I've been an email blackhole
>> at times...
>
> So, I sent you a partial implementation of JavaSound and a Vorbis SPI,
> any interest?
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 :)
> One problem is of course, that I more than once have taken
> a look at Sun's source code for different reasons and even signed an NDA
> some ten years ago to get access to the source code for JDK 1.1. Your
> requirements in the contributor license agreement and questionnaire are
> IMHO rather vague.
Which code, and what were the terms of the NDA? The CLA is fairly
lightwieght.
What questions do you have for both?
geir
Re: java.sql.*
Posted by Tor-Einar Jarnbjo <To...@Jarnbjo.de>.
Geir Magnusson Jr wrote:
> Yes, this would be the place. Sorry about that - I am in the middle
> of a machine change, and email switch, so I've been an email blackhole
> at times...
So, I sent you a partial implementation of JavaSound and a Vorbis SPI,
any interest? One problem is of course, that I more than once have taken
a look at Sun's source code for different reasons and even signed an NDA
some ten years ago to get access to the source code for JDK 1.1. Your
requirements in the contributor license agreement and questionnaire are
IMHO rather vague.
Tor
Re: java.sql.*
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tor-Einar Jarnbjo wrote:
> Jeremy Huiskamp wrote:
>
>> Didn't say it was difficult, just that it's not trivial ;-) As in,
>> the javadocs don't tell me everything I could possibly need to know
>> to implement it. I'd love to take a crack at it, but I figured I'd
>> start with the really easy stuff. If you beat me to it then so much
>> the better :)
>
> I already thought about contributing some other stuff, but I am unsure
> if I fulfil the requirements for contributing (especially regarding
> exposure to Sun's source code). I sent a mail to Geir Magnusson about
> JavaSound implementation a few weeks ago, but didn't get any reaction.
> Perhaps it's better to discuss this here on the mailing list.
Yes, this would be the place. Sorry about that - I am in the middle of
a machine change, and email switch, so I've been an email blackhole at
times...
geir
>
> Tor
>
>
Re: java.sql.*
Posted by Tor-Einar Jarnbjo <To...@Jarnbjo.de>.
Jeremy Huiskamp wrote:
> Didn't say it was difficult, just that it's not trivial ;-) As in,
> the javadocs don't tell me everything I could possibly need to know
> to implement it. I'd love to take a crack at it, but I figured I'd
> start with the really easy stuff. If you beat me to it then so much
> the better :)
I already thought about contributing some other stuff, but I am unsure
if I fulfil the requirements for contributing (especially regarding
exposure to Sun's source code). I sent a mail to Geir Magnusson about
JavaSound implementation a few weeks ago, but didn't get any reaction.
Perhaps it's better to discuss this here on the mailing list.
Tor
Re: java.sql.*
Posted by zoe slattery <zo...@googlemail.com>.
Actually, we've been looking at contributing some stuff that we have
already got in this area - I'll let you know by Tuesday (latest). If we
can it would at least give you a head start on this and it would be
really great if you could help us improve what we have.
Jeremy Huiskamp wrote:
> On 10-Feb-06, at 1:14 PM, Tor-Einar Jarnbjo wrote:
>
>> Jeremy Huiskamp schrieb:
>>
>>> Would I be correct in assuming that the majority of java.sql would
>>> be trivial to implement by reading the javadocs (everything except
>>> DriverManager)? I can take a whack at the low hanging fruit this
>>> weekend.
>>
>> The java.sql package mostly contains interfaces, so it shouldn't be
>> too much work, but what's so difficult about the DriverManager. It
>> only has to manage a list of registered Driver implementations and
>> the getConnection methods should only iterate through the available
>> drivers, check if the URL is supported and if yes, delegate the call
>> to Driver#connect.
>
> Didn't say it was difficult, just that it's not trivial ;-) As in, the
> javadocs don't tell me everything I could possibly need to know to
> implement it. I'd love to take a crack at it, but I figured I'd start
> with the really easy stuff. If you beat me to it then so much the
> better :)
>
> Jeremy
>
>>
>> Tor
>>
>
>
Re: java.sql.*
Posted by Jeremy Huiskamp <jh...@uoguelph.ca>.
On 10-Feb-06, at 1:14 PM, Tor-Einar Jarnbjo wrote:
> Jeremy Huiskamp schrieb:
>
>> Would I be correct in assuming that the majority of java.sql would
>> be trivial to implement by reading the javadocs (everything
>> except DriverManager)? I can take a whack at the low hanging
>> fruit this weekend.
>
> The java.sql package mostly contains interfaces, so it shouldn't be
> too much work, but what's so difficult about the DriverManager. It
> only has to manage a list of registered Driver implementations and
> the getConnection methods should only iterate through the available
> drivers, check if the URL is supported and if yes, delegate the
> call to Driver#connect.
Didn't say it was difficult, just that it's not trivial ;-) As in,
the javadocs don't tell me everything I could possibly need to know
to implement it. I'd love to take a crack at it, but I figured I'd
start with the really easy stuff. If you beat me to it then so much
the better :)
Jeremy
>
> Tor
>
Re: java.sql.*
Posted by Tor-Einar Jarnbjo <To...@Jarnbjo.de>.
Jeremy Huiskamp schrieb:
> Would I be correct in assuming that the majority of java.sql would be
> trivial to implement by reading the javadocs (everything except
> DriverManager)? I can take a whack at the low hanging fruit this
> weekend.
The java.sql package mostly contains interfaces, so it shouldn't be too
much work, but what's so difficult about the DriverManager. It only has
to manage a list of registered Driver implementations and the
getConnection methods should only iterate through the available drivers,
check if the URL is supported and if yes, delegate the call to
Driver#connect.
Tor
java.sql.* (was: Re: Which applications run using Harmony classes?)
Posted by Jeremy Huiskamp <jh...@uoguelph.ca>.
Would I be correct in assuming that the majority of java.sql would be
trivial to implement by reading the javadocs (everything except
DriverManager)? I can take a whack at the low hanging fruit this
weekend.
Jeremy
On 10-Feb-06, at 12:05 PM, zoe slattery wrote:
> Upayavira wrote:
>> zoe slattery wrote:
>>
>>> OK - well - here is a plan.....
>>>
>>> I have these scripts in a "hacked together" state and they currently
>>> rely on reading the output from -verbose:class generated by an
>>> IBM JRE.
>>> Ideally I'd like them to be able to read a couple of different
>>> formats.
>>>
>>> If anyone is interested in knowing if their app would (in
>>> theory) run
>>> using Harmony classes open a JIRA called "Would $my_favourite_app
>>> run on
>>> Harmony?" and attach the output from "java -verbose:class
>>> $my_favourite_app". If this works I can pick up the output and
>>> use it to
>>> test the tool. Please would you also attach the output from "java
>>> -version"? I will append (or ask someone to append) a list of
>>> missing
>>> files to the JIRA.
>>>
>>> When I'm happy that my scripts work and I've tidied up the code I'll
>>> attach the source as a JIRA and write some instructions on how to
>>> use it.
>>>
>>> FWIW in looking at Derby, it looks as though we still need SQL
>>> (could
>>> have predicted that I suppose) and JNDI, but those seem to be all
>>> that
>>> are missing. I can send the list of missing classes to anyone that
>>> wants to verify this - it's just slightly too long to paste into
>>> mail
>>>
>>
>> Paste it on the wiki (wiki.apache.org/harmony/). I'd be curious to
>> see it.
>>
> Done - at the end of Tim's Apache Derby page: http://
> wiki.apache.org/harmony/Apache_Derby
>> Upayavira
>>
>>
>
Re: Which applications run using Harmony classes?
Posted by zoe slattery <zo...@googlemail.com>.
Upayavira wrote:
> zoe slattery wrote:
>
>> OK - well - here is a plan.....
>>
>> I have these scripts in a "hacked together" state and they currently
>> rely on reading the output from -verbose:class generated by an IBM JRE.
>> Ideally I'd like them to be able to read a couple of different formats.
>>
>> If anyone is interested in knowing if their app would (in theory) run
>> using Harmony classes open a JIRA called "Would $my_favourite_app run on
>> Harmony?" and attach the output from "java -verbose:class
>> $my_favourite_app". If this works I can pick up the output and use it to
>> test the tool. Please would you also attach the output from "java
>> -version"? I will append (or ask someone to append) a list of missing
>> files to the JIRA.
>>
>> When I'm happy that my scripts work and I've tidied up the code I'll
>> attach the source as a JIRA and write some instructions on how to use it.
>>
>> FWIW in looking at Derby, it looks as though we still need SQL (could
>> have predicted that I suppose) and JNDI, but those seem to be all that
>> are missing. I can send the list of missing classes to anyone that
>> wants to verify this - it's just slightly too long to paste into mail
>>
>
> Paste it on the wiki (wiki.apache.org/harmony/). I'd be curious to see it.
>
Done - at the end of Tim's Apache Derby page:
http://wiki.apache.org/harmony/Apache_Derby
> Upayavira
>
>
Re: Which applications run using Harmony classes?
Posted by Tim Ellison <t....@gmail.com>.
I did a simple test and put the results here:
http://wiki.apache.org/harmony/Apache_Derby
but it sounds like Zoe's approach is smarter.
Regards,
Tim
Upayavira wrote:
> zoe slattery wrote:
>> OK - well - here is a plan.....
>>
>> I have these scripts in a "hacked together" state and they currently
>> rely on reading the output from -verbose:class generated by an IBM JRE.
>> Ideally I'd like them to be able to read a couple of different formats.
>>
>> If anyone is interested in knowing if their app would (in theory) run
>> using Harmony classes open a JIRA called "Would $my_favourite_app run on
>> Harmony?" and attach the output from "java -verbose:class
>> $my_favourite_app". If this works I can pick up the output and use it to
>> test the tool. Please would you also attach the output from "java
>> -version"? I will append (or ask someone to append) a list of missing
>> files to the JIRA.
>>
>> When I'm happy that my scripts work and I've tidied up the code I'll
>> attach the source as a JIRA and write some instructions on how to use it.
>>
>> FWIW in looking at Derby, it looks as though we still need SQL (could
>> have predicted that I suppose) and JNDI, but those seem to be all that
>> are missing. I can send the list of missing classes to anyone that
>> wants to verify this - it's just slightly too long to paste into mail
>
> Paste it on the wiki (wiki.apache.org/harmony/). I'd be curious to see it.
>
> Upayavira
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Which applications run using Harmony classes?
Posted by Upayavira <uv...@odoko.co.uk>.
zoe slattery wrote:
> OK - well - here is a plan.....
>
> I have these scripts in a "hacked together" state and they currently
> rely on reading the output from -verbose:class generated by an IBM JRE.
> Ideally I'd like them to be able to read a couple of different formats.
>
> If anyone is interested in knowing if their app would (in theory) run
> using Harmony classes open a JIRA called "Would $my_favourite_app run on
> Harmony?" and attach the output from "java -verbose:class
> $my_favourite_app". If this works I can pick up the output and use it to
> test the tool. Please would you also attach the output from "java
> -version"? I will append (or ask someone to append) a list of missing
> files to the JIRA.
>
> When I'm happy that my scripts work and I've tidied up the code I'll
> attach the source as a JIRA and write some instructions on how to use it.
>
> FWIW in looking at Derby, it looks as though we still need SQL (could
> have predicted that I suppose) and JNDI, but those seem to be all that
> are missing. I can send the list of missing classes to anyone that
> wants to verify this - it's just slightly too long to paste into mail
Paste it on the wiki (wiki.apache.org/harmony/). I'd be curious to see it.
Upayavira
Re: Which applications run using Harmony classes?
Posted by zoe slattery <zo...@googlemail.com>.
OK - well - here is a plan.....
I have these scripts in a "hacked together" state and they currently
rely on reading the output from -verbose:class generated by an IBM JRE.
Ideally I'd like them to be able to read a couple of different formats.
If anyone is interested in knowing if their app would (in theory) run
using Harmony classes open a JIRA called "Would $my_favourite_app run on
Harmony?" and attach the output from "java -verbose:class
$my_favourite_app". If this works I can pick up the output and use it to
test the tool. Please would you also attach the output from "java
-version"? I will append (or ask someone to append) a list of missing
files to the JIRA.
When I'm happy that my scripts work and I've tidied up the code I'll
attach the source as a JIRA and write some instructions on how to use it.
FWIW in looking at Derby, it looks as though we still need SQL (could
have predicted that I suppose) and JNDI, but those seem to be all that
are missing. I can send the list of missing classes to anyone that
wants to verify this - it's just slightly too long to paste into mail
Geir Magnusson Jr wrote:
>
>
> zoe slattery wrote:
>> I've tried to post this a couple of times from another mail account -
>> but it seems to go into a black hole - apologies if another two copies
>> turn up later :-(
>>
>> I had some thoughts about running applications using Harmony classes.
>> Rather than just getting various applications and trying them with
>> Harmony I've been trying to see what classes they need.
>>
>> For example, I downloaded and installed Derby then ran this:
>>
>> java –verbose:class org.apache.derby.drda.NetworkServerControl start
>> > dbc.txt
>>
>> This generates a file (dbc.txt) showing all of the classes that get
>> loaded when Derby starts up. The format of the output is something
>> like this:
>>
>> ...
>> class load: java/io/BufferedOutputStream
>> class load: java/io/BufferedReader
>> class load: java/io/BufferedWriter
>> class load: java/io/ByteArrayInputStream
>> class load: java/io/ByteArrayOutputStream
>> class load: java/io/CharConversionException
>> class load: java/io/DataInput
>> class load: java/io/DataInputStream
>> ...
>>
>> using an IBM JRE - the format would likely be different using another
>> JRE. I ran a few more similar things to look at what classes get
>> loaded when you create tables, add rows etc. and then cat'd the class
>> load output into a single file. A more extensive test could be run by
>> using Derby unit tests.
>>
>> I wrote a small perl script that extracts the names of all of the java
>> classes and then compares these against the API spec to generate a
>> final list of API classes that are used by an application. I'd be
>> happy to supply the perl, although it needs a bit of tidying up.
>
> This is cool.
>
>>
>> The next step would be to check how many of these exist in SVN already
>> - and maybe highlight the areas that we are missing?
>
> Yes!
>
>> So far, the only
>> way I have found to get a list of files that exist in SVN is using
>> something like "svn list $repos_path -R", if anyone knows of a better
>> (faster) way I'd be happy to hear it.
>
> Try to find a way to do it on a local checkout. We don't want to be
> banging the SVN repo like this. (We've been having problems lately w/
> people walking through the SVN repo, file after file, version after
> version, via the viewCVS interface. Not a good use of resources.
>
Agreed - I did try the svn list command once and realised that it wasn't
going to be practical. It's easy to do on a local checkout.
> This would be cool - I'd love to post these on the website, to let
> people know what they could do to help get their favorite app up and
> going.
>
> I wonder too if this could be combined with Gump somehow, so we can
> automatically test a large swatch of the "popular java app" world.
>
I don't know but would be happy to look (later)
>>
>> Thoughts?
>>
>> --
>> Zoe Slattery
>> IBM
>>
>>
>
Re: Which applications run using Harmony classes?
Posted by Tim Ellison <t....@gmail.com>.
Would be good to get Japitools reports going on the Harmony codebase too.
Regards,
Tim
Geir Magnusson Jr wrote:
>
>
> zoe slattery wrote:
>> I've tried to post this a couple of times from another mail account -
>> but it seems to go into a black hole - apologies if another two copies
>> turn up later :-(
>>
>> I had some thoughts about running applications using Harmony classes.
>> Rather than just getting various applications and trying them with
>> Harmony I've been trying to see what classes they need.
>>
>> For example, I downloaded and installed Derby then ran this:
>>
>> java –verbose:class org.apache.derby.drda.NetworkServerControl start >
>> dbc.txt
>>
>> This generates a file (dbc.txt) showing all of the classes that get
>> loaded when Derby starts up. The format of the output is something
>> like this:
>>
>> ...
>> class load: java/io/BufferedOutputStream
>> class load: java/io/BufferedReader
>> class load: java/io/BufferedWriter
>> class load: java/io/ByteArrayInputStream
>> class load: java/io/ByteArrayOutputStream
>> class load: java/io/CharConversionException
>> class load: java/io/DataInput
>> class load: java/io/DataInputStream
>> ...
>>
>> using an IBM JRE - the format would likely be different using another
>> JRE. I ran a few more similar things to look at what classes get
>> loaded when you create tables, add rows etc. and then cat'd the class
>> load output into a single file. A more extensive test could be run by
>> using Derby unit tests.
>>
>> I wrote a small perl script that extracts the names of all of the java
>> classes and then compares these against the API spec to generate a
>> final list of API classes that are used by an application. I'd be
>> happy to supply the perl, although it needs a bit of tidying up.
>
> This is cool.
>
>>
>> The next step would be to check how many of these exist in SVN already
>> - and maybe highlight the areas that we are missing?
>
> Yes!
>
>> So far, the only
>> way I have found to get a list of files that exist in SVN is using
>> something like "svn list $repos_path -R", if anyone knows of a better
>> (faster) way I'd be happy to hear it.
>
> Try to find a way to do it on a local checkout. We don't want to be
> banging the SVN repo like this. (We've been having problems lately w/
> people walking through the SVN repo, file after file, version after
> version, via the viewCVS interface. Not a good use of resources.
>
> This would be cool - I'd love to post these on the website, to let
> people know what they could do to help get their favorite app up and going.
>
> I wonder too if this could be combined with Gump somehow, so we can
> automatically test a large swatch of the "popular java app" world.
>
> geir
>
>>
>> Thoughts?
>>
>> --
>> Zoe Slattery
>> IBM
>>
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Which applications run using Harmony classes?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
zoe slattery wrote:
> I've tried to post this a couple of times from another mail account -
> but it seems to go into a black hole - apologies if another two copies
> turn up later :-(
>
> I had some thoughts about running applications using Harmony classes.
> Rather than just getting various applications and trying them with
> Harmony I've been trying to see what classes they need.
>
> For example, I downloaded and installed Derby then ran this:
>
> java –verbose:class org.apache.derby.drda.NetworkServerControl start > dbc.txt
>
> This generates a file (dbc.txt) showing all of the classes that get
> loaded when Derby starts up. The format of the output is something
> like this:
>
> ...
> class load: java/io/BufferedOutputStream
> class load: java/io/BufferedReader
> class load: java/io/BufferedWriter
> class load: java/io/ByteArrayInputStream
> class load: java/io/ByteArrayOutputStream
> class load: java/io/CharConversionException
> class load: java/io/DataInput
> class load: java/io/DataInputStream
> ...
>
> using an IBM JRE - the format would likely be different using another
> JRE. I ran a few more similar things to look at what classes get
> loaded when you create tables, add rows etc. and then cat'd the class
> load output into a single file. A more extensive test could be run by
> using Derby unit tests.
>
> I wrote a small perl script that extracts the names of all of the java
> classes and then compares these against the API spec to generate a
> final list of API classes that are used by an application. I'd be
> happy to supply the perl, although it needs a bit of tidying up.
This is cool.
>
> The next step would be to check how many of these exist in SVN already
> - and maybe highlight the areas that we are missing?
Yes!
> So far, the only
> way I have found to get a list of files that exist in SVN is using
> something like "svn list $repos_path -R", if anyone knows of a better
> (faster) way I'd be happy to hear it.
Try to find a way to do it on a local checkout. We don't want to be
banging the SVN repo like this. (We've been having problems lately w/
people walking through the SVN repo, file after file, version after
version, via the viewCVS interface. Not a good use of resources.
This would be cool - I'd love to post these on the website, to let
people know what they could do to help get their favorite app up and going.
I wonder too if this could be combined with Gump somehow, so we can
automatically test a large swatch of the "popular java app" world.
geir
>
> Thoughts?
>
> --
> Zoe Slattery
> IBM
>
>
Re: Which applications run using Harmony classes?
Posted by Alexey Petrenko <al...@gmail.com>.
That will be a good tool!
> The next step would be to check how many of these exist in SVN already
> - and maybe highlight the areas that we are missing? So far, the only
> way I have found to get a list of files that exist in SVN is using
> something like "svn list $repos_path -R", if anyone knows of a better
> (faster) way I'd be happy to hear it.
You can also use reflection for checking for class availability.
IMHO it will be an easiest way if we will keep modularity in mind.
--
Alexey A. Petrenko
Intel Middleware Products Division