You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by James M Snell <ja...@gmail.com> on 2008/03/31 17:42:25 UTC

[VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

The Abdera project has resolved the issues raised previously and have 
voted to release a new build of the 0.4.0-incubating release.

Binary distributions:

http://people.apache.org/~dandiep/abdera-take6/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.zip
http://people.apache.org/~dandiep/abdera-take6/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.tar.gz

Source distributions:

http://people.apache.org/~dandiep/abdera-take6/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.zip
http://people.apache.org/~dandiep/abdera-take6/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.tar.gz

Maven Repository: http://people.apache.org/~dandiep/abdera-take6/

Please take a look and cast your vote!

- Abdera Team

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Mar 31, 2008 at 10:56 PM, sebb <se...@gmail.com> wrote:
> On 31/03/2008, James M Snell <ja...@gmail.com> wrote:

>  > ... None of the build scripts contain license headers.  Given that the build
>  >  scripts are everyday, normal maven build scripts, I do believe they
>  >  qualify under the "a file without any degree of creativity" clause.
>
>  I disagree....

Disagree as well - it is very possible for a pom to contain some
degree of creativity, it's easy to add license headers to them, and
asking the incubator PMC to look at all of them to verify that they're
not creative is a waste of time, IMHO.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Mon, Mar 31, 2008 at 5:56 PM, sebb <se...@gmail.com> wrote:

>  Probably.
>  Though if the AL header affects the parsing, then there may well be a
>  problem with the parsing...

Please.  Are you actually suggesting that it's a good idea to make all
of our test cases demonstrably different from the content that you
actually see in the wild?  Should we be able to parse a comment at the
top?  Sure.  Should that be the default case we're testing just to
satisfy pointless arguments about who can be more pedantically correct
about where license headers go?  No.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by James M Snell <ja...@gmail.com>.
Notice added. Do you see anything else?

- James

sebb wrote:
> [snip]
>>  > Also, SVN includes the file
>>  > dependencies/i18n/src/main/java/org/apache/abdera/i18n/text/data/CompositionExclusions.txt
>>  > which is not AL licensed; IMO it should be attributed in the NOTICE file.
>>  >
>>
>>
>> I've just removed the file completely as we actually no longer need it
>>  at runtime. In the future, I plan to automate the process of downloading
>>  and processing that file during the build process.
>>
> 
> However the product still depends on the file - I don't think the fact
> that the file is not in SVN makes any dfference.
> [snip]

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by sebb <se...@gmail.com>.
On 01/04/2008, James M Snell <ja...@gmail.com> wrote:
>
>
>  sebb wrote:
>  > The following do not seem to be test files, nor are they trivially short.
>  > So they should have AL headers please:
>  >
>  > core/src/main/resources/abdera.properties.example
>  > dependencies/deps.properties
>  >
>
>
> Done
>

Thanks

>  > The top level NOTICE file should not have the 4 line == header.
>
>
> Removed
>

Thanks

>  > Also, SVN includes the file
>  > dependencies/i18n/src/main/java/org/apache/abdera/i18n/text/data/CompositionExclusions.txt
>  > which is not AL licensed; IMO it should be attributed in the NOTICE file.
>  >
>
>
> I've just removed the file completely as we actually no longer need it
>  at runtime. In the future, I plan to automate the process of downloading
>  and processing that file during the build process.
>

However the product still depends on the file - I don't think the fact
that the file is not in SVN makes any dfference.

>
>  - James
>
>
>  > Probably something needs to go in the LICENSE file as well
>  >
>  >
>  >
>  > On 01/04/2008, James M Snell <ja...@gmail.com> wrote:
>  >> I've added license headers to the build scripts and to the localization
>  >>  file and log4j.properties file. The rest I intend to leave as is.  Is
>  >>  that sufficient?  If so, we'll roll a new build.
>  >>
>  >>
>  >>  - James
>  >>
>  >>  sebb wrote:
>  >>  > On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
>  >>  >> In the FAQ I see this: "A file without any degree of creativity in
>  >>  >>  either its literal elements or its structure is not protected by
>  >>  >>  copyright law; therefore, such a file does not require a license header.
>  >>  >
>  >>  > Yes, but:
>  >>  >
>  >>  >>   If in doubt about the extent of the file's creativity, add the license
>  >>  >>  header to the file."
>  >>  >
>  >>  >>  Here's the breakdown that I see from Rat:
>  >>  >>
>  >>  >>  None of the build scripts contain license headers.  Given that the build
>  >>  >>  scripts are everyday, normal maven build scripts, I do believe they
>  >>  >>  qualify under the "a file without any degree of creativity" clause.
>  >>  >
>  >>  > I disagree.
>  >>  >
>  >>  > Note that all Commons poms include the AL header.
>  >>  >
>  >>  >>   ? adapters/pom.xml
>  >>  >>   ? client/pom.xml
>  >>  >>   ? core/pom.xml
>  >>  >>   ? examples/pom.xml
>  >>  >>   ? extensions/pom.xml
>  >>  >>   ? extensions/gdata/pom.xml
>  >>  >>   ? extensions/geo/pom.xml
>  >>  >>   ? extensions/html/pom.xml
>  >>  >>   ? extensions/json/pom.xml
>  >>  >>   ? extensions/main/pom.xml
>  >>  >>   ? extensions/media/pom.xml
>  >>  >>   ? extensions/oauth/pom.xml
>  >>  >>   ? extensions/opensearch/pom.xml
>  >>  >>   ? extensions/serializer/pom.xml
>  >>  >>   ? extensions/sharing/pom.xml
>  >>  >>   ? extensions/wsse/pom.xml
>  >>  >>   ? parser/pom.xml
>  >>  >>   ? security/pom.xml
>  >>  >>   ? server/pom.xml
>  >>  >>   ? spring/pom.xml
>  >>  >>   ? dependencies/deps.properties
>  >>  >>
>  >>  >>  The following file used to provide localization strings may possibly
>  >>  >>  require a license header.
>  >>  >>
>  >>  >>   ? core/src/main/resources/abderamessages.properties
>  >>  >>
>  >>  >>  The following are configuration files used at runtime, the majority of
>  >>  >>  which consist of only a few lines of text and also fall under the above
>  >>  >>  quoted clause.
>  >>  >>
>  >>  >>   ? client/src/main/java/log4j.properties
>  >>  >>   ? core/src/main/resources/abdera.properties.example
>  >>  >>   ?
>  >>  >
>  >>  > These have less content, so the creative aspect is definitely lower.
>  >>  > However, I don't think there's no creativity involved.
>  >>  >
>  >>  >>  core/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory.example
>  >>  >>   ?
>  >>  >>  core/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>  >>   ?
>  >>  >>  core/src/test/resources/META-INF/services/org.apache.abdera.converter.ConverterProvider
>  >>  >>   ?
>  >>  >>  examples/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>  >>   ?
>  >>  >>  extensions/complete/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>  >>  >>   ?
>  >>  >>  extensions/complete/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>  >>   ?
>  >>  >>  extensions/complete/resources/META-INF/services/org.apache.abdera.parser.NamedParser
>  >>  >>   ?
>  >>  >>  extensions/html/src/main/resources/META-INF/services/org.apache.abdera.parser.NamedParser
>  >>  >>   ?
>  >>  >>  extensions/json/src/main/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>  >>  >>  !?????
>  >>  >>  extensions/main/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>  >>   ?
>  >>  >>  extensions/media/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>  >>   ?
>  >>  >>  extensions/opensearch/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>  >>   ?
>  >>  >>  extensions/sharing/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>  >>   ?
>  >>  >>  parser/src/main/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>  >>  >>   ?
>  >>  >>  contrib/rss/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>  >>
>  >>  >
>  >>  > Agreed.
>  >>  >
>  >>  >>  The following simple files are used for example purposes and do not
>  >>  >>  contain any creative content whatsoever.
>  >>  >>
>  >>  >>   ? examples/src/main/resources/xmlcontent.xml
>  >>  >>   ? examples/src/main/resources/log4j.properties
>  >>  >>   ? examples/src/main/resources/simple.xml
>  >>  >>   ? examples/src/main/resources/test.xslt
>  >>  >>   ? examples/src/main/resources/content.xslt
>  >>  >>   ? examples/src/main/resources/org/apache/abdera/examples/appserver/web.xml
>  >>  >
>  >>  > Not much creativity, and small files, so the AL header is not essential.
>  >>  >
>  >>  >>  The following were also (inappropriately) flagged by RAT
>  >>  >>
>  >>  >>   ? extensions/complete/resources/META-INF/LICENSE.htmlparser.txt
>  >>  >>   ? extensions/complete/resources/META-INF/NOTICE.htmlparser.txt
>  >>  >>   ? extensions/complete/resources/META-INF/NOTICE.serializer.txt
>  >>  >>   ? extensions/json/src/main/resources/META-INF/LICENSE.htmlparser.txt
>  >>  >>   ? extensions/json/src/main/resources/META-INF/NOTICE.htmlparser.txt
>  >>  >>   ? extensions/json/src/main/resources/META-INF/NOTICE.serializer.txt
>  >>  >>   ? dependencies/legal/servlet-api-LICENSE.txt
>  >>  >>   ? dependencies/legal/htmlparser-LICENSE.txt
>  >>  >>
>  >>  >>
>  >>  >>  The following resources are test resources that in addition to not
>  >>  >>  containing any degree of creative content, they arguably should not
>  >>  >>  contain license headers because the presence of the license header could
>  >>  >>  potentially impact the results of the tests.
>  >>  >>
>  >>  >
>  >>  > Probably.
>  >>  > Though if the AL header affects the parsing, then there may well be a
>  >>  > problem with the parsing...
>  >>  >
>  >>  >>   ? adapters/hibernate/src/test/resources/abdera/adapter/hibernate.cfg.xml
>  >>  >>   ? adapters/hibernate/src/test/resources/abdera/adapter/DummyData.hbm.xml
>  >>  >>   ? extensions/opensearch/src/test/resources/opensearch.xml
>  >>  >>   ?
>  >>  >>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace.xml
>  >>  >>   ?
>  >>  >>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace3.xml
>  >>  >>   ?
>  >>  >>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace2.xml
>  >>  >>   ? parser/src/test/resources/www.snellspace.com/public/xmlbase.xml
>  >>  >>   ? parser/src/test/resources/www.snellspace.com/public/ordertest.xml
>  >>  >>   ? parser/src/test/resources/www.snellspace.com/public/linktests.xml
>  >>  >>   ? parser/src/test/resources/www.snellspace.com/public/contentsummary.xml
>  >>  >>   ? parser/src/test/resources/simpleFeed.xml
>  >>  >>   ? parser/src/test/resources/xmlcontent.xml
>  >>  >>   ? parser/src/test/resources/feed.xml
>  >>  >>   ? parser/src/test/resources/simple.xml
>  >>  >>   ?
>  >>  >>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_content_base64_2.xml
>  >>  >>   ?
>  >>  >>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_content_base64.xml
>  >>  >>   ?
>  >>  >>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_author_email.xml
>  >>  >>   ?
>  >>  >>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_author_name.xml
>  >>  >>   ?
>  >>  >>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/atom10_namespace.xml
>  >>  >>   ? parser/src/test/resources/complete.xml
>  >>  >>   ? parser/src/test/resources/simpleService.xml
>  >>  >>   ? parser/src/test/resources/simpleEntry.xml
>  >>  >>   ? parser/src/test/resources/test.xslt
>  >>  >>   ? parser/src/test/resources/entry.xml
>  >>  >>   ? parser/src/test/resources/content.xslt
>  >>  >>   ? spring/src/test/resources/org/apache/abdera/spring/beans.xml
>  >>  >>   ? contrib/rss/src/test/resources/rss1.rdf
>  >>  >>   ?
>  >>  >>  adapters/hibernate/src/test/resources/abdera/adapter/hibernate.properties
>  >>  >>   ? security/src/test/resources/log4j.properties
>  >>  >>   ? server/src/test/resources/abdera/adapter/sample.properties
>  >>  >>
>  >>  >>  This one documentation file, which contains only a single one sentence
>  >>  >>  statement, does not contain a license header.
>  >>  >>
>  >>  >>   ? docs/knownissues.txt
>  >>  >>
>  >>  >>  Which of these files do you think we absolutely have to add license
>  >>  >>  headers to?
>  >>  >>
>  >>  >>
>  >>  >>  - James
>  >>  >>
>  >>  >>
>  >>  >>  sebb wrote:
>  >>  >>  > On 31/03/2008, Dan Diephouse <da...@mulesource.com> wrote:
>  >>  >>  >> sebb wrote:
>  >>  >>  >>  > On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
>  >>  >>  >>  >
>  >>  >>  >>  >>
>  >>  >>  >>  >
>  >>  >>  >>
>  >>  >>  >>> -1: There are MD5 and SHA1 digests in the directory, but the archives
>  >>  >>  >>  > have no signatures.
>  >>  >>  >>  >
>  >>  >>  >>  >
>  >>  >>  >>
>  >>  >>  >> OK, I will fix this.
>  >>  >>  >>
>  >>  >>  >>>>  Maven Repository: http://people.apache.org/~dandiep/abdera-take6/
>  >>  >>  >>  >>
>  >>  >>  >>  >>
>  >>  >>  >>  >
>  >>  >>  >>  > -0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
>  >>  >>  >>  > have any content - only the META-INF directory is present. Is that
>  >>  >>  >>  > correct?
>  >>  >>  >>  >
>  >>  >>  >>
>  >>  >>  >> This is just a by-product of Maven. We can delete it.
>  >>  >>  >>
>  >>  >>  >>> -1: The NOTICE files in that jar (and others) contains far too much.
>  >>  >>  >>  > The NOTICE file is for required attribtions ONLY (e.g. as per an About box)
>  >>  >>  >>  > There's really no need to repeat ASF for each project used by Abdera.
>  >>  >>  >>  >
>  >>  >>  >>
>  >>  >>  >> Having too much information in the NOTICE files is not a crime. The
>  >>  >>  >>  Maven remote-resources plugin aggregates all this stuff for us so we
>  >>  >>  >>  never miss any notice that we need to put in.
>  >>  >>  >
>  >>  >>  > Unfortunately the plugin generates incorrect information.
>  >>  >>  > It *is* a problem having all the redundant information.
>  >>  >>  >
>  >>  >>  > See for example:
>  >>  >>  >
>  >>  >>  > http://www.apache.org/legal/src-headers.html
>  >>  >>  > also
>  >>  >>  > http://wiki.apache.org/legal/3party/notice
>  >>  >>  > http://wiki.apache.org/legal/3party/notice/discuss
>  >>  >>  >
>  >>  >>  >>> -1: The LICENSE files need to either contain copies of the 3rd party
>  >>  >>  >>  > licenses, or they need to have a reference to the 3rd party licences.
>  >>  >>  >>  > Equally, there is no need for the lib directory to contain copies of
>  >>  >>  >>  > the AL for every ASF product.
>  >>  >>  >>  >
>  >>  >>  >>
>  >>  >>  >> Why does the LICENSE file need to have a copy of all the other licenses?
>  >>  >>  >>  These are contained in the lib/ directory like many other ASF projects.
>  >>  >>  >>
>  >>  >>  >
>  >>  >>  > See the last paragraph of:
>  >>  >>  >
>  >>  >>  > http://www.apache.org/dev/apply-license.html#new
>  >>  >>  >
>  >>  >>  >>  Re: the ASL license in lib/ - once again having too much information is
>  >>  >>  >>  not a crime. This is a service to uesrs so they know where the libraries
>  >>  >>  >>  came from.
>  >>  >>  >
>  >>  >>  > I agree the source is useful, but the place for this is the LICENSE file.
>  >>  >>  >
>  >>  >>  >>> -1: RAT report says:
>  >>  >>  >>  >
>  >>  >>  >>  > 99 Unknown Licenses
>  >>  >>  >>  >
>  >>  >>  >>  > Some of these are trivial, but most require an AL header.
>  >>  >>  >>  >
>  >>  >>  >>
>  >>  >>  >> Not true - there is not consensus that properties/xml files need to have
>  >>  >>  >>  headers. All the Java source code files have headers. If there are
>  >>  >>  >>  specific files that you feel should have a license that don't please
>  >>  >>  >>  list them and explain why. I'm not saying that we didn't miss something,
>  >>  >>  >>  but I am saying that the ones that I know about don't necessarily
>  >>  >>  >>  require a header.
>  >>  >>  >
>  >>  >>  > Yes, they do, see:
>  >>  >>  >
>  >>  >>  > http://www.apache.org/legal/src-headers.html#faq-exceptions
>  >>  >>  >
>  >>  >>  >>> What is the SVN tag that corresponds with the archives?
>  >>  >>  >>  >
>  >>  >>  >>  >
>  >>  >>  >>
>  >>  >>  >> the branch will be tagged once its released.
>  >>  >>  >>
>  >>  >>  >>  Dan
>  >>  >>  >>
>  >>  >>  >>
>  >>  >>  >>  --
>  >>  >>  >>  Dan Diephouse
>  >>  >>  >>  MuleSource
>  >>  >>  >>  http://mulesource.com | http://netzooid.com
>  >>  >>  >>
>  >>  >>  >>
>  >>  >>  >>
>  >>  >>  >>  ---------------------------------------------------------------------
>  >>  >>  >>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  >>  >>  >>  For additional commands, e-mail: general-help@incubator.apache.org
>  >>  >>  >>
>  >>  >>  >>
>  >>  >>  >
>  >>  >>  > ---------------------------------------------------------------------
>  >>  >>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  >>  >>  > For additional commands, e-mail: general-help@incubator.apache.org
>  >>  >>  >
>  >>  >>  >
>  >>  >>
>  >>  >>  ---------------------------------------------------------------------
>  >>  >>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  >>  >>  For additional commands, e-mail: general-help@incubator.apache.org
>  >>  >>
>  >>  >>
>  >>  >
>  >>  > ---------------------------------------------------------------------
>  >>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  >>  > For additional commands, e-mail: general-help@incubator.apache.org
>  >>  >
>  >>  >
>  >>
>  >>  ---------------------------------------------------------------------
>  >>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  >>  For additional commands, e-mail: general-help@incubator.apache.org
>  >>
>  >>
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  > For additional commands, e-mail: general-help@incubator.apache.org
>  >
>  >
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by James M Snell <ja...@gmail.com>.

sebb wrote:
> The following do not seem to be test files, nor are they trivially short.
> So they should have AL headers please:
> 
> core/src/main/resources/abdera.properties.example
> dependencies/deps.properties
> 

Done

> The top level NOTICE file should not have the 4 line == header.

Removed

> Also, SVN includes the file
> dependencies/i18n/src/main/java/org/apache/abdera/i18n/text/data/CompositionExclusions.txt
> which is not AL licensed; IMO it should be attributed in the NOTICE file.
> 

I've just removed the file completely as we actually no longer need it 
at runtime. In the future, I plan to automate the process of downloading 
and processing that file during the build process.

- James

> Probably something needs to go in the LICENSE file as well
> 
> 
> 
> On 01/04/2008, James M Snell <ja...@gmail.com> wrote:
>> I've added license headers to the build scripts and to the localization
>>  file and log4j.properties file. The rest I intend to leave as is.  Is
>>  that sufficient?  If so, we'll roll a new build.
>>
>>
>>  - James
>>
>>  sebb wrote:
>>  > On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
>>  >> In the FAQ I see this: "A file without any degree of creativity in
>>  >>  either its literal elements or its structure is not protected by
>>  >>  copyright law; therefore, such a file does not require a license header.
>>  >
>>  > Yes, but:
>>  >
>>  >>   If in doubt about the extent of the file's creativity, add the license
>>  >>  header to the file."
>>  >
>>  >>  Here's the breakdown that I see from Rat:
>>  >>
>>  >>  None of the build scripts contain license headers.  Given that the build
>>  >>  scripts are everyday, normal maven build scripts, I do believe they
>>  >>  qualify under the "a file without any degree of creativity" clause.
>>  >
>>  > I disagree.
>>  >
>>  > Note that all Commons poms include the AL header.
>>  >
>>  >>   ? adapters/pom.xml
>>  >>   ? client/pom.xml
>>  >>   ? core/pom.xml
>>  >>   ? examples/pom.xml
>>  >>   ? extensions/pom.xml
>>  >>   ? extensions/gdata/pom.xml
>>  >>   ? extensions/geo/pom.xml
>>  >>   ? extensions/html/pom.xml
>>  >>   ? extensions/json/pom.xml
>>  >>   ? extensions/main/pom.xml
>>  >>   ? extensions/media/pom.xml
>>  >>   ? extensions/oauth/pom.xml
>>  >>   ? extensions/opensearch/pom.xml
>>  >>   ? extensions/serializer/pom.xml
>>  >>   ? extensions/sharing/pom.xml
>>  >>   ? extensions/wsse/pom.xml
>>  >>   ? parser/pom.xml
>>  >>   ? security/pom.xml
>>  >>   ? server/pom.xml
>>  >>   ? spring/pom.xml
>>  >>   ? dependencies/deps.properties
>>  >>
>>  >>  The following file used to provide localization strings may possibly
>>  >>  require a license header.
>>  >>
>>  >>   ? core/src/main/resources/abderamessages.properties
>>  >>
>>  >>  The following are configuration files used at runtime, the majority of
>>  >>  which consist of only a few lines of text and also fall under the above
>>  >>  quoted clause.
>>  >>
>>  >>   ? client/src/main/java/log4j.properties
>>  >>   ? core/src/main/resources/abdera.properties.example
>>  >>   ?
>>  >
>>  > These have less content, so the creative aspect is definitely lower.
>>  > However, I don't think there's no creativity involved.
>>  >
>>  >>  core/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory.example
>>  >>   ?
>>  >>  core/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>>  >>   ?
>>  >>  core/src/test/resources/META-INF/services/org.apache.abdera.converter.ConverterProvider
>>  >>   ?
>>  >>  examples/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>>  >>   ?
>>  >>  extensions/complete/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>>  >>   ?
>>  >>  extensions/complete/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>>  >>   ?
>>  >>  extensions/complete/resources/META-INF/services/org.apache.abdera.parser.NamedParser
>>  >>   ?
>>  >>  extensions/html/src/main/resources/META-INF/services/org.apache.abdera.parser.NamedParser
>>  >>   ?
>>  >>  extensions/json/src/main/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>>  >>  !?????
>>  >>  extensions/main/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>>  >>   ?
>>  >>  extensions/media/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>>  >>   ?
>>  >>  extensions/opensearch/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>>  >>   ?
>>  >>  extensions/sharing/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>>  >>   ?
>>  >>  parser/src/main/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>>  >>   ?
>>  >>  contrib/rss/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>>  >>
>>  >
>>  > Agreed.
>>  >
>>  >>  The following simple files are used for example purposes and do not
>>  >>  contain any creative content whatsoever.
>>  >>
>>  >>   ? examples/src/main/resources/xmlcontent.xml
>>  >>   ? examples/src/main/resources/log4j.properties
>>  >>   ? examples/src/main/resources/simple.xml
>>  >>   ? examples/src/main/resources/test.xslt
>>  >>   ? examples/src/main/resources/content.xslt
>>  >>   ? examples/src/main/resources/org/apache/abdera/examples/appserver/web.xml
>>  >
>>  > Not much creativity, and small files, so the AL header is not essential.
>>  >
>>  >>  The following were also (inappropriately) flagged by RAT
>>  >>
>>  >>   ? extensions/complete/resources/META-INF/LICENSE.htmlparser.txt
>>  >>   ? extensions/complete/resources/META-INF/NOTICE.htmlparser.txt
>>  >>   ? extensions/complete/resources/META-INF/NOTICE.serializer.txt
>>  >>   ? extensions/json/src/main/resources/META-INF/LICENSE.htmlparser.txt
>>  >>   ? extensions/json/src/main/resources/META-INF/NOTICE.htmlparser.txt
>>  >>   ? extensions/json/src/main/resources/META-INF/NOTICE.serializer.txt
>>  >>   ? dependencies/legal/servlet-api-LICENSE.txt
>>  >>   ? dependencies/legal/htmlparser-LICENSE.txt
>>  >>
>>  >>
>>  >>  The following resources are test resources that in addition to not
>>  >>  containing any degree of creative content, they arguably should not
>>  >>  contain license headers because the presence of the license header could
>>  >>  potentially impact the results of the tests.
>>  >>
>>  >
>>  > Probably.
>>  > Though if the AL header affects the parsing, then there may well be a
>>  > problem with the parsing...
>>  >
>>  >>   ? adapters/hibernate/src/test/resources/abdera/adapter/hibernate.cfg.xml
>>  >>   ? adapters/hibernate/src/test/resources/abdera/adapter/DummyData.hbm.xml
>>  >>   ? extensions/opensearch/src/test/resources/opensearch.xml
>>  >>   ?
>>  >>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace.xml
>>  >>   ?
>>  >>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace3.xml
>>  >>   ?
>>  >>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace2.xml
>>  >>   ? parser/src/test/resources/www.snellspace.com/public/xmlbase.xml
>>  >>   ? parser/src/test/resources/www.snellspace.com/public/ordertest.xml
>>  >>   ? parser/src/test/resources/www.snellspace.com/public/linktests.xml
>>  >>   ? parser/src/test/resources/www.snellspace.com/public/contentsummary.xml
>>  >>   ? parser/src/test/resources/simpleFeed.xml
>>  >>   ? parser/src/test/resources/xmlcontent.xml
>>  >>   ? parser/src/test/resources/feed.xml
>>  >>   ? parser/src/test/resources/simple.xml
>>  >>   ?
>>  >>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_content_base64_2.xml
>>  >>   ?
>>  >>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_content_base64.xml
>>  >>   ?
>>  >>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_author_email.xml
>>  >>   ?
>>  >>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_author_name.xml
>>  >>   ?
>>  >>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/atom10_namespace.xml
>>  >>   ? parser/src/test/resources/complete.xml
>>  >>   ? parser/src/test/resources/simpleService.xml
>>  >>   ? parser/src/test/resources/simpleEntry.xml
>>  >>   ? parser/src/test/resources/test.xslt
>>  >>   ? parser/src/test/resources/entry.xml
>>  >>   ? parser/src/test/resources/content.xslt
>>  >>   ? spring/src/test/resources/org/apache/abdera/spring/beans.xml
>>  >>   ? contrib/rss/src/test/resources/rss1.rdf
>>  >>   ?
>>  >>  adapters/hibernate/src/test/resources/abdera/adapter/hibernate.properties
>>  >>   ? security/src/test/resources/log4j.properties
>>  >>   ? server/src/test/resources/abdera/adapter/sample.properties
>>  >>
>>  >>  This one documentation file, which contains only a single one sentence
>>  >>  statement, does not contain a license header.
>>  >>
>>  >>   ? docs/knownissues.txt
>>  >>
>>  >>  Which of these files do you think we absolutely have to add license
>>  >>  headers to?
>>  >>
>>  >>
>>  >>  - James
>>  >>
>>  >>
>>  >>  sebb wrote:
>>  >>  > On 31/03/2008, Dan Diephouse <da...@mulesource.com> wrote:
>>  >>  >> sebb wrote:
>>  >>  >>  > On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
>>  >>  >>  >
>>  >>  >>  >>
>>  >>  >>  >
>>  >>  >>
>>  >>  >>> -1: There are MD5 and SHA1 digests in the directory, but the archives
>>  >>  >>  > have no signatures.
>>  >>  >>  >
>>  >>  >>  >
>>  >>  >>
>>  >>  >> OK, I will fix this.
>>  >>  >>
>>  >>  >>>>  Maven Repository: http://people.apache.org/~dandiep/abdera-take6/
>>  >>  >>  >>
>>  >>  >>  >>
>>  >>  >>  >
>>  >>  >>  > -0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
>>  >>  >>  > have any content - only the META-INF directory is present. Is that
>>  >>  >>  > correct?
>>  >>  >>  >
>>  >>  >>
>>  >>  >> This is just a by-product of Maven. We can delete it.
>>  >>  >>
>>  >>  >>> -1: The NOTICE files in that jar (and others) contains far too much.
>>  >>  >>  > The NOTICE file is for required attribtions ONLY (e.g. as per an About box)
>>  >>  >>  > There's really no need to repeat ASF for each project used by Abdera.
>>  >>  >>  >
>>  >>  >>
>>  >>  >> Having too much information in the NOTICE files is not a crime. The
>>  >>  >>  Maven remote-resources plugin aggregates all this stuff for us so we
>>  >>  >>  never miss any notice that we need to put in.
>>  >>  >
>>  >>  > Unfortunately the plugin generates incorrect information.
>>  >>  > It *is* a problem having all the redundant information.
>>  >>  >
>>  >>  > See for example:
>>  >>  >
>>  >>  > http://www.apache.org/legal/src-headers.html
>>  >>  > also
>>  >>  > http://wiki.apache.org/legal/3party/notice
>>  >>  > http://wiki.apache.org/legal/3party/notice/discuss
>>  >>  >
>>  >>  >>> -1: The LICENSE files need to either contain copies of the 3rd party
>>  >>  >>  > licenses, or they need to have a reference to the 3rd party licences.
>>  >>  >>  > Equally, there is no need for the lib directory to contain copies of
>>  >>  >>  > the AL for every ASF product.
>>  >>  >>  >
>>  >>  >>
>>  >>  >> Why does the LICENSE file need to have a copy of all the other licenses?
>>  >>  >>  These are contained in the lib/ directory like many other ASF projects.
>>  >>  >>
>>  >>  >
>>  >>  > See the last paragraph of:
>>  >>  >
>>  >>  > http://www.apache.org/dev/apply-license.html#new
>>  >>  >
>>  >>  >>  Re: the ASL license in lib/ - once again having too much information is
>>  >>  >>  not a crime. This is a service to uesrs so they know where the libraries
>>  >>  >>  came from.
>>  >>  >
>>  >>  > I agree the source is useful, but the place for this is the LICENSE file.
>>  >>  >
>>  >>  >>> -1: RAT report says:
>>  >>  >>  >
>>  >>  >>  > 99 Unknown Licenses
>>  >>  >>  >
>>  >>  >>  > Some of these are trivial, but most require an AL header.
>>  >>  >>  >
>>  >>  >>
>>  >>  >> Not true - there is not consensus that properties/xml files need to have
>>  >>  >>  headers. All the Java source code files have headers. If there are
>>  >>  >>  specific files that you feel should have a license that don't please
>>  >>  >>  list them and explain why. I'm not saying that we didn't miss something,
>>  >>  >>  but I am saying that the ones that I know about don't necessarily
>>  >>  >>  require a header.
>>  >>  >
>>  >>  > Yes, they do, see:
>>  >>  >
>>  >>  > http://www.apache.org/legal/src-headers.html#faq-exceptions
>>  >>  >
>>  >>  >>> What is the SVN tag that corresponds with the archives?
>>  >>  >>  >
>>  >>  >>  >
>>  >>  >>
>>  >>  >> the branch will be tagged once its released.
>>  >>  >>
>>  >>  >>  Dan
>>  >>  >>
>>  >>  >>
>>  >>  >>  --
>>  >>  >>  Dan Diephouse
>>  >>  >>  MuleSource
>>  >>  >>  http://mulesource.com | http://netzooid.com
>>  >>  >>
>>  >>  >>
>>  >>  >>
>>  >>  >>  ---------------------------------------------------------------------
>>  >>  >>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>  >>  >>  For additional commands, e-mail: general-help@incubator.apache.org
>>  >>  >>
>>  >>  >>
>>  >>  >
>>  >>  > ---------------------------------------------------------------------
>>  >>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>  >>  > For additional commands, e-mail: general-help@incubator.apache.org
>>  >>  >
>>  >>  >
>>  >>
>>  >>  ---------------------------------------------------------------------
>>  >>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>  >>  For additional commands, e-mail: general-help@incubator.apache.org
>>  >>
>>  >>
>>  >
>>  > ---------------------------------------------------------------------
>>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>  > For additional commands, e-mail: general-help@incubator.apache.org
>>  >
>>  >
>>
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>  For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by sebb <se...@gmail.com>.
The following do not seem to be test files, nor are they trivially short.
So they should have AL headers please:

core/src/main/resources/abdera.properties.example
dependencies/deps.properties

The top level NOTICE file should not have the 4 line == header.
Also, SVN includes the file
dependencies/i18n/src/main/java/org/apache/abdera/i18n/text/data/CompositionExclusions.txt
which is not AL licensed; IMO it should be attributed in the NOTICE file.

Probably something needs to go in the LICENSE file as well



On 01/04/2008, James M Snell <ja...@gmail.com> wrote:
> I've added license headers to the build scripts and to the localization
>  file and log4j.properties file. The rest I intend to leave as is.  Is
>  that sufficient?  If so, we'll roll a new build.
>
>
>  - James
>
>  sebb wrote:
>  > On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
>  >> In the FAQ I see this: "A file without any degree of creativity in
>  >>  either its literal elements or its structure is not protected by
>  >>  copyright law; therefore, such a file does not require a license header.
>  >
>  > Yes, but:
>  >
>  >>   If in doubt about the extent of the file's creativity, add the license
>  >>  header to the file."
>  >
>  >>  Here's the breakdown that I see from Rat:
>  >>
>  >>  None of the build scripts contain license headers.  Given that the build
>  >>  scripts are everyday, normal maven build scripts, I do believe they
>  >>  qualify under the "a file without any degree of creativity" clause.
>  >
>  > I disagree.
>  >
>  > Note that all Commons poms include the AL header.
>  >
>  >>   ? adapters/pom.xml
>  >>   ? client/pom.xml
>  >>   ? core/pom.xml
>  >>   ? examples/pom.xml
>  >>   ? extensions/pom.xml
>  >>   ? extensions/gdata/pom.xml
>  >>   ? extensions/geo/pom.xml
>  >>   ? extensions/html/pom.xml
>  >>   ? extensions/json/pom.xml
>  >>   ? extensions/main/pom.xml
>  >>   ? extensions/media/pom.xml
>  >>   ? extensions/oauth/pom.xml
>  >>   ? extensions/opensearch/pom.xml
>  >>   ? extensions/serializer/pom.xml
>  >>   ? extensions/sharing/pom.xml
>  >>   ? extensions/wsse/pom.xml
>  >>   ? parser/pom.xml
>  >>   ? security/pom.xml
>  >>   ? server/pom.xml
>  >>   ? spring/pom.xml
>  >>   ? dependencies/deps.properties
>  >>
>  >>  The following file used to provide localization strings may possibly
>  >>  require a license header.
>  >>
>  >>   ? core/src/main/resources/abderamessages.properties
>  >>
>  >>  The following are configuration files used at runtime, the majority of
>  >>  which consist of only a few lines of text and also fall under the above
>  >>  quoted clause.
>  >>
>  >>   ? client/src/main/java/log4j.properties
>  >>   ? core/src/main/resources/abdera.properties.example
>  >>   ?
>  >
>  > These have less content, so the creative aspect is definitely lower.
>  > However, I don't think there's no creativity involved.
>  >
>  >>  core/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory.example
>  >>   ?
>  >>  core/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>   ?
>  >>  core/src/test/resources/META-INF/services/org.apache.abdera.converter.ConverterProvider
>  >>   ?
>  >>  examples/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>   ?
>  >>  extensions/complete/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>  >>   ?
>  >>  extensions/complete/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>   ?
>  >>  extensions/complete/resources/META-INF/services/org.apache.abdera.parser.NamedParser
>  >>   ?
>  >>  extensions/html/src/main/resources/META-INF/services/org.apache.abdera.parser.NamedParser
>  >>   ?
>  >>  extensions/json/src/main/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>  >>  !?????
>  >>  extensions/main/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>   ?
>  >>  extensions/media/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>   ?
>  >>  extensions/opensearch/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>   ?
>  >>  extensions/sharing/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>   ?
>  >>  parser/src/main/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>  >>   ?
>  >>  contrib/rss/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>  >>
>  >
>  > Agreed.
>  >
>  >>  The following simple files are used for example purposes and do not
>  >>  contain any creative content whatsoever.
>  >>
>  >>   ? examples/src/main/resources/xmlcontent.xml
>  >>   ? examples/src/main/resources/log4j.properties
>  >>   ? examples/src/main/resources/simple.xml
>  >>   ? examples/src/main/resources/test.xslt
>  >>   ? examples/src/main/resources/content.xslt
>  >>   ? examples/src/main/resources/org/apache/abdera/examples/appserver/web.xml
>  >
>  > Not much creativity, and small files, so the AL header is not essential.
>  >
>  >>  The following were also (inappropriately) flagged by RAT
>  >>
>  >>   ? extensions/complete/resources/META-INF/LICENSE.htmlparser.txt
>  >>   ? extensions/complete/resources/META-INF/NOTICE.htmlparser.txt
>  >>   ? extensions/complete/resources/META-INF/NOTICE.serializer.txt
>  >>   ? extensions/json/src/main/resources/META-INF/LICENSE.htmlparser.txt
>  >>   ? extensions/json/src/main/resources/META-INF/NOTICE.htmlparser.txt
>  >>   ? extensions/json/src/main/resources/META-INF/NOTICE.serializer.txt
>  >>   ? dependencies/legal/servlet-api-LICENSE.txt
>  >>   ? dependencies/legal/htmlparser-LICENSE.txt
>  >>
>  >>
>  >>  The following resources are test resources that in addition to not
>  >>  containing any degree of creative content, they arguably should not
>  >>  contain license headers because the presence of the license header could
>  >>  potentially impact the results of the tests.
>  >>
>  >
>  > Probably.
>  > Though if the AL header affects the parsing, then there may well be a
>  > problem with the parsing...
>  >
>  >>   ? adapters/hibernate/src/test/resources/abdera/adapter/hibernate.cfg.xml
>  >>   ? adapters/hibernate/src/test/resources/abdera/adapter/DummyData.hbm.xml
>  >>   ? extensions/opensearch/src/test/resources/opensearch.xml
>  >>   ?
>  >>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace.xml
>  >>   ?
>  >>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace3.xml
>  >>   ?
>  >>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace2.xml
>  >>   ? parser/src/test/resources/www.snellspace.com/public/xmlbase.xml
>  >>   ? parser/src/test/resources/www.snellspace.com/public/ordertest.xml
>  >>   ? parser/src/test/resources/www.snellspace.com/public/linktests.xml
>  >>   ? parser/src/test/resources/www.snellspace.com/public/contentsummary.xml
>  >>   ? parser/src/test/resources/simpleFeed.xml
>  >>   ? parser/src/test/resources/xmlcontent.xml
>  >>   ? parser/src/test/resources/feed.xml
>  >>   ? parser/src/test/resources/simple.xml
>  >>   ?
>  >>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_content_base64_2.xml
>  >>   ?
>  >>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_content_base64.xml
>  >>   ?
>  >>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_author_email.xml
>  >>   ?
>  >>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_author_name.xml
>  >>   ?
>  >>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/atom10_namespace.xml
>  >>   ? parser/src/test/resources/complete.xml
>  >>   ? parser/src/test/resources/simpleService.xml
>  >>   ? parser/src/test/resources/simpleEntry.xml
>  >>   ? parser/src/test/resources/test.xslt
>  >>   ? parser/src/test/resources/entry.xml
>  >>   ? parser/src/test/resources/content.xslt
>  >>   ? spring/src/test/resources/org/apache/abdera/spring/beans.xml
>  >>   ? contrib/rss/src/test/resources/rss1.rdf
>  >>   ?
>  >>  adapters/hibernate/src/test/resources/abdera/adapter/hibernate.properties
>  >>   ? security/src/test/resources/log4j.properties
>  >>   ? server/src/test/resources/abdera/adapter/sample.properties
>  >>
>  >>  This one documentation file, which contains only a single one sentence
>  >>  statement, does not contain a license header.
>  >>
>  >>   ? docs/knownissues.txt
>  >>
>  >>  Which of these files do you think we absolutely have to add license
>  >>  headers to?
>  >>
>  >>
>  >>  - James
>  >>
>  >>
>  >>  sebb wrote:
>  >>  > On 31/03/2008, Dan Diephouse <da...@mulesource.com> wrote:
>  >>  >> sebb wrote:
>  >>  >>  > On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
>  >>  >>  >
>  >>  >>  >>
>  >>  >>  >
>  >>  >>
>  >>  >>> -1: There are MD5 and SHA1 digests in the directory, but the archives
>  >>  >>  > have no signatures.
>  >>  >>  >
>  >>  >>  >
>  >>  >>
>  >>  >> OK, I will fix this.
>  >>  >>
>  >>  >>>>  Maven Repository: http://people.apache.org/~dandiep/abdera-take6/
>  >>  >>  >>
>  >>  >>  >>
>  >>  >>  >
>  >>  >>  > -0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
>  >>  >>  > have any content - only the META-INF directory is present. Is that
>  >>  >>  > correct?
>  >>  >>  >
>  >>  >>
>  >>  >> This is just a by-product of Maven. We can delete it.
>  >>  >>
>  >>  >>> -1: The NOTICE files in that jar (and others) contains far too much.
>  >>  >>  > The NOTICE file is for required attribtions ONLY (e.g. as per an About box)
>  >>  >>  > There's really no need to repeat ASF for each project used by Abdera.
>  >>  >>  >
>  >>  >>
>  >>  >> Having too much information in the NOTICE files is not a crime. The
>  >>  >>  Maven remote-resources plugin aggregates all this stuff for us so we
>  >>  >>  never miss any notice that we need to put in.
>  >>  >
>  >>  > Unfortunately the plugin generates incorrect information.
>  >>  > It *is* a problem having all the redundant information.
>  >>  >
>  >>  > See for example:
>  >>  >
>  >>  > http://www.apache.org/legal/src-headers.html
>  >>  > also
>  >>  > http://wiki.apache.org/legal/3party/notice
>  >>  > http://wiki.apache.org/legal/3party/notice/discuss
>  >>  >
>  >>  >>> -1: The LICENSE files need to either contain copies of the 3rd party
>  >>  >>  > licenses, or they need to have a reference to the 3rd party licences.
>  >>  >>  > Equally, there is no need for the lib directory to contain copies of
>  >>  >>  > the AL for every ASF product.
>  >>  >>  >
>  >>  >>
>  >>  >> Why does the LICENSE file need to have a copy of all the other licenses?
>  >>  >>  These are contained in the lib/ directory like many other ASF projects.
>  >>  >>
>  >>  >
>  >>  > See the last paragraph of:
>  >>  >
>  >>  > http://www.apache.org/dev/apply-license.html#new
>  >>  >
>  >>  >>  Re: the ASL license in lib/ - once again having too much information is
>  >>  >>  not a crime. This is a service to uesrs so they know where the libraries
>  >>  >>  came from.
>  >>  >
>  >>  > I agree the source is useful, but the place for this is the LICENSE file.
>  >>  >
>  >>  >>> -1: RAT report says:
>  >>  >>  >
>  >>  >>  > 99 Unknown Licenses
>  >>  >>  >
>  >>  >>  > Some of these are trivial, but most require an AL header.
>  >>  >>  >
>  >>  >>
>  >>  >> Not true - there is not consensus that properties/xml files need to have
>  >>  >>  headers. All the Java source code files have headers. If there are
>  >>  >>  specific files that you feel should have a license that don't please
>  >>  >>  list them and explain why. I'm not saying that we didn't miss something,
>  >>  >>  but I am saying that the ones that I know about don't necessarily
>  >>  >>  require a header.
>  >>  >
>  >>  > Yes, they do, see:
>  >>  >
>  >>  > http://www.apache.org/legal/src-headers.html#faq-exceptions
>  >>  >
>  >>  >>> What is the SVN tag that corresponds with the archives?
>  >>  >>  >
>  >>  >>  >
>  >>  >>
>  >>  >> the branch will be tagged once its released.
>  >>  >>
>  >>  >>  Dan
>  >>  >>
>  >>  >>
>  >>  >>  --
>  >>  >>  Dan Diephouse
>  >>  >>  MuleSource
>  >>  >>  http://mulesource.com | http://netzooid.com
>  >>  >>
>  >>  >>
>  >>  >>
>  >>  >>  ---------------------------------------------------------------------
>  >>  >>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  >>  >>  For additional commands, e-mail: general-help@incubator.apache.org
>  >>  >>
>  >>  >>
>  >>  >
>  >>  > ---------------------------------------------------------------------
>  >>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  >>  > For additional commands, e-mail: general-help@incubator.apache.org
>  >>  >
>  >>  >
>  >>
>  >>  ---------------------------------------------------------------------
>  >>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  >>  For additional commands, e-mail: general-help@incubator.apache.org
>  >>
>  >>
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  > For additional commands, e-mail: general-help@incubator.apache.org
>  >
>  >
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by James M Snell <ja...@gmail.com>.
I've added license headers to the build scripts and to the localization 
file and log4j.properties file. The rest I intend to leave as is.  Is 
that sufficient?  If so, we'll roll a new build.

- James

sebb wrote:
> On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
>> In the FAQ I see this: "A file without any degree of creativity in
>>  either its literal elements or its structure is not protected by
>>  copyright law; therefore, such a file does not require a license header.
> 
> Yes, but:
> 
>>   If in doubt about the extent of the file's creativity, add the license
>>  header to the file."
> 
>>  Here's the breakdown that I see from Rat:
>>
>>  None of the build scripts contain license headers.  Given that the build
>>  scripts are everyday, normal maven build scripts, I do believe they
>>  qualify under the "a file without any degree of creativity" clause.
> 
> I disagree.
> 
> Note that all Commons poms include the AL header.
> 
>>   ? adapters/pom.xml
>>   ? client/pom.xml
>>   ? core/pom.xml
>>   ? examples/pom.xml
>>   ? extensions/pom.xml
>>   ? extensions/gdata/pom.xml
>>   ? extensions/geo/pom.xml
>>   ? extensions/html/pom.xml
>>   ? extensions/json/pom.xml
>>   ? extensions/main/pom.xml
>>   ? extensions/media/pom.xml
>>   ? extensions/oauth/pom.xml
>>   ? extensions/opensearch/pom.xml
>>   ? extensions/serializer/pom.xml
>>   ? extensions/sharing/pom.xml
>>   ? extensions/wsse/pom.xml
>>   ? parser/pom.xml
>>   ? security/pom.xml
>>   ? server/pom.xml
>>   ? spring/pom.xml
>>   ? dependencies/deps.properties
>>
>>  The following file used to provide localization strings may possibly
>>  require a license header.
>>
>>   ? core/src/main/resources/abderamessages.properties
>>
>>  The following are configuration files used at runtime, the majority of
>>  which consist of only a few lines of text and also fall under the above
>>  quoted clause.
>>
>>   ? client/src/main/java/log4j.properties
>>   ? core/src/main/resources/abdera.properties.example
>>   ?
> 
> These have less content, so the creative aspect is definitely lower.
> However, I don't think there's no creativity involved.
> 
>>  core/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory.example
>>   ?
>>  core/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>>   ?
>>  core/src/test/resources/META-INF/services/org.apache.abdera.converter.ConverterProvider
>>   ?
>>  examples/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>>   ?
>>  extensions/complete/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>>   ?
>>  extensions/complete/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>>   ?
>>  extensions/complete/resources/META-INF/services/org.apache.abdera.parser.NamedParser
>>   ?
>>  extensions/html/src/main/resources/META-INF/services/org.apache.abdera.parser.NamedParser
>>   ?
>>  extensions/json/src/main/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>>  !?????
>>  extensions/main/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>>   ?
>>  extensions/media/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>>   ?
>>  extensions/opensearch/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>>   ?
>>  extensions/sharing/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>>   ?
>>  parser/src/main/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>>   ?
>>  contrib/rss/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>>
> 
> Agreed.
> 
>>  The following simple files are used for example purposes and do not
>>  contain any creative content whatsoever.
>>
>>   ? examples/src/main/resources/xmlcontent.xml
>>   ? examples/src/main/resources/log4j.properties
>>   ? examples/src/main/resources/simple.xml
>>   ? examples/src/main/resources/test.xslt
>>   ? examples/src/main/resources/content.xslt
>>   ? examples/src/main/resources/org/apache/abdera/examples/appserver/web.xml
> 
> Not much creativity, and small files, so the AL header is not essential.
> 
>>  The following were also (inappropriately) flagged by RAT
>>
>>   ? extensions/complete/resources/META-INF/LICENSE.htmlparser.txt
>>   ? extensions/complete/resources/META-INF/NOTICE.htmlparser.txt
>>   ? extensions/complete/resources/META-INF/NOTICE.serializer.txt
>>   ? extensions/json/src/main/resources/META-INF/LICENSE.htmlparser.txt
>>   ? extensions/json/src/main/resources/META-INF/NOTICE.htmlparser.txt
>>   ? extensions/json/src/main/resources/META-INF/NOTICE.serializer.txt
>>   ? dependencies/legal/servlet-api-LICENSE.txt
>>   ? dependencies/legal/htmlparser-LICENSE.txt
>>
>>
>>  The following resources are test resources that in addition to not
>>  containing any degree of creative content, they arguably should not
>>  contain license headers because the presence of the license header could
>>  potentially impact the results of the tests.
>>
> 
> Probably.
> Though if the AL header affects the parsing, then there may well be a
> problem with the parsing...
> 
>>   ? adapters/hibernate/src/test/resources/abdera/adapter/hibernate.cfg.xml
>>   ? adapters/hibernate/src/test/resources/abdera/adapter/DummyData.hbm.xml
>>   ? extensions/opensearch/src/test/resources/opensearch.xml
>>   ?
>>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace.xml
>>   ?
>>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace3.xml
>>   ?
>>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace2.xml
>>   ? parser/src/test/resources/www.snellspace.com/public/xmlbase.xml
>>   ? parser/src/test/resources/www.snellspace.com/public/ordertest.xml
>>   ? parser/src/test/resources/www.snellspace.com/public/linktests.xml
>>   ? parser/src/test/resources/www.snellspace.com/public/contentsummary.xml
>>   ? parser/src/test/resources/simpleFeed.xml
>>   ? parser/src/test/resources/xmlcontent.xml
>>   ? parser/src/test/resources/feed.xml
>>   ? parser/src/test/resources/simple.xml
>>   ?
>>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_content_base64_2.xml
>>   ?
>>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_content_base64.xml
>>   ?
>>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_author_email.xml
>>   ?
>>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_author_name.xml
>>   ?
>>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/atom10_namespace.xml
>>   ? parser/src/test/resources/complete.xml
>>   ? parser/src/test/resources/simpleService.xml
>>   ? parser/src/test/resources/simpleEntry.xml
>>   ? parser/src/test/resources/test.xslt
>>   ? parser/src/test/resources/entry.xml
>>   ? parser/src/test/resources/content.xslt
>>   ? spring/src/test/resources/org/apache/abdera/spring/beans.xml
>>   ? contrib/rss/src/test/resources/rss1.rdf
>>   ?
>>  adapters/hibernate/src/test/resources/abdera/adapter/hibernate.properties
>>   ? security/src/test/resources/log4j.properties
>>   ? server/src/test/resources/abdera/adapter/sample.properties
>>
>>  This one documentation file, which contains only a single one sentence
>>  statement, does not contain a license header.
>>
>>   ? docs/knownissues.txt
>>
>>  Which of these files do you think we absolutely have to add license
>>  headers to?
>>
>>
>>  - James
>>
>>
>>  sebb wrote:
>>  > On 31/03/2008, Dan Diephouse <da...@mulesource.com> wrote:
>>  >> sebb wrote:
>>  >>  > On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
>>  >>  >
>>  >>  >>
>>  >>  >
>>  >>
>>  >>> -1: There are MD5 and SHA1 digests in the directory, but the archives
>>  >>  > have no signatures.
>>  >>  >
>>  >>  >
>>  >>
>>  >> OK, I will fix this.
>>  >>
>>  >>>>  Maven Repository: http://people.apache.org/~dandiep/abdera-take6/
>>  >>  >>
>>  >>  >>
>>  >>  >
>>  >>  > -0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
>>  >>  > have any content - only the META-INF directory is present. Is that
>>  >>  > correct?
>>  >>  >
>>  >>
>>  >> This is just a by-product of Maven. We can delete it.
>>  >>
>>  >>> -1: The NOTICE files in that jar (and others) contains far too much.
>>  >>  > The NOTICE file is for required attribtions ONLY (e.g. as per an About box)
>>  >>  > There's really no need to repeat ASF for each project used by Abdera.
>>  >>  >
>>  >>
>>  >> Having too much information in the NOTICE files is not a crime. The
>>  >>  Maven remote-resources plugin aggregates all this stuff for us so we
>>  >>  never miss any notice that we need to put in.
>>  >
>>  > Unfortunately the plugin generates incorrect information.
>>  > It *is* a problem having all the redundant information.
>>  >
>>  > See for example:
>>  >
>>  > http://www.apache.org/legal/src-headers.html
>>  > also
>>  > http://wiki.apache.org/legal/3party/notice
>>  > http://wiki.apache.org/legal/3party/notice/discuss
>>  >
>>  >>> -1: The LICENSE files need to either contain copies of the 3rd party
>>  >>  > licenses, or they need to have a reference to the 3rd party licences.
>>  >>  > Equally, there is no need for the lib directory to contain copies of
>>  >>  > the AL for every ASF product.
>>  >>  >
>>  >>
>>  >> Why does the LICENSE file need to have a copy of all the other licenses?
>>  >>  These are contained in the lib/ directory like many other ASF projects.
>>  >>
>>  >
>>  > See the last paragraph of:
>>  >
>>  > http://www.apache.org/dev/apply-license.html#new
>>  >
>>  >>  Re: the ASL license in lib/ - once again having too much information is
>>  >>  not a crime. This is a service to uesrs so they know where the libraries
>>  >>  came from.
>>  >
>>  > I agree the source is useful, but the place for this is the LICENSE file.
>>  >
>>  >>> -1: RAT report says:
>>  >>  >
>>  >>  > 99 Unknown Licenses
>>  >>  >
>>  >>  > Some of these are trivial, but most require an AL header.
>>  >>  >
>>  >>
>>  >> Not true - there is not consensus that properties/xml files need to have
>>  >>  headers. All the Java source code files have headers. If there are
>>  >>  specific files that you feel should have a license that don't please
>>  >>  list them and explain why. I'm not saying that we didn't miss something,
>>  >>  but I am saying that the ones that I know about don't necessarily
>>  >>  require a header.
>>  >
>>  > Yes, they do, see:
>>  >
>>  > http://www.apache.org/legal/src-headers.html#faq-exceptions
>>  >
>>  >>> What is the SVN tag that corresponds with the archives?
>>  >>  >
>>  >>  >
>>  >>
>>  >> the branch will be tagged once its released.
>>  >>
>>  >>  Dan
>>  >>
>>  >>
>>  >>  --
>>  >>  Dan Diephouse
>>  >>  MuleSource
>>  >>  http://mulesource.com | http://netzooid.com
>>  >>
>>  >>
>>  >>
>>  >>  ---------------------------------------------------------------------
>>  >>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>  >>  For additional commands, e-mail: general-help@incubator.apache.org
>>  >>
>>  >>
>>  >
>>  > ---------------------------------------------------------------------
>>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>  > For additional commands, e-mail: general-help@incubator.apache.org
>>  >
>>  >
>>
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>  For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by sebb <se...@gmail.com>.
On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
> In the FAQ I see this: "A file without any degree of creativity in
>  either its literal elements or its structure is not protected by
>  copyright law; therefore, such a file does not require a license header.

Yes, but:

>   If in doubt about the extent of the file's creativity, add the license
>  header to the file."

>  Here's the breakdown that I see from Rat:
>
>  None of the build scripts contain license headers.  Given that the build
>  scripts are everyday, normal maven build scripts, I do believe they
>  qualify under the "a file without any degree of creativity" clause.

I disagree.

Note that all Commons poms include the AL header.

>   ? adapters/pom.xml
>   ? client/pom.xml
>   ? core/pom.xml
>   ? examples/pom.xml
>   ? extensions/pom.xml
>   ? extensions/gdata/pom.xml
>   ? extensions/geo/pom.xml
>   ? extensions/html/pom.xml
>   ? extensions/json/pom.xml
>   ? extensions/main/pom.xml
>   ? extensions/media/pom.xml
>   ? extensions/oauth/pom.xml
>   ? extensions/opensearch/pom.xml
>   ? extensions/serializer/pom.xml
>   ? extensions/sharing/pom.xml
>   ? extensions/wsse/pom.xml
>   ? parser/pom.xml
>   ? security/pom.xml
>   ? server/pom.xml
>   ? spring/pom.xml
>   ? dependencies/deps.properties
>
>  The following file used to provide localization strings may possibly
>  require a license header.
>
>   ? core/src/main/resources/abderamessages.properties
>
>  The following are configuration files used at runtime, the majority of
>  which consist of only a few lines of text and also fall under the above
>  quoted clause.
>
>   ? client/src/main/java/log4j.properties
>   ? core/src/main/resources/abdera.properties.example
>   ?

These have less content, so the creative aspect is definitely lower.
However, I don't think there's no creativity involved.

>  core/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory.example
>   ?
>  core/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>   ?
>  core/src/test/resources/META-INF/services/org.apache.abdera.converter.ConverterProvider
>   ?
>  examples/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>   ?
>  extensions/complete/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>   ?
>  extensions/complete/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>   ?
>  extensions/complete/resources/META-INF/services/org.apache.abdera.parser.NamedParser
>   ?
>  extensions/html/src/main/resources/META-INF/services/org.apache.abdera.parser.NamedParser
>   ?
>  extensions/json/src/main/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>  !?????
>  extensions/main/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>   ?
>  extensions/media/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>   ?
>  extensions/opensearch/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>   ?
>  extensions/sharing/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>   ?
>  parser/src/main/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>   ?
>  contrib/rss/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>

Agreed.

>
>  The following simple files are used for example purposes and do not
>  contain any creative content whatsoever.
>
>   ? examples/src/main/resources/xmlcontent.xml
>   ? examples/src/main/resources/log4j.properties
>   ? examples/src/main/resources/simple.xml
>   ? examples/src/main/resources/test.xslt
>   ? examples/src/main/resources/content.xslt
>   ? examples/src/main/resources/org/apache/abdera/examples/appserver/web.xml

Not much creativity, and small files, so the AL header is not essential.

>  The following were also (inappropriately) flagged by RAT
>
>   ? extensions/complete/resources/META-INF/LICENSE.htmlparser.txt
>   ? extensions/complete/resources/META-INF/NOTICE.htmlparser.txt
>   ? extensions/complete/resources/META-INF/NOTICE.serializer.txt
>   ? extensions/json/src/main/resources/META-INF/LICENSE.htmlparser.txt
>   ? extensions/json/src/main/resources/META-INF/NOTICE.htmlparser.txt
>   ? extensions/json/src/main/resources/META-INF/NOTICE.serializer.txt
>   ? dependencies/legal/servlet-api-LICENSE.txt
>   ? dependencies/legal/htmlparser-LICENSE.txt
>
>
>  The following resources are test resources that in addition to not
>  containing any degree of creative content, they arguably should not
>  contain license headers because the presence of the license header could
>  potentially impact the results of the tests.
>

Probably.
Though if the AL header affects the parsing, then there may well be a
problem with the parsing...

>   ? adapters/hibernate/src/test/resources/abdera/adapter/hibernate.cfg.xml
>   ? adapters/hibernate/src/test/resources/abdera/adapter/DummyData.hbm.xml
>   ? extensions/opensearch/src/test/resources/opensearch.xml
>   ?
>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace.xml
>   ?
>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace3.xml
>   ?
>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace2.xml
>   ? parser/src/test/resources/www.snellspace.com/public/xmlbase.xml
>   ? parser/src/test/resources/www.snellspace.com/public/ordertest.xml
>   ? parser/src/test/resources/www.snellspace.com/public/linktests.xml
>   ? parser/src/test/resources/www.snellspace.com/public/contentsummary.xml
>   ? parser/src/test/resources/simpleFeed.xml
>   ? parser/src/test/resources/xmlcontent.xml
>   ? parser/src/test/resources/feed.xml
>   ? parser/src/test/resources/simple.xml
>   ?
>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_content_base64_2.xml
>   ?
>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_content_base64.xml
>   ?
>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_author_email.xml
>   ?
>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_author_name.xml
>   ?
>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/atom10_namespace.xml
>   ? parser/src/test/resources/complete.xml
>   ? parser/src/test/resources/simpleService.xml
>   ? parser/src/test/resources/simpleEntry.xml
>   ? parser/src/test/resources/test.xslt
>   ? parser/src/test/resources/entry.xml
>   ? parser/src/test/resources/content.xslt
>   ? spring/src/test/resources/org/apache/abdera/spring/beans.xml
>   ? contrib/rss/src/test/resources/rss1.rdf
>   ?
>  adapters/hibernate/src/test/resources/abdera/adapter/hibernate.properties
>   ? security/src/test/resources/log4j.properties
>   ? server/src/test/resources/abdera/adapter/sample.properties
>
>  This one documentation file, which contains only a single one sentence
>  statement, does not contain a license header.
>
>   ? docs/knownissues.txt
>
>  Which of these files do you think we absolutely have to add license
>  headers to?
>
>
>  - James
>
>
>  sebb wrote:
>  > On 31/03/2008, Dan Diephouse <da...@mulesource.com> wrote:
>  >> sebb wrote:
>  >>  > On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
>  >>  >
>  >>  >>
>  >>  >
>  >>
>  >>> -1: There are MD5 and SHA1 digests in the directory, but the archives
>  >>  > have no signatures.
>  >>  >
>  >>  >
>  >>
>  >> OK, I will fix this.
>  >>
>  >>>>  Maven Repository: http://people.apache.org/~dandiep/abdera-take6/
>  >>  >>
>  >>  >>
>  >>  >
>  >>  > -0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
>  >>  > have any content - only the META-INF directory is present. Is that
>  >>  > correct?
>  >>  >
>  >>
>  >> This is just a by-product of Maven. We can delete it.
>  >>
>  >>> -1: The NOTICE files in that jar (and others) contains far too much.
>  >>  > The NOTICE file is for required attribtions ONLY (e.g. as per an About box)
>  >>  > There's really no need to repeat ASF for each project used by Abdera.
>  >>  >
>  >>
>  >> Having too much information in the NOTICE files is not a crime. The
>  >>  Maven remote-resources plugin aggregates all this stuff for us so we
>  >>  never miss any notice that we need to put in.
>  >
>  > Unfortunately the plugin generates incorrect information.
>  > It *is* a problem having all the redundant information.
>  >
>  > See for example:
>  >
>  > http://www.apache.org/legal/src-headers.html
>  > also
>  > http://wiki.apache.org/legal/3party/notice
>  > http://wiki.apache.org/legal/3party/notice/discuss
>  >
>  >>> -1: The LICENSE files need to either contain copies of the 3rd party
>  >>  > licenses, or they need to have a reference to the 3rd party licences.
>  >>  > Equally, there is no need for the lib directory to contain copies of
>  >>  > the AL for every ASF product.
>  >>  >
>  >>
>  >> Why does the LICENSE file need to have a copy of all the other licenses?
>  >>  These are contained in the lib/ directory like many other ASF projects.
>  >>
>  >
>  > See the last paragraph of:
>  >
>  > http://www.apache.org/dev/apply-license.html#new
>  >
>  >>  Re: the ASL license in lib/ - once again having too much information is
>  >>  not a crime. This is a service to uesrs so they know where the libraries
>  >>  came from.
>  >
>  > I agree the source is useful, but the place for this is the LICENSE file.
>  >
>  >>> -1: RAT report says:
>  >>  >
>  >>  > 99 Unknown Licenses
>  >>  >
>  >>  > Some of these are trivial, but most require an AL header.
>  >>  >
>  >>
>  >> Not true - there is not consensus that properties/xml files need to have
>  >>  headers. All the Java source code files have headers. If there are
>  >>  specific files that you feel should have a license that don't please
>  >>  list them and explain why. I'm not saying that we didn't miss something,
>  >>  but I am saying that the ones that I know about don't necessarily
>  >>  require a header.
>  >
>  > Yes, they do, see:
>  >
>  > http://www.apache.org/legal/src-headers.html#faq-exceptions
>  >
>  >>> What is the SVN tag that corresponds with the archives?
>  >>  >
>  >>  >
>  >>
>  >> the branch will be tagged once its released.
>  >>
>  >>  Dan
>  >>
>  >>
>  >>  --
>  >>  Dan Diephouse
>  >>  MuleSource
>  >>  http://mulesource.com | http://netzooid.com
>  >>
>  >>
>  >>
>  >>  ---------------------------------------------------------------------
>  >>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  >>  For additional commands, e-mail: general-help@incubator.apache.org
>  >>
>  >>
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  > For additional commands, e-mail: general-help@incubator.apache.org
>  >
>  >
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Mon, Mar 31, 2008 at 5:52 PM, Luciano Resende <lu...@gmail.com> wrote:
> I'd probably error on the side of caution here, and add license
>  headers in all files, unless it breakes something. Most if not all
>  projects does add the license headers in maven pom files, property
>  files, etc. I'd suggest you to fix at least in trunk, but as you
>  mentioned you need to fix the the file below [1], I'd then recommend
>  fixing as much as possible from the list you have.
>
>  [1] core/src/main/resources/abderamessages.properties

For crying out loud, we've had this freaking argument every single
time abdera has released.  There is zero reason to add license headers
to two line properties files, test data that is explicitly testing
atom content as it exists in the real world (where it would NOT have
any license headers), or any number of other cases in that list.  If
you have specific examples of things you do think need licenses, cite
them.  Saying "everything that you can slap a license header on
without breaking something" is not helpful, see the archives of this
list for details.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by Luciano Resende <lu...@gmail.com>.
I'd probably error on the side of caution here, and add license
headers in all files, unless it breakes something. Most if not all
projects does add the license headers in maven pom files, property
files, etc. I'd suggest you to fix at least in trunk, but as you
mentioned you need to fix the the file below [1], I'd then recommend
fixing as much as possible from the list you have.

[1] core/src/main/resources/abderamessages.properties


On Mon, Mar 31, 2008 at 1:59 PM, James M Snell <ja...@gmail.com> wrote:
> In the FAQ I see this: "A file without any degree of creativity in
>  either its literal elements or its structure is not protected by
>  copyright law; therefore, such a file does not require a license header.
>   If in doubt about the extent of the file's creativity, add the license
>  header to the file."
>
>  Here's the breakdown that I see from Rat:
>
>  None of the build scripts contain license headers.  Given that the build
>  scripts are everyday, normal maven build scripts, I do believe they
>  qualify under the "a file without any degree of creativity" clause.
>
>   ? adapters/pom.xml
>   ? client/pom.xml
>   ? core/pom.xml
>   ? examples/pom.xml
>   ? extensions/pom.xml
>   ? extensions/gdata/pom.xml
>   ? extensions/geo/pom.xml
>   ? extensions/html/pom.xml
>   ? extensions/json/pom.xml
>   ? extensions/main/pom.xml
>   ? extensions/media/pom.xml
>   ? extensions/oauth/pom.xml
>   ? extensions/opensearch/pom.xml
>   ? extensions/serializer/pom.xml
>   ? extensions/sharing/pom.xml
>   ? extensions/wsse/pom.xml
>   ? parser/pom.xml
>   ? security/pom.xml
>   ? server/pom.xml
>   ? spring/pom.xml
>   ? dependencies/deps.properties
>
>  The following file used to provide localization strings may possibly
>  require a license header.
>
>   ? core/src/main/resources/abderamessages.properties
>
>  The following are configuration files used at runtime, the majority of
>  which consist of only a few lines of text and also fall under the above
>  quoted clause.
>
>   ? client/src/main/java/log4j.properties
>   ? core/src/main/resources/abdera.properties.example
>   ?
>  core/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory.example
>   ?
>  core/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>   ?
>  core/src/test/resources/META-INF/services/org.apache.abdera.converter.ConverterProvider
>   ?
>  examples/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>   ?
>  extensions/complete/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>   ?
>  extensions/complete/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>   ?
>  extensions/complete/resources/META-INF/services/org.apache.abdera.parser.NamedParser
>   ?
>  extensions/html/src/main/resources/META-INF/services/org.apache.abdera.parser.NamedParser
>   ?
>  extensions/json/src/main/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>  !?????
>  extensions/main/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>   ?
>  extensions/media/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>   ?
>  extensions/opensearch/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>   ?
>  extensions/sharing/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>   ?
>  parser/src/main/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
>   ?
>  contrib/rss/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
>
>
>
>  The following simple files are used for example purposes and do not
>  contain any creative content whatsoever.
>
>   ? examples/src/main/resources/xmlcontent.xml
>   ? examples/src/main/resources/log4j.properties
>   ? examples/src/main/resources/simple.xml
>   ? examples/src/main/resources/test.xslt
>   ? examples/src/main/resources/content.xslt
>   ? examples/src/main/resources/org/apache/abdera/examples/appserver/web.xml
>
>  The following were also (inappropriately) flagged by RAT
>
>   ? extensions/complete/resources/META-INF/LICENSE.htmlparser.txt
>   ? extensions/complete/resources/META-INF/NOTICE.htmlparser.txt
>   ? extensions/complete/resources/META-INF/NOTICE.serializer.txt
>   ? extensions/json/src/main/resources/META-INF/LICENSE.htmlparser.txt
>   ? extensions/json/src/main/resources/META-INF/NOTICE.htmlparser.txt
>   ? extensions/json/src/main/resources/META-INF/NOTICE.serializer.txt
>   ? dependencies/legal/servlet-api-LICENSE.txt
>   ? dependencies/legal/htmlparser-LICENSE.txt
>
>
>  The following resources are test resources that in addition to not
>  containing any degree of creative content, they arguably should not
>  contain license headers because the presence of the license header could
>  potentially impact the results of the tests.
>
>   ? adapters/hibernate/src/test/resources/abdera/adapter/hibernate.cfg.xml
>   ? adapters/hibernate/src/test/resources/abdera/adapter/DummyData.hbm.xml
>   ? extensions/opensearch/src/test/resources/opensearch.xml
>   ?
>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace.xml
>   ?
>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace3.xml
>   ?
>  parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace2.xml
>   ? parser/src/test/resources/www.snellspace.com/public/xmlbase.xml
>   ? parser/src/test/resources/www.snellspace.com/public/ordertest.xml
>   ? parser/src/test/resources/www.snellspace.com/public/linktests.xml
>   ? parser/src/test/resources/www.snellspace.com/public/contentsummary.xml
>   ? parser/src/test/resources/simpleFeed.xml
>   ? parser/src/test/resources/xmlcontent.xml
>   ? parser/src/test/resources/feed.xml
>   ? parser/src/test/resources/simple.xml
>   ?
>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_content_base64_2.xml
>   ?
>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_content_base64.xml
>   ?
>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_author_email.xml
>   ?
>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_author_name.xml
>   ?
>  parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/atom10_namespace.xml
>   ? parser/src/test/resources/complete.xml
>   ? parser/src/test/resources/simpleService.xml
>   ? parser/src/test/resources/simpleEntry.xml
>   ? parser/src/test/resources/test.xslt
>   ? parser/src/test/resources/entry.xml
>   ? parser/src/test/resources/content.xslt
>   ? spring/src/test/resources/org/apache/abdera/spring/beans.xml
>   ? contrib/rss/src/test/resources/rss1.rdf
>   ?
>  adapters/hibernate/src/test/resources/abdera/adapter/hibernate.properties
>   ? security/src/test/resources/log4j.properties
>   ? server/src/test/resources/abdera/adapter/sample.properties
>
>  This one documentation file, which contains only a single one sentence
>  statement, does not contain a license header.
>
>   ? docs/knownissues.txt
>
>  Which of these files do you think we absolutely have to add license
>  headers to?
>
>  - James
>
>
>
>  sebb wrote:
>  > On 31/03/2008, Dan Diephouse <da...@mulesource.com> wrote:
>  >> sebb wrote:
>  >>  > On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
>  >>  >
>  >>  >>
>  >>  >
>  >>
>  >>> -1: There are MD5 and SHA1 digests in the directory, but the archives
>  >>  > have no signatures.
>  >>  >
>  >>  >
>  >>
>  >> OK, I will fix this.
>  >>
>  >>>>  Maven Repository: http://people.apache.org/~dandiep/abdera-take6/
>  >>  >>
>  >>  >>
>  >>  >
>  >>  > -0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
>  >>  > have any content - only the META-INF directory is present. Is that
>  >>  > correct?
>  >>  >
>  >>
>  >> This is just a by-product of Maven. We can delete it.
>  >>
>  >>> -1: The NOTICE files in that jar (and others) contains far too much.
>  >>  > The NOTICE file is for required attribtions ONLY (e.g. as per an About box)
>  >>  > There's really no need to repeat ASF for each project used by Abdera.
>  >>  >
>  >>
>  >> Having too much information in the NOTICE files is not a crime. The
>  >>  Maven remote-resources plugin aggregates all this stuff for us so we
>  >>  never miss any notice that we need to put in.
>  >
>  > Unfortunately the plugin generates incorrect information.
>  > It *is* a problem having all the redundant information.
>  >
>  > See for example:
>  >
>  > http://www.apache.org/legal/src-headers.html
>  > also
>  > http://wiki.apache.org/legal/3party/notice
>  > http://wiki.apache.org/legal/3party/notice/discuss
>  >
>  >>> -1: The LICENSE files need to either contain copies of the 3rd party
>  >>  > licenses, or they need to have a reference to the 3rd party licences.
>  >>  > Equally, there is no need for the lib directory to contain copies of
>  >>  > the AL for every ASF product.
>  >>  >
>  >>
>  >> Why does the LICENSE file need to have a copy of all the other licenses?
>  >>  These are contained in the lib/ directory like many other ASF projects.
>  >>
>  >
>  > See the last paragraph of:
>  >
>  > http://www.apache.org/dev/apply-license.html#new
>  >
>  >>  Re: the ASL license in lib/ - once again having too much information is
>  >>  not a crime. This is a service to uesrs so they know where the libraries
>  >>  came from.
>  >
>  > I agree the source is useful, but the place for this is the LICENSE file.
>  >
>  >>> -1: RAT report says:
>  >>  >
>  >>  > 99 Unknown Licenses
>  >>  >
>  >>  > Some of these are trivial, but most require an AL header.
>  >>  >
>  >>
>  >> Not true - there is not consensus that properties/xml files need to have
>  >>  headers. All the Java source code files have headers. If there are
>  >>  specific files that you feel should have a license that don't please
>  >>  list them and explain why. I'm not saying that we didn't miss something,
>  >>  but I am saying that the ones that I know about don't necessarily
>  >>  require a header.
>  >
>  > Yes, they do, see:
>  >
>  > http://www.apache.org/legal/src-headers.html#faq-exceptions
>  >
>  >>> What is the SVN tag that corresponds with the archives?
>  >>  >
>  >>  >
>  >>
>  >> the branch will be tagged once its released.
>  >>
>  >>  Dan
>  >>
>  >>
>  >>  --
>  >>  Dan Diephouse
>  >>  MuleSource
>  >>  http://mulesource.com | http://netzooid.com
>  >>
>  >>
>  >>
>  >>  ---------------------------------------------------------------------
>  >>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  >>  For additional commands, e-mail: general-help@incubator.apache.org
>  >>
>  >>
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  > For additional commands, e-mail: general-help@incubator.apache.org
>  >
>  >
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  For additional commands, e-mail: general-help@incubator.apache.org
>
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by James M Snell <ja...@gmail.com>.
In the FAQ I see this: "A file without any degree of creativity in 
either its literal elements or its structure is not protected by 
copyright law; therefore, such a file does not require a license header. 
  If in doubt about the extent of the file's creativity, add the license 
header to the file."

Here's the breakdown that I see from Rat:

None of the build scripts contain license headers.  Given that the build 
scripts are everyday, normal maven build scripts, I do believe they 
qualify under the "a file without any degree of creativity" clause.

  ? adapters/pom.xml
  ? client/pom.xml
  ? core/pom.xml
  ? examples/pom.xml
  ? extensions/pom.xml
  ? extensions/gdata/pom.xml
  ? extensions/geo/pom.xml
  ? extensions/html/pom.xml
  ? extensions/json/pom.xml
  ? extensions/main/pom.xml
  ? extensions/media/pom.xml
  ? extensions/oauth/pom.xml
  ? extensions/opensearch/pom.xml
  ? extensions/serializer/pom.xml
  ? extensions/sharing/pom.xml
  ? extensions/wsse/pom.xml
  ? parser/pom.xml
  ? security/pom.xml
  ? server/pom.xml
  ? spring/pom.xml
  ? dependencies/deps.properties

The following file used to provide localization strings may possibly 
require a license header.

  ? core/src/main/resources/abderamessages.properties

The following are configuration files used at runtime, the majority of 
which consist of only a few lines of text and also fall under the above 
quoted clause.

  ? client/src/main/java/log4j.properties
  ? core/src/main/resources/abdera.properties.example
  ? 
core/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory.example
  ? 
core/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
  ? 
core/src/test/resources/META-INF/services/org.apache.abdera.converter.ConverterProvider
  ? 
examples/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
  ? 
extensions/complete/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
  ? 
extensions/complete/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
  ? 
extensions/complete/resources/META-INF/services/org.apache.abdera.parser.NamedParser
  ? 
extensions/html/src/main/resources/META-INF/services/org.apache.abdera.parser.NamedParser
  ? 
extensions/json/src/main/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
!????? 
extensions/main/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
  ? 
extensions/media/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
  ? 
extensions/opensearch/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
  ? 
extensions/sharing/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory
  ? 
parser/src/main/resources/META-INF/services/org.apache.abdera.writer.NamedWriter
  ? 
contrib/rss/src/main/resources/META-INF/services/org.apache.abdera.factory.ExtensionFactory 



The following simple files are used for example purposes and do not 
contain any creative content whatsoever.

  ? examples/src/main/resources/xmlcontent.xml
  ? examples/src/main/resources/log4j.properties
  ? examples/src/main/resources/simple.xml
  ? examples/src/main/resources/test.xslt
  ? examples/src/main/resources/content.xslt
  ? examples/src/main/resources/org/apache/abdera/examples/appserver/web.xml

The following were also (inappropriately) flagged by RAT

  ? extensions/complete/resources/META-INF/LICENSE.htmlparser.txt
  ? extensions/complete/resources/META-INF/NOTICE.htmlparser.txt
  ? extensions/complete/resources/META-INF/NOTICE.serializer.txt
  ? extensions/json/src/main/resources/META-INF/LICENSE.htmlparser.txt
  ? extensions/json/src/main/resources/META-INF/NOTICE.htmlparser.txt
  ? extensions/json/src/main/resources/META-INF/NOTICE.serializer.txt
  ? dependencies/legal/servlet-api-LICENSE.txt
  ? dependencies/legal/htmlparser-LICENSE.txt


The following resources are test resources that in addition to not 
containing any degree of creative content, they arguably should not 
contain license headers because the presence of the license header could 
potentially impact the results of the tests.

  ? adapters/hibernate/src/test/resources/abdera/adapter/hibernate.cfg.xml
  ? adapters/hibernate/src/test/resources/abdera/adapter/DummyData.hbm.xml
  ? extensions/opensearch/src/test/resources/opensearch.xml
  ? 
parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace.xml
  ? 
parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace3.xml
  ? 
parser/src/test/resources/www.snellspace.com/public/nondefaultnamespace2.xml
  ? parser/src/test/resources/www.snellspace.com/public/xmlbase.xml
  ? parser/src/test/resources/www.snellspace.com/public/ordertest.xml
  ? parser/src/test/resources/www.snellspace.com/public/linktests.xml
  ? parser/src/test/resources/www.snellspace.com/public/contentsummary.xml
  ? parser/src/test/resources/simpleFeed.xml
  ? parser/src/test/resources/xmlcontent.xml
  ? parser/src/test/resources/feed.xml
  ? parser/src/test/resources/simple.xml
  ? 
parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_content_base64_2.xml
  ? 
parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_content_base64.xml
  ? 
parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_author_email.xml
  ? 
parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/entry_author_name.xml
  ? 
parser/src/test/resources/www.feedparser.org/tests/wellformed/atom10/atom10_namespace.xml
  ? parser/src/test/resources/complete.xml
  ? parser/src/test/resources/simpleService.xml
  ? parser/src/test/resources/simpleEntry.xml
  ? parser/src/test/resources/test.xslt
  ? parser/src/test/resources/entry.xml
  ? parser/src/test/resources/content.xslt
  ? spring/src/test/resources/org/apache/abdera/spring/beans.xml
  ? contrib/rss/src/test/resources/rss1.rdf
  ? 
adapters/hibernate/src/test/resources/abdera/adapter/hibernate.properties
  ? security/src/test/resources/log4j.properties
  ? server/src/test/resources/abdera/adapter/sample.properties

This one documentation file, which contains only a single one sentence 
statement, does not contain a license header.

  ? docs/knownissues.txt

Which of these files do you think we absolutely have to add license 
headers to?

- James

sebb wrote:
> On 31/03/2008, Dan Diephouse <da...@mulesource.com> wrote:
>> sebb wrote:
>>  > On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
>>  >
>>  >>
>>  >
>>
>>> -1: There are MD5 and SHA1 digests in the directory, but the archives
>>  > have no signatures.
>>  >
>>  >
>>
>> OK, I will fix this.
>>
>>>>  Maven Repository: http://people.apache.org/~dandiep/abdera-take6/
>>  >>
>>  >>
>>  >
>>  > -0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
>>  > have any content - only the META-INF directory is present. Is that
>>  > correct?
>>  >
>>
>> This is just a by-product of Maven. We can delete it.
>>
>>> -1: The NOTICE files in that jar (and others) contains far too much.
>>  > The NOTICE file is for required attribtions ONLY (e.g. as per an About box)
>>  > There's really no need to repeat ASF for each project used by Abdera.
>>  >
>>
>> Having too much information in the NOTICE files is not a crime. The
>>  Maven remote-resources plugin aggregates all this stuff for us so we
>>  never miss any notice that we need to put in.
> 
> Unfortunately the plugin generates incorrect information.
> It *is* a problem having all the redundant information.
> 
> See for example:
> 
> http://www.apache.org/legal/src-headers.html
> also
> http://wiki.apache.org/legal/3party/notice
> http://wiki.apache.org/legal/3party/notice/discuss
> 
>>> -1: The LICENSE files need to either contain copies of the 3rd party
>>  > licenses, or they need to have a reference to the 3rd party licences.
>>  > Equally, there is no need for the lib directory to contain copies of
>>  > the AL for every ASF product.
>>  >
>>
>> Why does the LICENSE file need to have a copy of all the other licenses?
>>  These are contained in the lib/ directory like many other ASF projects.
>>
> 
> See the last paragraph of:
> 
> http://www.apache.org/dev/apply-license.html#new
> 
>>  Re: the ASL license in lib/ - once again having too much information is
>>  not a crime. This is a service to uesrs so they know where the libraries
>>  came from.
> 
> I agree the source is useful, but the place for this is the LICENSE file.
> 
>>> -1: RAT report says:
>>  >
>>  > 99 Unknown Licenses
>>  >
>>  > Some of these are trivial, but most require an AL header.
>>  >
>>
>> Not true - there is not consensus that properties/xml files need to have
>>  headers. All the Java source code files have headers. If there are
>>  specific files that you feel should have a license that don't please
>>  list them and explain why. I'm not saying that we didn't miss something,
>>  but I am saying that the ones that I know about don't necessarily
>>  require a header.
> 
> Yes, they do, see:
> 
> http://www.apache.org/legal/src-headers.html#faq-exceptions
> 
>>> What is the SVN tag that corresponds with the archives?
>>  >
>>  >
>>
>> the branch will be tagged once its released.
>>
>>  Dan
>>
>>
>>  --
>>  Dan Diephouse
>>  MuleSource
>>  http://mulesource.com | http://netzooid.com
>>
>>
>>
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>  For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Apr 2, 2008 at 6:25 PM, Dan Diephouse
<da...@mulesource.com> wrote:
> sebb wrote:
>
> > On 31/03/2008, Dan Diephouse <da...@mulesource.com> wrote:
> >
> >
> > >  >>> -1: The LICENSE files need to either contain copies of the 3rd
> party
> > >  >>>
> > >  >>  > licenses, or they need to have a reference to the 3rd party
> licences.
> > >  >>  > Equally, there is no need for the lib directory to contain copies
> of
> > >  >>  > the AL for every ASF product.
> > >  >>  >
> > >  >>
> > >  >> Why does the LICENSE file need to have a copy of all the other
> licenses?
> > >  >>  These are contained in the lib/ directory like many other ASF
> projects.
> > >  >>
> > >  >>
> > >  >
> > >  > See the last paragraph of:
> > >  >
> > >  > http://www.apache.org/dev/apply-license.html#new
> > >  >
> > >  >
> > >
> > > "or at least put a pointer in the LICENSE file to the third-party
> > >  license" - which we in the NOTICE file.
> > >
> > >
> > >
> >
> > But they need to go in the LICENSE file, see:
> >
> > http://www.apache.org/dev/apply-license.html#new

i'm a little worried by this document: looks a little old to me. for example:

<blockquote cite=http://www.apache.org/dev/apply-license.html#new''>
>Source files contributed to or developed as part of an ASF project
should begin with a copyright notice like
>
>   Copyright 2004 The Apache Software Foundation.
>or
>   Copyright 1999-2004 The Apache Software Foundation.
>or
>   Copyright 2002,2004 The Apache Software Foundation.
</blockquote>

this is wrong: apache cannot claim copyright on any particular file
but only to the collective work

AIUI modern legal information should be linked from http://www.apache.org/legal/

(this discussion probably needs to move to legal discuss)

<snip>

> > >  There is not a legal requirement here that it must be in the LICENSE
> > >  file itself - if so, please point me to the place in the license. This
> > >  is page is to provide "guidance" (see the first sentence), not be the
> > >  ultimate authority on what exactly is legally permissible for
> distributions.
> > >
> > >  If you look at many other ASF projects in the incubator and outside,
> > >  you'll see that this is not an enforced policy - this is simply telling
> > >  developers one way to get started here.

<snip>

>  I have never ever seen this enforced and I do not believe its a
> requirement. Just to summarize - do we need to 1) include all the licenses
> for all our dependencies in a single libary or can we 2) have our top
> LICENSE file which is ASL and then have individual LICENSE files for each
> library in the lib/ directory.
>
>  I think not allowing the second would be a HUGE mistake. It makes it much
> clearer which license applies to which file.

