firebird-docs — chat stuff about documentation

[Firebird-docs] FbManager documentation

[Nando D. <na...@de...>]

Hello,
first of all, kudos to everyone for the grat work that's going on here.
I hope I'll be able to contribute something myself.

Now to the subject of this message: I am in charge of writing
documentation for a project that has the temporary name of
"FbManager", which aims to be a simple, lightweight, cross-platform
GUI for Firebird (think of it as a graphical isql + gbak + gsec). Once
it's finished, we would like to have it distributed together with
Firebird so newbies (especially under Windows) notice they have
actually installed something. :-)

Having said this, perhaps it would be a good idea to integrate such
documentation with the Firebird documentation from the start.

Comments?
-- 
Nando Dessena
mailto:na...@de...

Re: [Firebird-docs] ATTN Darcy, and all: PDF rendering

[Darcy O'N. <ds...@sk...>]

Hello,

I believe 90% of these are easily fixed in Ventura, the other 10% 
shouldn't be much harder since Ventura supports scripting which will 
allow me to correct any issues. For example the ampersand issue would 
use a script to fix the import problem.

I'll see what I can fix up in the next few days.

Darcy

[Firebird-docs] [Firebird-general] New Firebird Logo? (fwd)

[Paul V. <pa...@vi...>]

Hi all,

Funny coincidence: here we are talking about logos, and this was just
posted to Firebird-general. BTW what Roger saw is the Conference
mascot, a doll hand-made by Helen Borrie and flown to Europe.

(Rumour has it that the mascot flew from Australia to Europe all
by itself and arrived just before the plane carrying Helen...)


Greetings,
Paul Vinkenoog


---------- Forwarded message ----------
Date: Mon, 22 Mar 2004 17:44:52 -0000
From: Roger Vellacott <rve...@pa...>
Reply-To: Fir...@ya...
To: "'Fir...@ya...'" <Fir...@ya...>
Subject: [Firebird-general] New Firebird Logo?

Do I see a new Firebird logo - a cheery red baby bird - on the Firebird
conference site?

> http://www.firebird-conference.com/doc_131167-1.html
>

Is this in any way official?  It is much more appealing than the
normal one.

Roger Vellacott

Re: [Firebird-docs] Ventura docs, logo's, etc.

[Darcy O'N. <ds...@sk...>]

Here's the information I can fill in on this topic:

>Hi all,
>
>- But of course we
>  shouldn't be dogmatic about this. If Darcy can produce great-looking
>  PDFs with Ventura we would be daft to use our own, which at the
>  moment look poor *and* are broken.
>  
>
The Ventura approach is just an added approach to producing documents in 
the best available formats. Once the system works and PDF's can be 
created properly with Open Source software then they can co-exist 
without any issues. The benefit of a desktop publishing application is 
only that it provides better page layout and graphic handling and a more 
'professional' look..

>  In the meantime, if Darcy uses any intermediate files, import
>  definition files, style maps or so (I have no idea how this works!),
>  
>
Ventura produces a style sheet which can be exported to CSS which will 
maintain the format, or as in this case I use different font's that are 
not 'open' but if someone wanted to change the fonts in the CSS file it 
would be a simple procedure.

As for the Ventura XML Import function, it basically maps an XML tag to 
the Ventura style sheet. This is a text file so keeping it in CVS is no 
problem. For those who would like to view the XML map it can be found 
here: http://firebird.methyl.ca/fb-xml-map.vmf

>- About style and logos: if this thing works out, the "Darcy docs"
>  will be an important part of the Firebird face as others see it.
>  Use of another logo, especially if it features prominently on the
>  cover page of the docs, should therefore be widely discussed within
>  the community (project members, project admins, webmaster, FFmembers
>  list...). This is not something that should be decided by a handful
>  of people in firebird-docs.
>  
>
As this part of the doc project develops this will be increasingly 
important. As we all know a 'strong image' is important but the key is 
to be consistently different than the other projects.

>  Maybe it's better to concentrate on the technical aspects for now
>  (see other post) and keep the current logo on the cover. We can
>  always talk about new logos later. And of course anybody can develop
>  new logos if he wants to, not just Darcy. But to make it the new
>  official Firebird logo is another thing.
>  
>
Right now I think working out the technical details is the best 
direction. From what I'm seeing right now it shouldn't be a problem. The 
'style' of the future Firebird docs is something we will all need to 
discuss but it would be easier if I could just make a change, publish 
the doc correctly and then collect opinions. Repeat until finished and 
80% of the group is happy.

>    Look at http://www.firebirdsql.org/ff/foundation/ if you want to
>    know more.
>
I'm looking into this and in all likelihood will be joining shortly.

Darcy O'Neil

[Firebird-docs] Ventura docs, logo's, etc.

[Paul V. <pa...@vi...>]

Hi all,

Some more thoughts about the PDFs that Darcy can produce with Ventura:

- Ideally, we should have all our sources, configuration files, etc.,
  in CVS and work with free and/or open source tools. But of course we
  shouldn't be dogmatic about this. If Darcy can produce great-looking
  PDFs with Ventura we would be daft to use our own, which at the
  moment look poor *and* are broken.

  Still, the long-term goal IMO must remain that anybody who checks
  out the manual module can build all the targets (including PDF)
  without having to buy proprietary software. But I don't see this
  happen very soon.

  In the meantime, if Darcy uses any intermediate files, import
  definition files, style maps or so (I have no idea how this works!),
  it would be good to add these to the module. This way other Ventura
  users could build the docs too. And what's more: everybody could
  look at them, discuss them, suggest and test enhancements etc...
  which is one of the most powerful assets of open source development.
  Also, if Darcy ever leaves us, or has little time, we'll still be
  able to build on his contributions.

- About style and logos: if this thing works out, the "Darcy docs"
  will be an important part of the Firebird face as others see it.
  Use of another logo, especially if it features prominently on the
  cover page of the docs, should therefore be widely discussed within
  the community (project members, project admins, webmaster, FFmembers
  list...). This is not something that should be decided by a handful
  of people in firebird-docs.

  Maybe it's better to concentrate on the technical aspects for now
  (see other post) and keep the current logo on the cover. We can
  always talk about new logos later. And of course anybody can develop
  new logos if he wants to, not just Darcy. But to make it the new
  official Firebird logo is another thing.

- <shameless plug>
    Talking about the FFmembers list: this is the discussion list of
    the Firebird Foundation. The Foundation supports the Firebird
    Project in a number of ways, both financially (grants to active
    developers) and non-financially (making noise in public places).
    You can become an Associate Member for as little as $50/yr; a full
    membership costs $300/yr. All members can take part in the
    discussions on the FFmembers list, but only full members have
    voting rights.
    Look at http://www.firebirdsql.org/ff/foundation/ if you want to
    know more.
  </shameless plug>


Greetings,
Paul Vinkenoog

[Firebird-docs] ATTN Darcy, and all: PDF rendering

[Paul V. <pa...@vi...>]

Hi Darcy,

Here are the issues I've found in the PDF you made with Ventura. I
have no idea how easy or difficult it will be to fix them, but most of
them *must* be fixed because they really "break" the doc.

Just an idea: would it be easier if you imported the HTML instead of
the XML? Because in the HTML, the rendering has already taken place. I
can easily set up a target so that what needs to become one PDF file
is also in one HTML file (unlike now, where it is chunked into
top-level sections).

OK, here goes:

- "Chapter One" shouldn't be there (single-chapter doc).

- Can URL/email links be made to work? It's not critical, but it
  would be nice.

- Speaking of which: URL links wreak havoc all over the place: they
  are formatted as a block (should be inline) and they "outdent"
  from their surrounding blockquotes, listitems etc. instead of
  respecting the current indentation/margins. They also tend to
  break away from the listitems they're supposed to belong to.

- <sect1>: Leave more vertical space before it (say 1.5 times as much
  as now). Within an <article> (as opposed to a <book>) it would be
  nice if <sect1>s started on a new page (but not very important).

- Blockquotes: bit more space before them (one line's worth).

- <quote> tags should not translate to italics. Italics emphasize,
  whereas quotes often relativize. Best translate them as surrounding
  double-quotes.

- Sometimes spaces get eaten after a tag, e.g.: "primerif" and
  "primersif" under "DocBook XML - An Introduction".

- Internal links should work.

- <programlisting>s should honour whitespace, especially newlines
  and start-of-line spaces/tabs. A fixed-width font is also highly
  desirable here.
  OTOH, no extra whitespace or newlines must be added. This goes
  wrong under "Typing text" where the text demonstrates that an
  "unreadable" layout has the same validity as a pretty one.

- If a programlisting occurs within an indented block, it should not
  "outdent" from the block. Same goes for <example>s.

- The element <sgmltag class="starttag"> should be translated to '<'
  + element content + '>', like in the HTML. If class = "endtag", it
  should be rendered as '</' + constant + '>'. For "emptytag", it's
  '<' + content + '/>'
  Now you see in the PDF: "italics is a start tag, italics is an end
  tag, ..." - you don't see the difference between the two.

- The element <sgmltag class="genentity"> should be translated to '&'
  + element content + ';', like in the HTML. In the PDF it now says:

      ...you type this:

        lt

      That's an ampersand, followed by the letters l and t (for less
      than), followed by a semicolon.

  The "lt" should be "&lt;" of course, otherwise the whole point of
  the text is lost.

- Content of <literal> elements should stand out typographically. The
  usual solution is to use a fixed-width font with the same size as
  the surrounding text. No italics or boldface. And keep it inline.

- <emphasis> should stand out, preferably as italics. But:
    <emphasis role="bold"> should always be rendered in boldface.

- Admonitions (<caution>, <important>, <note>, <tip>, and <warning>)
  should be recognizable as such. They should be formatted as a block,
  indented or with a frame around it, possibly in a smaller font, and
  with some kind of caption denoting what it is: a note, a warning,
  a tip, ...
  Of course this can also be a graphic (light bulb for a tip, excl.
  mark for a warning etc.)

- Paragraphs within a listitem shouldn't get bullets of their own -
  this makes them look like extra listitems. I see this happen in
  itemizedlists and variablelists.

- listitems in an <orderedlist> should not have bullets, but (by
  default) Arabic numerals. Unless otherwise specified by the
  "numeration" attribute.

- <literallayout> and <screen> MUST honour the source layout!
  <screen> must have fixed-width font.

- Tables: <tfoot> elements should wind up at the foot of the table,
  not near the top. <thead> and <tfoot> content should be printed
  bold or italic (preferably bold) to distinguish them from ordinary
  rows.
  "align" attributes should be honoured if possible.

- command, application, superscript and subscript tags should be
  honoured. Same for all those other tags discussed under "Various
  inline elements". It's OK if you render them all the same as
  <literal> (see above).

- <computeroutput> is an inline element and shouldn't be formatted
  as a block.

- Spaces before a smiley :-) are eaten in the PDF.

- A nested list should have its own indentation level and preferably
  also another type of bullet. This goes wrong under "Style".


Greetings,
Paul Vinkenoog

Re: [Firebird-docs] Documentation Help

[Darcy O'N. <ds...@sk...>]

Lester Caine wrote:

> I agree with Paul here. I find the red bars distracting, but
> the whole point of XML is that you can use your own style :)
>
> Personally I will stick with 'plain text'.

Ok, making modifications to Venture is very easy so I'll play around and 
see if I can come up with something a little less distracting but still 
more than plain paper. Also, I should look into creating a marketing 
brochure for Firebird.

> This does however bring back the problem of navigation. I
> like the way the old Borland docs had the 'library' and
> dropped into the correct 'book' as required. Can Ventura
> manage that?

If you mean having a "linked master index" it may be possible. I'll have 
to look, but I do know that when Ventura outputs to PDF the Table of 
Contents and Index link to the appropriate place in the document.

Darcy O'Neil

Re: [Firebird-docs] Documentation Help

[Lester C. <le...@ls...>]

Paul Vinkenoog wrote:

>>Basically, I've been playing around with the XML documents and I
>>think it may be possible to directly import it into Corel Ventura to
>>give the documents a more polished look (PDF form anyway). I've
>>created a rough sample PDF document (highlights style, not content
>>right now) and put it up at http://firebird.methyl.ca for anyone to
>>look over.
> 
> On the following pages, the frame and decoration are nice, but I only
> like that for very small brochure-like documents. For tutorials,
> manuals, refguides etc. I prefer a minimum of decoration (if at all)
> and no frame around the text body.
> 
> Of course, all this is a just my opinion - it has a lot to do with
> personal taste. Please don't see it as criticizing the *quality* of
> your design: I mean it when I say I'm impressed!

I agree with Paul here. I find the red bars distracting, but
the whole point of XML is that you can use your own style :)

