You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/05/15 19:37:37 UTC
[Bugs] URLSource
Carsten,
I've recently switched to the new source-resolving excalibur code and I
found that you use the following
File file = new File( this.systemId.substring( "file".length() ) );
to obtain the 'path' part of a 'file' URI. The above might work on UNIX,
but it clearly doesn't work on other operating systems, since URIs like
these
file:///c:/path/to/file
are totally valid and your code is not able to handle them.
Now, my suggestion would be to use the standard java.net API because
they already handle all these issues (file: protocol handling is
expecially tricky on regards of the number of slashes).
NOTE: there is no official indication on how the file: URI should be
addressed, but all these
file:/file
file://file
file:///file
are all valid URIs and should point to the same file (at least, this was
my understanding). It could be possible to add
file:file
to indicate a relative location. This is normally achieved by avoiding
to indicate the protocol (such as in "file"), but since we need a
protocol to identify the handler, "file:file" might just be a way to
encode relativity in file positioning.
- o -
I just found another bug: the docs say that if you call
resolver.resolveURI()
and the resource doesn't exist, you get a SourceNotFoundException. If yo
are accessing file resources, instead you get a FileNotFoundException,
which is not even inherited.
Expect more bug report soon since I'm getting pretty heavy on sources :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Doc: common howtos/docs (Was: [Bugs] URLSource)
Posted by David Crossley <cr...@indexgeo.com.au>.
J.Pietschmann wrote:
> Stefano Mazzocchi wrote:
> >
> > Many thanks for the clarification.
> >
> > Ok, people, I'm sure there is some patching to do now :)
>
> It would be interesting whether there would be a project
> responsible for some "commonly used" documentation.
> For example:
> - Understanding the Apache license :-)
> - Understanding URIs and URLs
> - Understanding the Java classpath and other common
> Java related problems
> and the like.
> All these cause FAQs for all Apache projects I've watched.
> Instead of having each project answering this stuff for
> itself, it could be handled globally and only referenced
> by the project FAQs or included from a repository (the
> "short form"). Would this fit the Forrest project? Or
> Avalon or XML Commons? Or should some sort of "Apache
> encyclopedia" be spawned?
>
> J.Pietschmann
(Sorry about my Cc of this thread, i am never sure what to do.)
You are right J. There is a stack of such common documentation
needed ... contributing, voting procedures, tips for new committers,
what the general mailing lists are and how to subscribe, ...
It sounds like something that should be on Forrest's dream list,
though Forrest seems to be running in circles.
I tried a thread on forrest-dev a while ago, but got no reply.
Re: Does Forrest intend to provide overview doco for all projects?
http://marc.theaimsgroup.com/?l=forrest-dev&m=101936135715629
--David
Doc: common howtos/docs (Was: [Bugs] URLSource)
Posted by David Crossley <cr...@indexgeo.com.au>.
J.Pietschmann wrote:
> Stefano Mazzocchi wrote:
> >
> > Many thanks for the clarification.
> >
> > Ok, people, I'm sure there is some patching to do now :)
>
> It would be interesting whether there would be a project
> responsible for some "commonly used" documentation.
> For example:
> - Understanding the Apache license :-)
> - Understanding URIs and URLs
> - Understanding the Java classpath and other common
> Java related problems
> and the like.
> All these cause FAQs for all Apache projects I've watched.
> Instead of having each project answering this stuff for
> itself, it could be handled globally and only referenced
> by the project FAQs or included from a repository (the
> "short form"). Would this fit the Forrest project? Or
> Avalon or XML Commons? Or should some sort of "Apache
> encyclopedia" be spawned?
>
> J.Pietschmann
(Sorry about my Cc of this thread, i am never sure what to do.)
You are right J. There is a stack of such common documentation
needed ... contributing, voting procedures, tips for new committers,
what the general mailing lists are and how to subscribe, ...
It sounds like something that should be on Forrest's dream list,
though Forrest seems to be running in circles.
I tried a thread on forrest-dev a while ago, but got no reply.
Re: Does Forrest intend to provide overview doco for all projects?
http://marc.theaimsgroup.com/?l=forrest-dev&m=101936135715629
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: copyright for docs [was: Re: [Bugs] URLSource]
Posted by Stefano Mazzocchi <st...@apache.org>.
"Andrew C. Oliver" wrote:
>
> Oh man, the docs copyrights should be assigned to the ASF. What a pain
> otherwise.
I substantially agree, but I want to make a little clarification: as it
happens with code today and how the Apache License 2.0 will clarify in
defined legal details, if you donate something to an Apache project
covered by the Apache License, the copyright goes to the copyright owner
of the package you sumbit your stuff to.
In the Cocoon's case, the ASF. No way out of this. It is for code, docs,
images and what not.
This is done to have just one legal umbrella for the whole thing,
otherwise, as Andrew notes, it's going to be a PITA to defend us in case
something happens. Don't know what, but legal protection is there for
what you *don't* know nor forecast.
For what I know, a company in the future can claim a patent on the
ability to use XML for documentation. In that case, if the users retains
copyright, the ASF can't do anything to protect him/her... and each time
we make a release, we need to have an agreement with all the people to
allow us to distribute their work with ours.
A real mess.
But let me clarify something: as it happens with code, if I donate
something to this project, I *DO* keep the copyright of it. So, if I
write an document for Cocoon, submit it to the cocoon documentation and
then somebody wants to publish it, I don't have to ask the ASF
permission, as long as I don't incorporate modifications that were done
*after* my donation.
In strict legal sense, a donation doesn't affect copyright
retroactively.
I think all this should convince almost everyone that donating their
docs to the ASF under theri copyright, is a win-win solution for both.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs
[was: Re: [Bugs] URLSource])
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Yes, I actually did know that (looked it up once for some work I was
doing). It would be nice if everyone working on docs to be posted on
the site and distributed with cocoon put <!-- copyright Apache Software
Foundation -->. Theoretically a documentor could start charging the ASF
and users fees or royalties just for having copies of cocoon on their
hard drive. Sure would be fun to see them try and collect for the
latter, but still...
Dunno if it counts but many of the templates put "copyright Apache
Software Foundation" at the bottom of the page anyhow so I suppose if
one doesn't object for some period of time then assignment could be
implied, but I think <!-- copyright Apache software foundation --> in
the xml leaves less in doubt. I think this should be a precondition for
accepting docs.
-Andy
Berin Loritsch wrote:
>>From: Andrew C. Oliver [mailto:acoliver@apache.org]
>>
>>Oh man, the docs copyrights should be assigned to the ASF.
>>What a pain otherwise.
>>
>>
>
>According to U.S. Copyright Law, your copyright is a real
>(as in Real Estate) property that is intangible, but assignable.
>You can bequeath your copyright, donate it, or by your discression
>not use it (given to public domain).
>
>Also according to copyright law, any original work is _implicitly_
>copyrighted whether you register that copyright or not. Therefore,
>you may easily add the copyright notice without registering the
>copyright. The registration is a legal way of having record that
>the content in question was in fact prior art should we need to
>go to court over the issue.
>
>A U.S. copyright after 1971 lasts for the artists/authors lifetime
>plus 50 years. Before that time, it was 25 years renewable once
>for an additional 25 years for a maximum of 50 years. That's a long
>time.
>
>Considering the changing nature of most Apache or technical sites,
>the information on the site can quickly become outdated. The act
>of registering a copyright is therefore only really suggested for
>works in an unchanging format: like books, music recordings, sheet
>music, etc.
>
>While IANAL, I had a crash course in Copyright Law taught by Al
>Schlessinger, one of the top lawyers in the field (he represents
>people like Janet Jackson and other really big names). While I
>don't know enough to practice law, I know enough to give the
>backgrounder information. I have a good understanding of the
>overview of copyright law--but not any real depth (the class was
>only a couple of weeks long).
>
>If you want to know any more than that, ask some specific questions.
>I will give you as specific an answer as I have.
>
>BTW, if you place the Copyright by Apache Software Foundation tag
>on your documentation (as will be done when published on the site),
>you have effectively donated your copyright to the ASF.
>
>A copyright gives you the right to control the distribution of your
>work, maintain the identity of the author, and extract fees or royalties
>from its use. There are standards for what a royalty fee is for
>recorded music, as well as for print materials. I am not up on what
>the current standards are. The standards represent the minimum
>that someone has to pay in order to use your work--if you are collecting
>money. Some artists have negotiated bigger slices of the pie for their
>works than others.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs
[was: Re: [Bugs] URLSource])
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Agreed.
Diana Shannon wrote:
>
> On Monday, May 20, 2002, at 09:09 AM, Berin Loritsch wrote:
>
>> BTW, if you place the Copyright by Apache Software Foundation tag
>> on your documentation (as will be done when published on the site),
>> you have effectively donated your copyright to the ASF.
>
>
> My point: authors aren't placing "copyright by Apache..." text within
> their contribution source files. The Cocoon web site, by default,
> currently adds this copyright tag via transformation. Thus, we should
> make it very clear to authors (by pointing them to a revised
> contrib.xml, etc.) *before* they contribute. I'll go ahead and update
> instructions, templates, and contrib.xml, etc. as appropriate.
>
> Otherwise, without this disclosure, it's *not* reasonable (from a
> legal perspective) for Apache to conclude authors are donating the
> copyright to their works. For example, what if an author contributes a
> work with personal copyright info already on it? We can't just assume
> the Apache copyright overrides it, can we, if we don't clarify
> copyright details ahead of time?
>
> Seems to me if authors want to retain copyright to their works, they
> should publish them elsewhere. We can still provide links to such
> off-site works from the Cocoon web site.
>
> Thanks.
>
> Diana
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs
[was: Re: [Bugs] URLSource])
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>>My point: authors aren't placing "copyright by Apache..." text within
>>their contribution source files. The Cocoon web site, by default,
>>currently adds this copyright tag via transformation. Thus, we should
>>make it very clear to authors (by pointing them to a revised
>>contrib.xml, etc.) *before* they contribute. I'll go ahead and update
>>instructions, templates, and contrib.xml, etc. as appropriate.
>>
>>
>
>That can be a problem for items submitted via a patch, or from
>non-committers
>
>
whine when the patch is submitted. or ask them to at least explicitly
state it in the bugzilla comments. Or templatize the area where one
puts "authors" and have it say "By adding your name here you explicitly
assign your rights to the apache software foundation" -- I'm certain
this can be navigated.
>
>
>>Otherwise, without this disclosure, it's *not* reasonable
>>(from a legal
>>perspective) for Apache to conclude authors are donating the
>>copyright
>>to their works. For example, what if an author contributes a
>>work with
>>personal copyright info already on it? We can't just assume
>>the Apache
>>copyright overrides it, can we, if we don't clarify copyright details
>>ahead of time?
>>
>>
>
>Committers are aware of the implications of their work in the CVS
>meaning that they implicitly donated the code to the ASF. That is
>part of the agreement they are forced to sign.
>
>
>
>>Seems to me if authors want to retain copyright to their works, they
>>should publish them elsewhere. We can still provide links to such
>>off-site works from the Cocoon web site.
>>
>>
>
>
>Absolutely. We should assume that if the documentation was submitted
>for inclusion in CVS, that those documents are donated to the ASF. We
>do need a disclosure page (as you noted) that specifically says that.
>Therefore, no author can retain their right to extract royalties from
>their documentation if it is available freely on the Cocoon web site.
>
>
yes.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: SUMMARY [ was Re: [LAW] Quick Lesson in Copyright Law (was RE:
copyright for docs [was: Re: [Bugs] URLSource])
Posted by Stefano Mazzocchi <st...@apache.org>.
First of all, I'm not a lawyer and I know everything I know about these
issues becaues I've been watching legal battles over members@apache.org
and licensing@apache.org which are, unfortunately but for good reasons,
closed lists.
I'll try to shed some light on this.
Diana Shannon wrote:
> Here's my current understanding.
>
> 1. contrib.xml makes the distinction between "core" and "optional"
> contributions of source code via patches supplied by non-committers.
> Core source code contributions must have copyright assigned to Apache.
> Optional contributions do not. Contributions of documentation are not
> discussed.
Yes, this is clearly a bug in the process and it's a good thing you are
bringing this up.
> 2. The Contributor License Agreement page
> (http://jakarta.apache.org/site/agreement.html) states that
> contributions from committers, not non-committers, are governed by
> licenses, not copyright assignments.
>
> How should we extend this language to cover non-committer contributions
> of documentation?
The Apache License 2.0 will cover both the 'outward' (read: you get the
stuff) and the 'inward' (read: you donate your stuff) flows.
If a project adopts this license, it is enough to state that everything
that is hosted on CVS must be covered by this license and everything
will be set, because simply by submitting your stuff as a donation, you
agree to a number of things.
Until this license is out, we have to fix the current process.
> a. If you extend the "spirit" of contrib.xml to documentation, then the
> decision (license or assignment) is based on how "core" or "optional"
> you consider the documentation.
I would personally suggest to remove such difference between "core" and
"optional".
> b. If you extend the "spirit" of the Contributor License Agreement, then
> non-committer contributions should be governed by licensing also, not
> assignment. Why should it be more restrictive?
>
> IMO, both approaches suggest licensing, not assignment. In other words,
> contributors of documentation in the form of patches must agree to
> provide Apache a "non-exclusive, irrevocable, worldwide, no-charge,
> transferable copyright license to use, execute, prepare derivative works
> of, and distribute ... " for their contributions. I don't see why
> assignment is necessary. In fact, licensing may create more incentives
> for would-be authors, because it allows more opportunities for their
> work to be published. This doesn't hurt, in fact, it helps advance
Cocoon.
>
> If you agree, I'll update contrib.xml (and other author docs) to reflect
> that understanding. If this is incorrect, then please advise.
I agree with this.
In short, you give a copy of your work to us and allow us to do anything
we want from it (but stealing your credits, of course). Then you can
still do whatever you want with the copy you donated.
Is this ok for you?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
SUMMARY [ was Re: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs [was: Re: [Bugs] URLSource])
Posted by Diana Shannon <te...@mac.com>.
Here's my current understanding.
1. contrib.xml makes the distinction between "core" and "optional"
contributions of source code via patches supplied by non-committers.
Core source code contributions must have copyright assigned to Apache.
Optional contributions do not. Contributions of documentation are not
discussed.
2. The Contributor License Agreement page
(http://jakarta.apache.org/site/agreement.html) states that
contributions from committers, not non-committers, are governed by
licenses, not copyright assignments.
How should we extend this language to cover non-committer contributions
of documentation?
a. If you extend the "spirit" of contrib.xml to documentation, then the
decision (license or assignment) is based on how "core" or "optional"
you consider the documentation.
b. If you extend the "spirit" of the Contributor License Agreement, then
non-committer contributions should be governed by licensing also, not
assignment. Why should it be more restrictive?
IMO, both approaches suggest licensing, not assignment. In other words,
contributors of documentation in the form of patches must agree to
provide Apache a "non-exclusive, irrevocable, worldwide, no-charge,
transferable copyright license to use, execute, prepare derivative works
of, and distribute ... " for their contributions. I don't see why
assignment is necessary. In fact, licensing may create more incentives
for would-be authors, because it allows more opportunities for their
work to be published. This doesn't hurt, in fact, it helps advance
Cocoon.
If you agree, I'll update contrib.xml (and other author docs) to reflect
that understanding. If this is incorrect, then please advise.
Thanks for your patience.
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs [was: Re: [Bugs] URLSource])
Posted by Diana Shannon <te...@mac.com>.
On Monday, May 20, 2002, at 11:41 AM, Berin Loritsch wrote:
> Pay attention to the Contributor License Agreement page,
> or http://jakarta.apache.org/site/agreement.html
*Thanks* for the links, Berin. They really helped!
Ok, this clarifies the situation a lot. For example, Section 2 states
contributors do not transfer *copyright* to Apache, rather, a
non-exclusive *license* to use, execute, prepare derivative works of,
and distribute, etc. As programmers/writers/etc., they still retain
their own right to use (etc.) their works. Seems to me, the same should
apply for non-committers who contribute patches, whether code or docs...
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs [was: Re: [Bugs] URLSource])
Posted by Berin Loritsch <bl...@apache.org>.
http://jakarta.apache.org/site/roles.html
Pay attention to the Contributor License Agreement page,
or http://jakarta.apache.org/site/agreement.html
I have signed the agreement.
> -----Original Message-----
> From: Gianugo Rabellino [mailto:gianugo@apache.org]
> Sent: Monday, May 20, 2002 11:38 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [LAW] Quick Lesson in Copyright Law (was RE:
> copyright for docs [was: Re: [Bugs] URLSource])
>
>
> Berin Loritsch wrote:
> >
> > Committers are aware of the implications of their work in the CVS
> > meaning that they implicitly donated the code to the ASF. That is
> > part of the agreement they are forced to sign.
> >
>
> OK guys, you know I'm a lawyer so I'm getting picky in those
> things... :-)
>
> While I sure do know in my soul how this is true, and it's my
> intention
> to donate all of my work to the ASF, it might be worth noticing that
> when I was proposed and accepted as a committer no one made me sign
> anything or even sent me a mail stating what were my obligations as a
> committer using CVS.
>
> I don't know if this was an oversight in my case: if so then
> no problem
> at all, but if mine is a normal case then AFAIU (based on
> most european
> laws) there is no legal bound between committing code and
> automagically
> donate it to the ASF. If this what we want to achieve (and I
> certainly
> want it) then it might be the case of having some sort of
> procedure for
> new committers so that they know precisely what are their
> obligations in
> contributing to ASF codebases. Probably it would be enough to have a
> sentence like "by logging into your new account you explicitly accept
> the ASF rules found at the address http://www.apache.org/whatever"
> included in the email where the account data is sent to the
> new committer.
>
> How about it?
>
> --
> Gianugo Rabellino
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs
[was: Re: [Bugs] URLSource])
Posted by Gianugo Rabellino <gi...@apache.org>.
Berin Loritsch wrote:
>
> Committers are aware of the implications of their work in the CVS
> meaning that they implicitly donated the code to the ASF. That is
> part of the agreement they are forced to sign.
>
OK guys, you know I'm a lawyer so I'm getting picky in those things... :-)
While I sure do know in my soul how this is true, and it's my intention
to donate all of my work to the ASF, it might be worth noticing that
when I was proposed and accepted as a committer no one made me sign
anything or even sent me a mail stating what were my obligations as a
committer using CVS.
I don't know if this was an oversight in my case: if so then no problem
at all, but if mine is a normal case then AFAIU (based on most european
laws) there is no legal bound between committing code and automagically
donate it to the ASF. If this what we want to achieve (and I certainly
want it) then it might be the case of having some sort of procedure for
new committers so that they know precisely what are their obligations in
contributing to ASF codebases. Probably it would be enough to have a
sentence like "by logging into your new account you explicitly accept
the ASF rules found at the address http://www.apache.org/whatever"
included in the email where the account data is sent to the new committer.
How about it?
--
Gianugo Rabellino
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs
[was: Re: [Bugs] URLSource])
Posted by "Andrew C. Oliver" <ac...@apache.org>.
It was in reply to this
> I'm pretty sure this will change when the Apache web site
> runs Cocoon with process support (C3.x? <bg>). I imagine
> forms for applying for access, a workflow for signing,
> set up accounts, generating certificates, filing the
> paperwork...
(yes, I realize you were kidding) -- "greater confederation" refers to
Apache.. (I regard Apache as a confederation)
-Andy
On Mon, 2002-05-20 at 16:07, J.Pietschmann wrote:
> Andrew C. Oliver wrote:
> > Oh man, and I nominate you to try and get that passed across the greater
> > confederation.
>
> Try what? And what's "the greater confederation"?
>
> J.Pietschmann
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs [was: Re: [Bugs] URLSource])
Posted by Steven Noels <st...@outerthought.org>.
Joerg,
>
> Andrew C. Oliver wrote:
> > Oh man, and I nominate you to try and get that passed
> across the greater
> > confederation.
>
> Try what? And what's "the greater confederation"?
>
ASF. You know, HTTP Server, APR, Jakarta, Perl, PHP, TCL, XML,
*.apache.org......
AKA infrastructure@apache.org and the PMC of all these projects.
All these projects who have other, similar,
complementary/supplementary/concurrent technologies to host such a
thing.
To get a feeling of the partisanship that sometimes arises in this
confederation, try reading:
http://marc.theaimsgroup.com/?t=102020211600005&r=1&w=2
http://marc.theaimsgroup.com/?t=102036180400001&r=2&w=2
http://marc.theaimsgroup.com/?t=102044546400003&r=1&w=2
</Steven>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs
[was: Re: [Bugs] URLSource])
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Andrew C. Oliver wrote:
> Oh man, and I nominate you to try and get that passed across the greater
> confederation.
Try what? And what's "the greater confederation"?
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs
[was: Re: [Bugs] URLSource])
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Oh man, and I nominate you to try and get that passed across the greater
confederation.
-Andy
J.Pietschmann wrote:
> Steven Noels wrote:
>
>> I do not know for any of you, but nobody made me sign something before I
>> became a committer. And I will sue the ASF for that :-D
>
>
> There is a page somewhere on jakarta with some legal stuff.
> I copied the text, filled my name in signed it and send it
> in per snail mail. I had my CVS access already by that
> time. I never recieved a receipt or something that it was
> really filed with the ASF. Not that this bothers me.
>
>> The process of actually receiving commit access on cvs.apache.org after
>> being voted upon is sketchy at best. There's no support or guidelines
>> except for what you can obtain from your peers [1].
>
>
> I'm pretty sure this will change when the Apache web site
> runs Cocoon with process support (C3.x? <bg>). I imagine
> forms for applying for access, a workflow for signing,
> set up accounts, generating certificates, filing the
> paperwork...
> Seriously: ASF and the projects have grown to a point where
> some bureaucracy seems to be hard to avoid. All we can do
> is to automate as much as possible. And Cocoon is a perfect
> platform to do it, isn't it?
>
> J.Pietschmann
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs
[was: Re: [Bugs] URLSource])
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Steven Noels wrote:
> Cool, thanks to this thread I finally know this document exists -
> unfortunately not on the XML project site.
There should be a PDF, of course produced from a common
source XML by FOP :-)
> Then we'd better focus on getting Forrest up & running soon, instead of
> discussing XML grammar languages ;-)
>
> Care to lend a helping hand? Come join us!
Do you have something concrete in mind? I'm somewhat absorbed
with the FOP helpdesk and FAQ writinig currently, but if there
is something to analyse, I might be interested.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs [was: Re: [Bugs] URLSource])
Posted by Steven Noels <st...@outerthought.org>.
Hi Joerg,
> There is a page somewhere on jakarta with some legal stuff.
> I copied the text, filled my name in signed it and send it
> in per snail mail. I had my CVS access already by that
> time. I never recieved a receipt or something that it was
> really filed with the ASF. Not that this bothers me.
Cool, thanks to this thread I finally know this document exists -
unfortunately not on the XML project site.
> > The process of actually receiving commit access on
> cvs.apache.org after
> > being voted upon is sketchy at best. There's no support or
> guidelines
> > except for what you can obtain from your peers [1].
>
> I'm pretty sure this will change when the Apache web site
> runs Cocoon with process support (C3.x? <bg>). I imagine
> forms for applying for access, a workflow for signing,
> set up accounts, generating certificates, filing the
> paperwork...
> Seriously: ASF and the projects have grown to a point where
> some bureaucracy seems to be hard to avoid. All we can do
> is to automate as much as possible. And Cocoon is a perfect
> platform to do it, isn't it?
Then we'd better focus on getting Forrest up & running soon, instead of
discussing XML grammar languages ;-)
Care to lend a helping hand? Come join us!
</Steven>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs
[was: Re: [Bugs] URLSource])
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Steven Noels wrote:
> I do not know for any of you, but nobody made me sign something before I
> became a committer. And I will sue the ASF for that :-D
There is a page somewhere on jakarta with some legal stuff.
I copied the text, filled my name in signed it and send it
in per snail mail. I had my CVS access already by that
time. I never recieved a receipt or something that it was
really filed with the ASF. Not that this bothers me.
> The process of actually receiving commit access on cvs.apache.org after
> being voted upon is sketchy at best. There's no support or guidelines
> except for what you can obtain from your peers [1].
I'm pretty sure this will change when the Apache web site
runs Cocoon with process support (C3.x? <bg>). I imagine
forms for applying for access, a workflow for signing,
set up accounts, generating certificates, filing the
paperwork...
Seriously: ASF and the projects have grown to a point where
some bureaucracy seems to be hard to avoid. All we can do
is to automate as much as possible. And Cocoon is a perfect
platform to do it, isn't it?
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs [was: Re: [Bugs] URLSource])
Posted by Steven Noels <st...@outerthought.org>.
Berin wrote:
> Committers are aware of the implications of their work in the CVS
> meaning that they implicitly donated the code to the ASF. That is
> part of the agreement they are forced to sign.
I do not know for any of you, but nobody made me sign something before I
became a committer. And I will sue the ASF for that :-D
The process of actually receiving commit access on cvs.apache.org after
being voted upon is sketchy at best. There's no support or guidelines
except for what you can obtain from your peers [1]. For fledgling [2]
projects, almost everything is sketchy. Most of the knowledge needed to
do some efficient Apache contribution (at least the process part of it)
is hidden in the minds of long-time contributors which sometimes have
limited bandwidth. But that was not the topic of this discussion, wasn't
it?
</Steven>
-----------
[1] Thanks, John, for helping me out on this for Forrest. I hope I
became a good student :-)
[2] And thanks for David for adding this new word to my English
vocabulary, and learning me how to spell it right ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs
[was: Re: [Bugs] URLSource])
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Diana Shannon wrote:
>
> On Monday, May 20, 2002, at 11:56 AM, Andrew C. Oliver wrote:
>
>>> Then, in effect, the copyright terms for docs will be stricter than
>>> the revised copyright terms proposed for code, as per Stefano's
>>> email, which stated "GPL code can use Apache code". In other words,
>>> why wouldn't we want a potential GPL project to "use" (revise,
>>> distribute) Apache docs, as long as the project makes such
>>> modifications available? Why should docs be treated differently than
>>> code under Stefano's new proposal?
>>
>>
>>
>> Umm...no. IANAL....but... to my understanding, as explained GPL
>> project could use revise, distribute Apache docs. They're be
>> released under APL. The difference being depending on the
>> benevolence of many individuals or the ASF itself. For instance,
>> currently, any docs I have donated that I feel I still hold the
>> rights to I could suddenly decide all projects that distribute them
>> (GPL or not) need to pay me a nickle a copy (where copy is defined as
>> a unique copy of my documentation on any location on a hard drive. I
>> could require the ASF, you and anyone else who downloaded Cocoon and
>> has a copy to play me for my documentation work.
>
>
> No, you couldn't do this, as long as you you granted the ASF a
> "non-exclusive, irrevocable, worldwide, no-charge, transferable
> copyright license" (as per Berin's link:
> http://jakarta.apache.org/site/agreement.html). In your example,
> "no-charge" and "transferable" are the key words.
True.. . If I were not a committer I could though. Those submitting
patches do not generally sign that agreement.
>
> We're talking about two separate copyright issues here, and it's
> potentially confusing. One is the copyright terms governing
> contributions which I believe Berin has clarified with his links. The
> other is the implications of Stefano's proposal on how documentation,
> included in Cocoon, can be used by third parties. On that issue, I'm
> still a bit confused...
>
> Diana
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs [was: Re: [Bugs] URLSource])
Posted by Diana Shannon <te...@mac.com>.
On Monday, May 20, 2002, at 11:56 AM, Andrew C. Oliver wrote:
>> Then, in effect, the copyright terms for docs will be stricter than
>> the revised copyright terms proposed for code, as per Stefano's email,
>> which stated "GPL code can use Apache code". In other words, why
>> wouldn't we want a potential GPL project to "use" (revise,
>> distribute) Apache docs, as long as the project makes such
>> modifications available? Why should docs be treated differently than
>> code under Stefano's new proposal?
>
>
> Umm...no. IANAL....but... to my understanding, as explained GPL
> project could use revise, distribute Apache docs. They're be released
> under APL. The difference being depending on the benevolence of many
> individuals or the ASF itself. For instance, currently, any docs I
> have donated that I feel I still hold the rights to I could suddenly
> decide all projects that distribute them (GPL or not) need to pay me a
> nickle a copy (where copy is defined as a unique copy of my
> documentation on any location on a hard drive. I could require the
> ASF, you and anyone else who downloaded Cocoon and has a copy to play
> me for my documentation work.
No, you couldn't do this, as long as you you granted the ASF a
"non-exclusive, irrevocable, worldwide, no-charge, transferable
copyright license" (as per Berin's link:
http://jakarta.apache.org/site/agreement.html). In your example,
"no-charge" and "transferable" are the key words.
We're talking about two separate copyright issues here, and it's
potentially confusing. One is the copyright terms governing
contributions which I believe Berin has clarified with his links. The
other is the implications of Stefano's proposal on how documentation,
included in Cocoon, can be used by third parties. On that issue, I'm
still a bit confused...
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs
[was: Re: [Bugs] URLSource])
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>>
>> Absolutely. We should assume that if the documentation was submitted
>> for inclusion in CVS, that those documents are donated to the ASF. We
>> do need a disclosure page (as you noted) that specifically says that.
>> Therefore, no author can retain their right to extract royalties from
>> their documentation if it is available freely on the Cocoon web site.
>
>
> Then, in effect, the copyright terms for docs will be stricter than
> the revised copyright terms proposed for code, as per Stefano's email,
> which stated "GPL code can use Apache code". In other words, why
> wouldn't we want a potential GPL project to "use" (revise,
> distribute) Apache docs, as long as the project makes such
> modifications available? Why should docs be treated differently than
> code under Stefano's new proposal?
Umm...no. IANAL....but... to my understanding, as explained GPL
project could use revise, distribute Apache docs. They're be released
under APL. The difference being depending on the benevolence of many
individuals or the ASF itself. For instance, currently, any docs I have
donated that I feel I still hold the rights to I could suddenly decide
all projects that distribute them (GPL or not) need to pay me a nickle a
copy (where copy is defined as a unique copy of my documentation on any
location on a hard drive. I could require the ASF, you and anyone else
who downloaded Cocoon and has a copy to play me for my documentation work.
If the ASF owns the rights and presumably chooses to license it for free
under the APL then the public's rights are protected. GPL projects can
use it to their misguided goal of making all software GPL and you could
use it without fear (presuming you trust the ASF ;-) )...etc.
-Andy
PS Keep your nickles ;-)
>
> Diana
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs [was: Re: [Bugs] URLSource])
Posted by Diana Shannon <te...@mac.com>.
On Monday, May 20, 2002, at 10:24 AM, Berin Loritsch wrote:
>> My point: authors aren't placing "copyright by Apache..." text within
>> their contribution source files. The Cocoon web site, by default,
>> currently adds this copyright tag via transformation. Thus, we should
>> make it very clear to authors (by pointing them to a revised
>> contrib.xml, etc.) *before* they contribute. I'll go ahead and update
>> instructions, templates, and contrib.xml, etc. as appropriate.
>
> That can be a problem for items submitted via a patch, or from
> non-committers
Not necessarily, unless the patch is a new/separate component/document.
The right of revision (among other rights) is retained by the copyright
owner, in this case, Apache, unless specified otherwise. Still, good
point. We need to make this clear in the instructions.
>> Seems to me if authors want to retain copyright to their works, they
>> should publish them elsewhere. We can still provide links to such
>> off-site works from the Cocoon web site.
>
>
> Absolutely. We should assume that if the documentation was submitted
> for inclusion in CVS, that those documents are donated to the ASF. We
> do need a disclosure page (as you noted) that specifically says that.
> Therefore, no author can retain their right to extract royalties from
> their documentation if it is available freely on the Cocoon web site.
Then, in effect, the copyright terms for docs will be stricter than the
revised copyright terms proposed for code, as per Stefano's email, which
stated "GPL code can use Apache code". In other words, why wouldn't we
want a potential GPL project to "use" (revise, distribute) Apache docs,
as long as the project makes such modifications available? Why should
docs be treated differently than code under Stefano's new proposal?
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs [was: Re: [Bugs] URLSource])
Posted by Berin Loritsch <bl...@apache.org>.
> From: Diana Shannon [mailto:terracare@mac.com]
>
>
> On Monday, May 20, 2002, at 09:09 AM, Berin Loritsch wrote:
>
> > BTW, if you place the Copyright by Apache Software
> Foundation tag on
> > your documentation (as will be done when published on the
> site), you
> > have effectively donated your copyright to the ASF.
>
> My point: authors aren't placing "copyright by Apache..." text within
> their contribution source files. The Cocoon web site, by default,
> currently adds this copyright tag via transformation. Thus, we should
> make it very clear to authors (by pointing them to a revised
> contrib.xml, etc.) *before* they contribute. I'll go ahead and update
> instructions, templates, and contrib.xml, etc. as appropriate.
That can be a problem for items submitted via a patch, or from
non-committers
>
> Otherwise, without this disclosure, it's *not* reasonable
> (from a legal
> perspective) for Apache to conclude authors are donating the
> copyright
> to their works. For example, what if an author contributes a
> work with
> personal copyright info already on it? We can't just assume
> the Apache
> copyright overrides it, can we, if we don't clarify copyright details
> ahead of time?
Committers are aware of the implications of their work in the CVS
meaning that they implicitly donated the code to the ASF. That is
part of the agreement they are forced to sign.
>
> Seems to me if authors want to retain copyright to their works, they
> should publish them elsewhere. We can still provide links to such
> off-site works from the Cocoon web site.
Absolutely. We should assume that if the documentation was submitted
for inclusion in CVS, that those documents are donated to the ASF. We
do need a disclosure page (as you noted) that specifically says that.
Therefore, no author can retain their right to extract royalties from
their documentation if it is available freely on the Cocoon web site.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [LAW] Quick Lesson in Copyright Law (was RE: copyright for docs [was: Re: [Bugs] URLSource])
Posted by Diana Shannon <te...@mac.com>.
On Monday, May 20, 2002, at 09:09 AM, Berin Loritsch wrote:
> BTW, if you place the Copyright by Apache Software Foundation tag
> on your documentation (as will be done when published on the site),
> you have effectively donated your copyright to the ASF.
My point: authors aren't placing "copyright by Apache..." text within
their contribution source files. The Cocoon web site, by default,
currently adds this copyright tag via transformation. Thus, we should
make it very clear to authors (by pointing them to a revised
contrib.xml, etc.) *before* they contribute. I'll go ahead and update
instructions, templates, and contrib.xml, etc. as appropriate.
Otherwise, without this disclosure, it's *not* reasonable (from a legal
perspective) for Apache to conclude authors are donating the copyright
to their works. For example, what if an author contributes a work with
personal copyright info already on it? We can't just assume the Apache
copyright overrides it, can we, if we don't clarify copyright details
ahead of time?
Seems to me if authors want to retain copyright to their works, they
should publish them elsewhere. We can still provide links to such
off-site works from the Cocoon web site.
Thanks.
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[LAW] Quick Lesson in Copyright Law (was RE: copyright for docs [was: Re: [Bugs] URLSource])
Posted by Berin Loritsch <bl...@apache.org>.
> From: Andrew C. Oliver [mailto:acoliver@apache.org]
>
> Oh man, the docs copyrights should be assigned to the ASF.
> What a pain otherwise.
According to U.S. Copyright Law, your copyright is a real
(as in Real Estate) property that is intangible, but assignable.
You can bequeath your copyright, donate it, or by your discression
not use it (given to public domain).
Also according to copyright law, any original work is _implicitly_
copyrighted whether you register that copyright or not. Therefore,
you may easily add the copyright notice without registering the
copyright. The registration is a legal way of having record that
the content in question was in fact prior art should we need to
go to court over the issue.
A U.S. copyright after 1971 lasts for the artists/authors lifetime
plus 50 years. Before that time, it was 25 years renewable once
for an additional 25 years for a maximum of 50 years. That's a long
time.
Considering the changing nature of most Apache or technical sites,
the information on the site can quickly become outdated. The act
of registering a copyright is therefore only really suggested for
works in an unchanging format: like books, music recordings, sheet
music, etc.
While IANAL, I had a crash course in Copyright Law taught by Al
Schlessinger, one of the top lawyers in the field (he represents
people like Janet Jackson and other really big names). While I
don't know enough to practice law, I know enough to give the
backgrounder information. I have a good understanding of the
overview of copyright law--but not any real depth (the class was
only a couple of weeks long).
If you want to know any more than that, ask some specific questions.
I will give you as specific an answer as I have.
BTW, if you place the Copyright by Apache Software Foundation tag
on your documentation (as will be done when published on the site),
you have effectively donated your copyright to the ASF.
A copyright gives you the right to control the distribution of your
work, maintain the identity of the author, and extract fees or royalties
from its use. There are standards for what a royalty fee is for
recorded music, as well as for print materials. I am not up on what
the current standards are. The standards represent the minimum
that someone has to pay in order to use your work--if you are collecting
money. Some artists have negotiated bigger slices of the pie for their
works than others.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: copyright for docs [was: Re: [Bugs] URLSource]
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Oh man, the docs copyrights should be assigned to the ASF. What a pain
otherwise.
-Andy
On Sun, 2002-05-19 at 11:55, Diana Shannon wrote:
>
> On Sunday, May 19, 2002, at 06:11 AM, Stefano Mazzocchi wrote:
>
> >> It would be interesting whether there would be a project
> >> responsible for some "commonly used" documentation.
> >> For example:
> >> - Understanding the Apache license :-)
> >
> > eh eh, you'll be happy to know that yesterday I submitted a patch
> > exactly for this for the 'almost-to-be-released-after-years' Apache
> > License 2.0,
>
> I'm trying to understand if this has *any* bearing on user contributions
> of documents.
>
> For example, the Apache HTTP Server docs project appears to retain
> copyright for their collective text (and collects royalties for
> non-exclusive publishing by third parties.) On the other extreme, if you
> peruse Linux Document Project contributions, you'll find most works are
> copyrighted by their respective authors.
>
> AFAIK, the Cocoon project's language (e.g. contrib.xml) only discusses
> copyright issues as related to contributions of *code*.
>
> What is your understanding?
> (1) User contributed-docs must be provided with ASF-compatible terms;
> or
> (2) users retain copyright to their contributions.
>
> I don't care, either way. I'd just like to clarify the situation up
> front for would-be authors.
>
> Diana
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
http://www.superlinksoftware.com - software solutions for business
http://jakarta.apache.org/poi - Excel/Word/OLE 2 Compound Document in
Java
http://krysalis.sourceforge.net/centipede - the best build/project
structure
a guy/gal could have! - Make Ant simple on complex Projects!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
copyright for docs [was: Re: [Bugs] URLSource]
Posted by Diana Shannon <te...@mac.com>.
On Sunday, May 19, 2002, at 06:11 AM, Stefano Mazzocchi wrote:
>> It would be interesting whether there would be a project
>> responsible for some "commonly used" documentation.
>> For example:
>> - Understanding the Apache license :-)
>
> eh eh, you'll be happy to know that yesterday I submitted a patch
> exactly for this for the 'almost-to-be-released-after-years' Apache
> License 2.0,
I'm trying to understand if this has *any* bearing on user contributions
of documents.
For example, the Apache HTTP Server docs project appears to retain
copyright for their collective text (and collects royalties for
non-exclusive publishing by third parties.) On the other extreme, if you
peruse Linux Document Project contributions, you'll find most works are
copyrighted by their respective authors.
AFAIK, the Cocoon project's language (e.g. contrib.xml) only discusses
copyright issues as related to contributions of *code*.
What is your understanding?
(1) User contributed-docs must be provided with ASF-compatible terms;
or
(2) users retain copyright to their contributions.
I don't care, either way. I'd just like to clarify the situation up
front for would-be authors.
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Bugs] URLSource
Posted by Steven Noels <st...@outerthought.org>.
Stefano wrote:
> > Instead of having each project answering this stuff for
> > itself, it could be handled globally and only referenced
> > by the project FAQs or included from a repository (the
> > "short form"). Would this fit the Forrest project? Or
> > Avalon or XML Commons? Or should some sort of "Apache
> > encyclopedia" be spawned?
>
> I think it's hard enough to create docs for one project. Created such
> 'common docs' would be a real nightmare... but I won't stop any
> contributions, just I don't know who should handle them :/
I'll be happy to add them to Forrest as template documents for project
documentation, if they are sufficiently generic in scope. One of the
build targets of Forrest *will* be the new xml.apache.org frontpage,
which should include this kind of info, as Jakarta does.
</Steven>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Bugs] URLSource
Posted by Steven Noels <st...@outerthought.org>.
Stefano wrote:
> > Instead of having each project answering this stuff for
> > itself, it could be handled globally and only referenced
> > by the project FAQs or included from a repository (the
> > "short form"). Would this fit the Forrest project? Or
> > Avalon or XML Commons? Or should some sort of "Apache
> > encyclopedia" be spawned?
>
> I think it's hard enough to create docs for one project. Created such
> 'common docs' would be a real nightmare... but I won't stop any
> contributions, just I don't know who should handle them :/
I'll be happy to add them to Forrest as template documents for project
documentation, if they are sufficiently generic in scope. One of the
build targets of Forrest *will* be the new xml.apache.org frontpage,
which should include this kind of info, as Jakarta does.
</Steven>
Re: [Bugs] URLSource
Posted by Stefano Mazzocchi <st...@apache.org>.
"J.Pietschmann" wrote:
>
> Stefano Mazzocchi wrote:
> >
> > Many thanks for the clarification.
> >
> > Ok, people, I'm sure there is some patching to do now :)
> >
> It would be interesting whether there would be a project
> responsible for some "commonly used" documentation.
> For example:
> - Understanding the Apache license :-)
eh eh, you'll be happy to know that yesterday I submitted a patch
exactly for this for the 'almost-to-be-released-after-years' Apache
License 2.0, which is going to be:
1) GPL compatible [means: GPL code can use Apache code without forcing
to make it GPL. Of course, the other way around is impossible by GPL
definition] [WARNING: RMS disagrees but we decided not to care, since
apparently he doesn't want any license to be compatible with the GPL
except the GPL itself]
2) protects from patent infringments
3) covers both "inward" and "outward" changes: means that the license
also include the contributor agreement that otherwise you'd have to sign
if you are a committer (and we normally don't, unless your contribution
is substantial and maybe legally controversial)
4) can be located in just one place of the distro! the code will
contain a very small placeholder (this will reduce the size of our code
by at least 10% on average, expecially on java which has many small
files)
5) it is extensible. Means that you can use it for your own stuff,
without having to modify it and without having to give copyright to the
ASF.
6) trademark, brand protection and major contribution credits are
included in a separate file, so that every Apache project can share the
same LICENSE file and just attach a different NOTICE file.
The suggested patch adds http://www.apache.org/licenses/ right below the
"Apache License 2.0" title: we aim to place in that location all the
information and non-legalese translations about the licensing and legal
issues of the ASF and the AL.
> - Understanding URIs and URLs
Well, this should be a W3C effort :)
> - Understanding the Java classpath and other common
> Java related problems and the like.
This sounds like a java.sun.com effort.
Don't get me wrong, I agree all these things are pretty hard to get and
few people know them in full details, but that's life and as long as
there is crosspollination between the lists (or somebody points to a RFC
or to a maillist message) I think we are set.
Note also, that Apache doesn't host non-software-related projects,
unless strictly connected to their software counterparts (like
httpd-docs, for example)
> All these cause FAQs for all Apache projects I've watched.
We are going to remove your first concern. But I don't think I would
venture to try to fix the other two around apacheland.
> Instead of having each project answering this stuff for
> itself, it could be handled globally and only referenced
> by the project FAQs or included from a repository (the
> "short form"). Would this fit the Forrest project? Or
> Avalon or XML Commons? Or should some sort of "Apache
> encyclopedia" be spawned?
I think it's hard enough to create docs for one project. Created such
'common docs' would be a real nightmare... but I won't stop any
contributions, just I don't know who should handle them :/
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Bugs] URLSource
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Stefano Mazzocchi wrote:
>
> Many thanks for the clarification.
>
> Ok, people, I'm sure there is some patching to do now :)
>
It would be interesting whether there would be a project
responsible for some "commonly used" documentation.
For example:
- Understanding the Apache license :-)
- Understanding URIs and URLs
- Understanding the Java classpath and other common
Java related problems
and the like.
All these cause FAQs for all Apache projects I've watched.
Instead of having each project answering this stuff for
itself, it could be handled globally and only referenced
by the project FAQs or included from a repository (the
"short form"). Would this fit the Forrest project? Or
Avalon or XML Commons? Or should some sort of "Apache
encyclopedia" be spawned?
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Bugs] URLSource
Posted by Stefano Mazzocchi <st...@apache.org>.
"J.Pietschmann" wrote:
>
> Stefano Mazzocchi wrote:
> > NOTE: there is no official indication on how the file: URI should be
> > addressed, but all these
> >
> > file:/file
> > file://file
> > file:///file
> >
> > are all valid URIs and should point to the same file (at least, this was
> > my understanding).
>
> Your understanding is wrong. Only the last is a valid URI.
> The RFC for this appears to be
> http://www.rfc-editor.org/rfc/rfc2396.txt
> and some predecessors.
>
> > It could be possible to add
> >
> > file:file
> >
> > to indicate a relative location.
>
> This is wrong too. An URI starting with an URI scheme
> identificator (like file:) is *always* an absolute URI.
> This:
> /file
> is an *relative* URI, despite being an *absolute* path.
>
> > This is normally achieved by avoiding
> > to indicate the protocol (such as in "file"), but since we need a
> > protocol to identify the handler, "file:file" might just be a way to
> > encode relativity in file positioning.
>
> A relative URI is resolved against a base URI, which sepcifies
> the URI scheme. If your base URI is a file URL, *all* relative
> URIs encountered are resolved to files. You can't have a base
> HTTP URI and suddenly have a relative URI point to a file.
>
> Well, hope this helps:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102027988321347&w=2
Many thanks for the clarification.
Ok, people, I'm sure there is some patching to do now :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Bugs] URLSource
Posted by David Crossley <cr...@indexgeo.com.au>.
J.Pietschmann wrote:
> Stefano Mazzocchi wrote:
> > NOTE: there is no official indication on how the file: URI should be
> > addressed, but all these
> >
> > file:/file
> > file://file
> > file:///file
> >
> > are all valid URIs and should point to the same file (at least, this was
> > my understanding).
>
> Your understanding is wrong. Only the last is a valid URI.
> The RFC for this appears to be
> http://www.rfc-editor.org/rfc/rfc2396.txt
> and some predecessors.
>
> > It could be possible to add
> >
> > file:file
> >
> > to indicate a relative location.
>
> This is wrong too. An URI starting with an URI scheme
> identificator (like file:) is *always* an absolute URI.
> This:
> /file
> is an *relative* URI, despite being an *absolute* path.
>
> > This is normally achieved by avoiding
> > to indicate the protocol (such as in "file"), but since we need a
> > protocol to identify the handler, "file:file" might just be a way to
> > encode relativity in file positioning.
>
> A relative URI is resolved against a base URI, which sepcifies
> the URI scheme. If your base URI is a file URL, *all* relative
> URIs encountered are resolved to files. You can't have a base
> HTTP URI and suddenly have a relative URI point to a file.
>
> Well, hope this helps:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102027988321347&w=2
> Re: changed behaviour with source resolving
As part of that earlier thread i added some corrections to
Cocoon xdocs to encourage proper use of file: URLs.
Those docs have not yet made it to the website, so start at
build/cocoon/docs/faq/faq-sitemap.html#faq-12
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Bugs] URLSource
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Stefano Mazzocchi wrote:
> NOTE: there is no official indication on how the file: URI should be
> addressed, but all these
>
> file:/file
> file://file
> file:///file
>
> are all valid URIs and should point to the same file (at least, this was
> my understanding).
Your understanding is wrong. Only the last is a valid URI.
The RFC for this appears to be
http://www.rfc-editor.org/rfc/rfc2396.txt
and some predecessors.
> It could be possible to add
>
> file:file
>
> to indicate a relative location.
This is wrong too. An URI starting with an URI scheme
identificator (like file:) is *always* an absolute URI.
This:
/file
is an *relative* URI, despite being an *absolute* path.
> This is normally achieved by avoiding
> to indicate the protocol (such as in "file"), but since we need a
> protocol to identify the handler, "file:file" might just be a way to
> encode relativity in file positioning.
A relative URI is resolved against a base URI, which sepcifies
the URI scheme. If your base URI is a file URL, *all* relative
URIs encountered are resolved to files. You can't have a base
HTTP URI and suddenly have a relative URI point to a file.
Well, hope this helps:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102027988321347&w=2
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Bugs] URLSource
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
>
> > Stefano Mazzocchi wrote:
> >
> > Carsten,
> >
> > I've recently switched to the new source-resolving excalibur code and I
> > found that you use the following
> >
> > File file = new File( this.systemId.substring( "file".length() ) );
> >
> Where did you see this? AFAIS it's ... "file:".length() ... for example
> in the URLSource
Yes, I adapted this for this email because people didn't know what FILE
pointed to.
> > to obtain the 'path' part of a 'file' URI. The above might work on UNIX,
> > but it clearly doesn't work on other operating systems, since URIs like
> > these
> >
> > file:///c:/path/to/file
> >
> > are totally valid and your code is not able to handle them.
> >
> > Now, my suggestion would be to use the standard java.net API because
> > they already handle all these issues (file: protocol handling is
> > expecially tricky on regards of the number of slashes).
> >
> > NOTE: there is no official indication on how the file: URI should be
> > addressed, but all these
> >
> > file:/file
> > file://file
> > file:///file
> >
> > are all valid URIs and should point to the same file (at least, this was
> > my understanding). It could be possible to add
> >
> > file:file
> >
> > to indicate a relative location. This is normally achieved by avoiding
> > to indicate the protocol (such as in "file"), but since we need a
> > protocol to identify the handler, "file:file" might just be a way to
> > encode relativity in file positioning.
> >
>
> Actually the code used in the "new" source resoling is the old code
> which is in Cocoon 2 since the early days. So if this is a problem it
> was there for "years".
No, search for 'M$' and you'll see something that it's not there
anymore.
> Can someone verify if it is a problem on some OS and then please
> do a patch?
>
> > - o -
> >
> > I just found another bug: the docs say that if you call
> >
> > resolver.resolveURI()
> >
> > and the resource doesn't exist, you get a SourceNotFoundException. If yo
> > are accessing file resources, instead you get a FileNotFoundException,
> > which is not even inherited.
> Yes, this is true and it's a bug! I added the SourceNotFoundException
> recently
> but didn't have time to add the "throwing" code. So the docs are more
> upto-date
> than the code...
> Perhaps if someone could send a patch...
>
> >
> > Expect more bug report soon since I'm getting pretty heavy on sources :)
> >
> This is good! Really! I didn't have the time to do as much testing as I
> wanted
> as we are currently working on some great things for Cocoon which will
> (hopefully)
> make Cocoon the number one web application framework and scare many big
> companies
> as this all will be open source ;)
> But currently I don't want to say more, I expect to finish most of it in
> late
> summer!
:)
Unfortunately, I don't have time to follow this now and I'm doing my
development on 2.0.3 not on 2.1 (not yet, I'll do this when I have time
and probably when Schecoon will be merged in the 2.1 tree since I need
it!)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Bugs] URLSource
Posted by Stefano Mazzocchi <st...@apache.org>.
Matthew Langham wrote:
>
> >>
> This is good! Really! I didn't have the time to do as much testing as I
> wanted as we are currently working on some great things for Cocoon which
> will (hopefully) make Cocoon the number one web application framework and
> scare many big companies as this all will be open source ;) But currently I
> don't want to say more, I expect to finish most of it in late summer!
> <<
> Everyone - please ignore this. Carsten had too many drinks at Jax2002.
> Carsten - please come round to see me :-)
>
> :-)
ROTFL :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Bugs] URLSource
Posted by Matthew Langham <ml...@s-und-n.de>.
>>
This is good! Really! I didn't have the time to do as much testing as I
wanted as we are currently working on some great things for Cocoon which
will (hopefully) make Cocoon the number one web application framework and
scare many big companies as this all will be open source ;) But currently I
don't want to say more, I expect to finish most of it in late summer!
<<
Everyone - please ignore this. Carsten had too many drinks at Jax2002.
Carsten - please come round to see me :-)
:-)
Matthew
--
Open Source Group Cocoon { Consulting, Training, Projects }
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
-----------------------------------------------------------------
Cocoon book:
http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
=================================================================
-----Original Message-----
From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
Sent: Friday, May 17, 2002 10:23 AM
To: Cocoon-Dev
Subject: RE: [Bugs] URLSource
> Stefano Mazzocchi wrote:
>
> Carsten,
>
> I've recently switched to the new source-resolving excalibur code and I
> found that you use the following
>
> File file = new File( this.systemId.substring( "file".length() ) );
>
Where did you see this? AFAIS it's ... "file:".length() ... for example
in the URLSource
> to obtain the 'path' part of a 'file' URI. The above might work on UNIX,
> but it clearly doesn't work on other operating systems, since URIs like
> these
>
> file:///c:/path/to/file
>
> are totally valid and your code is not able to handle them.
>
> Now, my suggestion would be to use the standard java.net API because
> they already handle all these issues (file: protocol handling is
> expecially tricky on regards of the number of slashes).
>
> NOTE: there is no official indication on how the file: URI should be
> addressed, but all these
>
> file:/file
> file://file
> file:///file
>
> are all valid URIs and should point to the same file (at least, this was
> my understanding). It could be possible to add
>
> file:file
>
> to indicate a relative location. This is normally achieved by avoiding
> to indicate the protocol (such as in "file"), but since we need a
> protocol to identify the handler, "file:file" might just be a way to
> encode relativity in file positioning.
>
Actually the code used in the "new" source resoling is the old code
which is in Cocoon 2 since the early days. So if this is a problem it
was there for "years".
Can someone verify if it is a problem on some OS and then please
do a patch?
> - o -
>
> I just found another bug: the docs say that if you call
>
> resolver.resolveURI()
>
> and the resource doesn't exist, you get a SourceNotFoundException. If yo
> are accessing file resources, instead you get a FileNotFoundException,
> which is not even inherited.
Yes, this is true and it's a bug! I added the SourceNotFoundException
recently
but didn't have time to add the "throwing" code. So the docs are more
upto-date
than the code...
Perhaps if someone could send a patch...
>
> Expect more bug report soon since I'm getting pretty heavy on sources :)
>
This is good! Really! I didn't have the time to do as much testing as I
wanted
as we are currently working on some great things for Cocoon which will
(hopefully)
make Cocoon the number one web application framework and scare many big
companies
as this all will be open source ;)
But currently I don't want to say more, I expect to finish most of it in
late
summer!
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Bugs] URLSource
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> Stefano Mazzocchi wrote:
>
> Carsten,
>
> I've recently switched to the new source-resolving excalibur code and I
> found that you use the following
>
> File file = new File( this.systemId.substring( "file".length() ) );
>
Where did you see this? AFAIS it's ... "file:".length() ... for example
in the URLSource
> to obtain the 'path' part of a 'file' URI. The above might work on UNIX,
> but it clearly doesn't work on other operating systems, since URIs like
> these
>
> file:///c:/path/to/file
>
> are totally valid and your code is not able to handle them.
>
> Now, my suggestion would be to use the standard java.net API because
> they already handle all these issues (file: protocol handling is
> expecially tricky on regards of the number of slashes).
>
> NOTE: there is no official indication on how the file: URI should be
> addressed, but all these
>
> file:/file
> file://file
> file:///file
>
> are all valid URIs and should point to the same file (at least, this was
> my understanding). It could be possible to add
>
> file:file
>
> to indicate a relative location. This is normally achieved by avoiding
> to indicate the protocol (such as in "file"), but since we need a
> protocol to identify the handler, "file:file" might just be a way to
> encode relativity in file positioning.
>
Actually the code used in the "new" source resoling is the old code
which is in Cocoon 2 since the early days. So if this is a problem it
was there for "years".
Can someone verify if it is a problem on some OS and then please
do a patch?
> - o -
>
> I just found another bug: the docs say that if you call
>
> resolver.resolveURI()
>
> and the resource doesn't exist, you get a SourceNotFoundException. If yo
> are accessing file resources, instead you get a FileNotFoundException,
> which is not even inherited.
Yes, this is true and it's a bug! I added the SourceNotFoundException
recently
but didn't have time to add the "throwing" code. So the docs are more
upto-date
than the code...
Perhaps if someone could send a patch...
>
> Expect more bug report soon since I'm getting pretty heavy on sources :)
>
This is good! Really! I didn't have the time to do as much testing as I
wanted
as we are currently working on some great things for Cocoon which will
(hopefully)
make Cocoon the number one web application framework and scare many big
companies
as this all will be open source ;)
But currently I don't want to say more, I expect to finish most of it in
late
summer!
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org