Why not host new libraries at Lift?

Lift as an incubator for (some parts of) the Scala distribution? I am
very much in favor.

On Wed, Sep 9, 2009 at 10:17 AM, martin odersky <martin.odersky@epfl.ch> wrote:

Lift as an incubator for (some parts of) the Scala distribution?

Incubator is exactly the word that I left out, but yes, that single word sums it up perfectly!
 

I am
very much in favor.

I love it

On Wed, Sep 9, 2009 at 9:32 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Wed, Sep 9, 2009 at 10:17 AM, martin odersky <martin.odersky@epfl.ch> wrote:

Lift as an incubator for (some parts of) the Scala distribution?

Incubator is exactly the word that I left out, but yes, that single word sums it up perfectly!
 

I am
very much in favor.

How difficult would it be to split the web frontend from the libraries in lift?
This would send a nice clear message that everything in the libs project can be used outside of a web application.


On Wed, Sep 9, 2009 at 8:32 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Wed, Sep 9, 2009 at 10:17 AM, martin odersky <martin.odersky@epfl.ch> wrote:

Lift as an incubator for (some parts of) the Scala distribution?

Incubator is exactly the word that I left out, but yes, that single word sums it up perfectly!
 

I am
very much in favor.

On Thu, Sep 10, 2009 at 1:08 AM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

How difficult would it be to split the web frontend from the libraries in lift?

They already are split.

The lift-json library depend on nothing.  lift-utils depends on nothing.  lift-textile depends on nothing.  lift-actor depends on lift-utils.  lift-webkit (the web frontend) depends on the above libraries.
 

This would send a nice clear message that everything in the libs project can be used outside of a web application.


On Wed, Sep 9, 2009 at 8:32 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Wed, Sep 9, 2009 at 10:17 AM, martin odersky <martin.odersky@epfl.ch> wrote:

Lift as an incubator for (some parts of) the Scala distribution?

Incubator is exactly the word that I left out, but yes, that single word sums it up perfectly!
 

I am
very much in favor.

David,  Would you mind sharing the Lift contributor agreement with the community so that it can be discussed?  It is much stricter than the EPFL's contributor agreement, and may represent a barrier to some contributing.  An explanation in more layman's terms would also be helpful, along with some explanation of the rationale.
-Erik

On Wed, Sep 9, 2009 at 1:11 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

Folks,

There's some chat about a new Scala IO library.  I think a much better IO library would be a win, but I also think that the value of this being integrated into the main Scala distribution may lead to the bloat we see in the Java libraries.  See Alex's discussion of modularization of Scala for more of a discussion.

I am happy to offer Lift and the Lift infrastructure to host modular libraries for Scala.  Joni brought his awesome JSON library over to Lift.  He's working on it and enhancing it, but he benefits from the Lift release machinery.

So, what does Lift have to offer:

• A more flexible release schedule than EPFL.  We do monthly milestone releases and have major releases that we're expecting to coordinate with Scala releases.
• We have maintenance branches and will release fixes to older versions of Lift, so fixes can be back-ported to older versions of the library.
  
• We will be integrating with the multi-version build stuff that the SBT folks are working on so a single library will be available for different Scala releases (and bug fixes will be as well).
• A commitment to OSGi support so our stuff is very modular.
  
• A migration path to the core Scala libraries.  Some of Lift (e.g., the XHTML libraries) have made it to the core Scala distribution.
• A very clean set of intellectual property.

I know this path was tried in the past with ScalaX.  In the case of Lift, we've got momentum and lots of active development.  We've got great hosting and build infrastructure.

So, if folks have interest in doing specific modules for Scala and want to take advantage of the Lift infrastructure, please ping me.

Thanks,

David

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
http://erikengbrecht.blogspot.com/

On Thu, Sep 10, 2009 at 7:25 PM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

David,  Would you mind sharing the Lift contributor agreement with the community so that it can be discussed?

