liblo-devel Mailing List for LibLO

> However, our corporate lawyers have signed off on us both using, and in fact distributing code under the GPL (v3). In absolute terms it was quite expensive to get their software licensing experts legal opinion, but a small fraction of our annual legal costs. We could have got indemnity insurance even without expert legal opinion however

Can't wait to buy a policy of my own so that I can start using "free software".


> As you correctly identified, it's 90% an ideological difference. Liblo authors are not going to change their ideology over what we know to be irrelevant, groundless hypothetical concerns — and you're not going to change your's over what you presumably see as a bunch of misguided licensing zealots.


Actually my concerns are in a sense irrelevant and hypothetical, because the GPL is practically speaking unenforceable on a work without significant value, because civil damages are limited to fair economic compensation.  But I'm sure that wouldn't stop FSF from trying, as they designed GPL to keep themselves in business, and lawyers don't need to win to stay in business.

Unless you are talking about a major work like the Linux kernel, the entire debate of GPL vs BSD vs whatever is simply void of substance; the only consequence in the flesh-and-blood part of the universe is the feeding and care of lawyers in the name of an idea, and of course the general discouragement of potential users as well.  I actually have no objection to the idea, nor to the feeding and care of lawyers.  The only thing I am interested in promoting is use of OSC.

---

Andy W. Schmeder
email: andy [at] cnmat.berkeley.edu

On 2011-02-23, at 00:13, Andy W. Schmeder wrote:

> On Feb 18, 2011, at 11:25 AM, Charlie Roberts wrote:
> 
>> It's not your problem, and the CNMAT emails seemed a little aggressive to say the least.
> 
> I agree some language in that first message from Adrian may have seemed that way but it wasn't the intention (I can say so because I was in such discussions at the outset).
> 
> The situation we are presently considering at CNMAT is that the (rather old) CNMAT OSCKit is out of date and no longer maintained, we have newer code, used internally and not otherwise distributed, but the long term maintenance of said code may eventually present some issues for us because we have limited resources, so it is in our general interest to look into one or more open source projects (community managed) that we can contribute that code into, to extend its useful life.  Furthermore we are interested in pure C implementations since we need to support embedded targets also (which curiously is now being done through a fork of liblo, which I find to be a bit scary, this should just be a compile-time switch).
> 
> Unfortunately to contribute our code into any other repository we need those projects to use a BSD style license.  Its not just "our sponsors" (some of whom are generous companies and others whom are the taxpaying citizens), but this is firstly a long standing tradition of the university going all the way back to early days of unix, and furthermore its a basic requirement of essentially all open standards (for example look at Zeroconf, or any reference implementation produced by an IEEE/IETF working group).  Such implementations must be compatible with the needs of commercial software which means 1) no patent obligations, 2) no contractual obligations.  There just isn't much value otherwise since protocols are only useful insofar as they are actually used, and any barriers, especially legal ones, are basically cost prohibitive of use (if you don't believe me ask your lawyer to have a look over the LGPL and give an opinion...  a single lawsuit can easily kill a small company or startup). The GPL and/or LGPL is a license with a contractual obligation so its simply out of the question.

I'm sorry, but I have to respectfully disagree.

My day job is as the CTO of a Financial Services company, we do data analysis over fraud, stolen identities, and financial crime data, so we're bound up with more regulation, due diligence requirements, and legislative red tape than you can even imagine.

However, our corporate lawyers have signed off on us both using, and in fact distributing code under the GPL (v3). In absolute terms it was quite expensive to get their software licensing experts legal opinion, but a small fraction of our annual legal costs. We could have got indemnity insurance even without expert legal opinion however.