IMHO the best possible practice would be indicate all licenses in the
top level LICENSE file and to include .LICENSE files for every
artifact included that does not contain an embedded one. but it's
possible to argue about release best practice forever...

AIUI policy is that a license must be included for every third party
artifact and the principle is that users must be able to easily
discover the license under which apache is distributed it. this may be
achieved by including within the LICENSE file licenses and references
to the files they apply to or by using individual LICENSE files
provided that they are easy for users to understand.

<legal-hat>
if policy is not clear then please raise the issue on the
legal-discuss list (probably prefix with [POLICY] or something so that
it's harder to ignore)
</legal-hat>

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

Posted by Kevan Miller <ke...@gmail.com>.
On Apr 2, 2008, at 2:41 PM, Dan Diephouse wrote:

> Kevan Miller wrote:

<snip>

> Each jar has a NOTICE file in META-INF/NOTICE. The source and binary  
> distributions each have a NOTICE file in /.
>
> Where are the multiple NOTICE files?

I cracked open abdera-bundle-0.4.0-incubating.jar and found the  
following files:

   -rw-rw-rw-      1129  25-Mar-2008  09:26:52  META-INF/ 
LICENSE.htmlparser.txt
   -rw-rw-rw-     11558  25-Mar-2008  09:26:52  META-INF/ 
LICENSE.serializer.txt
   -rw-rw-rw-       164  25-Mar-2008  09:26:52  META-INF/ 
NOTICE.htmlparser.txt
   -rw-rw-rw-       864  25-Mar-2008  09:26:52  META-INF/ 
NOTICE.serializer.txt

The single NOTICE file contains all of the m-r-r-p cruft (are you  
removing this?) and does not contain the htmlparser and serializer  
notice info. Do the jars contain htmlparser/serializer artifacts? I  
would wonder if they need the notices...

--kevan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

Posted by Dan Diephouse <da...@mulesource.com>.
Kevan Miller wrote:
>
> On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:
>
>> Dan Diephouse wrote:
>>> sebb wrote:
>>>> On 31/03/2008, Dan Diephouse <da...@mulesource.com> wrote:
>>>>
>>>>> >>> -1: The LICENSE files need to either contain copies of the 3rd 
>>>>> party
>>>>> >>>
>>>>> >>  > licenses, or they need to have a reference to the 3rd party 
>>>>> licences.
>>>>> >>  > Equally, there is no need for the lib directory to contain 
>>>>> copies of
>>>>> >>  > the AL for every ASF product.
>>>>> >>  >
>>>>> >>
>>>>> >> Why does the LICENSE file need to have a copy of all the other 
>>>>> licenses?
>>>>> >>  These are contained in the lib/ directory like many other ASF 
>>>>> projects.
>>>>> >>
>>>>> >>
>>>>> >
>>>>> > See the last paragraph of:
>>>>> >
>>>>> > http://www.apache.org/dev/apply-license.html#new
>>>>> >
>>>>> >
>>>>>
>>>>> "or at least put a pointer in the LICENSE file to the third-party
>>>>> license" - which we in the NOTICE file.
>>>>>
>>>>>
>>>>
>>>> But they need to go in the LICENSE file, see:
>>>>
>>>> http://www.apache.org/dev/apply-license.html#new
>>>>
>>> Did you not read the next paragraph?
>>>>> There is not a legal requirement here that it must be in the LICENSE
>>>>> file itself - if so, please point me to the place in the license. 
>>>>> This
>>>>> is page is to provide "guidance" (see the first sentence), not be the
>>>>> ultimate authority on what exactly is legally permissible for 
>>>>> distributions.
>>>>>
>>>>>  If you look at many other ASF projects in the incubator and outside,
>>>>> you'll see that this is not an enforced policy - this is simply 
>>>>> telling
>>>>> developers one way to get started here.
>>>>>
>>> Can other people please chime in here?
>>>
>>> I have never ever seen this enforced and I do not believe its a 
>>> requirement. Just to summarize - do we need to 1) include all the 
>>> licenses for all our dependencies in a single libary or can we 2) 
>>> have our top LICENSE file which is ASL and then have individual 
>>> LICENSE files for each library in the lib/ directory.
>>>
>>> I think not allowing the second would be a HUGE mistake. It makes it 
>>> much clearer which license applies to which file.
>>>
>>> Dan
>>>
>> I misspoke. Here's what I meant to ask:
>>
>> Do we need to 1) include all the licenses for all our dependencies in 
>> a single LICENSE file or can we 2) have our top LICENSE file which is 
>> ASL and then have individual LICENSE files for each library in the 
>> lib/ directory.
>
> I'm not aware of a requirement for having only 1 LICENSE file. In 
> fact, the document says you don't have to append 3rd-party licenses to 
> the LICENSE file. It does say you should put a pointer to the license 
> files. So, IMO, 2) is fine. Other Apache projects do this also.
>
> I do think LICENSE information in jar files should be complete (i.e. 
> jar files shouldn't reference information that would only be found in 
> a full binary distribution). It looks like your jars are ok, in that 
> respect.
>
> On the other hand, I believe there must be only one NOTICE file. I see 
> multiple NOTICE files in your jars. I haven't downloaded the full 
> distribution given the number of changes which seem to be occurring... 
> Hard to keep track.
Each jar has a NOTICE file in META-INF/NOTICE. The source and binary 
distributions each have a NOTICE file in /.

