Questions about distributing a Lift app

[Grzegorz Balcerek]

Hello,

 

I am new to Lift and I trying to figure out what I need to do to
distribute an application written in Lift.  I managed to run
the "lift basic" example application and I managed to create a
war file.

 

I am now trying to figure out under what legal terms I can
distribute the application.

 

On the Lift website I found the information that lift is licensed
under an Apache 2.0 license, so I presume I need to include with
the application a copy of that license ("You must give any other
recipients of the Work or Derivative Works a copy of this
License"), however I did not find it in the war file or anywhere
else in the project. Where can I find it? Is it present somewhere
in the war file or in the generated documentation? Or am I
missing something? Do I need to create the war file or the
documentation in a special way?

 

I also noticed several jar file inside the war and I am trying to
figure out what are the license terms for all of the
dependencies. Where I can find that information?

 

Regards,
Grzegorz

[Diego Medina]

Hi,

You can find a copy if the apache license on their site [1].
About the legal terms, the fact that Lift is under the apache 2
license, as opposed to, let's say, the GPL2 license, means (in simple
terms), that you can sell your application without having to disclose
the source code you wrote.

All the dependencies that Lift comes with (those jars you saw) are
wither under the same license, or under a compatible license. NOw, if
your application uses some dependencies that are not related to Lift,
you would have to check on those projects to see what their licenses
are.

I hope this answers part of your question.

[1] http://www.apache.org/licenses/LICENSE-2.0.html

Diego

> --
> Lift, the simply functional web framework: http://liftweb.net
> Code: http://github.com/lift
> Discussion: http://groups.google.com/group/liftweb
> Stuck? Help us help you:
> https://www.assembla.com/wiki/show/liftweb/Posting_example_code



--
Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://www.fmpwizard.com

[David Pollak]

Speaking on behalf of WorldWide Conferencing, LLC (the owner of the Lift source code): do what you want with your Lift app.  If you redistribute Lift source code, please retain the copyright notice at the top.  If you make a derivative work of a Lift source file, please retain the Lift copyright notice in the file.  Other than that, do what you want.  Lift apps are meant to be business friendly and making a business on top of an app you build with Lift is totally awesome (and if you feel inclined, please share information about your success with the Lift community).

--

Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

--

Telegram, Simply Beautiful CMS https://telegr.am

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[Grzegorz Balcerek]

Hello,

 

Thank you for responding. However you did not answer my question. I
will try to elaborate to make myself clear.

 

Your web page says Lift is licensed under Apache 2.0 license, so if I
want to distribute my software with Lift in one package (assume I just
want to distribute the war file), I need to include with it a copy of
that license (Apache 2.0 license requires that).  That is fine - even
though for some reason the license text does not seem to be included
with the Lift distribution that I downloaded nor in the war file which
was created, I can find it on the Internet and include in my package.

 

However, after building an example application with Lift, I noticed
several jar files included inside the war file. So, for example
slf4j-api-1.6.4.jar is one of them. But slf4j is not licensed under
Apache 2.0 but it has another license which requires to include some
information with the software. So I know I need to include Apache 2.0
and the appropriate info from the SLF4j license in my package.

 

Well, there are more jar files. So here is my question: do I need to
manually go through all of them and try to figure out what they are
and how they are licensed in order to include the appropriate license
text with my software?  Or is this information available somewhere
already?

 

I cannot just take the war file and give it to a client with no
license information and say "just use it, do not worry about the
license details" (or rather, I could try, but I do not want to do it
that way, I want to do it properly).
Apache 2.0 and other licenses may be "business friendly" but that does
not mean I can totally ignore them.

 

Thanks,
Grzegorz

[David Pollak]

On Fri, Jun 8, 2012 at 6:32 AM, Grzegorz Balcerek <gbalc...@gmail.com> wrote:

Hello,

 

Thank you for responding. However you did not answer my question.

In fact, I did answer your question, but I will try to be more explicit: unless you are distributing source code, you do not need to do anything when you distribute your app.  You do not need to include copyright notices.  You do not need to include any form of advertising or origin.

 

I
will try to elaborate to make myself clear.

 

Your web page says Lift is licensed under Apache 2.0 license, so if I
want to distribute my software with Lift in one package (assume I just
want to distribute the war file), I need to include with it a copy of
that license (Apache 2.0 license requires that).  That is fine - even
though for some reason the license text does not seem to be included
with the Lift distribution that I downloaded nor in the war file which
was created, I can find it on the Internet and include in my package.

 

However, after building an example application with Lift, I noticed
several jar files included inside the war file. So, for example
slf4j-api-1.6.4.jar is one of them. But slf4j is not licensed under
Apache 2.0 but it has another license which requires to include some
information with the software. So I know I need to include Apache 2.0
and the appropriate info from the SLF4j license in my package.

 