> To be perfectly frank, even if liblo had a BSD license, there isn't a company out there that will take the code, make a bunch of improvements without contributing said improvements back, and then make a bunch of money off that.  A niche like OSC parsing is simply not a significant market, its not complex enough that any such improvements would provide any significant advantage, and its not lucrative enough to outweigh the (significant) cost of internally maintaining any such improvement versus the potential value lost by contributing a patch to a public repository. Even *if* some closed source software required a change to liblo, it would probably be a hack of some nature to fix some weird problem, and generally inconsequential to the rest of the world.  Maybe that LGPL helps you all sleep at night or something but from what I can see its just a philosophical baggage (actually, worse, its legal baggage).

They won't make a bunch of money, because there isn't a bunch of money to be made.

As you correctly identified, it's 90% an ideological difference. Liblo authors are not going to change their ideology over what we know to be irrelevant, groundless hypothetical concerns — and you're not going to change your's over what you presumably see as a bunch of misguided licensing zealots.

- Steve

On Feb 22, 2011, at 9:17 PM, Tristan Matthews wrote:

> Just out of curiosity, is this an official policy of the school that is documented somewhere? It would be shame if a publicly funded university such as UCB imposed anti-GPL/LGPL restrictions like this.

No.


> Plenty of people use liblo and countless other GPL and LGPL projects. I'm typing this email via firefox, a very "useful" and "actually used" piece of free software! In any case, since I'm under the impression this is an IOS/App store-motivated debate (correct me if I'm wrong), would it not be more productive to pressure Apple to change its terms of service to be LGPL-compliant? Barring that, one can always choose to work with platforms that don't force such compromise.

Others have expressed that here, but I have no particular interest in using liblo on iOS.  In fact I have no particular need for using liblo at at all right now, although I have done so in the past.  


> To be perfectly frank, even if liblo had a BSD license, there isn't a company out there that will take the code, make a bunch of improvements without contributing said improvements back, and then make a bunch of money off that.

> That's not the issue. There is nothing in the GPL or LGPL that says that you can't "make a bunch of money off" your modifications. Free software licenses are about protecting the freedoms of developers and users.

It is the issue (essentially, economic fairness) for some, previously stated by others in this thread.


> I'm afraid that I don't see a license that protects my rights as "legal baggage."

The GPL license is a contract that is leveraged on the basis of copyright.  The contractual terms of the GPL are designed to promote a certain social behavior.

The right to freedom of information is actually more fundamental than copyright, which is why copyright (and patent) terms are finite.  Once the work is public domain the GPL is irrelevant,   If its freedom of information that is desired, that can be had in its purist form by waiving copyright entirely and permanently.  If one believes that promoting said social behavior is important, then use the GPL because that is what it aims to promote.

Contracts cannot provide nor protect rights, only the state can do that.  Contracts may negotiate them through waivers.  The GPL is a conditional waiver on copyright, provided that the receivers of copies comply with certain actions in certain situations, and the recourse for violating those constraints is a civil lawsuit.

Its the last part of that statement that makes some a bit wary, at least in nation states such as the USA, where it is good idea to adopt a strict policy of not getting sued because legal defense is very expensive.


---

Andy W. Schmeder
email: andy [at] cnmat.berkeley.edu
skype: andy.schmeder

Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu

2011/2/22 Andy W. Schmeder <an...@cn...>

> On Feb 18, 2011, at 11:25 AM, Charlie Roberts wrote:
>
> > It's not your problem, and the CNMAT emails seemed a little aggressive to
> say the least.
>
> I agree some language in that first message from Adrian may have seemed
> that way but it wasn't the intention (I can say so because I was in such
> discussions at the outset).
>
> The situation we are presently considering at CNMAT is that the (rather
> old) CNMAT OSCKit is out of date and no longer maintained, we have newer
> code, used internally and not otherwise distributed, but the long term
> maintenance of said code may eventually present some issues for us because
> we have limited resources, so it is in our general interest to look into one
> or more open source projects (community managed) that we can contribute that
> code into, to extend its useful life.  Furthermore we are interested in pure
> C implementations since we need to support embedded targets also (which
> curiously is now being done through a fork of liblo, which I find to be a
> bit scary, this should just be a compile-time switch).
>
> Unfortunately to contribute our code into any other repository we need
> those projects to use a BSD style license.  Its not just "our sponsors"
> (some of whom are generous companies and others whom are the taxpaying
> citizens), but this is firstly a long standing tradition of the university
> going all the way back to early days of unix, and furthermore its a basic
> requirement of essentially all open standards (for example look at Zeroconf,
> or any reference implementation produced by an IEEE/IETF working group).
>  Such implementations must be compatible with the needs of commercial
> software which means 1) no patent obligations, 2) no contractual
> obligations.


