Hmm, what license to use?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
97 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

Don Stewart-2
brianchina60221:

> On Tue, Sep 30, 2008 at 8:54 PM, Stefan Monnier
> <[hidden email]> wrote:
> >> That still leaves anyone free to use LGPL if they want to, but please
> >> don't assume that it allows commercial use by all potential users.
> >
> > It *does* allow commercial use.  Your example just shows that some
> > people may decide not to take advantage of it, based not on problematic
> > restrictions but just on paranoia.
>
> I was confused and worried about this subject lately, too; at some
> point in the future, I may want to ship closed-source commercial
> software that uses various LGPL libraries. But it doesn't seem to be
> as big a problem as I imagined. My understanding is that I can satisfy
> the requirements of the LGPL by dynamically linking, and that's
> already happening. Is there something else to worry about? I'd be in
> violation if I shipped something statically linked, but cabal doesn't
> seem inclined to do that by default.

And, importantly, the vast, vast majority of Haskell code is BSD
licensed, and the licenses are prominently displayed.

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

Magnus Therning
In reply to this post by brian-245
On Wed, Oct 1, 2008 at 3:31 AM, brian <[hidden email]> wrote:
[..]
> as big a problem as I imagined. My understanding is that I can satisfy
> the requirements of the LGPL by dynamically linking, and that's
> already happening. Is there something else to worry about? I'd be in
> violation if I shipped something statically linked, but cabal doesn't
> seem inclined to do that by default.

I'm not sure I understand you here.  Would you clarify your words
here, bearing in mind that GHC doesn't do dynamic linking of Haskell
modules?

Cheers,
M

--
Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
magnus@therning.org          Jabber: magnus@therning.org
http://therning.org/magnus         identi.ca|twitter: magthe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hmm, what license to use?

Simon Marlow-5
In reply to this post by brian-245
brian wrote:

> On Tue, Sep 30, 2008 at 8:54 PM, Stefan Monnier
> <[hidden email]> wrote:
>>> That still leaves anyone free to use LGPL if they want to, but please
>>> don't assume that it allows commercial use by all potential users.
>> It *does* allow commercial use.  Your example just shows that some
>> people may decide not to take advantage of it, based not on problematic
>> restrictions but just on paranoia.
>
> I was confused and worried about this subject lately, too; at some
> point in the future, I may want to ship closed-source commercial
> software that uses various LGPL libraries. But it doesn't seem to be
> as big a problem as I imagined. My understanding is that I can satisfy
> the requirements of the LGPL by dynamically linking, and that's
> already happening.

Dynamic linking doesn't solve all the problems, we still have the
problem that GHC does a lot of cross-module inlining, regardless of
whether dynamic linking is used.  However, I really would like to have a
way to have complete control over what is exposed across a package
boundary.  We need this not just for licensing reasons, but also for
making a dynamic library with a fixed ABI, so it can be upgraded later.

Incedentally the lack of this feature is one reason I've not being
rushing to get shared libraries into GHC.  They're just not that useful
unless you can upgrade a library independently of the things it depends on.

Cheers,
        Simon

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

Don Stewart-2
In reply to this post by Magnus Therning
magnus:

> On Wed, Oct 1, 2008 at 3:31 AM, brian <[hidden email]> wrote:
> [..]
> > as big a problem as I imagined. My understanding is that I can satisfy
> > the requirements of the LGPL by dynamically linking, and that's
> > already happening. Is there something else to worry about? I'd be in
> > violation if I shipped something statically linked, but cabal doesn't
> > seem inclined to do that by default.
>
> I'm not sure I understand you here.  Would you clarify your words
> here, bearing in mind that GHC doesn't do dynamic linking of Haskell
> modules?