Well, there are more jar files. So here is my question: do I need to
manually go through all of them and try to figure out what they are
and how they are licensed in order to include the appropriate license
text with my software?  Or is this information available somewhere
already?

No.  We curate the Lift dependencies so you don't have to do this.  There's no need to make these notices available in a WAR file.

 

 

I cannot just take the war file and give it to a client with no
license information and say "just use it, do not worry about the
license details" (or rather, I could try, but I do not want to do it
that way, I want to do it properly).
Apache 2.0 and other licenses may be "business friendly" but that does
not mean I can totally ignore them.

It means that you can give the WAR file to your client and say: this WAR file contains some of my work licensed under whatever license you choose and it also includes a bunch of other open source software that is licensed under licenses that allow you to use it for whatever purposes you want.  These licenses include the Apache 2.0 license and the MIT license.

Maven has a feature that will allow you to create a license report (a list of all the components and the license that each of the components is distributed under.)  I do not know if SBT does the same.

Once again, as a practical matter, we make sure that the licenses of Lift dependencies are business friendly so that it's possible for your to hand a WAR file over to your client with the confidence that they can use the code for their purposes.

Put another way, if you have a client that has particular IP audit requirements, please post those auditing requirements and we'll help to make sure that the generic Lift app meets those requirements.

Thanks,

David

[Grzegorz Balcerek]

 

 

No. We curate the Lift dependencies so you don't have to do this. There's no need to make these notices available in a WAR file.

 

What does it mean to "curate dependencies" ? I do not understand.

 

Grzegorz

 

 

[Antonio Salazar Cardozo]

On Friday, June 8, 2012 10:56:13 AM UTC-4, Grzegorz Balcerek wrote:

No. We curate the Lift dependencies so you don't have to do this. There's no need to make these notices available in a WAR file.

What does it mean to "curate dependencies" ? I do not understand.

As reiterated later in the email,

“Once again, as a practical matter, we make sure that the licenses of Lift dependencies are business friendly so that it's possible for your to hand a WAR file over to your client with the confidence that they can use the code for their purposes.”

Thanks,

Antonio

[Jack Park]

