[Framework-Team] Re: transforms

[Thierry Benita]

Hanno Schlichting a écrit :
> Thierry Benita wrote:
>   
>> [...]
>> We are adding transforms to plone.transforms, but it looks like there is
>> a licence issue at some point because we sometime need to include some
>> code that is published under free licence (mostly GPL) but we don't own
>> the code, and it is therefore impossible to give that code to the
>> Foundation.
>>     
> It is perfectly fine to add code to the Plone SVN repository which is
> owned by somebody else as long as it is clearly marked as such. We are
> doing this in CMFPlone itself (where we have separated it slightly in
> form of an svn:external reference for JavaScript libraries for example)
> but other places with direct inclusions as well.
>   
That's not what I understand reading the Plone contributor agreement. My
understanding is :
- the contributor agreement has to be signed before any commit in plone
svn. It's not needed for Archetypes or Collective.
- the discussions after the Foundation creation was about what is the
license that well be used for Plone ; that makes sense only if you are
the full copyright holder of Plone. You can't be the full copyright
holder if you include code that is copyrighted by someone else and have
a dependence on it.
- the contributor agreement intends to make the Foundation the legal
copyright holder for Plone, which means that the Foundation needs to
have all the copyright for Plone's code.

If we include in Plone some code that is'n owned by the Foundation, I
think that this may compromise the possibility for the Foundation to be
free to apply any license on Plone, because we have some code that
introduces obligations via its license.

Therefore my understanding is that the Plone svn repository is dedicated
to code copyrighted by the Plone Foundation, and other repositories are
for code that has specific license.

Am I wrong ?
>> This is especially true for openoffice xslt transforms (that rely on a
>> modified xslt sheet from opendocumentfellowship) and windows transforms
>> that need to embeed binaries if we want them to be easy to install.
>>     
>
> >From what I can tell plone.opendocument includes those xslt transforms
> as well. I'd rather like to see one implementation of openoffice support
> for Plone. Joscha just told me he'll be coming to the Plone conference
> and he's determined keep working on plone.opendocument for a while, so
> I'd rather see his work being supported by others.
>   
Joscha did a great work with plone.opendocument. That's not the point.
The question is : "can we include in a core plone repository code that
isn't copyrighted by the Foundation, as we can't give the Foundation a
copyright that we don't own.
> For the external binaries I think we need to rethink the way we do our
> development environments, distributions and installers for the next
> major Plone version anyways. We already started discussion around this
> on the plone-devel list (zc.buildout-based installers?) and I'm sure we
> will come up with something new here.
>
> The way in which we provide those binaries to further enhance the OOTB
> experience of Plone is a bit dependent on that discussion.
>
>   
The point here is that if we embed Windows binaries in a package, we
provide a running solution out of the box, without hassle for final
users. That's especially true for windows binaries. POSIX binaries are
most of time packaged and easy to install.
>> My proposal is to embeed AROfficeTransforms in the Plone bundle or
>> package. We may change the name if it is an issue.
>>
>> This would provide a full solution for indexing and previews (other
>> proposal) out of the box without licence issue.
>>     
>
> I'm not sure what exactly AROfficeTransforms provides here. For the
> actual transforms I hope we will have all of them covered in or based on
> plone.transforms in a short time.
>   
I was talking of AROfficeTransforms because it does exist, but the name
doesn't matter. The idea here is :
if we want to provide transforms that embed code that isn't copyrighted
by the Foundation, we can provide them in a separate package that may
have a different license from Plone core. This package can be maintained
in another place than Plone svn (collective ?). It can be provided in
plone bundle as a complementary package that isn't mandatory for Plone
to run.
This way we avoid licenses issues.
> The preview feature is something which in my opinion should either be
> included directly into Archetypes (if it is just  a tiny bit of code and
> some changes needed in AT itself anyways) or made available as a new
> archetypes.preview package.
>   
This is currently done by ARFilePreview. We are working on a lower level
version that would adapt a file field instead of the file object. We
need a little time in order to get this clearer.
This may become archetypes.preview .

PS : I'm not attached to the package name : I consider atReal as a Plone
contributor, and will be happy to give our code if it is considered useful.

Thierry.

-- 
atReal Xnet - http://www.atreal.net - contact at atreal.net
atReal collectivités - http://www.atreal.fr - contact at atreal.fr
Tél : +33 4 91 29 42 81 - Fax - +33 4 91 29 42 82
Spécialiste Zope et Plone