Just out of curiosity, is this an official policy of the school that is
documented somewhere? It would be shame if a publicly funded university such
as UCB imposed anti-GPL/LGPL restrictions like this.

 There just isn't much value otherwise since protocols are only useful
> insofar as they are actually used, and any barriers, especially legal ones,
> are basically cost prohibitive of use (if you don't believe me ask your
> lawyer to have a look over the LGPL and give an opinion...  a single lawsuit
> can easily kill a small company or startup). The GPL and/or LGPL is a
> license with a contractual obligation so its simply out of the question.
>

Plenty of people use liblo and countless other GPL and LGPL projects. I'm
typing this email via firefox, a very "useful" and "actually used" piece of
free software! In any case, since I'm under the impression this is an
IOS/App store-motivated debate (correct me if I'm wrong), would it not be
more productive to pressure Apple to change its terms of service to be
LGPL-compliant? Barring that, one can always choose to work with platforms
that don't force such compromise.


> To be perfectly frank, even if liblo had a BSD license, there isn't a
> company out there that will take the code, make a bunch of improvements
> without contributing said improvements back, and then make a bunch of money
> off that.


That's not the issue. There is nothing in the GPL or LGPL that says that you
can't "make a bunch of money off" your modifications. Free software licenses
are about protecting the freedoms of developers and users.


>  A niche like OSC parsing is simply not a significant market, its not
> complex enough that any such improvements would provide any significant
> advantage, and its not lucrative enough to outweigh the (significant) cost
> of internally maintaining any such improvement versus the potential value
> lost by contributing a patch to a public repository. Even *if* some closed
> source software required a change to liblo, it would probably be a hack of
> some nature to fix some weird problem, and generally inconsequential to the
> rest of the world.  Maybe that LGPL helps you all sleep at night or
> something but from what I can see its just a philosophical baggage
> (actually, worse, its legal baggage).
>

I'm afraid that I don't see a license that protects my rights as "legal
baggage."

Thanks to all the liblo-devs for making a great library, sorry to jump on
this issue but it's been coming up a lot lately in other projects so I felt
that I should say something.

Best,
Tristan

Thats all---thanks for listening.
>
>
>
> > That said, it might become a problem for you if you want to perform an
> audience interaction composition or create a piece of installation art that
> takes advantage of as many mobile device platforms as possible (there's WAY
> too much confusion about GPL / LGPL licensing on the app store for me to
> feel comfortable using GPL). And it might be -nice- to support open source
> music / art software on mobile devices.
> >
>
> ---
>
> Andy W. Schmeder
> email: andy [at] cnmat.berkeley.edu
> Programmer/Analyst II
> Research Group
> Center for New Music and Audio Technologies
> University of California at Berkeley
> http://cnmat.berkeley.edu
>
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT
> data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>



-- 
Tristan Matthews
email: tr...@sa...
web: http://tristanswork.blogspot.com

On Feb 18, 2011, at 11:25 AM, Charlie Roberts wrote:

> It's not your problem, and the CNMAT emails seemed a little aggressive to say the least.

I agree some language in that first message from Adrian may have seemed that way but it wasn't the intention (I can say so because I was in such discussions at the outset).

The situation we are presently considering at CNMAT is that the (rather old) CNMAT OSCKit is out of date and no longer maintained, we have newer code, used internally and not otherwise distributed, but the long term maintenance of said code may eventually present some issues for us because we have limited resources, so it is in our general interest to look into one or more open source projects (community managed) that we can contribute that code into, to extend its useful life.  Furthermore we are interested in pure C implementations since we need to support embedded targets also (which curiously is now being done through a fork of liblo, which I find to be a bit scary, this should just be a compile-time switch).

Unfortunately to contribute our code into any other repository we need those projects to use a BSD style license.  Its not just "our sponsors" (some of whom are generous companies and others whom are the taxpaying citizens), but this is firstly a long standing tradition of the university going all the way back to early days of unix, and furthermore its a basic requirement of essentially all open standards (for example look at Zeroconf, or any reference implementation produced by an IEEE/IETF working group).  Such implementations must be compatible with the needs of commercial software which means 1) no patent obligations, 2) no contractual obligations.  There just isn't much value otherwise since protocols are only useful insofar as they are actually used, and any barriers, especially legal ones, are basically cost prohibitive of use (if you don't believe me ask your lawyer to have a look over the LGPL and give an opinion...  a single lawsuit can easily kill a small company or startup). The GPL and/or LGPL is a license with a contractual obligation so its simply out of the question.

