Add-on can not be activated on macOS & license considerations

[regcs]

The add-on can not be activated on macOS, although the HoloPlay Core SDK is installed. Apparently it searches for the library in the user directory, but after installation of the HoloPlay Core this is found in the system library path.

At the moment the user has no choice to set a proper library path from the add-on preferences, in case the library is not found at the expected path. This is because the add-on raises an exception in the register() function which prevents activation of the add-on. I would suggest to load the library after add-on activation and add some further "os.path.exists" checks.

[GottfriedHofmann]

The next version should come with a Mac OS library that is placed at the right place from the beginning. The issue with the addon raising an exception when activated - with https://github.com/Looking-Glass/blenderLKG/commit/5c0395894368107bb33ad03de1d6c13375ba7735 this has been fixed, thanks for reporting. Can you test it? When setting the location of the library, the user currently has save or close the preferences and restart Blender. I'd like a more userfriendly approach but I could not make the filepath property trigger an update function when it is set by the user.

[regcs]

Yup, it works now.

Two suggestions:

• I decided to include the holoplay core libraries in my add-on package. That way you don't need to look for them somewhere else in the system
• if you don't want to include them for some reason, I would suggest to add an "refresh" button in your preferences next to the path. Then the user doesn't need to restart, but just click.

[regcs]

Ah, regarding the automatic update: I just tested it quickly and as for any property you can use the "update=FUNCTION" keyword of the property if you want to realize an automatic update. It would look something like this:

def test(self, context):

    print("PUT YOUR UPDATE CODE HERE")

class LookingGlassPreferences(AddonPreferences):
    # this must match the addon name
    bl_idname = __name__

    filepath: bpy.props.StringProperty(
            name="Location of libHoloPlayCore",
            subtype='FILE_PATH',
            update=test,
            )

[GottfriedHofmann]

Ah, regarding the automatic update: I just tested it quickly and as for any property you can use the "update=FUNCTION" keyword of the property if you want to realize an automatic update. It would look something like this:

def test(self, context):

  print("PUT YOUR UPDATE CODE HERE")

class LookingGlassPreferences(AddonPreferences):
  # this must match the addon name
  bl_idname = __name__

  filepath: bpy.props.StringProperty(
          name="Location of libHoloPlayCore",
          subtype='FILE_PATH',
          update=test,
          )

That's what I tried but it would only run the update function when the addon was registered (ie. when the property was updated from the code), not when it was updated by the user. Did you get it to work?

[regcs]

Well, the lines I posted above do print "PUT YOUR UPDATE CODE HERE" if I change the path via the UI from the preferences. But anyway, I don't see a point in not distributing the dynamic linked libraries with the add-on.

[GottfriedHofmann]

Well, the lines I posted above do print "PUT YOUR UPDATE CODE HERE" if I change the path via the UI from the preferences. But anyway, I don't see a point in not distributing the dynamic linked libraries with the add-on.

I also tried it again and it works now so I commited right away: https://github.com/Looking-Glass/blenderLKG/commit/e031b819253a7e33ae11c7125d8bc7e90759b6fe

Thanks for the report.

[GottfriedHofmann]

* I decided to include the holoplay core libraries in my add-on package. That way you don't need to look for them somewhere else in the system

We do not include the library due to legal reasons. All Blender addons are supposed to be under the GPL or a compatible license so bundling proprietary libraries with it is not good. Having the use download and install things seperately should solve this issue.

[regcs]

Thanks for the report.

You're welcome.

We do not include the library due to legal reasons. All Blender addons are supposed to be under the GPL or a compatible license so bundling proprietary libraries with it is not good.

Yeah, I know. After reading and thinking about that a lot, I think there are two options: (1) the HoloPlay Core SDK falls under the system library exception of GPL v3 or (2) it doesn't.

If (2) applies, then the add-on is not free software in accordance with the GPL, since it cannot run without this library. It's whole purpose relies on linking to the non-free HoloPlay Core SDK. So the only solution would be, to make this SDK open-source.

If (1) applies, then it doesn't matter if you distribute it with the package or not. GPL does allow distributing a system library with the package. See https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException:

the requirement to distribute source code for the whole program does not include those libraries, even if you distribute a linked executable containing them.

Since the SDK works like a driver, which is fundamentally necessary to use the Looking Glass Display, we assume the system library exception applies. Otherwise we couldn't distribute the add-on.

[Edit] This discussion might be also interesting for @alxdncn and @wormyrocks.

[alxdncn]

Hey there! Yeah we put a lot of thought into this, including for our earlier Blender add-on for 2.79.

Our conclusion at the end of the day is that the HoloPlay Core DLL, given that it's meant to work across applications for the Looking Glass, should be considered a system level library. We didn't see language in the FAQ you linked above @regcs that indicates that you can therefore distribute the library with the add-on, but perhaps that was a misreading.

[regcs]

Hi @alxdncn!

Our conclusion at the end of the day is that the HoloPlay Core DLL, given that it's meant to work across applications for the Looking Glass, should be considered a system level library.

Yeah, I would also say that the DLLs should be considered a system library and that the system library exception counts.

We didn't see language in the FAQ you linked above @regcs that indicates that you can therefore distribute the library with the add-on, but perhaps that was a misreading.

I would argue two things in favor for distributing it with the add-on:

1.) The FAQ states that the source code of system libraries does not need to be made open source even - and this is why I quoted that FAQ before - "if you distribute a linked executable containing them". That implies that it is allowed to distribute such libraries with GPL software in my understanding.

2.) I didn't find a passage in the GPL that prohibits distributing system libraries with GPL software. It merely states that libraries that can be considered system libraries do not need to be made open source, in contrast to other libraries.

[regcs]

Started a new issue #23 on the license discussion. The bug reported with this issue was fixed, therefore closing this.