Where are the multiple NOTICE files?

Dan

-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Apr 3, 2008 at 9:44 AM, sebb <se...@gmail.com> wrote:
>
> On 03/04/2008, Robert Burrell Donkin <ro...@gmail.com> wrote:
>  > On Wed, Apr 2, 2008 at 11:08 PM, sebb <se...@gmail.com> wrote:
>  >  >
>  >  > On 02/04/2008, Robert Burrell Donkin <ro...@gmail.com> wrote:
>  >  >  > On Wed, Apr 2, 2008 at 8:59 PM, sebb <se...@gmail.com> wrote:
>  >  >  >  > On 02/04/2008, Kevan Miller <ke...@gmail.com> wrote:
>  >  >  >  >  >  On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:
>  >  >  >
>  >  >  >
>  >  >  > <snip>
>  >  >  >
>  >  >  >
>  >  >  >  >  > > I misspoke. Here's what I meant to ask:
>  >  >  >  >  > >
>  >  >  >  >  > > Do we need to 1) include all the licenses for all our dependencies in a
>  >  >  >  >  > single LICENSE file or can we 2) have our top LICENSE file which is ASL and
>  >  >  >  >  > then have individual LICENSE files for each library in the lib/ directory.
>  >  >  >  >  > >
>  >  >  >  >  >
>  >  >  >  >  >  I'm not aware of a requirement for having only 1 LICENSE file. In fact, the
>  >  >  >  >  > document says you don't have to append 3rd-party licenses to the LICENSE
>  >  >  >  >  > file. It does say you should put a pointer to the license files. So, IMO, 2)
>  >  >  >  >  > is fine. Other Apache projects do this also.
>  >  >  >  >
>  >  >  >  >  2) is fine so long as the main LICENSE jar tells users where to find
>  >  >  >  >  the other license - i.e. it  has pointers to the other licenses.
>  >  >  >
>  >  >  >
>  >  >  > AIUI this is not policy
>  >  >  >
>  >  >
>  >  >  My understanding differs, so I think this needs to be resolved and
>  >  >  formally documented.
>  >
>  >
>  > where did you find the rule you based your understanding of policy on?
>  >
>
>  Please see the first message in this thread.

