You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Peter Donald <do...@apache.org> on 2000/12/06 11:14:02 UTC
Re: cvs commit: jakarta-ant/proposal/anteater/lib crimson.jar
jaxp.jar
At 09:58 6/12/00 -0000, you wrote:
> public class Bootstrap {
>
> private static String base = "../";
> + private static String crimsonSources = "../../../xml-crimson/src";
// relative to base
This makes it near impossible for a lot of people to build it with this
tool. It certainly up the stakes even for those who are willing to spend
the extra time/effort to check it out - worse it could leads us to not
being able to determine whos at fault after a change (ie crimson people
make a mistake and it could effect you). I dislike spiderweb builds for
this very reason.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: cvs commit: jakarta-ant/proposal/anteater/libcrimson.jarjaxp.jar
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Jon Stevens wrote:
> we don't have export restrictions on
> security code anymore which is nice.
Would that this were true :-(
There are still country restrictions that have to be respected. See questions
6-9 of the JSSE FAQ at <http://java.sun.com/products/jsse/FAQ.html>.
Because there is no reasonable way to enforce the country restrictions (do you
really want to see a click-through "I am not a crook" page to download it :-),
this is why Tomcat doesn't include the JSSE stuff in its binary distros.
>
> thanks,
>
> -jon
Craig
Re: cvs commit: jakarta-ant/proposal/anteater/lib
crimson.jarjaxp.jar
Posted by Jon Stevens <jo...@latchkey.com>.
on 12/6/2000 6:07 PM, "Peter Donald" <do...@apache.org> wrote:
> Thats why I *thought* that distributing
> mail.jar is legal but jaxp1.1.jar is not - thou IANAL so ... ;)
No way, we are still illegal. :-)
http://www.working-dogs.com/turbine/cvsweb/index.cgi/turbine/lib/mail-1.2ea.
jar
1.2EarlyAccess.
:-)
As for the rest of it, blocking by IP address is really only possible if Sun
would like to share the IP's they want blocked. As for nuclear...give me a
break. As for US gov, I have no idea...we don't have export restrictions on
security code anymore which is nice.
thanks,
-jon
Re: cvs commit: jakarta-ant/proposal/anteater/lib
crimson.jarjaxp.jar
Posted by James Duncan Davidson <du...@x180.net>.
On 12/6/00 6:07 PM, "Peter Donald" <do...@apache.org> wrote:
> I thought they were covered by "Binary Code License Agreement" + the
> standard extention Supplemental. I agree you break some parts .. namely you
> don't
>
> 1. comply with export restrictions to embargoes countries
> 2. allow it to be used within nuclear facilties ;)
> 3. possibly the strictures set out for US gov software (which I don't know
> anything about)
1. Well, we take about the same precautions as anyone else on the net --
that's what the gov't requires for technology. Everyone tries to log crypto
stuff.. But banning the 7 bad countries is another thing. Maybe we should IP
block em -- but when they get aol.com accounts, the gig is up anyway.
2. The nuclear stuff is legal "don't sue Sun if you do that" language. If a
nuke plant blows and it's cause they were running Java, Sun can point to
that and say "They weren't supposed to do that!"... That's about all it
means. It's like telling you that you aren't supposed to cross the street on
red. If you do it, it's your own damn fault for getting hit by a car.
3. Those restrictions only mean something to Gov't employees and
contractors. They don't apply to normal citizens. This is because the US
Gov't has interesting ways in which they require stuff to be made available
to them.
> However jaxp1.1 is an early release and thus covered by the "Pre-Release
> Binary Software Evaluation Agreement" which explictly disallows
> distribution (among other things). Thats why I *thought* that distributing
> mail.jar is legal but jaxp1.1.jar is not - thou IANAL so ... ;)
Were we distributing? I didn't see a release being made of Crimson with jaxp
1.1 yet. Not a final release. Until then, it's development software and not
released. :)
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: cvs commit: jakarta-ant/proposal/anteater/lib
crimson.jarjaxp.jar
Posted by Peter Donald <do...@apache.org>.
At 05:55 6/12/00 -0800, Jon Stevens wrote:
>on 12/6/2000 5:42 PM, "Peter Donald" <do...@apache.org> wrote:
>
>> Well not about that but more due to legal thing. I would never touch
>> something that has Suns license attached. I thought Apache had a clean tree
>> policy - ie only Apache copyright source is allowed to exist in CVS.
>> However Crimson has Sun copyright stuff in the tree - this seems silly -
>> especially as xml-xerces has similar source (the jaxp parser package) that
>> could be easily adpated to jaxp1.1 and we could do away with unclean tree
>> and that silly license.
>>
>> I guess it is a little anal but I have seen the results of discarding
>> legality (thou I live in a particularly restrictive country so YMMV).
>
>Turbine is totally illegal with regards to what it distributes. We are legal
>with regards to GPL (we don't include any GPL software), but not with
>regards to Sun's .jar files (ie: mail.jar, activation.jar, etc...)
I thought they were covered by "Binary Code License Agreement" + the
standard extention Supplemental. I agree you break some parts .. namely you
don't
1. comply with export restrictions to embargoes countries
2. allow it to be used within nuclear facilties ;)
3. possibly the strictures set out for US gov software (which I don't know
anything about)
Stefano said ages ago that (1) would be fixed (ie block ftp/cvs connections
from "bad" countries). You can comply with (2) by adding a simple
disclaimer (Not for use in nuclear facilties ;]). About 3 I don't know but
it could be looked into if it was an issue.
However jaxp1.1 is an early release and thus covered by the "Pre-Release
Binary Software Evaluation Agreement" which explictly disallows
distribution (among other things). Thats why I *thought* that distributing
mail.jar is legal but jaxp1.1.jar is not - thou IANAL so ... ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: Clean room policy
Posted by James Duncan Davidson <du...@x180.net>.
On 12/6/00 11:30 PM, "Peter Donald" <do...@apache.org> wrote:
> Not all of them - just the 5-6 in javax.xml.parser.* but if you say it is
> fine then I gonna upgrade a whole heap of projects to jaxp1.1 and claim you
> represented sun and allowed it ;) (I been wanting to do it for ages instead
> using custom factories ;-])
That particular email said it was fine in that particular context on that
day. If you want to interpret my message that day -- then go get it and
interpret it.. I'm not redefining it here -- and today I'm making no such
statements representing Sun or as a Sun spokesperson.
Note well -- If I'm not using my Sun address (which I can toggle if I so
choose with a pull down in my mailer), then I'm most definitely not speaking
for Sun. I'm just me, myself, and I speaking as an Apache Developer and
maybe as an Apache VP in my Jakarta Chair role... But nothing related to
Sun.
> Okay - does that mean I can check in code that isn't owned by Apache. There
> is a few - their licenses allow it and I am trying to clone behaviour in
> their system. It is just taking forever because I have to do it by myself -
> thou if I could put it in CVS someone else may pick up the banner ;)
It's not encouraged and the story is murky, but there are several cases
where its done as long as the licenses aren't in conflict. For example,
expat is in the httpd tree.
> It would also open up the oportunity for the log4j guys to put it in CVS
> and gradually remove the IPL bits? I guess I was under a different
> impression and I just told Ceki that Apache wouldn't accept IBM owned code
> so he had to rewrite it but if not ...
In general I'd like to not see this happen much, even though it does happen,
and would rather see those bits that are not controlled by us in .jar files
in binary format where a source license doesn't even apply. Jon's practices
of just using .jars is much more sane from a legal standpoint than checking
in source code. I'm probably going to be encouraging the Crimson folks to do
this.
--
James Duncan Davidson duncan@x180.net
!try; do()
Clean room policy
Posted by Peter Donald <do...@apache.org>.
At 10:43 6/12/00 -0800, you wrote:
>On 12/6/00 5:42 PM, "Peter Donald" <do...@apache.org> wrote:
>
>> Well not about that but more due to legal thing. I would never touch
>> something that has Suns license attached.
>
>You must be referring to the javax.xml.* classes, right?
Not all of them - just the 5-6 in javax.xml.parser.* but if you say it is
fine then I gonna upgrade a whole heap of projects to jaxp1.1 and claim you
represented sun and allowed it ;) (I been wanting to do it for ages instead
using custom factories ;-])
>> I thought Apache had a clean tree
>> policy - ie only Apache copyright source is allowed to exist in CVS.
>
>Apache only *works* on Apache copyright code. Our experience with code that
>we have to lean on is that we do what we can how we can.
Okay - does that mean I can check in code that isn't owned by Apache. There
is a few - their licenses allow it and I am trying to clone behaviour in
their system. It is just taking forever because I have to do it by myself -
thou if I could put it in CVS someone else may pick up the banner ;)
It would also open up the oportunity for the log4j guys to put it in CVS
and gradually remove the IPL bits? I guess I was under a different
impression and I just told Ceki that Apache wouldn't accept IBM owned code
so he had to rewrite it but if not ...
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: cvs commit: jakarta-ant/proposal/anteater/lib crimson.jar
jaxp.jar
Posted by James Duncan Davidson <du...@x180.net>.
On 12/6/00 5:42 PM, "Peter Donald" <do...@apache.org> wrote:
> Well not about that but more due to legal thing. I would never touch
> something that has Suns license attached.
You must be referring to the javax.xml.* classes, right? Since it was a Sun
engineer that checked them in -- then it must be ok. At least until somebody
complains. In any case, a Sun employee said on the xml lists that it was
perfectly ok to have the code for javax.xml.* in the repository and to
redistribute it. After all, they are just public interface classes (or very
light abstract classes and exceptions if you want to be technical) of a
public spec. It's in the xml-general archives somewhere. Search for some guy
named Davidson.
A better, more "legal" solution would be to have just the jaxp.jar checked
in somewhere with a clear binary redistribution license. A perfect thing for
CJAN.
Yes, that Sun employee has on his to-do list a clarification that is more in
line with Open Source usage of this code...
> I thought Apache had a clean tree
> policy - ie only Apache copyright source is allowed to exist in CVS.
Apache only *works* on Apache copyright code. Our experience with code that
we have to lean on is that we do what we can how we can. The other
alternative is for somebody that doesn't work for Sun to redo the classes.
If you want to, go ahead, but it's really unclear as to whether it matters
since, according to the spec license -- there are *no* provisions (either
restrictions or grants) given to any other party except clean room
implementations - and since the place has got lots of Sun folks around, it
would be hard to claim clean-room. :)
Yes -- that Sun employee is also working to get grants clarified as it *is*
clear what Sun's intent is here... And that intent is for people to use the
silly classes, but not change the public APIs which are fixed by a
specification.
.duncan
--
James Duncan Davidson duncan@x180.net
!try; do()
Re: cvs commit: jakarta-ant/proposal/anteater/lib crimson.jar
jaxp.jar
Posted by Jon Stevens <jo...@latchkey.com>.
on 12/6/2000 5:42 PM, "Peter Donald" <do...@apache.org> wrote:
> Well not about that but more due to legal thing. I would never touch
> something that has Suns license attached. I thought Apache had a clean tree
> policy - ie only Apache copyright source is allowed to exist in CVS.
> However Crimson has Sun copyright stuff in the tree - this seems silly -
> especially as xml-xerces has similar source (the jaxp parser package) that
> could be easily adpated to jaxp1.1 and we could do away with unclean tree
> and that silly license.
>
> I guess it is a little anal but I have seen the results of discarding
> legality (thou I live in a particularly restrictive country so YMMV).
Turbine is totally illegal with regards to what it distributes. We are legal
with regards to GPL (we don't include any GPL software), but not with
regards to Sun's .jar files (ie: mail.jar, activation.jar, etc...)
Until CJAN is setup and working, I'm not sure how to deal with the issue. I
can't wait to get the letter from Sun telling me to stop though. :-)
-jon
Re: cvs commit: jakarta-ant/proposal/anteater/lib crimson.jar
jaxp.jar
Posted by Peter Donald <do...@apache.org>.
At 09:28 6/12/00 -0800, James Duncan Davidson wrote:
>On 12/6/00 2:14 AM, "Peter Donald" <do...@apache.org> wrote:
>
>> At 09:58 6/12/00 -0000, you wrote:
>>> public class Bootstrap {
>>>
>>> private static String base = "../";
>>> + private static String crimsonSources = "../../../xml-crimson/src";
>> // relative to base
>>
>> This makes it near impossible for a lot of people to build it with this
>> tool.
>
>Why? If you are checking out jakarta-ant, it's just another word on the
>checkout command to checkout crimson.jar.
Well not about that but more due to legal thing. I would never touch
something that has Suns license attached. I thought Apache had a clean tree
policy - ie only Apache copyright source is allowed to exist in CVS.
However Crimson has Sun copyright stuff in the tree - this seems silly -
especially as xml-xerces has similar source (the jaxp parser package) that
could be easily adpated to jaxp1.1 and we could do away with unclean tree
and that silly license.
I guess it is a little anal but I have seen the results of discarding
legality (thou I live in a particularly restrictive country so YMMV).
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: cvs commit: jakarta-ant/proposal/anteater/lib crimson.jar
jaxp.jar
Posted by James Duncan Davidson <du...@x180.net>.
On 12/6/00 2:14 AM, "Peter Donald" <do...@apache.org> wrote:
> At 09:58 6/12/00 -0000, you wrote:
>> public class Bootstrap {
>>
>> private static String base = "../";
>> + private static String crimsonSources = "../../../xml-crimson/src";
> // relative to base
>
> This makes it near impossible for a lot of people to build it with this
> tool.
Why? If you are checking out jakarta-ant, it's just another word on the
checkout command to checkout crimson.jar.
> It certainly up the stakes even for those who are willing to spend
> the extra time/effort to check it out - worse it could leads us to not
> being able to determine whos at fault after a change (ie crimson people
> make a mistake and it could effect you). I dislike spiderweb builds for
> this very reason.
Crimson (or any other XML parser) changes can affect us at any time even if
we are using "promoted" jars. In fact, if we use promoted jars, then we
don't know that Crimson busted something stupid till whenever we decide to
update (whenever that might be). However, if you make things dependant, you
know for sure whenever the depended on tool busts -- which makes identifying
the culprit a bit easier.
So, I'd prefer a CJAN, or a setup with a central set of Jars to doing
this... But for right this second, given the balance of options, this avoids
having yet another jar in the repository. And for sure checking in a
crimson.jar into the workspace means that that jar will sit forever and then
crimson will change and then something will really be screwed up -- which is
the situtation Stylebook and so many other tools are in right now.
--
James Duncan Davidson duncan@x180.net
!try; do()