Personally I will stick with 'plain text'.

This does however bring back the problem of navigation. I
like the way the old Borland docs had the 'library' and
dropped into the correct 'book' as required. Can Ventura
manage that?

-- 
Lester Caine
-----------------------------
L.S.Caine Electronic Services

Re: [Firebird-docs] Writing Guide

[Darcy O'N. <ds...@sk...>]

>
>
>I see that some elements are not rendered the right way. But it's late
>now, I'll have a good look at it over the weekend and then followup
>here. I hope others will respond too because I think this is very
>promising. It makes all the difference if we can present decent PDF
>docs.
>  
>
Ya, I'm still working on the XML mappings but this is what was rendered 
after only an hour or two. Given a little more time I should be able to 
perfect it!

My basic goal was to produce some documents that 'professional' 
corporate types would get the confidence to use the product. MySQL is 
heading in that direction and frankly Firebird is much better than MySQL 
but this project doesn't have the momentum right now. Marketing can fix 
that, and good quality docs can give a powerful first impression to new 
users.

>One drawback is that we can't do this *within* the project at
>SourceForge, because we are certainly not going to buy Ventura and
>it wouldn't run on SF anyway. So we depend on you (or others) to
>produce them. That's not ideal, but still a heck of a lot better
>than ugly and/or broken PDF docs.
>
Ya, it's not perfect in the 'open' sense but I'm willing to contribute 
to this project for a good long time and based on the work I've done so 
far it's pretty much automated for me right now. It depends on the 
goals, I've always been of the mind set that we should use the 'right 
tool for the right job' and Ventura fits the bill.

That's an added benefit of Ventura, once we have a good level of 
documentation in place we can actually publish it to paper, and possible 
sell it via the Firebird site to help support the project. Obviously not 
yet, but this brings us closer.

Better marketing and image will hopefully increase support for this 
project and that can only be a good thing.

Darcy O'Neil

Re: [Firebird-docs] Documentation Help

[Darcy O'N. <ds...@sk...>]

Hello,

>I'm impressed. It looks *very* professional indeed!
>
>But... the style is not what I would prefer. The cover page makes me
>think of the kind of company where all the employees are clean-shaven
>and wear a suit and tie. I can't really relate to that - probably
>because I look like a bum myself :-)
>  
>
Thanks! I use to work for a giant corporation, so it's almost impossible 
to get that style out of my system.

>On the following pages, the frame and decoration are nice, but I only
>like that for very small brochure-like documents. For tutorials,
>manuals, refguides etc. I prefer a minimum of decoration (if at all)
>and no frame around the text body.
>
>Of course, all this is a just my opinion - it has a lot to do with
>personal taste. Please don't see it as criticizing the *quality* of
>your design: I mean it when I say I'm impressed!
>  
>
One thing I've learned about desktop publishing and that's every one has 
a style of their own. Basically, I just throw stuff out there and see 
what sticks. Hopefully, we can work away at it and come to a unanimous 
decision. (Probably not, but I'm sure we'll try).

>Ventura imports XML now, but is it also DocBook-aware? Or
>alternatively, can it process Formatting Objects? It would be great if
>you could develop a style we all like and then automate the process.
>  
>
Ventura is not DocBook aware, basically you map the tags to a Ventura 
style and then publish it to the selected format (PDF, print, etc.). As 
for automation, it can be done but professional doc's always need a good 
eye to go over it. I'm willing to do that.

>PS:
>What if you changed the grey in the logo to a warm sand color? I know,
>we have a grey bg on the website too, but I personally dislike it.
>  
>
Gray matches the colour of all those corporate execs!

Darcy O'Neil

Re: [Firebird-docs] Writing Guide

[Paul V. <pa...@vi...>]

Hi Darcy,

> I've managed to import the 'Writing Guide' into Corel Ventura and
> map most of the XML tags. It worked pretty smoothly. With this we
> can do some professional publishing of the Firebird docs. You can
> find the draft document at firebird.methyl.ca

Ha! You just updated it while I was visiting your pages to answer your
previous post! :-)