To be perfectly frank, even if liblo had a BSD license, there isn't a company out there that will take the code, make a bunch of improvements without contributing said improvements back, and then make a bunch of money off that.  A niche like OSC parsing is simply not a significant market, its not complex enough that any such improvements would provide any significant advantage, and its not lucrative enough to outweigh the (significant) cost of internally maintaining any such improvement versus the potential value lost by contributing a patch to a public repository. Even *if* some closed source software required a change to liblo, it would probably be a hack of some nature to fix some weird problem, and generally inconsequential to the rest of the world.  Maybe that LGPL helps you all sleep at night or something but from what I can see its just a philosophical baggage (actually, worse, its legal baggage).

That said we at CNMAT have no serious interest in whatever license liblo chooses to use--its your choice, but if there was any possibility of changing it to BSD style then we might become interested.  In addition, in my opinion it would be a benefit to the goals of liblo for its own sake.

Thats all---thanks for listening.



> That said, it might become a problem for you if you want to perform an audience interaction composition or create a piece of installation art that takes advantage of as many mobile device platforms as possible (there's WAY too much confusion about GPL / LGPL licensing on the app store for me to feel comfortable using GPL). And it might be -nice- to support open source music / art software on mobile devices.
> 

---

Andy W. Schmeder
email: andy [at] cnmat.berkeley.edu
Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu

It's not your problem, and the CNMAT emails seemed a little aggressive to
say the least.

That said, it might become a problem for you if you want to perform an
audience interaction composition or create a piece of installation art that
takes advantage of as many mobile device platforms as possible (there's WAY
too much confusion about GPL / LGPL licensing on the app store for me to
feel comfortable using GPL). And it might be -nice- to support open source
music / art software on mobile devices.

Since someone else posted their project, here's mine, unfortunately with all
of its liblo goodness gutted and replaced by oscpack...

http://createdigitalmusic.com/2011/01/music-control-meets-web-code-goodness-app-for-ios-soon-oscmidi-everywhere/#more-16101

- Charlie

PS - I really don't have a problem with liblo being LGPL although its of
course inconvenient. But to me it's not as black and white as some of the
emails in this thread make it out to be (just GPL it, just use another
library etc. etc.). To others it is that black and white and that's fine.

On Fri, Feb 18, 2011 at 9:28 AM, Steve Harris <S.W...@ec...>wrote:

> On 2011-02-18, at 15:35, Stephen Sinclair wrote:
> >
> > If people have a harder time using other solutions, it's not really
> > our problem.  The OSC spec is extremely well documented, so I don't
> > see why anyone would depend so heavily on a single implementation.  If
> > they like liblo enough, perhaps they should consider using the GPL for
> > their product.  That's the whole idea of having a healthy free
> > software ecosystem.
>
> Wholeheartedly agree.
>
> - Steve
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

On 2011-02-18, at 15:35, Stephen Sinclair wrote:
> 
> If people have a harder time using other solutions, it's not really
> our problem.  The OSC spec is extremely well documented, so I don't
> see why anyone would depend so heavily on a single implementation.  If
> they like liblo enough, perhaps they should consider using the GPL for
> their product.  That's the whole idea of having a healthy free
> software ecosystem.

Wholeheartedly agree.

- Steve

Glad to be getting some more feedback on this topic, thanks..

On Fri, Feb 18, 2011 at 9:00 AM, Sebastien Bourdeauducq
<seb...@mi...> wrote:
> On Fri, 2011-02-18 at 13:42 +0000, Nicholas J Humfrey wrote:
>> Generally I don't mind if liblo is used in closed-source projects as
>> long as any changes or improvements to liblo are contributed back to
>> the project. Is there a suggested a license that achieves that?
>
> LGPL does.
>
> That being said, I wouldn't mind if liblo was GPL.

It was previously.  That's the thing.. switching to LGPL actually was
the _compromise_ for us, because we were receiving many requests to
use liblo in commercial products.  I know that LGPL is not exactly
encouraged by the FSF, but it was the closest thing I could find to a
license that enforces GPL-style values (i.e. remains modifiable by the
user, requires changes be contributed back) but allows usage in
closed-source applications.

I know that the liblo community considers software freedom important;
in matters like these, it's good to remember that it is indeed more
important than getting more users at any cost---besides, it's not like
there aren't other options for sending and receiving OSC.  I'd rather
not see modified versions of liblo out there where I don't know what
changes have been made.

If people have a harder time using other solutions, it's not really
our problem.  The OSC spec is extremely well documented, so I don't
see why anyone would depend so heavily on a single implementation.  If
they like liblo enough, perhaps they should consider using the GPL for
their product.  That's the whole idea of having a healthy free
software ecosystem.

Well, that's how I see it anyways.

> I have personally
> taken the GPL principles to the next level and I'm building a single
> board computer for video synthesis that is totally open source down to
> the processor hardware design. It runs liblo, with some modifications
> (strip out the auto**** "portable build system" and abstract the socket
> code that did not play well with the RTEMS network stack). See
> www.milkymist.org

That is awesome.  :)