the only reference i could see is to
http://www.apache.org/dev/apply-license.html. this is not a normative
document and is not policy. this document is old and CTR so this is
easy to fix to prevent future confusion. (apologies if i've missed a
policy document hopefully you'll jump in and correct me.)

>  We should be making it as easy as possible for users to find the
>  relevant licenses.
>
>  That's presumably why the main license file is only called LICENSE or
>  LICENSE.txt, not license.doc or readme.license etc, and the file is
>  always in the top level directory (or META-INF for jars).
>
>  Why should we force users to go looking around the directory structure
>  to find all the relevant additional licenses?

i'm not arguing about best practice (i too personally prefer
everything in one LICENSE file) but about policy. AIUI policy does not
mandate that all licenses be included in one file. have i missed
normative documentation to the contrary?

there is a subjective element to judging releases in the incubator:
everyone acknowledges that. but it's important to be clearly right
when using policy to justify -1'ing a release. a subjective -1 is much
easier to accept than one based on a contentious reading of
non-normative documentation.

IMO the right way to promote best practice is by positive argument and
example. this means good documentation that positively promote good
practice. the incubator release document really needs a lot more work
before we can even then about trying to gain consensus on it's
contents. it'd be great if you'd write up something on the merits of
including all license information in one file that could be included.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