I see that some elements are not rendered the right way. But it's late
now, I'll have a good look at it over the weekend and then followup
here. I hope others will respond too because I think this is very
promising. It makes all the difference if we can present decent PDF
docs.

One drawback is that we can't do this *within* the project at
SourceForge, because we are certainly not going to buy Ventura and
it wouldn't run on SF anyway. So we depend on you (or others) to
produce them. That's not ideal, but still a heck of a lot better
than ugly and/or broken PDF docs.


Greetings,
Paul Vinkenoog

Re: [Firebird-docs] Documentation Help

[Paul V. <pa...@vi...>]

Hi Darcy,

> Basically, I've been playing around with the XML documents and I
> think it may be possible to directly import it into Corel Ventura to
> give the documents a more polished look (PDF form anyway). I've
> created a rough sample PDF document (highlights style, not content
> right now) and put it up at http://firebird.methyl.ca for anyone to
> look over.

I'm impressed. It looks *very* professional indeed!

But... the style is not what I would prefer. The cover page makes me
think of the kind of company where all the employees are clean-shaven
and wear a suit and tie. I can't really relate to that - probably
because I look like a bum myself :-)

On the following pages, the frame and decoration are nice, but I only
like that for very small brochure-like documents. For tutorials,
manuals, refguides etc. I prefer a minimum of decoration (if at all)
and no frame around the text body.