Steve

> Generally I don't mind if liblo is used in closed-source projects as 
> long as any changes or improvements to liblo are contributed back to 
> the project. Is there a suggested a license that achieves that?
>
LGPL?

http://www.gnu.org/copyleft/lesser.html

On Fri, 2011-02-18 at 13:42 +0000, Nicholas J Humfrey wrote:
> Generally I don't mind if liblo is used in closed-source projects as
> long as any changes or improvements to liblo are contributed back to
> the project. Is there a suggested a license that achieves that?

LGPL does.

That being said, I wouldn't mind if liblo was GPL. I have personally
taken the GPL principles to the next level and I'm building a single
board computer for video synthesis that is totally open source down to
the processor hardware design. It runs liblo, with some modifications
(strip out the auto**** "portable build system" and abstract the socket
code that did not play well with the RTEMS network stack). See
www.milkymist.org

Sébastien

On 15 Feb 2011, at 22:02, Stephen Sinclair <rad...@gm...> wrote:

> On Mon, Feb 14, 2011 at 11:03 PM,  <ad...@ad...> wrote:
>> 
>> 
>>> -------- Original Message --------
>>> Subject: Re: liblo licensing
>>> From: Stephen Sinclair <rad...@gm...>
>>> Date: Mon, February 14, 2011 7:25 pm
>>> To: ad...@ad...
>>> Cc: st...@pl..., Chris Salter <chr...@al...>,
>>> Sha Wei <sha...@gm...>, David Wessel <we...@cn...>,
>>>  liblo development list <lib...@li...>
>>> 
>>> 
>>> On Mon, Feb 14, 2011 at 9:30 PM,  <ad...@ad...> wrote:
>>>> 
>>>>> I'd hardly call the LGPL restrictive, it only requires that you keep
>>>>> liblo as a dynamically linked library so that it can be switched out.
>>>>> Any application code can still be closed source.  Why is this
>>>>> problematic for commercial users?  We specifically switched from GPL
>>> 
>>>> embedded systems don't have dynamic linking.
>>> 
>>> Since liblo uses a POSIX socket API, it pretty much requires the
>>> presence of a POSIX operating system on-board.  (This may not always
>>> be the case, but it is for now.)  All POSIX or POSIX-like embedded
>>> operating systems I know of do support dynamic linking.
>>> 
>>> If liblo is good enough that commercial developers want to use it in
>>> embedded systems, I don't see why they shouldn't enable their users to
>>> modify the onboard firmware, which would comply with the LGPL.  If
>>> their goals are to stop their users from accessing the firmware at all
>>> costs, I'm afraid it may simply be an idealogical problem and we are
>>> at an impasse.
>>> 
>>> As I said, there are other OSC libraries they could use.  If they
>>> don't consider these as adequate, I don't think that is our problem.
>>> If CNMAT wants to encourage OSC adoption in commercial products, then
>>> it's their job to provide the necessary tools, not ours.
>> 
>> I don't appreciate you telling CNMAT what its job is but I will
>> interpret
>> this to mean no collaboration around liblo is possible.
> 
> That's a strange twist to my words that I don't really appreciate.
> All I said is that if CNMAT wants to encourage their partners one way
> or another then that's up to them to deal with.  I just don't see how
> it should affect an unaffiliated project.
> 
> As for collaboration, I don't see why the LGPL is a strong
> disincentive, but if you see it that way then there is not much I can
> do.