It's easy to see how that could be confusing. A "curate", the noun, is
a clergy person (priest or helper). The process of curation is that of
taking care of the artifacts. In this context, there is a duty of care
to not mix jar files which have licenses which are inconsistent with
the project. For instance, it would be an "insane act of violence" to
add a jar file to Lift which is licensed GPL, due to the viral nature
of that license and what it would do to the rest of the project (force
it to be GPL, whether that's a desired outcome or not). So, curating
dependencies literally means keeping track (managing) the jar files on
which Lift depends. The licenses of those jar files must remain
compatible. And that's not all: versions and other code compatibility
issues are in play, not just licenses.

Jack

[David Pollak]

Please see this post: http://groups.google.com/group/liftweb/msg/936fe3145abaa98e which is in one of the many threads where we discuss what libraries we support and which libraries have licenses that are incompatible with the ability for anyone to distribute a Lift-powered app in any way they want.

 

Thanks,

Antonio

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

[Grzegorz Balcerek]

Thank you for responding.

 

I do not have a problem with the fact that some open source
licenses are incompatible or not business friendly. I think I
understand that.

 

What I do not understand is why you are claiming that "unless you

are distributing source code, you do not need to do anything when
you distribute your app."

 

I far as I can see, the Apache license clearly requires to include
a copy of the license in point 4.1 ("in Source or Object form" -
so not only when distributing the source code).  The FAQ on the
apache website says a similar thing:
http://www.apache.org/foundation/license-faq.html#WhatDoesItMEAN
"It requires you to:
include a copy of the license in any redistribution you may make that includes Apache software;"
The slf4j license states a similar thing:
 "The  above  copyright  notice  and  this permission  notice  shall  be
 included in all copies or substantial portions of the Software."

 

So I just don't get it. I do not see why I could skip all that
copyright notices and licenses.

 

Anyway, I tried the maven license report that you mentioned, but I did not get any useful info out of it.
(I did: mvn project-info-reports:license)
However, I do not know maven well.

 

Regards,
Grzegorz

----- Original Message -----

From: David Pollak

To: lif...@googlegroups.com

Sent: Friday, June 08, 2012 7:03 PM

Subject: Re: [Lift] Questions about distributing a Lift app

[David Pollak]

On Fri, Jun 8, 2012 at 3:35 PM, Grzegorz Balcerek <gbalc...@gmail.com> wrote:

Thank you for responding.

 

I do not have a problem with the fact that some open source
licenses are incompatible or not business friendly. I think I
understand that.

 

What I do not understand is why you are claiming that "unless you

are distributing source code, you do not need to do anything when
you distribute your app."

 

I far as I can see, the Apache license clearly requires to include
a copy of the license in point 4.1 ("in Source or Object form" -
so not only when distributing the source code).  The FAQ on the
apache website says a similar thing:
http://www.apache.org/foundation/license-faq.html#WhatDoesItMEAN
"It requires you to:
include a copy of the license in any redistribution you may make that includes Apache software;"
The slf4j license states a similar thing:
 "The  above  copyright  notice  and  this permission  notice  shall  be
 included in all copies or substantial portions of the Software."

 

So I just don't get it. I do not see why I could skip all that
copyright notices and licenses.

Because I'm the guy that owns the company that owns the Lift license and I'm telling you that I'm not going to enforce that clause.  That's why!

[Grzegorz Balcerek]

Because I'm the guy that owns the company that owns the Lift license and I'm telling you that I'm not going to enforce that clause. That's why!

 

 

That is clear!  However, because you own the lift code but not
the code of the dependencies like slf4j, I think I will play safe
and I include their licenses if I distribute my app.

 

I have another other question.

 

What build tool is the best one (or which one is the main one? which one is used by the lift team?) for lift?
I have build the example app both using sbt and maven (I had to do one manual correction in the pom.xml file though to make it work).
The end result is not the same at least for the dependencies. For example sbt downloaded slf4j-api-1.6.4 and maven slf4j-api-1.6.1.

Regards,
Grzegorz

[David Pollak]

Personally, I think sbt is a piece of crap.  It's half-baked.  It sits on Ivy for dependency resolution.  It doen't deal well with locally compiled assets (I have to blow away my .ivy2 directory every few days.)  sbt sucks for identifying tests that have failed.  sbt doesn't understand dependencies and doesn't treat them correctly (this is important for multi-module projects.)

Maven is rock solid, well maintained, and has a lot of tools.  It's very well integrated with testing tools and produces excellent actionable items on test failure.

With all that being said, sbt is better integrated with Scala-land.  It does much better incremental compilation (maven recompiles the whole source tree each time).  sbt is better integrated with the Scala Eclipse Plugin.

With all the above being said, I use sbt because Indrajit is always there to help me.

--

Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

[Andreas Joseph Krogh]

On 06/09/2012 04:18 PM, David Pollak wrote:
> Personally, I think sbt is a piece of crap. It's half-baked. It sits
> on Ivy for dependency resolution. It doen't deal well with locally
> compiled assets (I have to blow away my .ivy2 directory every few
> days.) sbt sucks for identifying tests that have failed. sbt doesn't
> understand dependencies and doesn't treat them correctly (this is
> important for multi-module projects.)
>
> Maven is rock solid, well maintained, and has a lot of tools. It's
> very well integrated with testing tools and produces excellent
> actionable items on test failure.
>
> With all that being said, sbt is better integrated with Scala-land.
> It does much better incremental compilation (maven recompiles the
> whole source tree each time). sbt is better integrated with the Scala
> Eclipse Plugin.
>
> With all the above being said, I use sbt because Indrajit is always
> there to help me.

Just thought I'd add to this that Typesafe are focusing on enhancing the
maven-scala-plugin to make it more "incremental compilation"-friendly.
So I think there is a future for Maven-based scala-projects.

--
Andreas Joseph Krogh<and...@officenet.no> - mob: +47 909 56 963
Senior Software Developer / CEO - OfficeNet AS - http://www.officenet.no
Public key: http://home.officenet.no/~andreak/public_key.asc

[Naftoli Gugenheim]

On Sun, Jun 10, 2012 at 6:52 AM, Andreas Joseph Krogh <and...@officenet.no> wrote:

 sbt doesn't understand dependencies and doesn't treat them correctly (this is important for multi-module projects.)

Could you elaborate on that one?

Thanks.

[Andreas Joseph Krogh]

These were @dpp's words, you're wrongly quoting my message.

[Naftoli Gugenheim]

Oops, I didn't realize it put the quote next to your name, sorry. (I used the Gmail feature where you select text and then press Reply, and it only quotes the selected text in the new message. I must have accidentally selected the text in your reply to DPP, somehow, and not paid attention to how it came out.)

[Andreas Joseph Krogh]

On 06/12/2012 01:18 AM, Naftoli Gugenheim wrote:
> Oops, I didn't realize it put the quote next to your name, sorry. (I
> used the Gmail feature where you select text and then press Reply, and
> it only quotes the selected text in the new message. I must have
> accidentally selected the text in your reply to DPP, somehow, and not
> paid attention to how it came out.)

No worries:)