Of course, all this is a just my opinion - it has a lot to do with
personal taste. Please don't see it as criticizing the *quality* of
your design: I mean it when I say I'm impressed!


Ventura imports XML now, but is it also DocBook-aware? Or
alternatively, can it process Formatting Objects? It would be great if
you could develop a style we all like and then automate the process.


Greetings,
Paul Vinkenoog


PS:
What if you changed the grey in the logo to a warm sand color? I know,
we have a grey bg on the website too, but I personally dislike it.

[Firebird-docs] Writing Guide

[Darcy O'N. <ds...@sk...>]

I've managed to import the 'Writing Guide' into Corel Ventura and map 
most of the XML tags. It worked pretty smoothly. With this we can do 
some professional publishing of the Firebird docs. You can find the 
draft document at firebird.methyl.ca

There are still a few issues, mostly getting the spacing for the XML 
examples to import correctly, but worst case is manually correcting it. 
Anyway, let me know if you like this direction.

Darcy O'Neil

[Firebird-docs] Documentation Help

[Darcy O'N. <ds...@sk...>]

Hello,

I've been looking at ways I can help the Firebird project and since most 
of my skills are in desktop publishing and other creative areas, 
(websites) I figured I'd stick with the document section to see how I 
could help.

Basically, I've been playing around with the XML documents and I think 
it may be possible to directly import it into Corel Ventura to give the 
documents a more polished look (PDF form anyway). I've created a rough 
sample PDF document (highlights style, not content right now) and put it 
up at http://firebird.methyl.ca for anyone to look over.

Let me know what you think, and if we want to go in this direction just 
list some suggestions and I'll work them into the document.

I do have some time every now and them that I can direct towards the 
Firebird project.  My goal would be to give the Firebird documents a 
professionally published look and feel to help increase it's growth.

Darcy O'Neil

Re: [Firebird-docs] Navigation icons

[Paul V. <pa...@vi...>]

Hi Lester,

> The way I work, each module is it's own book, with a TOC and
> Index. Each can be accessed in it's own right, so the top level is
> the library rather than some vast TOC :)

So you only have one or two levels of ToCs? In the manual module I
think we have four or five levels, of which at least three have ToCs.
That is OK, but the high-level ToCs mustn't get too complex (= too
much detail for too many documents at once).