For what it is worth, as a contributor to the liblo project:

Generally I don't mind if liblo is used in closed-source projects as long as any changes or improvements to liblo are contributed back to the project. Is there a suggested a license that achieves that?

However, in terms of iPhone apps, I don't know why people don't just GPL their code, which solves the linking problem. I don't hugely like the idea of someone making money from something that I have given my time to for free.


nick.

On Tue, Feb 15, 2011 at 5:05 PM,  <ad...@ad...> wrote:
>
>> As for collaboration, I don't see why the LGPL is a strong
>> disincentive, but if you see it that way then there is not much I can
>> do.
> I know you don't. I just took a look at your developer list and
> discovered this is old news.
> We are not the only ones moving on from considering liblo so I imagine
> you wont be offended if we don't use it.
> I was just trying to avoid duplication of effort.

Not at all!  We've been happy in the past, and continue to be, to
suggest alternatives for people who prefer a different license.

Steve

On Mon, Feb 14, 2011 at 11:03 PM,  <ad...@ad...> wrote:
>
>
>> -------- Original Message --------
>> Subject: Re: liblo licensing
>> From: Stephen Sinclair <rad...@gm...>
>> Date: Mon, February 14, 2011 7:25 pm
>> To: ad...@ad...
>> Cc: st...@pl..., Chris Salter <chr...@al...>,
>> Sha Wei <sha...@gm...>, David Wessel <we...@cn...>,
>>  liblo development list <lib...@li...>
>>
>>
>> On Mon, Feb 14, 2011 at 9:30 PM,  <ad...@ad...> wrote:
>> >
>> >> I'd hardly call the LGPL restrictive, it only requires that you keep
>> >> liblo as a dynamically linked library so that it can be switched out.
>> >> Any application code can still be closed source.  Why is this
>> >> problematic for commercial users?  We specifically switched from GPL
>>
>> > embedded systems don't have dynamic linking.
>>
>> Since liblo uses a POSIX socket API, it pretty much requires the
>> presence of a POSIX operating system on-board.  (This may not always
>> be the case, but it is for now.)  All POSIX or POSIX-like embedded
>> operating systems I know of do support dynamic linking.
>>
>> If liblo is good enough that commercial developers want to use it in
>> embedded systems, I don't see why they shouldn't enable their users to
>> modify the onboard firmware, which would comply with the LGPL.  If
>> their goals are to stop their users from accessing the firmware at all
>> costs, I'm afraid it may simply be an idealogical problem and we are
>> at an impasse.
>>
>> As I said, there are other OSC libraries they could use.  If they
>> don't consider these as adequate, I don't think that is our problem.
>> If CNMAT wants to encourage OSC adoption in commercial products, then
>> it's their job to provide the necessary tools, not ours.
>
> I don't appreciate you telling CNMAT what its job is but I will
> interpret
> this to mean no collaboration around liblo is possible.

