[doc] format of docs submitted to derby

[scott hutinger <sr...@www.mprojects.Horrabin.wiu.edu>]

I think a new thread is good.  Also : 
http://issues.apache.org/jira/browse/DERBY-259

Here are what I see as problems:

1) Microsoft Documents:  The location where documents are created has 
Microsoft products; that's what is on the machines.

Possible solutions:

-  import the document, after the document content person has sent the 
document, into OpenOffice.org, and save it as a OpenOffice Document.
    Why?:  An OpenOffice document can be saved and used as-is within 
forrest.
    Needs: openoffice plug-in from forrest
Changes:  This needs to be looked into, but I think any graphics need to 
be included somehow.

Example:  I put the JDBC howto document in the openoffice format.  It 
transformed into html and pdf, but the graphic portion of the document 
was not coherent.  Some mention of a method to include graphics in 
OpenOffice was mentioned in the past by someone in the forrest space.  
Getting the graphics to be included into the html and pdf (or whatever 
output) shouldn't need to concern the author.  It should be the concern 
of the output process.  This really should be automated, where an author 
places a document at a url, asks to transform and look at the result.  
If the result doesn't come out as the author intended, then the author 
should make clear comments about what is not correct about the output.  (?)


Other formats:

This also needs to be investigated a bit.  I looked briefly at xslt 
transform libraries.  I *think* ? this could be done out-of-derby 
without regard to license(?)  Can we use a transform process that does 
not fit within the Apache.org license scheme on out own, and put within 
the repository the output of the document?  Possibly the document needs 
cleaned,  possibly it depends on the license of the transform code.

?:  What outputs do all content processing applications output into?
?:  Can OpenOffice import and save into it's own format in a lossless 
way?  If not, what formats are preferred?

I don't know any of these answers, but I do know an easy-to-use format 
should exist for people that want to contribute content.  My opinion is, 
they spent so much time on content, that someone else can figure out how 
to convert it into some output that can be used.  For example: I spend 
10 hours in content production, then I spend (up-to) 50 hours trying to 
get everything into a format that can fit within a standard.  That might 
be a bit out-of-line, but very possible from what I have seen.

Possibly the forrest site has some hints on some of this.

My entire thoughts are related to the content.  I don't think people 
should have to give a second thought about sending in content.  If 
'crud' needs stripped, then lets look around for 'crud stripper' or 
write some content cleaning procedures.

Also, an important license issue; is OpenOffice compatible with 
Apache?   Can we stick content created by OOo into svn?  This was a 
current Forrest thread.

Any good solutions, ideas, etc?

scott

Re: [doc] format of docs submitted to derby

["Jean T. Anderson" <jt...@bristowhill.com>]

scott hutinger wrote:
>...
> 
> Also, an important license issue; is OpenOffice compatible with 
> Apache?   Can we stick content created by OOo into svn?  This was a 
> current Forrest thread. 
> ... 

Ross' original question (see the post below) was if the Open Office API 
libs could be used under the Sun Industry Standards Source License 
(SISSL). And the answer was "no", they cannot be checked into SVN, so 
that plugin will have to be hosted outside Apache.

However, I assume that a document produced by Open Office *can* be 
checked into SVN (ie. as part of a web site).  After all, results of a 
gcc compile can be checked in and gcc is under the GPL license.

Does anybody see a problem with my assumption?

  -jean




-------- Original Message --------
Subject: [Fwd: Re: SISSL compatible with ASL?]
Date: Wed, 04 May 2005 10:10:02 +0100
From: Ross Gardler <rg...@apache.org>
Reply-To: dev@forrest.apache.org
To: Forrest Developers List <de...@forrest.apache.org>

The legal-discuss list came up with the attached, summary is that the
MSOffice plugin will have to be hosted elsewhere. I'll put it in the
Burrokeet CVS. Any Forest committer requiring CVS access  over there
need only ask for it.

Ross

-------- Original Message --------
Date: Tue, 3 May 2005 16:17:07 -0700 (PDT)
From: Brian Behlendorf <br...@collab.net>
To: Ross Gardler <rg...@apache.org>
cc: legal-discuss@apache.org
Subject: Re: SISSL compatible with ASL?

The ASL-licensed works can be combined with SISSL-licensed works without
the license on one part encumbering the license on the other.  However
SISSL-licensed works can not be sublicensed under the ASL, which means you
can not incorporate the SISSL licensed works into a work that as a whole
is licensed under the ASL.  Which means the SISSL works must be kept out
of CVS/SVN and treated like an external dependency.  As best I can tell.

	Brian

On Tue, 3 May 2005, Ross Gardler wrote:
 > Over at Apache Forrest we have a plugin that needs to include the API
 > libs from OpenOffice.org (no source code). However, we are unsure if the
 > Sun Industry Standards Source License (SISSL) is compatible with the ASL.
 >
 > OOo is Tri licensed under the GPL, LGPL (obviously, not compatible) and
 > the Sun Industry Standards Source License (SISSL), so we are considering
 > the SISSL.
 >
 > The FAQ at http://www.openoffice.org/FAQs/faq-licensing.html#1 seems to
 > imply that it should be compatible:
 >
 > "This licensing structure provides the necessary flexibility for
 > combination of OpenOffice.org technologies with projects using other
 > licenses (e.g. MPL, Apache, Artistic, etc.)."
 >
 > However, being no legal experts we have no idea if this objective is
 > realised. Can someone with a little more understanding of these things
 > pass verdict?
 >
 > The SISSL license can be seen at http://www.openoffice.org/license.html
 >
 > Thanks,
 > Ross
 >
 > ---------------------------------------------------------------------
 > DISCLAIMER: Discussions on this list are informational and educational
 > only, are not privileged and do not constitute legal advice.
 > ---------------------------------------------------------------------
 > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
 > For additional commands, e-mail: legal-discuss-help@apache.org
 >