> THAT I think is the problem. As the volume grows will a complex TOC
> become too cumbersome?

Yes, it will. Because our overall ToC is already too detailed now
(with only four moderately-sized docs in the set). I would prefer it
to list only the titles. I'll find out if the ToC depth can be
adjusted for the top ToC (there is a parameter to adjust the depth,
but this also affects the local ToCs). If there isn't a parameter
we'll have to write an XSL template for it.


Greetings,
Paul Vinkenoog

Re: [Firebird-docs] Copyright

[Paul V. <pa...@vi...>]

Hi Helen,

> btw, if you're not squeamish and you want to read a crackup, go
> here: http://www.theregister.co.uk/content/30/36116.html

Nice one! :-)


Greetings,
Paul Vinkenoog

Re: [Firebird-docs] Copyright

[Paul V. <pa...@vi...>]

Hi Robert,

>> The Foundation neither runs nor owns Firebird, so if already you
>> want to relinquish the copyrights to your work, it should be to the
>> Firebird Project.

> Legally speaking, what is the Firebird project? What does it own?

I suppose the answer to both questions would come close to "nothing".
So perhaps transferring copyrights to the project would be impossible.
And even if not, I don't want to suggest that this would make sense.
But to me it would make even less sense to donate my copyrights to the
Foundation, because the Foundation doesn't write, manage or publish
Firebird docs (or code).

