You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2012/06/23 18:35:44 UTC

[DISCUSSION] (Re)use of Website Content

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.  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.

So (again, IMHO), as a project, we can best maintain the website
content, with practices like:

1) Don't remove any copyright statements

2) Preserve any license statements that are there

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.

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

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.

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.

-Rob

Re: [DISCUSSION] (Re)use of Website Content

Posted by Kay Schenk <ka...@gmail.com>.
On Sun, Jun 24, 2012 at 1:50 PM, Dave Fisher <da...@comcast.net> wrote:

> 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
>
>
Might we be better off just re-using the old TOU for basically the whole
site save some specific areas like the API docs?

(VERY surprised that this was even uneartherd given our previous
discussions centering around PDL. Is THAT still relevant in any way?).

I think tracking down what's "new" at this point and therfeore subject to
ALv2 might be difficult unless we examine all the svn logs for each page on
the site, and keeping tract of this same information would seem to be quite
a task.

So,using Dave's list, we could skip (A), do (B), work on (C) , and would
still need to do (D).




> >
> > -Rob
>
>


-- 
----------------------------------------------------------------------------------------
MzK

"I would rather have a donkey that takes me there
 than a horse that will not fare."
                                          -- Portuguese proverb

Re: [DISCUSSION] (Re)use of Website Content

Posted by Dave Fisher <da...@comcast.net>.
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