That's a strange twist to my words that I don't really appreciate.
All I said is that if CNMAT wants to encourage their partners one way
or another then that's up to them to deal with.  I just don't see how
it should affect an unaffiliated project.

As for collaboration, I don't see why the LGPL is a strong
disincentive, but if you see it that way then there is not much I can
do.

Steve

On Mon, Feb 14, 2011 at 9:30 PM,  <ad...@ad...> wrote:
>
>> I'd hardly call the LGPL restrictive, it only requires that you keep
>> liblo as a dynamically linked library so that it can be switched out.
>> Any application code can still be closed source.  Why is this
>> problematic for commercial users?  We specifically switched from GPL

> embedded systems don't have dynamic linking.

Since liblo uses a POSIX socket API, it pretty much requires the
presence of a POSIX operating system on-board.  (This may not always
be the case, but it is for now.)  All POSIX or POSIX-like embedded
operating systems I know of do support dynamic linking.

If liblo is good enough that commercial developers want to use it in
embedded systems, I don't see why they shouldn't enable their users to
modify the onboard firmware, which would comply with the LGPL.  If
their goals are to stop their users from accessing the firmware at all
costs, I'm afraid it may simply be an idealogical problem and we are
at an impasse.

As I said, there are other OSC libraries they could use.  If they
don't consider these as adequate, I don't think that is our problem.
If CNMAT wants to encourage OSC adoption in commercial products, then
it's their job to provide the necessary tools, not ours.

Steve

On Mon, Feb 14, 2011 at 7:59 PM,  <ad...@ad...> wrote:
> The current restrictive licensing for liblo is having a chilling effect
> on its adoption and OSC adoption in general.
> Any chance we can get it augmented to be like the no attribution MIT or
> BSD style licensing?
> Commercial users (e.g. one of CNMAT's sponsors) have decided to avoid it
> and start rolling their own OSC implementations because of the licensing
>  and this encourages them to do their own proprietary tweaks thereby
> watering down the whole goal of OSC.
>
> This becomes critical next week when we work with the Faust developers
> on OSC integration when we will have to choose a cross-platform library
> to build on.
>
> Thanks for looking into this.

I'm forwarding this to the liblo mailing list to get wider comments.
Is there any reason you didn't email this there in the first place?

Personally, I'm not interested in changing the license, and not sure
the majority of liblo developers would be.  However, if we were, more
than 10 individuals would have to be contacted, so it would likely
take more than one week.  Longer if anyone objects.

I'd hardly call the LGPL restrictive, it only requires that you keep
liblo as a dynamically linked library so that it can be switched out.
Any application code can still be closed source.  Why is this
problematic for commercial users?  We specifically switched from GPL
to LGPL to be more friendly to commercial users, without sacrificing
too much of the free software ideals we'd like to maintain for the
library.

In the past Steve H. has made exceptions for those who requested it,
asking for a donation to a charity in return; I'd be happy to put this
offer back on the main page.

Overall, I am confused why you think CNMAT's commercial partners
should have any bearing on licensing decisions for unrelated projects
like liblo.  It is certainly too bad that they are implementing OSC
badly.  It seems a more appropriate resolution would be to ensure more
strategic agreements between CNMAT and their partners.

There are, of course, other alternatives.  Why don't they look at
OSCPack, which is BSD licenced, or CNMAT's own OSC library?  Perhaps
it doesn't help that the link [1] to CNMAT's OSC library goes to a
blank page [2].

Also, why is it problematic for FAUST by the way? FAUST is GPL.  And
developed at Grame, not CNMAT, so if there are any decisions to make
for FAUST, I'm not sure why it is not Yann Orlarey sending this.
Should I include him in the cc list?

Steve

[1] http://opensoundcontrol.org/cnmat-software-library-downloads
[2] http://cnmat.berkeley.edu/OpenSoundControl/src

On 8 February 2011 22:18, Charlie Roberts <big...@gm...> wrote:
> This is really more what I was curious about... to see if people had this
> type of objection. Anyways, I've already ripped it out and put oscpack in,
> and have no interest in participating in a merits of free software cage
> battle  :)

