incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: [DISCUSSION] (Re)use of Website Content
Date Sun, 24 Jun 2012 20:50:17 GMT
Hi Rob,

Thanks for this. This is a good framework of principles for actions to address the lack of
clarity.

Having done with Kay and others the heavy forklift of moving the website files I do have the
inside knowledge of what can be done here using existing information and tools.

On Jun 23, 2012, at 9:35 AM, Rob Weir wrote:

> We've received a few requests from corporations and individuals
> seeking to reuse portions of the www.openoffice.org website.  These
> have ranged from inclusion of images into textbooks, to creating
> translations of pages for a 3rd party website.  In some cases it boils
> down to a trademark use question.  But in some cases it is purely a
> content reuse question.
> 
> In these cases my personal stance has been to point to the appropriate
> license for the content.  IMHO we (as a project) should not be giving
> permission.  That is what the license is for, and we cannot/should not
> add or subtract to what the license says.  Only the content owner
> (copyright holder) can do that.
> 
> However, in the case of the www.openoffice.org website, the license
> which pertains to individual pages is not always very clear.  The
> website (and the project) has a long and complicated history, with
> various contributor agreements and terms of service over time.

The current TOU states the right to change the TOU at any time. INAL, but I believe this means
that unless another license can be found this license *IS* the license.

>  It is
> clear that at all times (that I know of at least) content was made
> available under some form of open source license or analogous
> documentation license (CC or PDL).   But on a page-by-page basis this
> is not always clear.

We can only know when individual files are so noted. or projects are so noted. AFAIK these
are, but I agree a careful inspection along your principles is important.

> 
> So (again, IMHO), as a project, we can best maintain the website
> content, with practices like:
> 
> 1) Don't remove any copyright statements

This is certainly a given. In the old structure there was a page that aggregated all the copyright
holders who might have a claim on a part of the site whether or not it is still active. We'll
need to find and preserve this page as part of a website license page.

> 
> 2) Preserve any license statements that are there

These are often within comments and hidden from public presentation. We should indicate that
these may be found by inspection of the source. 

> 
> 3) Make explicit any implicit license statements or copyrights.  For
> example, if a license is indicated for
> www.openoffice.org/foo/index.html, then maybe we explicitly put that
> license statement on all content in /foo, if it is clear it was a
> single work.

For the license, we can consider whether we want to add explicit footers or take some additional
action during the CMS conversion from source html to website html. This would occur within
ooo-site/lib/view.pm, templates/footer.html, and content/footer.mdtext. This can be on a folder
by folder basis just like we do for brand.mdtext for NL sites.

Copyrights are more difficult as they may not be as clearly applied. We are going to need
for copyright holders to positively assert their rights.

> 4) Be crystal clear what the license is for new incoming contributions

New files and content should be clearly AL 2.0. We can assume that all mdtext content is such
and treat it that way in the view.pm work above.


> 
> 5) Craft license statement that is as complete and accurate as we can,
> for the website.  It might have a predominant license as well as a
> long list of exceptions.  Think of what we did for the AOO LICENSE and
> NOTICE files.

We can use the old Oracle TOU hidden at http://www.openoffice.org/terms_of_use.html as a starting
point. (The only difference here from the original is a change of the source code license
to AL2.

> 
> Now, we can do all of the above and still not have absolute clarity on
> all pages.  This will impact some edge cases involving re-use of
> content.  For example, if someone wants to take content, modify it and
> turn it into a DRM'ed E-Book, without making the source files
> available, them this would be permitted by some licenses but not
> permitted by others.

If someone will make it clear what the constraints are according to the various license terms
then we can link to ids on the new terms page from the footer according to which license is
detected.

I see these four action tracks.

(A) Determine which licenses to enumerate and make a table of permissible re-use for each.
Principles 4 and 5.

(B) Rewrite content/terms_of_use.html as website_terms.mdtext. Principles 4 and 5.

(C) Write the appropriate license identification and footer link from within the CMS conversion
from source to website content. Principles 2 and 3.

(D) Identify the folders (former projects) with differing default licenses. An example here
is the API which with J├╝rgen's new conversion should be AL2. Principle 3.

I volunteer to lead the effort on (C) - it is congruent with other work with NL and API that
I intend to finally find cycles to perform. I'll help with (D).

Regards,
Dave


> 
> -Rob


Mime
View raw message