www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <ru...@intertwingly.net>
Subject Re: FCKeditor
Date Mon, 07 Jan 2008 21:28:59 GMT
On Jan 7, 2008 3:49 PM, Henri Yandell <bayard@apache.org> wrote:
> On Jan 7, 2008 7:04 AM, Sam Ruby <rubys@apache.org> wrote:
> > I agree with Jeremias's comments.
> >
> > Note http://people.apache.org/~rubys/3party.html relabels this section
> > "reciprocal licenses", and opens the door slightly for scripting
> > languages.  After a brief glance at FCKeditor, I'm assuming that it is
> > Javascript.
>
> I don't see FCKeditor being classed as "For small amounts of source";
> so even by your newer 3party.html it is not useable as FCKeditor does
> not have a difference between its binary and source versions.

Roy said it a while back a lot more eloquently than I ever could, but
when we are dealing with artifacts are customarily provided and
consumed in source form, then us blindly applying a rule that we avoid
licenses that requires that such artifacts be provided in source form
is nonsensical and counter-productive.

However, I recognize that this opinion has not yet reached consensus.

> > I see it as Cocoon's responsibility to outline a policy by which it
> > ensures that the MPL licensed artifacts are not modified in the ASF
> > SVN, and that people who download Cocoon are made aware that this code
> > is under a different license.
>
> If we're going to go this way - I'd rather see us centralize such
> things - ie) a read only section for 3rd party works that Infra or
> Legal manage. Cocoon can svn:external to it.

That might be a reasonable proposal.  I may have said it poorly, but
what I intended to convey is that I would like for us to derive a
policy based on concrete use cases rather than theory on how things
should work.

> As it is, I don't see how Cocoon can be using this.

re: "As it is"... true.  That's why I would like to see a policy
outlined.  Preferably by the people who know the use case and are most
affected.  Once a proposal is in place, we can explore changing "as it
is".

> Hen

- Sam Ruby

---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message