> I thought that copyright on Firebird was with Borland + individual
> contributors, all under the IPL. As we are already restricted to the
> IPL, we can't do anything else other than continue with it.

This is true for Borland code and anything derived from it. But
there's a lot of new code already, and the individual developers have
chosen various OS licenses for their contributed code. There was an
interesting thread about this in Firebird-devel not long ago.

Our documentation is new, so we can choose any OS license there.

BTW, the project summary states MPL as the OS license. I suppose this
is the chosen "default" for fresh contributions. Or perhaps it's just
there because they had to fill in *something*.

> I want to avoid the situation of different pages of the docs being
> copyrighted all over the place. It would be a nightmare if there
> were ever an occasion in future where it mattered.

Well, we don't exactly have dozens of active docwriters. But even if
we had (let's hope we will!) : as long as they all use SF-approved OS
licenses (and they must; that's an SF requirement) it will always
remain possible to keep building on their contributions.

> One really obvious case I can see is publishing the documentation in
> a book. The foundation might want to put the documentation under a
> non-commercial license and then publish, raising money for the
> foundation...

It could do that already now, at least with regard to the OS license
aspect. No need to grant them extra rights. I'm not sure if the
Foundation is allowed to *sell* something for profit though.

> ...without allowing others to publish it for free, but still
> allowing free use on the web etc.

Keeping others from publishing it is impossible with an OS License.
And we can't use anything but OS licenses -- unless we keep our docs
outside of the project.

> An important point I did make above was not to assign code to the
> foundation, but to allow them unrestricted usage.

You're right, I interpreted that too quickly as "giving your
copyrights to the Foundation". Guess I have to think a little slower
sometimes :-)

But I still don't see the benefit in giving the FF unrestricted usage
rights. It just doesn't need them.


Greetings,
Paul Vinkenoog

Re: [Firebird-docs] Copyright

[Robert J M. <rj...@ar...>]

Paul Vinkenoog wrote:

 >Hi Robert,
 >
 > 
 >
 >>I think the current copyright regime for the docs looks a bit
 >>unmanageable. I would have something like this:
 >>
 >>* By contributing to the documentation project, you are
 >>automatically granting the firebird foundation a non-exclusive,
 >>perpetual license to use it however they wish.
 >>
 >>* The foundation agrees to release your contribution to the world
 >>under a creative commons attribution, sharealike license, and may
 >>release it under other licenses in future
 >>(http://creativecommons.org/licenses/by-sa/1.0/)
 >>
 >>* In certain cases, you may contribute material that you do not have
 >>full copyright ownership over. In these cases, you must mark the
 >>contribution with an XML tag so that it can be identified by the
 >>foundation, and they will be able to abide by the license terms. The
 >>cases are as follows:
 >> - Postgresql documentation license
 >> - (add others)
 >>   
 >>
 >
 >The Foundation neither runs nor owns Firebird, so if already you
 >want to relinquish the copyrights to your work, it should be to the
 >Firebird Project.
 >
Legally speaking, what is the Firebird project? What does it own? I
thought that copyright on Firebird was with Borland + individual
contributors, all under the IPL. As we are already restricted to the
IPL, we can't do anything else other than continue with it. There is not
much to be gained by contributors assigning there code to anyone (unless
they assign to borland and it can then go into IB7). If code was
assigned to a foundation, then it may be possible to get an agreement
from a future Borland to re-license the code in some way that was
beneficial.

 >But I don't think it's necessary, or even useful:
 >anything you place on SourceForge MUST be Open Source. That alone is
 >enough for the project (or anybody else, for that matter) to use it;
 >not in every way they please, but at least in every way that makes
 >sense for the further development of the project and its
 >documentation. All this can be done easily and legally, while you
 >still retain the copyright to your work.
 > 
 >
I want to avoid the situation of different pages of the docs being
copyrighted all over the place. It would be a nightmare if there were
ever an occasion in future where it mattered. One really obvious case I
can see is publishing the documentation in a book. The foundation might
want to put the documentation under a non-commercial license and then
publish, raising money for the foundation without allowing others to
publish it for free, but still allowing free use on the web etc.

IPL sounds like a silly license to use because it has an advertise
Borland clause "This product includes software developed by Borland
Software Corp." The documentation doesn't. It may in future have to
include the postgres license, which also covers postgres documentation
http://www.postgresql.org/docs/7.4/static/LEGALNOTICE.html

An important point I did make above was not to assign code to the
foundation, but to allow them unrestricted usage. Authors could still
use the bits they write for whatever other purpose they like regardless
(e.g. a magazine article or something)

Robert Munro

Re: [Firebird-docs] ATTN Carmen: InnoSetup

[Paul V. <pa...@vi...>]

Hello Carmen,

[ InnoSetup script translation ]

> I'v missed something to mention: I have not translated the
> IP_License.txt or the readme.txt, only the GUI has been
> translated...

No problem. I ran a French Firebird installer once and I think it
was the same there. Most people skip those documents anyway and a
translated license text wouldn't have any legal validity.

Since this is not documentation I can't place it myself, but I've
emailed the webmaster of the official Firebird site. Maybe he'll
contact you directly or maybe you'll hear from me again.


Greetings,
Paul Vinkenoog

Re: [Firebird-docs] ATTN Carmen: InnoSetup

[Carmen S. <ker...@we...>]

Paul Vinkenoog schrieb:

>>...since Dezember 2003 I have translated the InnoSetup files to
>>German for a project which needs Firebird. Maybe you're interested?
>>I have to update from RC7 to Release, but that should be done soon.
> 
> 
> Looks like a very useful contribution. Have you had any reactions yet?
> If you have the Release version ready, it would certainly deserve a
> place on the project website and/or the IBPhoenix site.

I'v missed something to mention: I have not translated the 
IP_License.txt or the readme.txt, only the GUI has been translated...

Regards,

Carmen Smolne

Re: [Firebird-docs] ATTN Carmen: InnoSetup

[Carmen S. <ker...@we...>]

Paul Vinkenoog schrieb:
> Hello Carmen,
> 
> 
>>...since Dezember 2003 I have translated the InnoSetup files to
>>German for a project which needs Firebird. Maybe you're interested?
>>I have to update from RC7 to Release, but that should be done soon.
> 
> 
> Looks like a very useful contribution. Have you had any reactions yet?
> If you have the Release version ready, it would certainly deserve a
> place on the project website and/or the IBPhoenix site.
> 

At the moment there's no reaction...I started with an own script in 
December, because I didn't know that there's an official iss-script on 
the CVS site (and it was my first contact with firebird). You can 
imagine how glad I was to find out, that the firebird developers also 
use the InnoSetup program for building a setup program. So I mixed the 
both scripts until it fit my needs (there were some problems with the 
gds32.dll in the official script in RC7). Now with the release of 1.5 
the script is nearly perfect in my eyes. I can translate the official 
one (because I have different paths and some changes in my own script) 
and can send it to you (or upload it where you want). You can contact me 
via email, if you want.

Regards,

Carmen Smolne

Re: [Firebird-docs] Copyright

[Paul V. <pa...@vi...>]

Hi Helen,

> Helen
> (c) 2004 <g>

BC ?  <bg>


Grtz,
Paul

Re: [Firebird-docs] Copyright

[Helen B. <he...@tp...>]

At 01:19 AM 11/03/2004 +0100, you wrote:

>The Foundation neither runs nor owns Firebird, so if already you
>want to relinquish the copyrights to your work, it should be to the
>Firebird Project. But I don't think it's necessary, or even useful:
>anything you place on SourceForge MUST be Open Source. That alone is
>enough for the project (or anybody else, for that matter) to use it;
>not in every way they please, but at least in every way that makes
>sense for the further development of the project and its
>documentation. All this can be done easily and legally, while you
>still retain the copyright to your work.
>
>If you don't include a copyright notice with your work, I suppose the
>"default" project OS license (IPL) applies, but I don't know if this
>is legally watertight. It just seems kinda logical to me.

Don't forget that open-sourcing your work is *not* the same as relinquishing your copyright (something that seems to have eluded the riddled brains of dear Darl and his family).  If you put a copyright notice on anything that you wrote as original work, the IDPL announces to the world that you are the copyright owner.  Open Source licensing reinforces personal copyright, it doesn't override it.  What it does is give the public implicit permission to use and modify your work and publish the modifications under the same terms.  The work that the contributor adds is copyright to the contributor.

You are *allowed* to relinquish your own copyright, but you certainly are not obliged to. 

btw, if you're not squeamish and you want to read a crackup, go here:
http://www.theregister.co.uk/content/30/36116.html

Helen
(c) 2004 <g>

Re: [Firebird-docs] Copyright

[Paul V. <pa...@vi...>]

Hi Robert,

> I think the current copyright regime for the docs looks a bit
> unmanageable. I would have something like this:
>
> * By contributing to the documentation project, you are
> automatically granting the firebird foundation a non-exclusive,
> perpetual license to use it however they wish.
>
> * The foundation agrees to release your contribution to the world
> under a creative commons attribution, sharealike license, and may
> release it under other licenses in future
> (http://creativecommons.org/licenses/by-sa/1.0/)
>
> * In certain cases, you may contribute material that you do not have
> full copyright ownership over. In these cases, you must mark the
> contribution with an XML tag so that it can be identified by the
> foundation, and they will be able to abide by the license terms. The
> cases are as follows:
>  - Postgresql documentation license
>  - (add others)

The Foundation neither runs nor owns Firebird, so if already you
want to relinquish the copyrights to your work, it should be to the
Firebird Project. But I don't think it's necessary, or even useful:
anything you place on SourceForge MUST be Open Source. That alone is
enough for the project (or anybody else, for that matter) to use it;
not in every way they please, but at least in every way that makes
sense for the further development of the project and its
documentation. All this can be done easily and legally, while you
still retain the copyright to your work.

If you don't include a copyright notice with your work, I suppose the
"default" project OS license (IPL) applies, but I don't know if this
is legally watertight. It just seems kinda logical to me.


Greetings,
Paul Vinkenoog, (C) 1959

[Firebird-docs] ATTN Carmen: InnoSetup (was: Firebird 1.5 releasenotes translators)

[Paul V. <pa...@vi...>]

Hello Carmen,

> ...since Dezember 2003 I have translated the InnoSetup files to
> German for a project which needs Firebird. Maybe you're interested?
> I have to update from RC7 to Release, but that should be done soon.

Looks like a very useful contribution. Have you had any reactions yet?
If you have the Release version ready, it would certainly deserve a
place on the project website and/or the IBPhoenix site.

> I'm not a translator, only a software developer, so some
> translations could be made better...

So... develop translation software and run *that* on the .iss! :-)


Greetings,
Paul Vinkenoog