Not at all.  Here's the agreement.  It's the Plone agreement with the word "plone" removed and the word "lift" inserted.  

 It is much stricter than the EPFL's contributor agreement, and may represent a barrier to some contributing.  An explanation in more layman's terms would also be helpful, along with some explanation of the rationale.

I'm kinda swamped today, but the short answer is that the intellectual property gets assigned to a single entity (rather than being licensed).  This allows the entity to enforce the license (which a license, you do not have the right to sue an infringer based on a license, only the assignee/owner of the IP has the right to enforce the license.)  This means that the license becomes unenforceable (which is more meaningful for the Apache license [and FsF-based licenses] because the licensee has affirmative obligations and/or the chance of losing the license.)
So, setting up a holding company for the IP that can enforce the rights in the IP is the route that I chose.  It means that you are giving your code to that entity (rather than just giving a license to use the code to the entity), but it means that the entity can protect the rights in that code.  

-Erik

On Wed, Sep 9, 2009 at 1:11 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

Folks,

There's some chat about a new Scala IO library.  I think a much better IO library would be a win, but I also think that the value of this being integrated into the main Scala distribution may lead to the bloat we see in the Java libraries.  See Alex's discussion of modularization of Scala for more of a discussion.

I am happy to offer Lift and the Lift infrastructure to host modular libraries for Scala.  Joni brought his awesome JSON library over to Lift.  He's working on it and enhancing it, but he benefits from the Lift release machinery.

So, what does Lift have to offer:

• A more flexible release schedule than EPFL.  We do monthly milestone releases and have major releases that we're expecting to coordinate with Scala releases.
• We have maintenance branches and will release fixes to older versions of Lift, so fixes can be back-ported to older versions of the library.
  
• We will be integrating with the multi-version build stuff that the SBT folks are working on so a single library will be available for different Scala releases (and bug fixes will be as well).
• A commitment to OSGi support so our stuff is very modular.
  
• A migration path to the core Scala libraries.  Some of Lift (e.g., the XHTML libraries) have made it to the core Scala distribution.
• A very clean set of intellectual property.

I know this path was tried in the past with ScalaX.  In the case of Lift, we've got momentum and lots of active development.  We've got great hosting and build infrastructure.

So, if folks have interest in doing specific modules for Scala and want to take advantage of the Lift infrastructure, please ping me.

Thanks,

David

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
http://erikengbrecht.blogspot.com/

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

On Sep 11, 2009, at 10:34 AM, David Pollak wrote:

>
>
> On Thu, Sep 10, 2009 at 7:25 PM, Erik Engbrecht > wrote:
> David,
> Would you mind sharing the Lift contributor agreement with the
> community so that it can be discussed?
>
> Not at all. Here's the agreement. It's the Plone agreement with
> the word "plone" removed and the word "lift" inserted.
>
> It is much stricter than the EPFL's contributor agreement, and may
> represent a barrier to some contributing. An explanation in more
> layman's terms would also be helpful, along with some explanation of
> the rationale.
>
> I'm kinda swamped today, but the short answer is that the
> intellectual property gets assigned to a single entity (rather than
> being licensed). This allows the entity to enforce the license
> (which a license, you do not have the right to sue an infringer
> based on a license, only the assignee/owner of the IP has the right
> to enforce the license.) This means that the license becomes
> unenforceable (which is more meaningful for the Apache license [and
> FsF-based licenses] because the licensee has affirmative obligations
> and/or the chance of losing the license.)

Why doesn't the Apache Software Foundation have such a license then?

>
> So, setting up a holding company for the IP that can enforce the
> rights in the IP is the route that I chose. It means that you are
> giving your code to that entity (rather than just giving a license
> to use the code to the entity), but it means that the entity can
> protect the rights in that code.

So you're saying that the ASF can't do that? Without being a lawyer,
it doesn't sound like the ASF would choose a license that they
couldn't enforce.

Regards,
Blair

On Fri, Sep 11, 2009 at 2:47 PM, Blair Zajac <blair@orcaware.com> wrote:

On Sep 11, 2009, at 10:34 AM, David Pollak wrote:

On Thu, Sep 10, 2009 at 7:25 PM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:
David,
 Would you mind sharing the Lift contributor agreement with the community so that it can be discussed?

Not at all.  Here's the agreement.  It's the Plone agreement with the word "plone" removed and the word "lift" inserted.

 It is much stricter than the EPFL's contributor agreement, and may represent a barrier to some contributing.  An explanation in more layman's terms would also be helpful, along with some explanation of the rationale.

I'm kinda swamped today, but the short answer is that the intellectual property gets assigned to a single entity (rather than being licensed).  This allows the entity to enforce the license (which a license, you do not have the right to sue an infringer based on a license, only the assignee/owner of the IP has the right to enforce the license.)  This means that the license becomes unenforceable (which is more meaningful for the Apache license [and FsF-based licenses] because the licensee has affirmative obligations and/or the chance of losing the license.)

Why doesn't the Apache Software Foundation have such a license then?

This is not a license, but an assignment.
I think that projects hosted at the ASF are on very shaky legal ground.  There is no entity that can enforce the license.  This may be a choice to encourage patches and community involvement vs. the ability to revoke a license in the event of a patent suit.  Or it may just be that the ASF people haven't really spent a lot of time on the issue.  I, on the other hand, have spent time discussing the issue with my in-house lawyer.  
Contrast this with what the FsF is doing... they are asking GPLed projects to assign the copyrights to the FsF for enforcement.  This allows the FsF to take whatever steps they want to enforce the license.  

So, setting up a holding company for the IP that can enforce the rights in the IP is the route that I chose.  It means that you are giving your code to that entity (rather than just giving a license to use the code to the entity), but it means that the entity can protect the rights in that code.

So you're saying that the ASF can't do that?  Without being a lawyer, it doesn't sound like the ASF would choose a license that they couldn't enforce.

There is a difference between a license which grants some specific sets of rights to copy a work and an assignment which transfers all the rights in a work to another party.  A weak analogy is the difference between inviting someone into your house (you still own the house) and selling the house to someone else.  The Lift IP Assignment agreement is *not* a license.  It is an assignment and it transfers ownership of the software committed into the Lift repository to the holding entity and the holding entity agrees to keep the software open.  The holding entity then grants licenses to everyone under the terms of the Apache License 2.0.
Why does the ASF operate the way it does?  Beats me, but after spending time with an incubated project there, I've got very little respect for the organization, legal, technical, or otherwise.
Thanks,
David 

Regards,
Blair

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

> Why doesn't the Apache Software Foundation have such a license then?

A licence cannot transfer copyright.

Also, a European cannot transfer copyright, but this law appears to be
generally ignored.

On 11 Sep 2009, at 23:11, David Pollak wrote:

> I think that projects hosted at the ASF are on very shaky legal
> ground. There is no entity that can enforce the license.

The license says what you can do with the code. If you do something
that is not covered by the license, or go outside of it, then you no
longer have a license to use it. In that case, you are using someone
else's copyrighted work without their permission and the legal
permissions associated therewith become the protection - anyone can
take action against an entity. This is exactly the same for any other
open-source license (EPL, GPL, ...)

> Contrast this with what the FsF is doing... they are asking GPLed
> projects to assign the copyrights to the FsF for enforcement.

No, they aren't asking for all GPL'd projects, they're only asking for
FSF programs. Almost all GPL programs are in fact not owned by the FSF.

http://www.fsf.org/licensing/licenses/why-assign.html
http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright

Note that in the (public) cases against the GPL, it was by individuals
with the support of the EFF. Here is a list of such cases:

http://gpl-violations.org

> This allows the FsF to take whatever steps they want to enforce the
> license.

Yes, and they suggest others using GPL to do similar - but that
doesn't mean all GPL must be transferred to the FSF. In any case,
regardless of who owns the underlying code the license is still fully
enforcable.

> There is a difference between a license which grants some specific
> sets of rights to copy a work and an assignment which transfers all
> the rights in a work to another party.