Posted by sebb <se...@gmail.com>.
On 03/04/2008, Robert Burrell Donkin <ro...@gmail.com> wrote:
> On Wed, Apr 2, 2008 at 11:08 PM, sebb <se...@gmail.com> wrote:
>  >
>  > On 02/04/2008, Robert Burrell Donkin <ro...@gmail.com> wrote:
>  >  > On Wed, Apr 2, 2008 at 8:59 PM, sebb <se...@gmail.com> wrote:
>  >  >  > On 02/04/2008, Kevan Miller <ke...@gmail.com> wrote:
>  >  >  >  >  On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:
>  >  >
>  >  >
>  >  > <snip>
>  >  >
>  >  >
>  >  >  >  > > I misspoke. Here's what I meant to ask:
>  >  >  >  > >
>  >  >  >  > > Do we need to 1) include all the licenses for all our dependencies in a
>  >  >  >  > single LICENSE file or can we 2) have our top LICENSE file which is ASL and
>  >  >  >  > then have individual LICENSE files for each library in the lib/ directory.
>  >  >  >  > >
>  >  >  >  >
>  >  >  >  >  I'm not aware of a requirement for having only 1 LICENSE file. In fact, the
>  >  >  >  > document says you don't have to append 3rd-party licenses to the LICENSE
>  >  >  >  > file. It does say you should put a pointer to the license files. So, IMO, 2)
>  >  >  >  > is fine. Other Apache projects do this also.
>  >  >  >
>  >  >  >  2) is fine so long as the main LICENSE jar tells users where to find
>  >  >  >  the other license - i.e. it  has pointers to the other licenses.
>  >  >
>  >  >
>  >  > AIUI this is not policy
>  >  >
>  >
>  >  My understanding differs, so I think this needs to be resolved and
>  >  formally documented.
>
>
> where did you find the rule you based your understanding of policy on?
>

