Closed BlaiseRideout closed 5 years ago
Probably not, but there should be. We'd have to decide on a license and ask all the individual author (e.g. for the BrainProducts apps @dmedine, me and Ole Traupe) if it's ok for them.
For the Apps, I'd suggest the GPL or MPL (see license comparison and how data.table handled it), but that's something that should be done for each app invididually and some vendor SDKs might impose additional restrictions.
Do you have a specific app in mind?
I'd actually suggest the MIT license since that is what liblsl is currently under.
On 5/8/2018 9:13 AM, Tristan Stenner wrote:
Probably not, but there should be. We'd have to decide on a license and ask all the individual author (e.g. for the BrainProducts apps @dmedine https://github.com/dmedine, me and Ole Traupe) if it's ok for them.
For the Apps, I'd suggest the GPL or MPL (see license comparison https://choosealicense.com/ and how data.table handled it https://github.com/Rdatatable/data.table/pull/2456), but that's something that could be done for each app invididually.
Do you have a specific app in mind?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sccn/labstreaminglayer/issues/298#issuecomment-387307559, or mute the thread https://github.com/notifications/unsubscribe-auth/ADch7ih_iwNh8RARcwmC-F__jjdPmfnrks5twUWbgaJpZM4T1cE3.
MIT wouldn't require anyone distributing/selling Apps (e.g. LabRecorderPlus) to share the modifications, so I'd prefer a slightly more restrictive license. In any case, distributing and selling the Apps would (and should) be allowed with either MIT, MPL or GPL.
GPL is fine with me.
On 5/8/2018 11:03 AM, Tristan Stenner wrote:
MIT wouldn't require anyone distributing/selling Apps (e.g. LabRecorderPlus) to share the modifications, so I'd prefer a slightly more restrictive license. In any case, distributing and selling the Apps would (and should) be allowed with either MIT, MPL or GPL.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sccn/labstreaminglayer/issues/298#issuecomment-387335722, or mute the thread https://github.com/notifications/unsubscribe-auth/ADch7nzn6xInUsUXq9VHghCrXJjTo1Zdks5twV94gaJpZM4T1cE3.
GPL is fine with me.
Good to hear. Does your employer requires any other licenses, especially for SDK headers?
The other committers in the Apps directory are:
92 David Medine 73 Chadwick Boulay 22 Tristan Stenner 5 Pablo Prietz 3 Steven Boswell 2 Anita Popescu 2 SCCN User sccnuser@rolling.ucsd.edu (?) 2 Christian Kothe 1 Rashi Abramson 1 Ole Traupe 1 Matthew Grivich
That leaves 8 other people to ask and someone to see if included SDKs have other licenses.
As of now, no and for various reasons that I am contractually obligated not to post on the internet this issue won't be settled for a few months. In the meantime, I would say that it is fine just to slap a GPL license on the whole thing. As time goes on we will have to make a few adjustments regarding 3rd party SDKs. This means checking with other manufacturers as well (e.g. Phase Space). I would imagine that a lot of those SDKs already have licenses in them. The overall license should note that it may be overwritten in this case.
Glad to see that I won the commit contest ;)
On 05/09/2018 01:17 PM, Tristan Stenner wrote:
GPL is fine with me. Good to hear. Does your employer requires any other licenses, especially for SDK headers?
The other committers in the Apps directory are:
92 David Medine 73 Chadwick Boulay 22 Tristan Stenner 5 Pablo Prietz 3 Steven Boswell 2 Anita Popescu 2 SCCN User sccnuser@rolling.ucsd.edu (?) 2 Christian Kothe 1 Rashi Abramson 1 Ole Traupe 1 Matthew Grivich
That leaves 8 other people to ask and someone to see if included SDKs have other licenses.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sccn/labstreaminglayer/issues/298#issuecomment-387706352, or mute the thread https://github.com/notifications/unsubscribe-auth/ADch7mslIMckluTiazuyPzGEVl1J00yJks5twtA2gaJpZM4T1cE3.
Is there any way the repo could have the license added to it? It would be awesome if it was MIT, but right now there's no license I can find listed anywhere so it's sort of murky waters to use it at all
It's easier to ask the authors of the individual apps, e.g. the BrainProducts apps would only require David, Ole and me to reach an agreement (git shortlog --no-merges -s Apps/BrainProducts/
). Which app did you have in mind?
it would be easier if the whole repo was under a single license as some license types "infect" others and it would become a maze to figure out, especially because beyond the apps directory there's also the question of the scripts + non app code in other directories like
https://github.com/sccn/labstreaminglayer
and all of the child directories in
@sterlingcrispin , we can't come up with a common license for the entire LSL repo because there are too many different sources of code and APIs. This would be a huge amount of work to figure out, and the lowest common denominator would probably be a pretty terrible license.
This problem was one of the motivations for breaking out LSL into a bunch of different repositories, found here: https://github.com/labstreaminglayer/
We're all quite busy so I doubt any of us are going to go through every repository and figure out its license, but if you tell us which of those repositories you need a license for then we'll try to accommodate.
@cboulay alright I see, in that case the interfaces would be great to get a license on
https://github.com/labstreaminglayer/liblsl-Csharp https://github.com/labstreaminglayer/App-MATLABViewer
and the example code meant to be expanded on
https://github.com/labstreaminglayer/App-BestPracticesGUI https://github.com/labstreaminglayer/App-Examples
@tstenner Can probably unilaterally do BestPracticesGUI and Examples.
The App-MATLABViewer isn't actually an interface to LSL. It's just something to look at streams. Do you instead mean https://github.com/labstreaminglayer/liblsl-Matlab ?
I put an MIT license on the Csharp wrapper with Christian Kothe as the copyright holder. I'm 95% sure he was the original author of it, but @dmedine please correct me if you know otherwise.
The examples are partially taken from the liblsl folder (which is MIT licensed), so MIT is fine.
I added license information to both repositories, so feel free to use it.
@cboulay yes that the repo I meant it looks like @xloem or @tstenner were the primary contributors? Could we get an MIT license on that repo for clarity?
Thanks for the help!
Regarding the Matlab bindings, The commit from @xloem was just normalizing the line endings. The commits from @tstenner are mostly for the build system and not the core code.
Before GitHub, the project was hosted on google code. Looking at the old commit messages there, it seems like the code was mostly written by @chkothe . I've pinged him to see if he's willing to put a license on it.
Edit: https://github.com/labstreaminglayer/liblsl-Matlab/issues/1
I'm most interested in seeing a license added to the LabRecorder app.
Note that the LabRecorder app (and most of the apps for that matter) link against Qt5 and boost.
Qt5 is LGPL3, but I don't think our use of it makes it transitive. i.e., because we're only using the API functions and structures, we're only linking dynamically, and we're not distributing any Qt5 headers or libraries, then we don't have to follow Qt5.
The boost license is much more permissive, and in the case of the apps we are only linking dynamically so there's no worry there.
@dmedine, you wrote most of the LabRecorder c++ app so can you put a license on it? If you want I can do it for you and put you as the copyright holder, just let me know which license (e.g. MIT).
@cboulay, I wrote the GUI code, but the underlying mechanics (recording.h) was authored by Christian. I think he should be the copyright holder. Also, the GUI code was basically a port of the previous Python implementation (also by Christian), which we should probably revert to anyway since you've fixed the data type marshalling problems in the pylsl interface. MIT license is fine as far as I'm concerned.
On 06/15/2018 07:55 PM, Chadwick Boulay wrote:
Note that the LabRecorder app (and most of the apps for that matter) link against Qt5 and boost.
Qt5 is LGPL3, but I don't think our use of it makes it transitive. i.e., because we're only using the API functions and structures, we're only linking dynamically, and we're not distributing any Qt5 headers or libraries, then we don't have to follow Qt5.
The boost license is much more permissive, and in the case of the apps we are only linking dynamically so there's no worry there.
@dmedine https://github.com/dmedine, you wrote most of the LabRecorder c++ app so can you put a license on it? If you want I can do it for you and put you as the copyright holder, just let me know which license (e.g. MIT).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sccn/labstreaminglayer/issues/298#issuecomment-397697329, or mute the thread https://github.com/notifications/unsubscribe-auth/ADch7uLnofvKbFh5fAJlQh_-nuBbD6Fzks5t8_UegaJpZM4T1cE3.
Naturally the recording.h code is what's most useful. @chkothe, would you mind giving some input?
Any update from @chkothe ?
Christian has said his LSL contributions are all under MIT. I don't have that in writing, but I'm confident that's accurate.
Confirmed with Christian and added a LICENSE file to the LabRecorder submodule repo. https://github.com/labstreaminglayer/App-LabRecorder
Currently it's unclear what license the Apps in this repository are under. The only thing that has a definite license is liblsl, which is MIT licensed. Does the same apply to the whole repository?