Agreed. All open-source licenses are just that; licenses. Almost no
open-source projects require you to transfer ownership. Code that I've
contributed to Apache isn't owned by Apache, but by me. However,
others can use it under the terms of the Apache License. Similarly,
code that I've developed under the Eclipse Public License is owned by
me; however, I grant a license to that to be used under the terms of
the EPL, and so it is in Eclipse (and other Eclipse derivatives like
the IBM commercial products).

> Why does the ASF operate the way it does? Beats me, but after
> spending time with an incubated project there, I've got very little
> respect for the organization, legal, technical, or otherwise.

It's a shame that you haven't had good experiences of the Apache
Software Foundation. I've always found them to be helpful and a widely
beneficial organisation for both the Java and widespread computing
community. If it weren't for developments like the Tomcat project,
Java would have taken longer to be as successful as it has on the
server side. Similarly, tools like Ant and Maven (and, for that
matter, Ivy) are all hosted at Apache. They also look out for the
'free' usage of Java - witness the ongoing disagreement with Sun on
the licensing of the TCK for Java.

In any case, none of this is meant as a detraction of the Lift
assignment nor of your rationale to use it. However, it is fairly
unique in the field of open-source and may not be seen by many as
necessary; furthermore, some may not be able/willing/interested to
contribute under such a restrictive agreement.

I therefore disagree that Lift should be the place of choice to host
Scala incubating code, though I do not see why others who are happy to
transfer rights could not do so if they wished.

Alex

On Fri, Sep 11, 2009 at 6:34 PM, David Pollak
wrote:
> Not at all.  Here's the agreement.  It's the Plone agreement with the word
> "plone" removed and the word "lift" inserted.

If this is intended as an incubator for contributions to the Scala
distribution (rather than Lift) then requiring a signed Scala
Contributor License Agreement[1] is sufficient.

It probably does make sense to ask for it to be signed before allowing
contributions so that there are no issues if/when code from multiple
contributors gets merged back into the main EPFL distribution.

[1] http://www.scala-lang.org/sites/default/files/contributor_agreement.pdf

Cheers,

Miles

I agree with this sentiment.  If the work is to be placed in scala, then we should aim for compatibility with their style of license.

Also, David.  If you feel Scala's IP/Contributor agreement forms are in jeopardy, we should take care of that.

No matter what, all contributors to "Scala Incubation" projects should  sign the Scala Contributor License Agreement regardless.  That way if the code migrates from Lift to Scala, they can continue to contribute to their own work.


- Josh



On Sat, Sep 12, 2009 at 7:30 AM, Miles Sabin <miles@milessabin.com> wrote:

On Fri, Sep 11, 2009 at 6:34 PM, David Pollak
<feeder.of.the.bears@gmail.com> wrote:
> Not at all.  Here's the agreement.  It's the Plone agreement with the word
> "plone" removed and the word "lift" inserted.

If this is intended as an incubator for contributions to the Scala
distribution (rather than Lift) then requiring a signed Scala
Contributor License Agreement[1] is sufficient.

It probably does make sense to ask for it to be signed before allowing
contributions so that there are no issues if/when code from multiple
contributors gets merged back into the main EPFL distribution.

[1] http://www.scala-lang.org/sites/default/files/contributor_agreement.pdf

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

On Sat, Sep 12, 2009 at 1:14 AM, Alex Blewitt <alex.blewitt@gmail.com> wrote:

On 11 Sep 2009, at 23:11, David Pollak wrote:

I think that projects hosted at the ASF are on very shaky legal ground.  There is no entity that can enforce the license.

The license says what you can do with the code. If you do something that is not covered by the license, or go outside of it, then you no longer have a license to use it. In that case, you are using someone else's copyrighted work without their permission and the legal permissions associated therewith become the protection - anyone can take action against an entity. This is exactly the same for any other open-source license (EPL, GPL, ...)