Please see the first message in this thread.

We should be making it as easy as possible for users to find the
relevant licenses.

That's presumably why the main license file is only called LICENSE or
LICENSE.txt, not license.doc or readme.license etc, and the file is
always in the top level directory (or META-INF for jars).

Why should we force users to go looking around the directory structure
to find all the relevant additional licenses?

>  - robert
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Apr 2, 2008 at 11:08 PM, sebb <se...@gmail.com> wrote:
>
> On 02/04/2008, Robert Burrell Donkin <ro...@gmail.com> wrote:
>  > On Wed, Apr 2, 2008 at 8:59 PM, sebb <se...@gmail.com> wrote:
>  >  > On 02/04/2008, Kevan Miller <ke...@gmail.com> wrote:
>  >  >  >  On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:
>  >
>  >
>  > <snip>
>  >
>  >
>  >  >  > > I misspoke. Here's what I meant to ask:
>  >  >  > >
>  >  >  > > Do we need to 1) include all the licenses for all our dependencies in a
>  >  >  > single LICENSE file or can we 2) have our top LICENSE file which is ASL and
>  >  >  > then have individual LICENSE files for each library in the lib/ directory.
>  >  >  > >
>  >  >  >
>  >  >  >  I'm not aware of a requirement for having only 1 LICENSE file. In fact, the
>  >  >  > document says you don't have to append 3rd-party licenses to the LICENSE
>  >  >  > file. It does say you should put a pointer to the license files. So, IMO, 2)
>  >  >  > is fine. Other Apache projects do this also.
>  >  >
>  >  >  2) is fine so long as the main LICENSE jar tells users where to find
>  >  >  the other license - i.e. it  has pointers to the other licenses.
>  >
>  >
>  > AIUI this is not policy
>  >
>
>  My understanding differs, so I think this needs to be resolved and
>  formally documented.

where did you find the rule you based your understanding of policy on?

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: License files - separate or one file

Posted by Henri Yandell <ba...@apache.org>.
Did this get resolved Dan?

We had a thread on this recently and there was definitely consensus
towards 2) being fine.

The only disagreement iirc between Sebb and I was whether it should be
in the LICENSE or whether it should be in a different file (the
README, or maybe a dedicated and structured THIRD_PARTY_README).

Hen

On Wed, Apr 2, 2008 at 3:20 PM, Dan Diephouse
<da...@mulesource.com> wrote:
> Can someone clarify the below for us on general@incubator?
>
> sebb wrote:
>>
>> On 02/04/2008, Robert Burrell Donkin <ro...@gmail.com>
>> wrote:
>>
>>>
>>> On Wed, Apr 2, 2008 at 8:59 PM, sebb <se...@gmail.com> wrote:
>>>  > On 02/04/2008, Kevan Miller <ke...@gmail.com> wrote:
>>>  >  >  On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:
>>>
>>>
>>> <snip>
>>>
>>>
>>>  >  > > I misspoke. Here's what I meant to ask:
>>>  >  > >
>>>  >  > > Do we need to 1) include all the licenses for all our
>>> dependencies in a
>>>  >  > single LICENSE file or can we 2) have our top LICENSE file which is
>>> ASL and
>>>  >  > then have individual LICENSE files for each library in the lib/
>>> directory.
>>>  >  > >
>>>  >  >
>>>  >  >  I'm not aware of a requirement for having only 1 LICENSE file. In
>>> fact, the
>>>  >  > document says you don't have to append 3rd-party licenses to the
>>> LICENSE
>>>  >  > file. It does say you should put a pointer to the license files.
>>> So, IMO, 2)
>>>  >  > is fine. Other Apache projects do this also.
>>>  >
>>>  >  2) is fine so long as the main LICENSE jar tells users where to find
>>>  >  the other license - i.e. it  has pointers to the other licenses.
>>>
>>>
>>> AIUI this is not policy
>>>
>>>
>>
>> My understanding differs, so I think this needs to be resolved and
>> formally documented.
>>
>>
>
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only.  Statements made on this list are not privileged, do not
> constitute legal advice, and do not necessarily reflect the opinions
> and policies of the ASF.  See <http://www.apache.org/licenses/> for
> official ASF policies and documents.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: License files - separate or one file

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Apr 2, 2008 at 11:20 PM, Dan Diephouse
<da...@mulesource.com> wrote:
> Can someone clarify the below for us on general@incubator?

probably needs more than someone (i'm on the legal committee) and more
like consensus

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: License files - separate or one file

Posted by Henri Yandell <ba...@apache.org>.
Did this get resolved Dan?

We had a thread on this recently and there was definitely consensus
towards 2) being fine.

The only disagreement iirc between Sebb and I was whether it should be
in the LICENSE or whether it should be in a different file (the
README, or maybe a dedicated and structured THIRD_PARTY_README).

Hen

On Wed, Apr 2, 2008 at 3:20 PM, Dan Diephouse
<da...@mulesource.com> wrote:
> Can someone clarify the below for us on general@incubator?
>
> sebb wrote:
>>
>> On 02/04/2008, Robert Burrell Donkin <ro...@gmail.com>
>> wrote:
>>
>>>
>>> On Wed, Apr 2, 2008 at 8:59 PM, sebb <se...@gmail.com> wrote:
>>>  > On 02/04/2008, Kevan Miller <ke...@gmail.com> wrote:
>>>  >  >  On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:
>>>
>>>
>>> <snip>
>>>
>>>
>>>  >  > > I misspoke. Here's what I meant to ask:
>>>  >  > >
>>>  >  > > Do we need to 1) include all the licenses for all our
>>> dependencies in a
>>>  >  > single LICENSE file or can we 2) have our top LICENSE file which is
>>> ASL and
>>>  >  > then have individual LICENSE files for each library in the lib/
>>> directory.
>>>  >  > >
>>>  >  >
>>>  >  >  I'm not aware of a requirement for having only 1 LICENSE file. In
>>> fact, the
>>>  >  > document says you don't have to append 3rd-party licenses to the
>>> LICENSE
>>>  >  > file. It does say you should put a pointer to the license files.
>>> So, IMO, 2)
>>>  >  > is fine. Other Apache projects do this also.
>>>  >
>>>  >  2) is fine so long as the main LICENSE jar tells users where to find
>>>  >  the other license - i.e. it  has pointers to the other licenses.
>>>
>>>
>>> AIUI this is not policy
>>>
>>>
>>
>> My understanding differs, so I think this needs to be resolved and
>> formally documented.
>>
>>
>
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only.  Statements made on this list are not privileged, do not
> constitute legal advice, and do not necessarily reflect the opinions
> and policies of the ASF.  See <http://www.apache.org/licenses/> for
> official ASF policies and documents.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: License files - separate or one file

Posted by Dan Diephouse <da...@mulesource.com>.
Can someone clarify the below for us on general@incubator?