Yes I agree this isn't the place for that. I'd assume though that
wherever there is LGPL there will probably be people aligned with the
FSF and against iOS, although you can't assume too much, as can be
seen with the vlc on iphone cage battle :)  If you are interested in
my personal rant on the subject it's over here:
  http://yaxu.org/the-iphone-and-toilet-paper-freedom/

Cheers

alex

-- 
http://yaxu.org/

On Tue, Feb 8, 2011 at 5:18 PM, Charlie Roberts <big...@gm...> wrote:
> This is really more what I was curious about... to see if people had this
> type of objection. Anyways, I've already ripped it out and put oscpack in,
> and have no interest in participating in a merits of free software cage
> battle  :) That said, this particular piece of software is also in the
> middle of being ported to android and I'm hoping to move it to many other
> mobile platforms that may or may not be freer than iOS. - Charlie

That said, one thing about this discussion confuses me.  Why do you
need to statically link your app simply because it is an iOS app?  Is
it not possible to use libraries / frameworks on iOS?

Steve

This is really more what I was curious about... to see if people had this
type of objection. Anyways, I've already ripped it out and put oscpack in,
and have no interest in participating in a merits of free software cage
battle  :) That said, this particular piece of software is also in the
middle of being ported to android and I'm hoping to move it to many other
mobile platforms that may or may not be freer than iOS. - Charlie


On Tue, Feb 8, 2011 at 2:02 PM, alex <al...@sl...> wrote:

> On 26 January 2011 22:30, Charlie Roberts <big...@gm...> wrote:
> > I know that the license was only just changed to LGPL in the last
> release,
> > but I'm wondering if there has been any thoughts about changing it
> (again)
> > for use in mobile applications? You can't have dynamically linked
> libraries
> > in the App Store, for example.
> > Thanks for any info... - Charlie
>
> Hi Charlie,
>
> It's not so straightforward to change the license of a free software
> project.  You have to contact every contributor and get them to agree
> to relicense their contribution.
>
> I'm only a minor contributor to liblo, but personally I'd be dead
> against that, as I am in favour of the software freedoms that the FSF
> promote and iOS walks all over.
>
> Cheers
>
> alex
>
> --
> http://yaxu.org/
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

On 26 January 2011 22:30, Charlie Roberts <big...@gm...> wrote:
> I know that the license was only just changed to LGPL in the last release,
> but I'm wondering if there has been any thoughts about changing it (again)
> for use in mobile applications? You can't have dynamically linked libraries
> in the App Store, for example.
> Thanks for any info... - Charlie

Hi Charlie,

It's not so straightforward to change the license of a free software
project.  You have to contact every contributor and get them to agree
to relicense their contribution.

I'm only a minor contributor to liblo, but personally I'd be dead
against that, as I am in favour of the software freedoms that the FSF
promote and iOS walks all over.

Cheers

alex

-- 
http://yaxu.org/