incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: [DISCUSSION] (Re)use of Website Content
Date Tue, 26 Jun 2012 20:29:23 GMT
On Sun, Jun 24, 2012 at 1:50 PM, Dave Fisher <dave2wave@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message