This is just wrong.  Only people with standing may take legal action.  Only the copyright holder or an entity that has contracted the right to assert copyright on behalf of the copyright holder has standing to assert copyright claims.  But for standing, everyone could sue everyone else asserting anyone's rights.
I'm a lawyer.  I was admitted to the bar in Rhode Island and the 1st Circuit.  I was the first person to assert First Amendment protections in computer programs (I was rejected by the 1st Circuit, but the 9th Circuit subsequently granted the protections). I've written license agreements that were used to protect million of copies of software.  My wife is one of the premier intellectual property attorneys in the US.  We have done significant analysis of the issue.  If you have legal background or training, I'd be happy to further discuss the issues.
In terms of the Lift IP structure, I have described it and why it exists.  I have had no reason to change it and ample reinforcement from prospective Lift users that Lift has very clean IP (which means a lot to corporate users who often pay the likes of IBM for insurance against getting sued for using open source software.)
Erik asked me to openly discuss the reasons behind the Lift IP assignment structure.  I've done that (and the same discussion recently took place on the Lift list.)  The discussion is to explain why it exists.  It is not a negotiation.
I made a simple offer: we will incubate Scala packages using the Lift infrastructure.  If there's something people don't like about the Lift infrastructure (Maven, the IP assignment, etc.) then don't take me up on the offer.
David
 

Contrast this with what the FsF is doing... they are asking GPLed projects to assign the copyrights to the FsF for enforcement.

No, they aren't asking for all GPL'd projects, they're only asking for FSF programs. Almost all GPL programs are in fact not owned by the FSF.

http://www.fsf.org/licensing/licenses/why-assign.html
http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright

Note that in the (public) cases against the GPL, it was by individuals with the support of the EFF. Here is a list of such cases:

http://gpl-violations.org

 This allows the FsF to take whatever steps they want to enforce the license.

Yes, and they suggest others using GPL to do similar - but that doesn't mean all GPL must be transferred to the FSF. In any case, regardless of who owns the underlying code the license is still fully enforcable.

There is a difference between a license which grants some specific sets of rights to copy a work and an assignment which transfers all the rights in a work to another party.

Agreed. All open-source licenses are just that; licenses. Almost no open-source projects require you to transfer ownership. Code that I've contributed to Apache isn't owned by Apache, but by me. However, others can use it under the terms of the Apache License. Similarly, code that I've developed under the Eclipse Public License is owned by me; however, I grant a license to that to be used under the terms of the EPL, and so it is in Eclipse (and other Eclipse derivatives like the IBM commercial products).

Why does the ASF operate the way it does?  Beats me, but after spending time with an incubated project there, I've got very little respect for the organization, legal, technical, or otherwise.

It's a shame that you haven't had good experiences of the Apache Software Foundation. I've always found them to be helpful and a widely beneficial organisation for both the Java and widespread computing community. If it weren't for developments like the Tomcat project, Java would have taken longer to be as successful as it has on the server side. Similarly, tools like Ant and Maven (and, for that matter, Ivy) are all hosted at Apache. They also look out for the 'free' usage of Java - witness the ongoing disagreement with Sun on the licensing of the TCK for Java.

In any case, none of this is meant as a detraction of the Lift assignment nor of your rationale to use it. However, it is fairly unique in the field of open-source and may not be seen by many as necessary; furthermore, some may not be able/willing/interested to contribute under such a restrictive agreement.

I therefore disagree that Lift should be the place of choice to host Scala incubating code, though I do not see why others who are happy to transfer rights could not do so if they wished.

Alex

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

On Sat, Sep 12, 2009 at 6:45 PM, David Pollak
wrote:
> I made a simple offer: we will incubate Scala packages using the Lift
> infrastructure.  If there's something people don't like about the Lift
> infrastructure (Maven, the IP assignment, etc.) then don't take me up on the
> offer.

Just to be clear: are you asking for all IP to be assigned to World
Wide Conferencing LLC, or would you be happy with an equivalent
assignment to EPFL or some other appropriate legal entity?

Cheers,

Miles

David~