Yes, its very simple:

    * C libraries are classically dynamically linked, so you're in
      compliance there with any LGPL C lib you use. (under the usual
      interpretation of the LGPL)

    * Haskell libraries are always statically linked and agressively
      inlined, so opinion seems to be that LGPL licensed *Haskell
      libaries* are unsuitable for any projects you want to ship
      commercially, without source code.

    * Only a small percent of Haskell libarires are LGPL, and nothing
      for which we don't have workarounds (e.g. HDBC vs galois-sqlite3
      vs takusen).

    * None of the core system or Haskell platform are LGPLd, they're all
      "BSD3"

    * "BSD3" style reminds the vast majority, and preferred license, for
      Haskell code.

IANAL.

-- Don "ship some Haskell today" Stewart
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

Malcolm Wallace
Just a small nuance to what Don wrote:

>    * Haskell libraries are always statically linked and agressively
>      inlined,

But only for GHC (and jhc?).

>              so opinion seems to be that LGPL licensed *Haskell
>      libaries* are unsuitable for any projects you want to ship
>      commercially, without source code.

Unless you use a different compiler.

Regards,
     Malcolm "keeping the dream of multiple implementations alive"  
Wallace

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hmm, what license to use?

Gour-3
In reply to this post by Don Stewart-2
>>>>> "Don" == Don Stewart <[hidden email]> writes:

Don>     * Only a small percent of Haskell libarires are LGPL, and
Don> nothing for which we don't have workarounds (e.g. HDBC vs
Don> galois-sqlite3 vs takusen).

Hmm, Gtk2Hs & wxhaskell - major GUI libs...


Sincerely,
Gour

--

Gour  | Zagreb, Croatia  | GPG key: C6E7162D
----------------------------------------------------------------

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

attachment0 (202 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

Don Stewart-2
In reply to this post by Malcolm Wallace
malcolm.wallace:

> Just a small nuance to what Don wrote:
>
> >   * Haskell libraries are always statically linked and agressively
> >     inlined,
>
> But only for GHC (and jhc?).
>
> >             so opinion seems to be that LGPL licensed *Haskell
> >     libaries* are unsuitable for any projects you want to ship
> >     commercially, without source code.
>
> Unless you use a different compiler.
>
>     Malcolm "keeping the dream of multiple implementations alive"  

And keep dividing our compiler teams' efforts, while
single-implementation languages conquer :)

    Don "thinking that compiler developer fragmentation doesn't help now the language research is 'done'"
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

Tom Schrijvers-2
>    Don "thinking that compiler developer fragmentation doesn't help now the language research is 'done'"

Language researchers should move to a new language?

Tom

--
Tom Schrijvers

Department of Computer Science
K.U. Leuven
Celestijnenlaan 200A
B-3001 Heverlee
Belgium

tel: +32 16 327544
e-mail: [hidden email]
url: http://www.cs.kuleuven.be/~toms/
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

Philippa Cowderoy
In reply to this post by Don Stewart-2
On Wed, 1 Oct 2008, Don Stewart wrote:

> malcolm.wallace:
> > Just a small nuance to what Don wrote:
> > >             so opinion seems to be that LGPL licensed *Haskell
> > >     libaries* are unsuitable for any projects you want to ship
> > >     commercially, without source code.
> >
> > Unless you use a different compiler.
> >
> >     Malcolm "keeping the dream of multiple implementations alive"  
>
> And keep dividing our compiler teams' efforts, while
> single-implementation languages conquer :)
>
>     Don "thinking that compiler developer fragmentation doesn't help now
> the language research is 'done'"
>

I'm not at all sure I agree with you there. That said, licensing's a
particularly poor reason for a separate implementation.

--
[hidden email]

'In Ankh-Morpork even the shit have a street to itself...
 Truly this is a land of opportunity.' - Detritus, Men at Arms
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Re: Hmm, what license to use?

Simon Peyton Jones
In reply to this post by Don Stewart-2
| > Unless you use a different compiler.
| >
| >     Malcolm "keeping the dream of multiple implementations alive"
|
| And keep dividing our compiler teams' efforts, while
| single-implementation languages conquer :)
|
|     Don "thinking that compiler developer fragmentation doesn't help now the language research
| is 'done'"

