SDK License Questions

This topic contains 6 replies, has 2 voices, and was last updated by  Joe Davis 2 years, 3 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #48851

    Simon
    Member

    Hi,

    We use the native SDK to provide POD support in our AR app and platform – see http://www.zappar.com. It’s a great format, and the SDK is really useful, so thanks very much for that. I’m sure our usage in Zappar is compliant with the license agreement (we list the required acknowledgement in our documentation).

    There are a few things that are not 100% clear though. We provide an embeddable component for third parties to include in their apps. This is provided in compiled binary form, and contains our complete content platform, a small part of which is the POD rendering support including code derived from the PVRTools SDK. Can you confirm that this usage is allowed under the license agreement, providing the third-party app developer includes the required attribution with their app?

    The term 2)b)ii) is a little confusing:

    2. […] Imagination grants to you a non-exclusive, non-assignable licence to:
    […] (b) distribute the SDK in source code, object file, or compiled binary form as a component of your application, provided that:
    […]
    ii. you distribute such components under terms no less restrictive than those in this Agreement;

    I don’t quite understand how that requirement can be met in general. Clearly any app on the app store is distributed under the terms of the user EULA that users must agree to before they are able to use the store at all. It is almost certain those terms are more restrictive than the SDK EULA. However the FAQ appears to be clear that the intention is the SDK can be used to build commercial apps without fee, as long as attribution is given.

    I suspect that the 2)b)ii) is referring more to source distributions, but it would be nice to have clarification that as long as the correct attribution is provided (a) people can safely use the SDK as part of commercial apps in general, and (b) that we can provide a compiled versions to a third party as part of a larger binary library which they can then incorporate into their app.

    Thanks!

    Simon

    #48853

    Simon
    Member

    I understand that you would want the closed-source parts of the SDK to have some special terms and restrictions applied, but the ideal approach for me would be to use a standard open-source licence for the parts of the SDK that are also published in source form on github (thanks for agreeing to my previous suggestion on an official github repository btw!).

    MIT/BSD offer the “permissive” re-use that the descriptions appear to encourage, and still have an attribution requirement. The advantage would be more commercial acceptance (legal departments can get spooked by custom licenses, and some even have a whitelist of acceptable licenses for open source code).

    Simon

    #48858

    Joe Davis
    Member

    Hi Simon,

    It’s a great format, and the SDK is really useful, so thanks very much for that.

    Glad to hear you’re finding the POD format useful. We’d like to start collecting quotes from developers for our download pages and other promotional material, so any kind words you can share about your experiences would be much appreciated 🙂

    We recently launched a PowerVR Showcase page. As you’ve used the POD format in Zappar, we’d be happy to include a section on this page to promote it. If you’re interested in this, I can discuss what we would need from you through our ticketing system.

    Can you confirm that this usage is allowed under the license agreement, providing the third-party app developer includes the required attribution with their app?

    Our SDK source code and PVR Tools binaries are released under the same license to help simplify distribution. In the license, the term “binaries” refers to the precompiled binaries supplied without source code (e.g. PVRTexTool, PVRTrace etc.). You can freely distribute any binaries generated from source code. I’ll discuss this with the team to see if we can come up with a good way to clarify this in the EULA and EULA FAQ.

    the ideal approach for me would be to use a standard open-source licence for the parts of the SDK that are also published in source form on github

    Thanks for the feedback. I’ll discuss this with the legal team.

    #48870

    Simon
    Member

    Thanks for the clarification Joe. It certainly felt like the intention of the license was to allow uses like ours but great to have it confirmed at least informally. I’d appreciate a ping on here if the legal team do make any clarifying changes to the license itself or the FAQ.

    The showcase sounds great, we’d love to be featured! Feel free to add me to a ticket or something to get the ball rolling on that front.

    Simon

    #48890

    Joe Davis
    Member

    Question 4 in our EULA FAQ has now been updated to clarify this.

    The showcase sounds great, we’d love to be featured! Feel free to add me to a ticket or something to get the ball rolling on that front.

    Our ticketing system isn’t integrated into the rest of our Community site yet . A separate login is required so I won’t be able to create a ticket for you until you have registered. If you sign up and file a ticket, we can discuss the Showcase requirements.

    Cheers,
    Joe

    #48898

    Simon
    Member

    Thanks Joe.

    It’s still a little confusing to me – perhaps the fact the fact the final sentence of Q4 says you must ensure that you comply with the SDK distribution terms directly after saying binaries derived from SDK source can be “freely distributed”. That begs the questions “how free is freely distributed?” and “which terms actually apply?”

    I mentioned above that I’d prefer a standard open-source license for the source components. That might be possible with minimal disruption by taking a dual-licensing approach that would allow users to choose a license, which would enable all existing users to carry on using the same terms as the current EULA, but would allow new users (or existing users finding it beneficial) to use the code under a more standard and possibly less permissive license.

    For example, MIT actually appears to be less permissive than my understanding of the intention of the existing license – you can’t “freely distribute” any derived binaries, but are instead granted specific rights to use, modify, redistribute, sublicense, etc providing a copy of the license and terms is included.

    I’ll sort out a ticket for the showcase stuff next week.

    #49182

    Joe Davis
    Member

    Hi Simon,

    Apologies for the delayed response. I’ve been OoO for the last few weeks.

    That begs the questions “how free is freely distributed?” and “which terms actually apply?”

    As soon as the SDK source is compiled into binary form, you can distribute the binaries however you see fit without having to worry about our licence. Our terms to retain the copyright notice only apply to unmodified source code. If you would like to mention us in your documentation somewhere we’d appreciate it, but it’s not a requirement.

    I mentioned above that I’d prefer a standard open-source license for the source components.

    I did get in touch with the legal team, but haven’t heard anything back from them yet. I’ll give them another nudge. I suspect it will take some time before we can push a change like this through, but I’ll keep trying.

Viewing 7 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic.