I think that issue has more to do with a lack of an established 
independent standard, like someone mentioned already. Without a 
standard, their implementation *is* the standard, and that is why you 
want to contribute changes back, because otherwise if you make a change 
that breaks the public interface, you become incompatible with everyone 
else. If there was a standard and a community process for moving the 
standard forward, then they not accepting changes back would not be an 
issue.
   Open source is about being able to see and change the code, there is 
no obligation of developers accepting changes from other developers, 
that part is related with community (or lack of) and each community is 
free to setup their own rules for that.
   But your point is important, open source projects if they are 
interested in this protocol they probably would be wise to make sure 
there was an independent standard at some point, in order not be 
dependent on Ableton. But I suspect the commercial companies will have 
much more to say about that than the small open source communities...

On 17-09-2016 22:05, Alex McLean wrote:
> 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
>
>
>


-- 
Miguel Negrão
http://www.friendlyvirus.org/miguelnegrao

-- 

Read the whole topic here: Haskell Art:
http://lurk.org/r/topic/6NF7RPfUokOGPgyAt9c3HQ

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

Reply via email to