I cannot speak for others, but I have definitely found your explanation clear and helpful. 

Given that agreement includes a "Grant Back" clause and that lift licenses its source under the Apache 2.0 license, contributors don't have to worry about their source code being inaccessible to them.  They will always retain the ability to use and modify their own code.  Additionally, I never had the means to pursue legal action against an infringer anyway... 

Thus, I definitely see the Lift contributer agreement as prudent rather than ownerous.

Thanks,
Matt

On Sat, Sep 12, 2009 at 1:45 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Sat, Sep 12, 2009 at 1:14 AM, Alex Blewitt <alex.blewitt@gmail.com> wrote:

On 11 Sep 2009, at 23:11, David Pollak wrote:

I think that projects hosted at the ASF are on very shaky legal ground.  There is no entity that can enforce the license.

The license says what you can do with the code. If you do something that is not covered by the license, or go outside of it, then you no longer have a license to use it. In that case, you are using someone else's copyrighted work without their permission and the legal permissions associated therewith become the protection - anyone can take action against an entity. This is exactly the same for any other open-source license (EPL, GPL, ...)

This is just wrong.  Only people with standing may take legal action.  Only the copyright holder or an entity that has contracted the right to assert copyright on behalf of the copyright holder has standing to assert copyright claims.  But for standing, everyone could sue everyone else asserting anyone's rights.
I'm a lawyer.  I was admitted to the bar in Rhode Island and the 1st Circuit.  I was the first person to assert First Amendment protections in computer programs (I was rejected by the 1st Circuit, but the 9th Circuit subsequently granted the protections). I've written license agreements that were used to protect million of copies of software.  My wife is one of the premier intellectual property attorneys in the US.  We have done significant analysis of the issue.  If you have legal background or training, I'd be happy to further discuss the issues.
In terms of the Lift IP structure, I have described it and why it exists.  I have had no reason to change it and ample reinforcement from prospective Lift users that Lift has very clean IP (which means a lot to corporate users who often pay the likes of IBM for insurance against getting sued for using open source software.)
Erik asked me to openly discuss the reasons behind the Lift IP assignment structure.  I've done that (and the same discussion recently took place on the Lift list.)  The discussion is to explain why it exists.  It is not a negotiation.
I made a simple offer: we will incubate Scala packages using the Lift infrastructure.  If there's something people don't like about the Lift infrastructure (Maven, the IP assignment, etc.) then don't take me up on the offer.
David
 

Contrast this with what the FsF is doing... they are asking GPLed projects to assign the copyrights to the FsF for enforcement.

No, they aren't asking for all GPL'd projects, they're only asking for FSF programs. Almost all GPL programs are in fact not owned by the FSF.

http://www.fsf.org/licensing/licenses/why-assign.html
http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright

Note that in the (public) cases against the GPL, it was by individuals with the support of the EFF. Here is a list of such cases:

http://gpl-violations.org

 This allows the FsF to take whatever steps they want to enforce the license.

Yes, and they suggest others using GPL to do similar - but that doesn't mean all GPL must be transferred to the FSF. In any case, regardless of who owns the underlying code the license is still fully enforcable.

There is a difference between a license which grants some specific sets of rights to copy a work and an assignment which transfers all the rights in a work to another party.

Agreed. All open-source licenses are just that; licenses. Almost no open-source projects require you to transfer ownership. Code that I've contributed to Apache isn't owned by Apache, but by me. However, others can use it under the terms of the Apache License. Similarly, code that I've developed under the Eclipse Public License is owned by me; however, I grant a license to that to be used under the terms of the EPL, and so it is in Eclipse (and other Eclipse derivatives like the IBM commercial products).

Why does the ASF operate the way it does?  Beats me, but after spending time with an incubated project there, I've got very little respect for the organization, legal, technical, or otherwise.