sebb wrote:
> On 02/04/2008, Robert Burrell Donkin <ro...@gmail.com> wrote:
>   
>> On Wed, Apr 2, 2008 at 8:59 PM, sebb <se...@gmail.com> wrote:
>>  > On 02/04/2008, Kevan Miller <ke...@gmail.com> wrote:
>>  >  >  On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:
>>
>>
>> <snip>
>>
>>
>>  >  > > I misspoke. Here's what I meant to ask:
>>  >  > >
>>  >  > > Do we need to 1) include all the licenses for all our dependencies in a
>>  >  > single LICENSE file or can we 2) have our top LICENSE file which is ASL and
>>  >  > then have individual LICENSE files for each library in the lib/ directory.
>>  >  > >
>>  >  >
>>  >  >  I'm not aware of a requirement for having only 1 LICENSE file. In fact, the
>>  >  > document says you don't have to append 3rd-party licenses to the LICENSE
>>  >  > file. It does say you should put a pointer to the license files. So, IMO, 2)
>>  >  > is fine. Other Apache projects do this also.
>>  >
>>  >  2) is fine so long as the main LICENSE jar tells users where to find
>>  >  the other license - i.e. it  has pointers to the other licenses.
>>
>>
>> AIUI this is not policy
>>
>>     
>
> My understanding differs, so I think this needs to be resolved and
> formally documented.
>
>   


-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

Posted by Santiago Gala <sg...@apache.org>.
El mié, 02-04-2008 a las 23:08 +0100, sebb escribió:
> On 02/04/2008, Robert Burrell Donkin <ro...@gmail.com> wrote:
> > On Wed, Apr 2, 2008 at 8:59 PM, sebb <se...@gmail.com> wrote:
> >  > On 02/04/2008, Kevan Miller <ke...@gmail.com> wrote:
> >  >  >  On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:
> >
> >
> > <snip>
> >
> >
> >  >  > > I misspoke. Here's what I meant to ask:
> >  >  > >
> >  >  > > Do we need to 1) include all the licenses for all our dependencies in a
> >  >  > single LICENSE file or can we 2) have our top LICENSE file which is ASL and
> >  >  > then have individual LICENSE files for each library in the lib/ directory.
> >  >  > >
> >  >  >
> >  >  >  I'm not aware of a requirement for having only 1 LICENSE file. In fact, the
> >  >  > document says you don't have to append 3rd-party licenses to the LICENSE
> >  >  > file. It does say you should put a pointer to the license files. So, IMO, 2)
> >  >  > is fine. Other Apache projects do this also.
> >  >
> >  >  2) is fine so long as the main LICENSE jar tells users where to find
> >  >  the other license - i.e. it  has pointers to the other licenses.
> >
> >
> > AIUI this is not policy
> >
> 
> My understanding differs, so I think this needs to be resolved and
> formally documented.
> 

My understanding is as sebb's, and the rationale is that the LICENSE
file is where the different licenses governing components of the product
are documented, and the NOTICE file documents mandatory copyright
notices and attributions from subcomponents, such as they would appear
in an "About..." box.

The part requiring that the top LICENSE file documents the whole
licensing agreement was stated recently in legal-discuss because of a
question asked there, and it is common sense, as the most natural place
to look for a LICENSE is a top level LICENSE file, which is additionally
a universal convention in the world of software from like 20 years ago.

Regards
Santiago

> >  - robert
> >
> >
> >  ---------------------------------------------------------------------
> >  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >  For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org

-- 
Santiago Gala
http://memojo.com/~sgala/blog/


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: License files - separate or one file

Posted by Dan Diephouse <da...@mulesource.com>.
Can someone clarify the below for us on general@incubator?

sebb wrote:
> On 02/04/2008, Robert Burrell Donkin <ro...@gmail.com> wrote:
>   
>> On Wed, Apr 2, 2008 at 8:59 PM, sebb <se...@gmail.com> wrote:
>>  > On 02/04/2008, Kevan Miller <ke...@gmail.com> wrote:
>>  >  >  On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:
>>
>>
>> <snip>
>>
>>
>>  >  > > I misspoke. Here's what I meant to ask:
>>  >  > >
>>  >  > > Do we need to 1) include all the licenses for all our dependencies in a
>>  >  > single LICENSE file or can we 2) have our top LICENSE file which is ASL and
>>  >  > then have individual LICENSE files for each library in the lib/ directory.
>>  >  > >
>>  >  >
>>  >  >  I'm not aware of a requirement for having only 1 LICENSE file. In fact, the
>>  >  > document says you don't have to append 3rd-party licenses to the LICENSE
>>  >  > file. It does say you should put a pointer to the license files. So, IMO, 2)
>>  >  > is fine. Other Apache projects do this also.
>>  >
>>  >  2) is fine so long as the main LICENSE jar tells users where to find
>>  >  the other license - i.e. it  has pointers to the other licenses.
>>
>>
>> AIUI this is not policy
>>
>>     
>
> My understanding differs, so I think this needs to be resolved and
> formally documented.
>
>   


-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 


---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Apr 2, 2008 at 11:08 PM, sebb <se...@gmail.com> wrote:
>
> On 02/04/2008, Robert Burrell Donkin <ro...@gmail.com> wrote:
>  > On Wed, Apr 2, 2008 at 8:59 PM, sebb <se...@gmail.com> wrote:
>  >  > On 02/04/2008, Kevan Miller <ke...@gmail.com> wrote:
>  >  >  >  On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:
>  >
>  >
>  > <snip>
>  >
>  >
>  >  >  > > I misspoke. Here's what I meant to ask:
>  >  >  > >
>  >  >  > > Do we need to 1) include all the licenses for all our dependencies in a
>  >  >  > single LICENSE file or can we 2) have our top LICENSE file which is ASL and
>  >  >  > then have individual LICENSE files for each library in the lib/ directory.
>  >  >  > >
>  >  >  >
>  >  >  >  I'm not aware of a requirement for having only 1 LICENSE file. In fact, the
>  >  >  > document says you don't have to append 3rd-party licenses to the LICENSE
>  >  >  > file. It does say you should put a pointer to the license files. So, IMO, 2)
>  >  >  > is fine. Other Apache projects do this also.
>  >  >
>  >  >  2) is fine so long as the main LICENSE jar tells users where to find
>  >  >  the other license - i.e. it  has pointers to the other licenses.
>  >
>  >
>  > AIUI this is not policy
>  >
>
>  My understanding differs, so I think this needs to be resolved

if you want a ruling on apache legal policy then you need to ask on
legal-discuss

> and formally documented.

if it isn't documented as policy, it's not policy ;-)

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

Posted by sebb <se...@gmail.com>.
On 02/04/2008, Robert Burrell Donkin <ro...@gmail.com> wrote:
> On Wed, Apr 2, 2008 at 8:59 PM, sebb <se...@gmail.com> wrote:
>  > On 02/04/2008, Kevan Miller <ke...@gmail.com> wrote:
>  >  >  On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:
>
>
> <snip>
>
>
>  >  > > I misspoke. Here's what I meant to ask:
>  >  > >
>  >  > > Do we need to 1) include all the licenses for all our dependencies in a
>  >  > single LICENSE file or can we 2) have our top LICENSE file which is ASL and
>  >  > then have individual LICENSE files for each library in the lib/ directory.
>  >  > >
>  >  >
>  >  >  I'm not aware of a requirement for having only 1 LICENSE file. In fact, the
>  >  > document says you don't have to append 3rd-party licenses to the LICENSE
>  >  > file. It does say you should put a pointer to the license files. So, IMO, 2)
>  >  > is fine. Other Apache projects do this also.
>  >
>  >  2) is fine so long as the main LICENSE jar tells users where to find
>  >  the other license - i.e. it  has pointers to the other licenses.
>
>
> AIUI this is not policy
>

My understanding differs, so I think this needs to be resolved and
formally documented.

>  - robert
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Apr 2, 2008 at 8:59 PM, sebb <se...@gmail.com> wrote:
> On 02/04/2008, Kevan Miller <ke...@gmail.com> wrote:
>  >  On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:

<snip>

>  > > I misspoke. Here's what I meant to ask:
>  > >
>  > > Do we need to 1) include all the licenses for all our dependencies in a
>  > single LICENSE file or can we 2) have our top LICENSE file which is ASL and
>  > then have individual LICENSE files for each library in the lib/ directory.
>  > >
>  >
>  >  I'm not aware of a requirement for having only 1 LICENSE file. In fact, the
>  > document says you don't have to append 3rd-party licenses to the LICENSE
>  > file. It does say you should put a pointer to the license files. So, IMO, 2)
>  > is fine. Other Apache projects do this also.
>
>  2) is fine so long as the main LICENSE jar tells users where to find
>  the other license - i.e. it  has pointers to the other licenses.

AIUI this is not policy

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

Posted by sebb <se...@gmail.com>.
On 02/04/2008, Kevan Miller <ke...@gmail.com> wrote:
>
>  On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:
>
>
> > Dan Diephouse wrote:
> >
> > > sebb wrote:
> > >
> > > > On 31/03/2008, Dan Diephouse <da...@mulesource.com> wrote:
> > > >
> > > >
> > > > > >>> -1: The LICENSE files need to either contain copies of the 3rd
> party
> > > > > >>>
> > > > > >>  > licenses, or they need to have a reference to the 3rd party
> licences.
> > > > > >>  > Equally, there is no need for the lib directory to contain
> copies of
> > > > > >>  > the AL for every ASF product.
> > > > > >>  >
> > > > > >>
> > > > > >> Why does the LICENSE file need to have a copy of all the other
> licenses?
> > > > > >>  These are contained in the lib/ directory like many other ASF
> projects.
> > > > > >>
> > > > > >>
> > > > > >
> > > > > > See the last paragraph of:
> > > > > >
> > > > > > http://www.apache.org/dev/apply-license.html#new
> > > > > >
> > > > > >
> > > > >
> > > > > "or at least put a pointer in the LICENSE file to the third-party
> > > > > license" - which we in the NOTICE file.
> > > > >
> > > > >
> > > > >
> > > >
> > > > But they need to go in the LICENSE file, see:
> > > >
> > > > http://www.apache.org/dev/apply-license.html#new
> > > >
> > > >
> > > Did you not read the next paragraph?
> > >
> > > >
> > > > > There is not a legal requirement here that it must be in the LICENSE
> > > > > file itself - if so, please point me to the place in the license.
> This
> > > > > is page is to provide "guidance" (see the first sentence), not be
> the
> > > > > ultimate authority on what exactly is legally permissible for
> distributions.
> > > > >
> > > > >  If you look at many other ASF projects in the incubator and
> outside,
> > > > > you'll see that this is not an enforced policy - this is simply
> telling
> > > > > developers one way to get started here.
> > > > >
> > > > >
> > > >
> > > Can other people please chime in here?
> > >
> > > I have never ever seen this enforced and I do not believe its a
> requirement. Just to summarize - do we need to 1) include all the licenses
> for all our dependencies in a single libary or can we 2) have our top
> LICENSE file which is ASL and then have individual LICENSE files for each
> library in the lib/ directory.
> > >
> > > I think not allowing the second would be a HUGE mistake. It makes it
> much clearer which license applies to which file.
> > >
> > > Dan
> > >
> > >
> > I misspoke. Here's what I meant to ask:
> >
> > Do we need to 1) include all the licenses for all our dependencies in a
> single LICENSE file or can we 2) have our top LICENSE file which is ASL and
> then have individual LICENSE files for each library in the lib/ directory.
> >
>
>  I'm not aware of a requirement for having only 1 LICENSE file. In fact, the
> document says you don't have to append 3rd-party licenses to the LICENSE
> file. It does say you should put a pointer to the license files. So, IMO, 2)
> is fine. Other Apache projects do this also.

2) is fine so long as the main LICENSE jar tells users where to find
the other license - i.e. it  has pointers to the other licenses.

>  I do think LICENSE information in jar files should be complete (i.e. jar
> files shouldn't reference information that would only be found in a full
> binary distribution). It looks like your jars are ok, in that respect.
>
>  On the other hand, I believe there must be only one NOTICE file. I see
> multiple NOTICE files in your jars. I haven't downloaded the full
> distribution given the number of changes which seem to be occurring... Hard
> to keep track.
>
>  --kevan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

Posted by Kevan Miller <ke...@gmail.com>.
On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote:

> Dan Diephouse wrote:
>> sebb wrote:
>>> On 31/03/2008, Dan Diephouse <da...@mulesource.com> wrote:
>>>
>>>> >>> -1: The LICENSE files need to either contain copies of the  
>>>> 3rd party
>>>> >>>
>>>> >>  > licenses, or they need to have a reference to the 3rd party  
>>>> licences.
>>>> >>  > Equally, there is no need for the lib directory to contain  
>>>> copies of
>>>> >>  > the AL for every ASF product.
>>>> >>  >
>>>> >>
>>>> >> Why does the LICENSE file need to have a copy of all the other  
>>>> licenses?
>>>> >>  These are contained in the lib/ directory like many other ASF  
>>>> projects.
>>>> >>
>>>> >>
>>>> >
>>>> > See the last paragraph of:
>>>> >
>>>> > http://www.apache.org/dev/apply-license.html#new
>>>> >
>>>> >
>>>>
>>>> "or at least put a pointer in the LICENSE file to the third-party
>>>> license" - which we in the NOTICE file.
>>>>
>>>>
>>>
>>> But they need to go in the LICENSE file, see:
>>>
>>> http://www.apache.org/dev/apply-license.html#new
>>>
>> Did you not read the next paragraph?
>>>> There is not a legal requirement here that it must be in the  
>>>> LICENSE
>>>> file itself - if so, please point me to the place in the license.  
>>>> This
>>>> is page is to provide "guidance" (see the first sentence), not be  
>>>> the
>>>> ultimate authority on what exactly is legally permissible for  
>>>> distributions.
>>>>
>>>>  If you look at many other ASF projects in the incubator and  
>>>> outside,
>>>> you'll see that this is not an enforced policy - this is simply  
>>>> telling
>>>> developers one way to get started here.
>>>>
>> Can other people please chime in here?
>>
>> I have never ever seen this enforced and I do not believe its a  
>> requirement. Just to summarize - do we need to 1) include all the  
>> licenses for all our dependencies in a single libary or can we 2)  
>> have our top LICENSE file which is ASL and then have individual  
>> LICENSE files for each library in the lib/ directory.
>>
>> I think not allowing the second would be a HUGE mistake. It makes  
>> it much clearer which license applies to which file.
>>
>> Dan
>>
> I misspoke. Here's what I meant to ask:
>
> Do we need to 1) include all the licenses for all our dependencies  
> in a single LICENSE file or can we 2) have our top LICENSE file  
> which is ASL and then have individual LICENSE files for each library  
> in the lib/ directory.

I'm not aware of a requirement for having only 1 LICENSE file. In  
fact, the document says you don't have to append 3rd-party licenses to  
the LICENSE file. It does say you should put a pointer to the license  
files. So, IMO, 2) is fine. Other Apache projects do this also.

I do think LICENSE information in jar files should be complete (i.e.  
jar files shouldn't reference information that would only be found in  
a full binary distribution). It looks like your jars are ok, in that  
respect.

On the other hand, I believe there must be only one NOTICE file. I see  
multiple NOTICE files in your jars. I haven't downloaded the full  
distribution given the number of changes which seem to be occurring...  
Hard to keep track.

--kevan

Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

Posted by Dan Diephouse <da...@mulesource.com>.
Dan Diephouse wrote:
> sebb wrote:
>> On 31/03/2008, Dan Diephouse <da...@mulesource.com> wrote:
>>  
>>>  >>> -1: The LICENSE files need to either contain copies of the 3rd 
>>> party
>>>  >>>
>>>  >>  > licenses, or they need to have a reference to the 3rd party 
>>> licences.
>>>  >>  > Equally, there is no need for the lib directory to contain 
>>> copies of
>>>  >>  > the AL for every ASF product.
>>>  >>  >
>>>  >>
>>>  >> Why does the LICENSE file need to have a copy of all the other 
>>> licenses?
>>>  >>  These are contained in the lib/ directory like many other ASF 
>>> projects.
>>>  >>
>>>  >>
>>>  >
>>>  > See the last paragraph of:
>>>  >
>>>  > http://www.apache.org/dev/apply-license.html#new
>>>  >
>>>  >
>>>
>>> "or at least put a pointer in the LICENSE file to the third-party
>>>  license" - which we in the NOTICE file.
>>>
>>>     
>>
>> But they need to go in the LICENSE file, see:
>>
>> http://www.apache.org/dev/apply-license.html#new
>>   
> Did you not read the next paragraph?
>>>  There is not a legal requirement here that it must be in the LICENSE
>>>  file itself - if so, please point me to the place in the license. This
>>>  is page is to provide "guidance" (see the first sentence), not be the
>>>  ultimate authority on what exactly is legally permissible for 
>>> distributions.
>>>
>>>   If you look at many other ASF projects in the incubator and outside,
>>>  you'll see that this is not an enforced policy - this is simply 
>>> telling
>>>  developers one way to get started here.
>>>     
> Can other people please chime in here?
>
> I have never ever seen this enforced and I do not believe its a 
> requirement. Just to summarize - do we need to 1) include all the 
> licenses for all our dependencies in a single libary or can we 2) have 
> our top LICENSE file which is ASL and then have individual LICENSE 
> files for each library in the lib/ directory.
>
> I think not allowing the second would be a HUGE mistake. It makes it 
> much clearer which license applies to which file.
>
> Dan
>
I misspoke. Here's what I meant to ask:

Do we need to 1) include all the licenses for all our dependencies in a 
single LICENSE file or can we 2) have our top LICENSE file which is ASL 
and then have individual LICENSE files for each library in the lib/ 
directory.

Dan

-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]

