incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <jogischm...@googlemail.com>
Subject Re: NOTICE, LICENSE, README etc.
Date Mon, 09 Jan 2012 16:50:18 GMT
On 1/9/12 5:31 PM, Rob Weir wrote:
> 2012/1/9 Jürgen Schmidt<jogischmidt@googlemail.com>:
>> Hi,
>>
>> I tried to get an overview about the current state in an installed office
>> and the process of generating localized LICENSE files, README and how the
>> THIRSPARTYLICENSEREADME.html comes into the game...
>>
>> Current situation on a
>>
>> MacOS system
>> ============
>> OpenOffice.org.app/Content/LICENSE
>> OpenOffice.org.app/Content/LICENSE.hmtl
>> OpenOffice.org.app/Content/README
>> OpenOffice.org.app/Content/README.html
>> OpenOffice.org.app/Content/basis-link/THIRDPARTYLICENSEREADME.html
>>
>> Window system
>> =============
>> .../OpenOffice.org 3/license.html
>> .../OpenOffice.org 3/license.txt
>> .../OpenOffice.org 3/readme.html
>> .../OpenOffice.org 3/readme.txt
>> .../OpenOffice.org 3/readmes/readme_en-US.html
>> .../OpenOffice.org 3/readmes/readme_en-US.txt
>> .../OpenOffice.org 3/THIRDPARTYLICENSEREADME.html
>>
>> readme files are always the same, readme.[txt|html] = readme.[txt|html]
>>
>> Linux System
>> ============
>> /org/openoffice.org/LICENSE
>> /org/openoffice.org/LICENSE.hmtl
>> /org/openoffice.org/README
>> /org/openoffice.org/README.html
>> /org/openoffice.org/THIRDPARTYLICENSEREADME.html
>>
>>
>> The input for these files comes from the main/readlicense_oo module
>>
>> LICENSE
>> readlicense_oo/source/license/license_en-US.html
>> readlicense_oo/source/license/license_en-US.txt
>> readlicense_oo/source/license/license_en-US.rtf
>>
>> README
>> readlicense_oo/docs/readme/readme.xrm
>>
>> the "plattform" specific README will be generated out of the readme.xrm file
>> . Well don't ask why it is done this way. It looks quite complicate ...
>>
>> THIRDPARTYLICENSEREADME
>> readlicense_oo/html/THIRDPARTYLICENSEREADME.html
>>
>>
>> I can't really find any information on [1] if we need localized versions of
>> the LICENSE, NOTICE, README files.
>>
>
> We're not required to translate these files and I'd advise against
> doing this at least in the case of the LICENSE and NOTICE files.   It
> is impossible to translate a license without applying our own
> interpretation of that license.  That is like giving legal advice
> then. We should not being doing that.
ok, I agree and we can probably simplify the process here

>
> The README file is another story, and I'd be open to a different story there.
>
> But how does README differ from the Release Notes?  Do we currently
> have both and translate both?
I have to confess I don't know it, will try to figure this out

>
>> The whole process in the office is a little bit more complex today and it
>> raised some questions for me.
>>
>> 1. Do we want to keep localized versions of these files, or do we need them?
>>
>
> I'd keep the required legal files (LICENSE and NOTICE) in their
> original form (English).
taken, see above

>
> For README, we need to consider the audience.  We will have source and
> binary packages.  For source packages, the README should be covering
> build pre-reqs, build flags, how to submit patches, generally a
> programmer-oriented README.  For the binary package, the README is
> admin and end-user oriented.
good point, we need definitely a second one for the source release.

The generated approach allows for example to change the $PRODUCT_NAME 
quite easily (probably not necessary anymore) and of course puts some 
platform specific content into the file.

>
>> 2. Should we simply create one README for all or one for each plattform and
>> should check in this directly?
>>
>
> That could be fine.

well if we check in the files directly we have to check how a potential 
translation of a plain text file works.

The source release README have to be in English only, yeah ;-)

>
>
>> 3. is related to the existing LICENSE [2] file in our source main directory.
>> In line 190 we have
>> ###
>> ...
>> Copyright [yyyy] [name of copyright owner]
>> ...
>> ###
>>
>> How does it have to be for a release? I assume something like
>> ###
>> ...
>> Copyright 2011 Apache Software Foundation
>> ...
>> ###
>>
>
> I don't think we change line 190.  That is instructions for someone
> who wants to add ALv2 to their own code.
>
ah you are right, my fault not reading careful enough the context here

Juergen

>
>> 4. THIRDPARTYLICENSEREADME.hmtl has to be merged into NOTICE (or already
>> had)
>>
>
> Most of THIRDPARTYLICENSEREADME will go into LICENSE.    That is where
> we aggregate the licenses for all of the code that we include in the
> release.  Since we're including additional libraries in the binary
> package that are not included in the source package, this probably
> means that we will have two different LICENSE and NOTICE files that we
> will need to rename and package at build time, depending on whether we
> are building a binary package or a source package.
>
> NOTICE is for any required notice that the 3rd party license requires
> us to make.  It does not include the full text of the license.  For
> example, a license might require that we include a link to where
> someone can download the source code of the component.  We'd put that
> in NOTICE.  And the Oracle copyright that Andrew is removing from
> source files, that would move into NOTICE as well.
>
> -Rob
>
>>
>> Juergen
>>
>> [1]: incubator.apache.org/guides/releasemanagement.html
>> [2]:
>> http://svn.apache.org/viewvc/incubator/ooo/trunk/main/LICENSE?view=markup
>>


Mime
View raw message