One thing you can't do is contribute changes back to the project, they
won't accept them unless you assign them the copyright of your change
(so they can sell it to others under their proprietary license). So it
is shared under an open source license, and *looks* like a free/open
source project, but actually isn't one until it's forked. It could be
that the GPLv2 is being used here as a firewall to protect commercial
interests, rather than in line with the principles of software freedom
that gave rise to the license.

On 16 September 2016 at 17:14, Miguel Negrão
<miguel.negrao-li...@friendlyvirus.org> wrote:
> Is the issue that you want an implementation that is BSD licensed
> instead of LGPL in order to use in proprietary software ? Because if you
> just want to use it in GPL licensed software, then you have no
> restrictions, you can use their implementation, change it, rewrite it,
> do whatever you want, as long as you don't change the license, that is
> keep using GPLv2.
>
> Best,
> Miguel Negrão
>
> On 16-09-2016 17:07, Spencer Russell wrote:
>> I think the fully legal clean-room path would be for someone to
>> reverse-engineer the code and write the spec, and then other people
>> (who haven't seen the code) to write implementations.
>>
>> Or maybe Ableton just hasn’t gotten around to documenting the spec
>> and will eventually. But given the strongly-worded branding
>> guidelines in the repo I’m guessing they want to maintain a certain
>> amount of control.
>>
>> -s
>>
>>> On Sep 16, 2016, at 11:31 AM, Tom Murphy <amin...@gmail.com>
>>> wrote:
>>>
>>> This is a good point -- there's still no legal impediment, right,
>>> to making interoperable implementations? I.e. if the spec is the
>>> implementation, and the implementation is open-source, then
>>> effectively we can create other implementations of the protocol,
>>> just maybe requiring more reverse-engineering?
>>>
>>> So we don't need to wait for them to allow us to, just wait for
>>> them to make it easy for us?
>>>
>>> Tom
>>>
>>> On Fri, Sep 16, 2016 at 3:48 PM, Spencer Russell
>>> <s...@media.mit.edu> wrote:
>>>
>>>> It’s also worth noting that they haven’t really opened the
>>>> protocol, they open-sourced their implementation of it, with an
>>>> option to pay for a license if you want to use it in proprietary
>>>> software. Definitely a step in the right direction, and exciting,
>>>> but I’m hoping at some point there’s actually an open spec for
>>>> the protocol so there can be interoperable implementations.
>>>>
>>>> -s
>>>>
>>>>
>>>>> On Sep 16, 2016, at 9:51 AM, Ogborn, David
>>>>> <ogbo...@mcmaster.ca> wrote:
>>>>>
>>>>> EspGrid already does this and has been used and tested for
>>>>> years
>>>> (although continues to develop of course)!
>>>>> http://d0kt0r0.github.io/EspGrid/
>>>>>
>>>>> -D
>>>>>
>>>>> ________________________________________ From:
>>>>> haskell-art@group.lurk.org [haskell-art@group.lurk.org] on
>>>>> behalf
>>>> of Tom Murphy [amin...@gmail.com]
>>>>> Sent: Friday, September 16, 2016 9:46 AM To:
>>>>> haskell-art@group.lurk.org Subject: Re: [haskell art] Ableton
>>>>> link
>>>>>
>>>>> Agreed, this could be very cool. Promises to be a common
>>>>> language for timing, where participants can use different
>>>>> applications, enter and
>>>> leave
>>>>> at any time, make tempo changes...
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Sep 14, 2016 at 3:56 PM, Alex McLean <a...@slab.org>
>>>>> wrote:
>>>>>
>>>>>> Ableton link have open sourced their sync protocol:
>>>>>> https://ableton.github.io/link/
>>>>>>
>>>>>> It would be wonderful to have a haskell implementation!
>>>>>>
>>>>>> alex
>>>>>>
>>>>>> -- blog: http://slab.org/ music: http://yaxu.org/ crowdfund:
>>>>>> http://www.pledgemusic.com/projects/spicule/
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Read the whole topic here: Haskell Art:
>>>>>> http://lurk.org/r/topic/29NxvfURM9xUEdjdub36Ws
>>>>>>
>>>>>> To leave Haskell Art, email haskell-art@group.lurk.org with
>>>>>> the
>>>> following
>>>>>> email subject: unsubscribe
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Read the whole topic here: Haskell Art:
>>>>> http://lurk.org/r/topic/7l2ZF7lVp3JFlNsiKMrMox
>>>>>
>>>>> To leave Haskell Art, email haskell-art@group.lurk.org with
>>>>> the
>>>> following email subject: unsubscribe
>>>>>
>>>>> --
>>>>>
>>>>> Read the whole topic here: Haskell Art:
>>>>> http://lurk.org/r/topic/7IXTuUgQWEDVBlyAitdFaN
>>>>>
>>>>> To leave Haskell Art, email haskell-art@group.lurk.org with
>>>>> the
>>>> following email subject: unsubscribe
>>>>
>>>>
>>>> --
>>>>
>>>> Read the whole topic here: Haskell Art:
>>>> http://lurk.org/r/topic/2iefHFFxvki17setSeu28Q
>>>>
>>>> To leave Haskell Art, email haskell-art@group.lurk.org with the
>>>> following email subject: unsubscribe
>>>>
>>>
>>> --
>>>
>>> Read the whole topic here: Haskell Art:
>>> http://lurk.org/r/topic/5Va4hqdqe12yjDhk4kiLmC
>>>
>>> To leave Haskell Art, email haskell-art@group.lurk.org with the
>>> following email subject: unsubscribe
>>
>>
>
>
> --
> Miguel Negrão
> http://www.friendlyvirus.org/miguelnegrao
>
> --
>
> Read the whole topic here: Haskell Art:
> http://lurk.org/r/topic/6QnKaxnlxrPNSCgNcJrD4O
>
> To leave Haskell Art, email haskell-art@group.lurk.org with the following 
> email subject: unsubscribe



-- 
blog: http://slab.org/
music: http://yaxu.org/
crowdfund: http://www.pledgemusic.com/projects/spicule/

-- 

Read the whole topic here: Haskell Art:
http://lurk.org/r/topic/40NOhcpW4FE5XaUWnAr1Q7

To leave Haskell Art, email haskell-art@group.lurk.org with the following email 
subject: unsubscribe

Reply via email to