Don, I usually agree with almost everything you say -- but not this!  I think diversity in compilers is good.  They tend to focus on different aspects (e.g. one might be small and accessible while another is more fully-featured but harder to modify), they keep each other on their toes, they serve as vehicles to explore different parts of the design space (eg jhc's implementation model is very different to ghc's).

Furthermore, language research in Haskell is *far* from done.  I regard GHC as a research platform, not as a product.  These goals are in tension but not in conflict -- GHC's usefulness as a research platform is derived in large part from the fact that it is so widely used, which in turn is because it is a decent product.

Yes, splitting effort has costs, and those costs are particularly apparent to you because of your fantastic work on libraries, packaging, and distribution.   But diversity also has benefits that I would hate to lose.  Much as I love GHC, my first baby, I'm glad GHC has siblings.

Simon
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

Don Stewart-2
simonpj:

> | > Unless you use a different compiler.
> | >
> | >     Malcolm "keeping the dream of multiple implementations alive"
> |
> | And keep dividing our compiler teams' efforts, while
> | single-implementation languages conquer :)
> |
> |     Don "thinking that compiler developer fragmentation doesn't help now the language research
> | is 'done'"
>
> Don, I usually agree with almost everything you say -- but not this!
> I think diversity in compilers is good.  They tend to focus on
> different aspects (e.g. one might be small and accessible while
> another is more fully-featured but harder to modify), they keep each
> other on their toes, they serve as vehicles to explore different parts
> of the design space (eg jhc's implementation model is very different
> to ghc's).
>
> Furthermore, language research in Haskell is *far* from done.  I
> regard GHC as a research platform, not as a product.  These goals are
> in tension but not in conflict -- GHC's usefulness as a research
> platform is derived in large part from the fact that it is so widely
> used, which in turn is because it is a decent product.
>
> Yes, splitting effort has costs, and those costs are particularly
> apparent to you because of your fantastic work on libraries,
> packaging, and distribution.   But diversity also has benefits that I
> would hate to lose.  Much as I love GHC, my first baby, I'm glad GHC
> has siblings.

Yes, I shouldn't tease. We need continued sources of new ideas to keep
things moving, since (going back to Malcolm's point) we see that some
implementations solve particular problems in easier ways than others.

My point was really that investing the effort required to get nhc98 into
the shape that we could actually use it to ship the kind of code that we
do with GHC -- to make nhc98 a GHC competitor product -- would not be as
an efficient use of our researchers and engineers.

That effort is better spent either working on GHC, or generating new
ideas in areas not directly competing with GHC (like YHC's javascript
backend, Hugs on the iphone, or nhc98's bytecode compression).

So keep the ideas coming!

-- Don


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: Re: Hmm, what license to use?

Bulat Ziganshin-2
Hello Don,

Thursday, October 2, 2008, 12:07:47 PM, you wrote:

>> Don, I usually agree with almost everything you say -- but not this!

and i usually answer only in those few cases when i disagree ;)

> My point was really that investing the effort required to get nhc98 into
> the shape that we could actually use it to ship the kind of code that we
> do with GHC -- to make nhc98 a GHC competitor product -- would not be as
> an efficient use of our researchers and engineers.

imho it's true for short-term, false for a longer terms. we need
different haskell platforms, otherwise haskell will eventually die,
and core libraries such as FPS are essential part of these platforms

and according to my experience, writing s/w in portable way is easy if
you care about it from the beginning of project. adding portability
later costs much more


--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

Jeremy O'Donoghue
In reply to this post by Stefan Monnier

On Tue, 30 Sep 2008 21:54:34 -0400, "Stefan Monnier"
<[hidden email]> said:

> > I am not allowed to use such an interpretation. The (expensive and very
> > carefully researched) legal advice used to shape the use of Open Source
> > code at my employer has resulted in a "no LGPL under any circumstances
> > whatsoever" policy.
> [...]
> > That still leaves anyone free to use LGPL if they want to, but please
> > don't assume that it allows commercial use by all potential users.
>
> It *does* allow commercial use.  Your example just shows that some
> people may decide not to take advantage of it, based not on problematic
> restrictions but just on paranoia.

The LGPL does not state that a "work that uses the library" may be
distributed
in conjunction with a closed source commercial program, although I grant
that
many (presumably including some who have actually consulted lawyers)
believe
that such an interpretation is reasonable.

However, the policy in place in my workplace was designed by lawyers
familiar
with contract law in multiple jurisdictions worldwide. I may not
personally
agree with their conclusions in every respect, but I'd be hard pressed
to
consider them "paranoid" - they are simply doing their job, and have
concluded
that the potential risk of a court somewhere in the World taking an
aggressive
view of the provisions of clause 5 is unacceptable.

I guess what I really mean is that if you choose LGPL as a license, some
people
who would like to use it in commercial products will do so, but others
(who would
have chosen to use the work if differently licensed) will not. Not a
question of
paranoia so much as corporate appetite for license risk.

Regards
Jeremy
--
  Jeremy O'Donoghue
  [hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

Darrin Thompson
In reply to this post by Don Stewart-2
On Wed, Oct 1, 2008 at 4:00 PM, Don Stewart <[hidden email]> wrote:
And keep dividing our compiler teams' efforts, while
single-implementation languages conquer :)


Seems like Haskell has a pretty clear story about which is the right implementation for general purpose use. I don't see a Scheme problem here.

--
Darrin


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

David Leimbach
In reply to this post by Jeremy O'Donoghue


On Thu, Oct 2, 2008 at 3:12 AM, Jeremy O'Donoghue <[hidden email]> wrote:

On Tue, 30 Sep 2008 21:54:34 -0400, "Stefan Monnier"
<[hidden email]> said:
> > I am not allowed to use such an interpretation. The (expensive and very
> > carefully researched) legal advice used to shape the use of Open Source
> > code at my employer has resulted in a "no LGPL under any circumstances
> > whatsoever" policy.
> [...]
> > That still leaves anyone free to use LGPL if they want to, but please
> > don't assume that it allows commercial use by all potential users.
>
> It *does* allow commercial use.  Your example just shows that some
> people may decide not to take advantage of it, based not on problematic
> restrictions but just on paranoia.

The LGPL does not state that a "work that uses the library" may be
distributed
in conjunction with a closed source commercial program, although I grant
that
many (presumably including some who have actually consulted lawyers)
believe
that such an interpretation is reasonable.

I believe the LGPL states that mere aggregation doesn't indicate derivative works.  In fact commercial video games have been distributed for linux that used the SDL library that I used to work with myself in a former life.

So I think we should all speak to our lawyers before assuming how it can be used.  The GPL and LGPL are needlessly difficult for mere mortals to understand in their entirety, and as you've alluded to, many lawyers would interpret it differently.  I suspect many different judges would too.

 


However, the policy in place in my workplace was designed by lawyers
familiar
with contract law in multiple jurisdictions worldwide. I may not
personally
agree with their conclusions in every respect, but I'd be hard pressed
to
consider them "paranoid" - they are simply doing their job, and have
concluded
that the potential risk of a court somewhere in the World taking an
aggressive
view of the provisions of clause 5 is unacceptable.

I guess what I really mean is that if you choose LGPL as a license, some
people
who would like to use it in commercial products will do so, but others
(who would
have chosen to use the work if differently licensed) will not. Not a
question of
paranoia so much as corporate appetite for license risk.

Yes, there's enough anti-GPL or GPL derived momentum in many places that I must say that using the LGPL or GPL would be highly frowned upon at my workplace as well. 

That said, I'm a huge fan of apache, BSD, MIT and Perl's licenses :-)
 


Regards
Jeremy
--
 Jeremy O'Donoghue
 [hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

David Leimbach
In reply to this post by Darrin Thompson


2008/10/2 Darrin Thompson <[hidden email]>
On Wed, Oct 1, 2008 at 4:00 PM, Don Stewart <[hidden email]> wrote:
And keep dividing our compiler teams' efforts, while
single-implementation languages conquer :)


Seems like Haskell has a pretty clear story about which is the right implementation for general purpose use. I don't see a Scheme problem here.

Just make Haskell more difficult to implement than Scheme and you've preemptively avoided that problem :-)
 


--
Darrin


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

Malcolm Wallace
In reply to this post by David Leimbach
>               The GPL and LGPL are needlessly difficult for mere
> mortals to understand in their entirety, and as you've alluded to,
> many lawyers would interpret it differently.  I suspect many different
> judges would too.

I think the evidence is rather to the contrary.  Most lawsuits involving
the GPL are settled out of court, precisely because the lawyers for the
violating party tend to realise they have no leg to stand on.  Of those
few cases which have made it to court, the judge has always decided in
favour of the GPL.  That is, the GPL is as solid a guarantee of code
freedom as you could wish for.

The lesson, from the point of view of an entity that wants to distribute
non-free code but making use of some free code, is simply to play nicely
with the community whose work you are using gratis.  Keeping to the
original authors' intent is ultimately cheaper than either writing your
own replacement code, or paying lawyers to fight it out.

In addition, if you want legal certainty , most GPL authors would
probably be happy to assign you a separate non-exclusive commercial
license, in return for a small payment or royalty agreement.

Regards,
    Malcolm
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hmm, what license to use?

Wolfgang Jeltsch-2
In reply to this post by Duncan Coutts
Am Dienstag, 30. September 2008 00:18 schrieb Duncan Coutts:
> Yet another reason for getting dynamic linking / shared libs for Haskell
> packages working reliably on all platforms.

You mean shared libraries without the opportunity to inline library code?  
This would result in a huge performance loss, I think.

Best wishes,
Wolfgang
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Hmm, what license to use?

Micah Cowan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wolfgang Jeltsch wrote:
> Am Dienstag, 30. September 2008 00:18 schrieb Duncan Coutts:
>> Yet another reason for getting dynamic linking / shared libs for Haskell
>> packages working reliably on all platforms.
>
> You mean shared libraries without the opportunity to inline library code?  
> This would result in a huge performance loss, I think.

Usually _mild_ performance loss, in exchange for major code-size
savings, I would think. C obviously has worked quite fine under exactly
this restraint (though C implementations obviously aren't built to take
as great advantage of inlining library code as Haskell may be).

Just because there's an important loss in value, doesn't mean there's
not a significant net gain for some needs. Dynamically linked libs in
Haskell have obvious benefits, as well as obvious drawbacks.

- --
But hey, YMMV. Just my opinion.
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
GNU Maintainer: wget, screen, teseq
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI5RP37M8hyUobTrERAgn3AJ9JfWDY269PiRyh2hei1uH6W+dJ2wCfY/YG
ztVcGYvH1+pQqG/fryr+YPw=
=ekJT
-----END PGP SIGNATURE-----
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Hmm, what license to use?

Magnus Therning
In reply to this post by Simon Marlow-5
On Wed, Oct 1, 2008 at 6:03 PM, Simon Marlow <[hidden email]> wrote:
[..]
> Dynamic linking doesn't solve all the problems, we still have the problem
> that GHC does a lot of cross-module inlining, regardless of whether dynamic
> linking is used.  However, I really would like to have a way to have
> complete control over what is exposed across a package boundary.  We need
> this not just for licensing reasons, but also for making a dynamic library
> with a fixed ABI, so it can be upgraded later.

I have a really hard time following this.  Are you seriously saying
that GHC is inlining code from modules _and_ link dynamically at the
same time.  That seems like a remarkably strange thing to do, or maybe
I'm just missing something.

My understanding from another thread on here was that dynamic linking
isn't working reliably, not even on Windows, where it once was
supported.  It has never worked on any other platform.  Am I wrong
about this?  IIRC I've never seen GHC produce anything that's
dynamically linked to _any_haskell module, and all modules I compile
are always packaged up in .hi and .a files.  Not a .so or .dll as far
I can see.

/M

--
Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
magnus@therning.org          Jabber: magnus@therning.org
http://therning.org/magnus         identi.ca|twitter: magthe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12345