Forum

Hello, Eigenlabs!

Your new controller is very promising! But now your poor programmers are going to be overburdened with work.

So why not get out of the software business and open source the software? You don't make money on it - you make money selling instruments. Of course, you'll still need to be the chief developers on the software to make it fly - but I'll bet you could make it fly faster and further if you had other programmers doing it for their own purposes...

I see that at least part of the software is written in Python, a very nice language where it's possible to do fast development with medium-sized groups. There are a zillion hackers out there and the moment you let them in they're going to do amazing things with the instrument, and each one of them will buy one.

You can keep tight control over the trunk and still allow people to make their own experimental versions of things. I'll bet some Mac hacker (not me) might make a really nice GUI for you without you really even trying...

John,

This is really fantastic and I will say that your statements around committing to release as open source and also your bio which shows that commitment where probably the factor that tipped me to buying an Alpha on faith alone. So you can chalk up at least one Alpha to this commitment.

So far i love the instrument and I am very much looking forward to it's release as Open Source. I'm a software developer in my day job and contribute to other open source initiatives in my spare time.

Thx,
Chris Lloyd

An update for you all:

*It's now looking likely that the main system software will be released under GPLv3. This may well be quite shortly, there are just a few details left to sort out, mostly technical in nature.

*There will be a binary component, the instrument drivers for the Alpha, Tau and Pico. These contain software that interoperates with some of our patents, forming part of them with the physical systems, so it is not possible to release this code, particularly under Gplv3. . It will be covered by a separate, proprietary licence. There is a pretty clearly defined interface between these drivers and the rest of EigenD now and there isn't much you would be able to do to them, so we don't think that this is going to be much of an issue for developers. We may be able to lighten this restriction for the Tau and Alpha drivers after a software audit as most of the clever DSP occurs in FPGA's in these instruments, bit it's not going to be legally possible for the Pico.

*There may be components of our system that are not released under the GPL, such as software instruments. These may either remain as proprietary products or more likely have a 12 months delay between the proprietary release and the Gplv3 release. Subscribers to our ongoing support contract (yet to be priced, but a fairly low cost annual subscription is likely) will get the software instruments a year ahead of non subscribers. This is to encourage you to pay for support, so that I might continue to be able to feed the software team and justify continued investment in new software instruments. To start with we'll probably make at least one of the software instruments available, so that people can see how they work. We may make all of the current instruments available, we haven't decided yet.

*There will be a Contributor Agreement that people who can contribute will need to sign. This has become pretty normal now in the OS software world in projects of this nature for a variety of reasons. Mark Shuttleworth has kindly agreed that we can use the Canonical one that Ubuntu now uses (he is making an effort to get everyone to agree in the OS world on a standard form of CA and I think this is a great idea) thereby saving us a load of money with the lawyers. The CA basically assigns the copyright to Eigenlabs for contributions. This allows us to both defend misuse of the GPL for our code and also allows us potentially to still licence proprietary versions of our software to other vendors in the future - possibly an important revenue stream for us - without having a copyright nightmare. I know this means that contributors will be helping us with no reward themselves (wouldn't that be nice if that were actually manageable?), but there's not much avoiding this if we want to release under Gplv3 instead of some other, less accepted licence. All I can say to this is that we'll be releasing code that cost millions of pounds to write (and rewrite, and rewrite) - I think it's a reasonable deal.

John

Hi Carlos

The main reason for the delay (the 'small technical matters') in releasing the code is really about making sure that we have some sort of support structure for developers - a Subversion checkout, section of the website etc. This is a bit complicated and requires some resources, all of which are flat out getting both Windows and the new software out there at the moment, so it's slow going. Jim and I are finally nearly done on the legal front. I doubt there'll be much in the way of useful documentation around the code for some time. We may end up taking an intermediate step on the way - a bare bones, code only view that people can play with.

I think that we'll probably get to the developer side of things sometime after Musicmesse in Frankfurt - after we've got the Windows release out there and stable.

John

Mike

We're all in favour of that. If you have an existing VST instrument then there will be a transition path towards a full EigenD instrument (which is a very different beast from an AU or VST) that should make it possible to add the expressivity in in easy(ish) steps. Jim is shortly to publish a RFC (request for comments) for AU/VST developers that will lay out our proposals for this, using the existing Au/VST MIDI Api to encode additional performance data. The idea being that developers can avoid a fork of their code to start with. Quite a few companies and people have been talking to us about this, and i think we're going to put an instrument store up as part of our site to sell native EigenD instruments from third party developers later this year, if you're interested.

John

Hi John,

Regarding your outline of the open-source plan. I like most of it, except the binary part. I understand why you think it's necessary, but I feel like it would defeat most of the purpose behind the open-source release.

For me, open-sourcing is only partly a matter of allowing contributions, it's mostly a matter of ensuring that in 50 years anyone can still maintain the code so that our instruments will work on what will be the computers of that time, even if Eigenlabs might not be in existence anymore. If the instrument drivers are binary, this is impossible and we're locked in. This is particularly important for the Alpha and the Tau since they're quite a substantial financial investment.

Take care,

Geert

The issue with patents is a thorny one. For a variety of reasons (mainly do do with not permitting TIVO isation of EigenD) we are going to release under GplV3. This implicitly allows our patents to be used - effectively eroding their value to near nothing. This is the purpose of GplV3, and I both understand and agree with it. There is not a lot of point in companies releasing code into the public domain which is protected by a patent then simply waiting to enforce it - this is submarine patent territory and I consider it quite immoral.

We have just had an operational board meeting here at Eigenlabs where we discussed this at some length and we have agreed what we think will be a decent way forward. Firstly, we may well release the Tau and Alpha driver code after an audit as we believe that this will not have any patent implications. In the case of the Pico, which definitely would, we are going to put the code in escrow with our lawyers with the instructions (to be made public here) that if Eigenlabs ceases to exist for any reason, or ceases to maintain a release of the driver (specific details of these criteria to be decided) then the code will be released under the GplV3. I will be looking to make this sufficiently binding that any potential future acquirer (and to cut off any rumors right now, no there is no one in the frame for this at the moment!) of Eigenlabs cannot wriggle out of it and that the developer community will be comfortable with the terms.

Any commentary on this is welcome...

John

John,

That certainly addresses my concerns as well. I want to say how much I appreciate your open communication about this,

jw

Hi John...as a software developer I´m really concerned about licenses and their usability... no efford are short when it comes to such an important matter.

It makes me sad a little the fact that the pico (which is the eigenharp I own) will be the last benefited from user developments but I understand that some legal issues have to be suited.

However I´m interested in developing some ideas I have for the pico, so if there is any way some of us can start working or at least teasting the API I will be definitly interested...

Cheers.

Carlos

The issue with patents is a thorny one. For a variety of reasons (mainly do do with not permitting TIVO isation of EigenD) we are going to release under GplV3. This implicitly allows our patents to be used - effectively eroding their value to near nothing. This is the purpose of GplV3, and I both understand and agree with it. There is not a lot of point in companies releasing code into the public domain which is protected by a patent then simply waiting to enforce it - this is submarine patent territory and I consider it quite immoral.

We have just had an operational board meeting here at Eigenlabs where we discussed this at some length and we have agreed what we think will be a decent way forward. Firstly, we may well release the Tau and Alpha driver code after an audit as we believe that this will not have any patent implications. In the case of the Pico, which definitely would, we are going to put the code in escrow with our lawyers with the instructions (to be made public here) that if Eigenlabs ceases to exist for any reason, or ceases to maintain a release of the driver (specific details of these criteria to be decided) then the code will be released under the GplV3. I will be looking to make this sufficiently binding that any potential future acquirer (and to cut off any rumors right now, no there is no one in the frame for this at the moment!) of Eigenlabs cannot wriggle out of it and that the developer community will be comfortable with the terms.

Any commentary on this is welcome...

John