It's a shame that you haven't had good experiences of the Apache Software Foundation. I've always found them to be helpful and a widely beneficial organisation for both the Java and widespread computing community. If it weren't for developments like the Tomcat project, Java would have taken longer to be as successful as it has on the server side. Similarly, tools like Ant and Maven (and, for that matter, Ivy) are all hosted at Apache. They also look out for the 'free' usage of Java - witness the ongoing disagreement with Sun on the licensing of the TCK for Java.

In any case, none of this is meant as a detraction of the Lift assignment nor of your rationale to use it. However, it is fairly unique in the field of open-source and may not be seen by many as necessary; furthermore, some may not be able/willing/interested to contribute under such a restrictive agreement.

I therefore disagree that Lift should be the place of choice to host Scala incubating code, though I do not see why others who are happy to transfer rights could not do so if they wished.

Alex

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Recent discussion on Lift list:http://groups.google.com/group/liftweb/msg/8748c5d6b6b2de65

On Sat, Sep 12, 2009 at 1:45 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

On Sat, Sep 12, 2009 at 1:14 AM, Alex Blewitt <alex.blewitt@gmail.com> wrote:

On 11 Sep 2009, at 23:11, David Pollak wrote:

I think that projects hosted at the ASF are on very shaky legal ground.  There is no entity that can enforce the license.

The license says what you can do with the code. If you do something that is not covered by the license, or go outside of it, then you no longer have a license to use it. In that case, you are using someone else's copyrighted work without their permission and the legal permissions associated therewith become the protection - anyone can take action against an entity. This is exactly the same for any other open-source license (EPL, GPL, ...)

This is just wrong.  Only people with standing may take legal action.  Only the copyright holder or an entity that has contracted the right to assert copyright on behalf of the copyright holder has standing to assert copyright claims.  But for standing, everyone could sue everyone else asserting anyone's rights.
I'm a lawyer.  I was admitted to the bar in Rhode Island and the 1st Circuit.  I was the first person to assert First Amendment protections in computer programs (I was rejected by the 1st Circuit, but the 9th Circuit subsequently granted the protections). I've written license agreements that were used to protect million of copies of software.  My wife is one of the premier intellectual property attorneys in the US.  We have done significant analysis of the issue.  If you have legal background or training, I'd be happy to further discuss the issues.
In terms of the Lift IP structure, I have described it and why it exists.  I have had no reason to change it and ample reinforcement from prospective Lift users that Lift has very clean IP (which means a lot to corporate users who often pay the likes of IBM for insurance against getting sued for using open source software.)
Erik asked me to openly discuss the reasons behind the Lift IP assignment structure.  I've done that (and the same discussion recently took place on the Lift list.)  The discussion is to explain why it exists.  It is not a negotiation.
I made a simple offer: we will incubate Scala packages using the Lift infrastructure.  If there's something people don't like about the Lift infrastructure (Maven, the IP assignment, etc.) then don't take me up on the offer.
David
 

Contrast this with what the FsF is doing... they are asking GPLed projects to assign the copyrights to the FsF for enforcement.

No, they aren't asking for all GPL'd projects, they're only asking for FSF programs. Almost all GPL programs are in fact not owned by the FSF.

http://www.fsf.org/licensing/licenses/why-assign.html
http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright

Note that in the (public) cases against the GPL, it was by individuals with the support of the EFF. Here is a list of such cases:

http://gpl-violations.org

 This allows the FsF to take whatever steps they want to enforce the license.

Yes, and they suggest others using GPL to do similar - but that doesn't mean all GPL must be transferred to the FSF. In any case, regardless of who owns the underlying code the license is still fully enforcable.

There is a difference between a license which grants some specific sets of rights to copy a work and an assignment which transfers all the rights in a work to another party.

Agreed. All open-source licenses are just that; licenses. Almost no open-source projects require you to transfer ownership. Code that I've contributed to Apache isn't owned by Apache, but by me. However, others can use it under the terms of the Apache License. Similarly, code that I've developed under the Eclipse Public License is owned by me; however, I grant a license to that to be used under the terms of the EPL, and so it is in Eclipse (and other Eclipse derivatives like the IBM commercial products).