Posted by Dan Diephouse <da...@mulesource.com>.
sebb wrote:
> On 31/03/2008, Dan Diephouse <da...@mulesource.com> wrote:
>   
>>  >>> -1: The LICENSE files need to either contain copies of the 3rd party
>>  >>>
>>  >>  > licenses, or they need to have a reference to the 3rd party licences.
>>  >>  > Equally, there is no need for the lib directory to contain copies of
>>  >>  > the AL for every ASF product.
>>  >>  >
>>  >>
>>  >> Why does the LICENSE file need to have a copy of all the other licenses?
>>  >>  These are contained in the lib/ directory like many other ASF projects.
>>  >>
>>  >>
>>  >
>>  > See the last paragraph of:
>>  >
>>  > http://www.apache.org/dev/apply-license.html#new
>>  >
>>  >
>>
>> "or at least put a pointer in the LICENSE file to the third-party
>>  license" - which we in the NOTICE file.
>>
>>     
>
> But they need to go in the LICENSE file, see:
>
> http://www.apache.org/dev/apply-license.html#new
>   
Did you not read the next paragraph?
>>  There is not a legal requirement here that it must be in the LICENSE
>>  file itself - if so, please point me to the place in the license. This
>>  is page is to provide "guidance" (see the first sentence), not be the
>>  ultimate authority on what exactly is legally permissible for distributions.
>>
>>   If you look at many other ASF projects in the incubator and outside,
>>  you'll see that this is not an enforced policy - this is simply telling
>>  developers one way to get started here.
>>     
Can other people please chime in here?

I have never ever seen this enforced and I do not believe its a 
requirement. Just to summarize - do we need to 1) include all the 
licenses for all our dependencies in a single libary or can we 2) have 
our top LICENSE file which is ASL and then have individual LICENSE files 
for each library in the lib/ directory.

I think not allowing the second would be a HUGE mistake. It makes it 
much clearer which license applies to which file.

Dan

-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by sebb <se...@gmail.com>.
On 31/03/2008, Dan Diephouse <da...@mulesource.com> wrote:
> sebb wrote:
>  >
>  >>  > The NOTICE file is for required attribtions ONLY (e.g. as per an About box)
>  >>  > There's really no need to repeat ASF for each project used by Abdera.
>  >>  >
>  >>
>  >> Having too much information in the NOTICE files is not a crime. The
>  >>  Maven remote-resources plugin aggregates all this stuff for us so we
>  >>  never miss any notice that we need to put in.
>  >>
>  >
>  > Unfortunately the plugin generates incorrect information.
>  >
>
> It does NOT generate incorrect information. It simply generates extra
>  attributions for all the ASF projects we reuse.
>
> > It *is* a problem having all the redundant information.
>  >
>  > See for example:
>  >
>  > http://www.apache.org/legal/src-headers.html
>  > also
>  > http://wiki.apache.org/legal/3party/notice
>  > http://wiki.apache.org/legal/3party/notice/discuss
>  >
>
> It says "should" not requires w.r.t. the mandatory license attributions.
>  Once again, I maintain that this is not a problem.
>
>
>  >>> -1: The LICENSE files need to either contain copies of the 3rd party
>  >>>
>  >>  > licenses, or they need to have a reference to the 3rd party licences.
>  >>  > Equally, there is no need for the lib directory to contain copies of
>  >>  > the AL for every ASF product.
>  >>  >
>  >>
>  >> Why does the LICENSE file need to have a copy of all the other licenses?
>  >>  These are contained in the lib/ directory like many other ASF projects.
>  >>
>  >>
>  >
>  > See the last paragraph of:
>  >
>  > http://www.apache.org/dev/apply-license.html#new
>  >
>  >
>
> "or at least put a pointer in the LICENSE file to the third-party
>  license" - which we in the NOTICE file.
>

But they need to go in the LICENSE file, see:

http://www.apache.org/dev/apply-license.html#new

>  There is not a legal requirement here that it must be in the LICENSE
>  file itself - if so, please point me to the place in the license. This
>  is page is to provide "guidance" (see the first sentence), not be the
>  ultimate authority on what exactly is legally permissible for distributions.
>
>   If you look at many other ASF projects in the incubator and outside,
>  you'll see that this is not an enforced policy - this is simply telling
>  developers one way to get started here.
>
>
>  Dan
>
>  --
>  Dan Diephouse
>  MuleSource
>  http://mulesource.com | http://netzooid.com
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by Dan Diephouse <da...@mulesource.com>.
sebb wrote:
>
>>  > The NOTICE file is for required attribtions ONLY (e.g. as per an About box)
>>  > There's really no need to repeat ASF for each project used by Abdera.
>>  >
>>
>> Having too much information in the NOTICE files is not a crime. The
>>  Maven remote-resources plugin aggregates all this stuff for us so we
>>  never miss any notice that we need to put in.
>>     
>
> Unfortunately the plugin generates incorrect information.
>   
It does NOT generate incorrect information. It simply generates extra 
attributions for all the ASF projects we reuse. 
> It *is* a problem having all the redundant information.
>
> See for example:
>
> http://www.apache.org/legal/src-headers.html
> also
> http://wiki.apache.org/legal/3party/notice
> http://wiki.apache.org/legal/3party/notice/discuss
>   
It says "should" not requires w.r.t. the mandatory license attributions. 
Once again, I maintain that this is not a problem.

>>> -1: The LICENSE files need to either contain copies of the 3rd party
>>>       
>>  > licenses, or they need to have a reference to the 3rd party licences.
>>  > Equally, there is no need for the lib directory to contain copies of
>>  > the AL for every ASF product.
>>  >
>>
>> Why does the LICENSE file need to have a copy of all the other licenses?
>>  These are contained in the lib/ directory like many other ASF projects.
>>
>>     
>
> See the last paragraph of:
>
> http://www.apache.org/dev/apply-license.html#new
>
>   
"or at least put a pointer in the LICENSE file to the third-party 
license" - which we in the NOTICE file.

There is not a legal requirement here that it must be in the LICENSE 
file itself - if so, please point me to the place in the license. This 
is page is to provide "guidance" (see the first sentence), not be the 
ultimate authority on what exactly is legally permissible for distributions.

 If you look at many other ASF projects in the incubator and outside, 
you'll see that this is not an enforced policy - this is simply telling 
developers one way to get started here.

Dan

-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by sebb <se...@gmail.com>.
On 31/03/2008, Dan Diephouse <da...@mulesource.com> wrote:
> sebb wrote:
>  > On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
>  >
>  >>
>  >
>
> > -1: There are MD5 and SHA1 digests in the directory, but the archives
>  > have no signatures.
>  >
>  >
>
> OK, I will fix this.
>
> >>  Maven Repository: http://people.apache.org/~dandiep/abdera-take6/
>  >>
>  >>
>  >
>  > -0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
>  > have any content - only the META-INF directory is present. Is that
>  > correct?
>  >
>
> This is just a by-product of Maven. We can delete it.
>
> > -1: The NOTICE files in that jar (and others) contains far too much.
>  > The NOTICE file is for required attribtions ONLY (e.g. as per an About box)
>  > There's really no need to repeat ASF for each project used by Abdera.
>  >
>
> Having too much information in the NOTICE files is not a crime. The
>  Maven remote-resources plugin aggregates all this stuff for us so we
>  never miss any notice that we need to put in.

Unfortunately the plugin generates incorrect information.
It *is* a problem having all the redundant information.

See for example:

http://www.apache.org/legal/src-headers.html
also
http://wiki.apache.org/legal/3party/notice
http://wiki.apache.org/legal/3party/notice/discuss

> > -1: The LICENSE files need to either contain copies of the 3rd party
>  > licenses, or they need to have a reference to the 3rd party licences.
>  > Equally, there is no need for the lib directory to contain copies of
>  > the AL for every ASF product.
>  >
>
> Why does the LICENSE file need to have a copy of all the other licenses?
>  These are contained in the lib/ directory like many other ASF projects.
>

See the last paragraph of:

http://www.apache.org/dev/apply-license.html#new

>  Re: the ASL license in lib/ - once again having too much information is
>  not a crime. This is a service to uesrs so they know where the libraries
>  came from.

I agree the source is useful, but the place for this is the LICENSE file.

> > -1: RAT report says:
>  >
>  > 99 Unknown Licenses
>  >
>  > Some of these are trivial, but most require an AL header.
>  >
>
> Not true - there is not consensus that properties/xml files need to have
>  headers. All the Java source code files have headers. If there are
>  specific files that you feel should have a license that don't please
>  list them and explain why. I'm not saying that we didn't miss something,
>  but I am saying that the ones that I know about don't necessarily
>  require a header.

Yes, they do, see:

http://www.apache.org/legal/src-headers.html#faq-exceptions

> > What is the SVN tag that corresponds with the archives?
>  >
>  >
>
> the branch will be tagged once its released.
>
>  Dan
>
>
>  --
>  Dan Diephouse
>  MuleSource
>  http://mulesource.com | http://netzooid.com
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by Dan Diephouse <da...@mulesource.com>.
Oops hit "ctrl enter" instead of "ctrl-v enter".  Here's the tag:

http://svn.apache.org/repos/asf/incubator/abdera/java/tags/abdera-0.4.0-incubating/

Dan

Dan Diephouse wrote:
> I removed the empty sources jar and tagged the release:
>
> Dan Diephouse wrote:
>> sebb wrote:
>>> On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
>>>  
>>>>     
>>>
>>> -1: There are MD5 and SHA1 digests in the directory, but the archives
>>> have no signatures.
>>>
>>>   
>> OK, I will fix this.
>>>>  Maven Repository: http://people.apache.org/~dandiep/abdera-take6/
>>>>
>>>>     
>>>
>>> -0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
>>> have any content - only the META-INF directory is present. Is that
>>> correct?
>>>   
>> This is just a by-product of Maven. We can delete it.
>>> -1: The NOTICE files in that jar (and others) contains far too much.
>>> The NOTICE file is for required attribtions ONLY (e.g. as per an 
>>> About box)
>>> There's really no need to repeat ASF for each project used by Abdera.
>>>   
>> Having too much information in the NOTICE files is not a crime. The 
>> Maven remote-resources plugin aggregates all this stuff for us so we 
>> never miss any notice that we need to put in.
>>> -1: The LICENSE files need to either contain copies of the 3rd party
>>> licenses, or they need to have a reference to the 3rd party licences.
>>> Equally, there is no need for the lib directory to contain copies of
>>> the AL for every ASF product.
>>>   
>> Why does the LICENSE file need to have a copy of all the other 
>> licenses? These are contained in the lib/ directory like many other 
>> ASF projects.
>>
>> Re: the ASL license in lib/ - once again having too much information 
>> is not a crime. This is a service to uesrs so they know where the 
>> libraries came from.
>>> -1: RAT report says:
>>>
>>> 99 Unknown Licenses
>>>
>>> Some of these are trivial, but most require an AL header.
>>>   
>> Not true - there is not consensus that properties/xml files need to 
>> have headers. All the Java source code files have headers. If there 
>> are specific files that you feel should have a license that don't 
>> please list them and explain why. I'm not saying that we didn't miss 
>> something, but I am saying that the ones that I know about don't 
>> necessarily require a header.
>>> What is the SVN tag that corresponds with the archives?
>>>
>>>   
>> the branch will be tagged once its released.
>>
>> Dan
>>
>
>


-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by Dan Diephouse <da...@mulesource.com>.
I removed the empty sources jar and tagged the release:

Dan Diephouse wrote:
> sebb wrote:
>> On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
>>  
>>>     
>>
>> -1: There are MD5 and SHA1 digests in the directory, but the archives
>> have no signatures.
>>
>>   
> OK, I will fix this.
>>>  Maven Repository: http://people.apache.org/~dandiep/abdera-take6/
>>>
>>>     
>>
>> -0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
>> have any content - only the META-INF directory is present. Is that
>> correct?
>>   
> This is just a by-product of Maven. We can delete it.
>> -1: The NOTICE files in that jar (and others) contains far too much.
>> The NOTICE file is for required attribtions ONLY (e.g. as per an 
>> About box)
>> There's really no need to repeat ASF for each project used by Abdera.
>>   
> Having too much information in the NOTICE files is not a crime. The 
> Maven remote-resources plugin aggregates all this stuff for us so we 
> never miss any notice that we need to put in.
>> -1: The LICENSE files need to either contain copies of the 3rd party
>> licenses, or they need to have a reference to the 3rd party licences.
>> Equally, there is no need for the lib directory to contain copies of
>> the AL for every ASF product.
>>   
> Why does the LICENSE file need to have a copy of all the other 
> licenses? These are contained in the lib/ directory like many other 
> ASF projects.
>
> Re: the ASL license in lib/ - once again having too much information 
> is not a crime. This is a service to uesrs so they know where the 
> libraries came from.
>> -1: RAT report says:
>>
>> 99 Unknown Licenses
>>
>> Some of these are trivial, but most require an AL header.
>>   
> Not true - there is not consensus that properties/xml files need to 
> have headers. All the Java source code files have headers. If there 
> are specific files that you feel should have a license that don't 
> please list them and explain why. I'm not saying that we didn't miss 
> something, but I am saying that the ones that I know about don't 
> necessarily require a header.
>> What is the SVN tag that corresponds with the archives?
>>
>>   
> the branch will be tagged once its released.
>
> Dan
>


-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by Dan Diephouse <da...@mulesource.com>.
sebb wrote:
> On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
>   
>>     
>
> -1: There are MD5 and SHA1 digests in the directory, but the archives
> have no signatures.
>
>   
OK, I will fix this.
>>  Maven Repository: http://people.apache.org/~dandiep/abdera-take6/
>>
>>     
>
> -0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
> have any content - only the META-INF directory is present. Is that
> correct?
>   
This is just a by-product of Maven. We can delete it.
> -1: The NOTICE files in that jar (and others) contains far too much.
> The NOTICE file is for required attribtions ONLY (e.g. as per an About box)
> There's really no need to repeat ASF for each project used by Abdera.
>   
Having too much information in the NOTICE files is not a crime. The 
Maven remote-resources plugin aggregates all this stuff for us so we 
never miss any notice that we need to put in.
> -1: The LICENSE files need to either contain copies of the 3rd party
> licenses, or they need to have a reference to the 3rd party licences.
> Equally, there is no need for the lib directory to contain copies of
> the AL for every ASF product.
>   
Why does the LICENSE file need to have a copy of all the other licenses? 
These are contained in the lib/ directory like many other ASF projects.

Re: the ASL license in lib/ - once again having too much information is 
not a crime. This is a service to uesrs so they know where the libraries 
came from.
> -1: RAT report says:
>
> 99 Unknown Licenses
>
> Some of these are trivial, but most require an AL header.
>   
Not true - there is not consensus that properties/xml files need to have 
headers. All the Java source code files have headers. If there are 
specific files that you feel should have a license that don't please 
list them and explain why. I'm not saying that we didn't miss something, 
but I am saying that the ones that I know about don't necessarily 
require a header.
> What is the SVN tag that corresponds with the archives?
>
>   
the branch will be tagged once its released.

Dan

-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)

Posted by sebb <se...@gmail.com>.
On 31/03/2008, James M Snell <ja...@gmail.com> wrote:
> The Abdera project has resolved the issues raised previously and have
>  voted to release a new build of the 0.4.0-incubating release.
>
>  Binary distributions:
>
>  http://people.apache.org/~dandiep/abdera-take6/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.zip
>  http://people.apache.org/~dandiep/abdera-take6/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating.tar.gz
>
>  Source distributions:
>
>  http://people.apache.org/~dandiep/abdera-take6/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.zip
>  http://people.apache.org/~dandiep/abdera-take6/org/apache/abdera/apache-abdera/0.4.0-incubating/apache-abdera-0.4.0-incubating-src.tar.gz
>

-1: There are MD5 and SHA1 digests in the directory, but the archives
have no signatures.

>  Maven Repository: http://people.apache.org/~dandiep/abdera-take6/
>

-0: The abdera-bundle-0.4.0-incubating-sources.jar does not appear to
have any content - only the META-INF directory is present. Is that
correct?

-1: The NOTICE files in that jar (and others) contains far too much.
The NOTICE file is for required attribtions ONLY (e.g. as per an About box)
There's really no need to repeat ASF for each project used by Abdera.

-0: The Maven abdera-bundle-0.4.0-incubating.jar file contains a
LICENSE for Xalan and HtmlParser, but does not actually contain
either.

-1: The LICENSE files need to either contain copies of the 3rd party
licenses, or they need to have a reference to the 3rd party licences.
Equally, there is no need for the lib directory to contain copies of
the AL for every ASF product.

-1: RAT report says:

99 Unknown Licenses

Some of these are trivial, but most require an AL header.

What is the SVN tag that corresponds with the archives?


=== Other comments ===

mvn test succeeded, however there were quite a few stack traces printed.
If possible, these should be suppressed.

The jar MANIFEST files could do with a bit more information.
This makes it easier to trace the provenance of the jars.

For example:

Built-By: xxxxx
Implementation-Title: Apache Abdera (Incubating)
Implementation-Vendor: The Apache Software Foundation
Implementation-Vendor-Id: org.apache
Implementation-Version:
Specification-Title:
Specification-Vendor: The Apache Software Foundation
Specification-Version: xxx
Build-Jdk: 1.5.0_12 (e.g.)
X-Compile-Source-JDK: 1.3 (e.g.)
X-Compile-Target-JDK: 1.3 (e.g.)


>  Please take a look and cast your vote!
>
>  - Abdera Team
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>  For additional commands, e-mail: general-help@incubator.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org