Why does the ASF operate the way it does?  Beats me, but after spending time with an incubated project there, I've got very little respect for the organization, legal, technical, or otherwise.

It's a shame that you haven't had good experiences of the Apache Software Foundation. I've always found them to be helpful and a widely beneficial organisation for both the Java and widespread computing community. If it weren't for developments like the Tomcat project, Java would have taken longer to be as successful as it has on the server side. Similarly, tools like Ant and Maven (and, for that matter, Ivy) are all hosted at Apache. They also look out for the 'free' usage of Java - witness the ongoing disagreement with Sun on the licensing of the TCK for Java.

In any case, none of this is meant as a detraction of the Lift assignment nor of your rationale to use it. However, it is fairly unique in the field of open-source and may not be seen by many as necessary; furthermore, some may not be able/willing/interested to contribute under such a restrictive agreement.

I therefore disagree that Lift should be the place of choice to host Scala incubating code, though I do not see why others who are happy to transfer rights could not do so if they wished.

Alex

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
http://erikengbrecht.blogspot.com/

On Sat, Sep 12, 2009 at 7:05 PM, Matt Fowles wrote:
> Given that agreement includes a "Grant Back" clause and that lift licenses
> its source under the Apache 2.0 license, contributors don't have to worry
> about their source code being inaccessible to them.  They will always retain
> the ability to use and modify their own code.

I could do with some clarification on the Grant Back clause. Does it
grant back an irrevocable right for contributors to use their
contributions for any purpose whatsoever?

Cheers,

Miles

On Sat, Sep 12, 2009 at 11:17 AM, Miles Sabin <miles@milessabin.com> wrote:

On Sat, Sep 12, 2009 at 7:05 PM, Matt Fowles <matt.fowles@gmail.com> wrote:
> Given that agreement includes a "Grant Back" clause and that lift licenses
> its source under the Apache 2.0 license, contributors don't have to worry
> about their source code being inaccessible to them.  They will always retain
> the ability to use and modify their own code.

I could do with some clarification on the Grant Back clause. Does it
grant back an irrevocable right for contributors to use their
contributions for any purpose whatsoever?

The Grant Back clause operates for obligations prior to execution of the agreement.  Once a work is submitted as part of Lift, it is covered by the Lift license (Apache 2.0).  The copyright license clause in the Apache 2.0 license reads as follows:

2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

So, you assign your rights to the holding company and the holding company grants you an irrevocable copyright license.  With the copyright license, you can include the software anywhere you want (you have to retain the copyright notice in source.)
More basically, if you assign your rights to the holding company, you can still use the software any way you would normally use it (include it in commercial projects, create derivative works [which *do not* need to be contributed into the Lift sources], put under your bed and sacrifice chickens over [doesn't everybody do that with their code?]).
What you lose: the ability to file a patent on the work you do (kinda defeats the intent behind open source.)  Trade secret protection in the work (once it's open source, it's no longer a trade secret.)  Trademarks in the code.  Ability to assign the rights in the code to another party.
Now, what can happen that could upset someone?  If WorldWide Conferencing, LLC (the holding company) decided to change the license to something you don't like, that could cause an issue.  For example, if the holding company chose to make future licenses of the work GPL, it would upset me.  All of my contributions to date would be under Apache 2.0 and I could fork the project, but derivative works of my code could be licensed under a license that I find offensive.
On the other hand, the Scala License differs from the Apache 2.0 license.  Any code that goes to EPFL would have to go under the Scala license.  Having a holding company that can make that decision is *much simpler* that going to each copyright holder and requesting that they grant a license in their code under the Scala License.  This means contacting 30 people (some of whom are no where to be found) and getting a new license grant from them.  That's a big time and effort savings.
My intent is to work with Martin and EPFL to make Scala better.  I intend to allow Martin and EPFL to cherry-pick whatever pieces of the Lift code base that would enhance Scala.  I intend to do what is necessary to license such works so they can be distributed with Scala under a unified license.
Thanks,
David
 

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp