I have a bad feeling about this...

It looks to me that that statement effectively violates and voids the GPL2 licence that has been used up until now.

That’s the problem we’re trying to solve: how can we allow Jamulus on the Apple App Store but still ensure the GPL rights (in practical terms). It’s always possible to build the macOS version from source and have all the rights from this version.

I‘m open for alternative suggestions.

Is there a licence that will work for both publishing to App Store and for keeping open source changes back?
I see we don't actually include a licence file in the repository at the moment - we probably should?

For discussion of this, I found:
https://stackoverflow.com/questions/459833/which-open-source-licenses-are-compatible-with-the-apples-iphone-and-its-offici

The Apache 2 licence seems to be the recommendation there, but I wasn't around at the inception of jamulus and why it was GPLv2 rather than Apache back then.

If we cannot have a licence that will work with the App Store, then we cannot publish something for iOS.

https://exygy.com/blog/which-license-should-i-use-mit-vs-apache-vs-gpl/ is an interesting read.

Ultimately, the issue is the conflict which is very well documented here: https://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement

The upshot is, to be 100% happy, we would not be able to use the App Store with GPLv2.

Now, this is always a grey area with a range of issues attached, I'm thinking ZFS usage on linux for one....

Is there a licence that will work for both publishing to App Store and for keeping open source changes back?

I don't think we can change the license at will at all. This would likely need an OK by all contributors which might be close to impossible.
Regarding the direction of (possible) license changes, there were different discussions with the intent of protecting Jamulus as an open source project even more (e.g. AGPLv3, which is more restrictive than GPL), and not lifting restrictions.

I understand that having a less restrictive license would be beneficial for the app store topic, but I doubt it is easily possible or even desirable for the other reasons.

I'd hope for something like the Nextcloud to work, although I don't quite understand all legal consequences. Maybe @gilgongo's friendly lawyer can help? :)

I see we don't actually include a licence file in the repository at the moment - we probably should?

We do -- the typical name (at least when using the GPL?) is COPYING though.

We do -- the typical name (at least when using the GPL?) is COPYING though.

Ah ha. missed that... Thanks. I'm used to seeing that in a LICENSE file

I don't think we can change the license at will at all. This would likely need an OK by all contributors which might be close to impossible.
Regarding the direction of (possible) license changes, there were different discussions with the intent of protecting Jamulus as an open source project even more (e.g. AGPLv3, which is more restrictive than GPL), and not lifting restrictions.

So then the question becomes, are we all comfortable in putting in a statement akin to what https://github.com/nextcloud/ios have done? Specifically, their wording is: here

This should be for both macOS and iOS app stores, so maybe the file would be a .apple_app_store suffix?

Specifically, their wording is: here

I know, but I didn’t want to copy it. The text above is at least partly based on the nextcloud file

Specifically, their wording is: here

I know, but I didn’t want to copy it. The text above is at least partly based on the nextcloud file

I see a lot more words on theirs - something I'm told legal folks like ;D
Do we have any lawyers that could look at it?

So I ran into another GPL software on the Mac app store today:
https://macos.telegram.org, which calls out their GPLv2 licence and is kept here.

I had a quick chat with my British Library licence manager friend today. He's not a FOSS expert because the library is mainly concerned with artistic works, but knows a lot about CC and commercial licences and how they work in the "real world". If we did a Nextcloud thing (publishing a disclaimer, essentially) then this shows an intention which a court would almost certainly take into account in the massively unlikely situation anyone tried to make a legal fuss.

So from my perspective, I’m happy to include these additional terms and publish to the App Store under my corporation, understanding the very small risk here. The most likely outcome in the event of a conflict would be the removal of the app from the store.
If we want to have an iOS version working, then we have to release via the store

@emlynmac There's some confusion about where and how to display licencing info in github repos as it's an issue that's come up before. We don't have a LICENSE.md but do have what I think github prefers which is as link from README.md to COPYING.md: https://github.com/jamulussoftware/jamulus/blob/master/COPYING

Our licence is also displayed on the github "code" page.

So there is one other potential option for iOS/macOS store compliance etc.
Creating a brand new Apple only client app using native swift and making it compatible with the jamulus server API.
This would then be independent from the original code and not interfering with the existing project

Yes, sure. But that would involve a lot of development and the need to maintain two compatible clients.

Yes, sure. But that would involve a lot of development and the need to maintain two compatible clients.

There will be fresh code but arguably simpler because it only needs to work for two very closely compatible targets using the same interfaces. I'm kinda curious to see how much work at this point. Maybe I'll have a look...

Remember, anything that's compatible with protocol.h/protocol.cpp will, arguably, be derived from them...

Remember, anything that's compatible with protocol.h/protocol.cpp will, arguably, be derived from them...

I think there's a definite line between copying the contents of the file vs defining against the interface to the server.

The only "published" definition, however, of that interface is subject to the GPL 2.0 terms.

The only "published" definition, however, of that interface is subject to the GPL 2.0 terms.

And if you were to really be thorough, then you could reverse-engineer the protocol from packet sniffing. At this point, it's a rather academic conversation which is detracting from the real issue of whether or not the existing codebase can get to the App Store or not.

If there is no comfort with publishing to the App Store due to licensing restrictions, then there really is no point in doing an iOS version as it will never be available. The Mac version can at least be signed, but again not in the store.

If there is no comfort with publishing to the App Store due to licensing restrictions, then there really is no point in doing an iOS version as it will never be available.

At least not easily available. However, sideloading or TestFlight Publishing might be possible?

If there is no comfort with publishing to the App Store due to licensing restrictions, then there really is no point in doing an iOS version as it will never be available.

At least not easily available. However, sideloading or TestFlight Publishing might be possible?

Hmm, side loading = jailbreaking. So likely no.
Testflight = somebody being ok with their apple developer account being used for that and having builds that expire after 90 days. Neither of these are workable IMHO.

I am beginning to think that it would be prudent to move the main network protocol definition to a separate repo under MIT licence and then have the jamulus repo pull that in for the current software.
Then for the apple-world stuff, we can build something specific for those and leverage the App Store and performance increase from not having QT in the binary.

I can create signed macOS builds for the jamulus main, but we can have something totally isolated in terms of licence and code for the app stores. This would likely be Apache 2 or MIT licensed.

Pros

• minimal existing code is made MIT (server interface),
• apple users get an efficient, signed client,
• easier to get existing apple developers helping out
• App Store releases
• Simplification of existing codebase - no iOS parts
• Server API changes clearer to see as committed to a separate repository

Cons

• Two code bases instead of one
• Need to MIT licence the message API

Sideloading != jailbreaking but close. Semi advanced users can do that e.g. via AltStore.

Pro: Shared code-base Con: not a long term solution.

I am beginning to think that it would be prudent to move the main network protocol definition to a separate repo under MIT licence

The question here is if that’s allowed.

As far as I know, you’re one of the rare (or only?) Apple developers in the Jamulus community.

Sideloading != jailbreaking but close. Semi advanced users can do that e.g. via AltStore.

Sorry, there's no way to side load on iOS without jailbreaking. Altstore is basically giving you a development release build after you give them your appleID and password....

As far as I know, you’re one of the rare (or only?) Apple developers in the Jamulus community.

I use Typescript, Dart, C, C++, Java, Swift on a fairly regular basis. Given the headaches the team are starting to see with making iOS work, I'm proposing what I think is the best option.

I am beginning to think that it would be prudent to move the main network protocol definition to a separate repo under MIT licence

The question here is if that’s allowed.

Well, here's the interesting part. You can totally reverse-engineer the protocol as it is un-encrypted - meaning it would be possible to build a completely independent client and/or server. That would be much faster done with shared headers for the protocol definition and better for all involved really - more exposure, more growth etc.

Thanks for the clarification.

So we have two options:

1. Separate app for macOS and iOS without Qt (I know that moving away from Qt was a discussion. Especially with the latest bugs on macOS, it might be a way to go)
2. Use the existing code and include the statement from above. I think the risk - if it even exists - is not too high and would only result in a removal of the app from the store. So this would be the way I‘d suggest for now.

Is it time to bring this PR out of WiP?

A few questions....

1- re: "no comfort in publishing to the Apple store"... would the alternatives be more comfortable?

2- How will the iOS version improve our community? I cringe at the thought it will create more support issues. Is this iOS for smartphones or for tablets(iPads)?

3- What will be the differences in user experience between desktop and iOS?
I am not interested in supporting a user that expects a simpler interface with the same musical experience as users with the desktop. (I guess this question assumes it is for smartphones and much smaller screens.)

1- re: "no comfort in publishing to the Apple store"... would the alternatives be more comfortable?

Not sure what you're getting at here. Can you elude what you consider the alternatives to be?

2- How will the iOS version improve our community? I cringe at the thought it will create more support issues. Is this iOS for smartphones or for tablets(iPads)?

If you support more platforms, you get more issues as more users use it. If there's a strong concern here around android / iOS users being more vocal, then maybe mobile support should not be part of the main code base.

3- What will be the differences in user experience between desktop and iOS? I am not interested in supporting a user that expects a simpler interface with the same musical experience as users with the desktop. (I guess this question assumes it is for smartphones and much smaller screens.)

This sounds like you have no interest in a mobile development - and if this is something that divides the jamulus contributors, then it does make sense to drop mobile support and introduce mobile clients for those interested in pursuing such.
Mobile clients don't generally have wired network connections, unless proper hardware is available.

We are not changing Jamulus's licence for anyone other than those who obtain it from the App Store. If you get Jamulus from somewhere else, you are bound by the GPL and only the GPL. That's not changing. As to getting agreement to do the App Store flip: are we not doing that here, now, with this PR? I'm not sure I understand your point on that.

All I'd say about getting legal advice is that its a very sensible thing to do :-)

I think the problem is "assumed assent" / "assumed consent" may not hold up. Absent parties cannot really be considered to have agreed to something they are not even aware is happening. There have been code contributions under the GPL going back over many, many years. I don't even know if all those contributors are aware we've moved to Github...

Putting Jamulus in the App Store is a violation of the GPL because Section 10 says, "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." The FSF is clear that you should not put GPL-ed apps in the App Store for this reason.

That still doesn't answer the question: what are these "further restrictions"? What am I being asked to consent to?

That still doesn't answer the question: what are these "further restrictions"? What am I being asked to consent to?

Presumably, these: https://www.apple.com/legal/internet-services/itunes/us/terms.html

Also explained futher in the FSF link I provided above. Essentially, while Apple let you provide a "custom" licence (in our case, the GPL), they still slap limitations onto the user's distiribution rights. But just so we're clear, there is nothing in them that say a commercial entity could take our code and put another Jamulus in the app store and start making money from it any more than that would happen outside the app store.

And anyway, those terms govern the distribution and use of the Jamulus binary by users of Jamulus, not you as a copyright holder of the code. Your rights to the Jamulus code under the GPL are unaffected by this proposal as far as I know. At least, Apple's terms say that "Apple’s delivery of Services or Content does not transfer any commercial or promotional use rights to you, and does not constitute a grant or waiver of any rights of the copyright owners."

And I assume that if somebody had used the App Store for getting any app, they would have agreed to the terms with that already?

Absent parties cannot really be considered to have agreed to something they are not even aware is happening.

If we cannot feasibly obtain agreement then we have to call all this off. Unless anyone has any better ideas?

Whilst the archived terms link from the blog are substantially different (being ten years older) than the current Apple T&C, they still seem pretty much heavy-handedly in violation of the GPL.

For a start, they claim that anything acquired through the App Store is an Apple Service or Apple Content. That's a claim of ownership or branding:

This Agreement governs your use of Apple’s services (“Services”), through which you can buy, get, license, rent or subscribe to content, Apps (as defined below), and other in-app services (collectively, “Content”). Content may be offered through the Services by Apple or a third party.

SERVICES AND CONTENT USAGE RULES
Your use of the Services and Content must follow the rules set forth in this section (“Usage Rules”). Any other use of the Services and Content is a material breach of this Agreement. Apple may monitor your use of the Services and Content to ensure that you are following these Usage Rules.

Basically, that says that Apple could decide to take action against anyone using Jamulus in a manner that they consider a material breach of the agreement, if it was acquired through the App Store. The "All Services:" section lists a number of additional restrictions. However, their wording seems to focus on content rather than apps and there's very little stated about what can or can't actually be done. Even in the section explicitly about apps...

It is made clear that "LICENSED APPLICATION END USER LICENSE AGREEMENT" does not apply as we provide our own licence agreement (the GPL) -- it's not that part that's the issue, though, it's those earlier bits.

There's also

Apple reserves the right at any time to modify this Agreement and to add new or additional terms or conditions on your use of the Services. Such modifications and additional terms and conditions will be effective immediately and incorporated into this Agreement. Your continued use of the Services will be deemed acceptance thereof.

Effectively, that hands Apple the right to change absolutely everything above that statement as they see fit and then enforce it.

Apple reserves the right at any time to modify this Agreement and to add new or additional terms or conditions on your use of the Services. Such modifications and additional terms and conditions will be effective immediately and incorporated into this Agreement. Your continued use of the Services will be deemed acceptance thereof.

The last sentence "Your continued use.... will be deemed acceptance...." says if apple changes the terms and conditions inconsistent with our intent, we can remove Jamulus from the store. The removal is our rejection of the new T&C.

How does that affect a Jamulus user who acquired "Content" -- Jamulus -- from the App Store and continues to use it? Do they become bound by Apple's updated T&C? I believe Apple expect so.

The new T&Cs will apply to new downloads. Since we would/should remove Jamulus from the app store as a rejection of the new T&Cs, there would be no downloads under the new terms. Continued use of the app downloaded before the new T&C would not fall under the new terms.

In my non-lawyer opinion, the Apple terms mostly affect content created with Jamulus. We don't have any functions that give Apple any oversight over copyright issues. (oversight, meaning the storage and distribution of copyright content, similar to YouTube - which could create liability to Apple.). Since there is no revenue to fight over, I think we are worrying excessively about theoretical problems. If Apple raises any issues, we simply pull Jamulus.
We continue and consistently assert GPLv2. The only real issue is if Apple claim they reject GPLv2 licensed content.

If I undertand correctly @emlynmac if anyone objects to this proposal, then those who do not object will re-write Jamulus for the app store with new code, and submit it that way (hence the wording of the disclaimer, which puzzled me at first).

But meanwhile, I think I can summarise all this such that any objection can be made a bit clearer:

1. Putting Jamulus in the app store is the only practical way of allowing its use on Apple mobile, which is seen as desireable by some people. It would also perhaps make more people aware of Jamulus whether they used it on their mobiles or not.

2. Apple's T&Cs apply to people who obtain Jamulus fom the app store. It does not affect the copyright holders' assertion of the GPL, nor does it affect any rights to the Jamlus "brand", music played with it, require a licence change, or any such thing affecting the project.

3. Although Apple will assert the GPL as the "Custom EULA” for Jamulus, it imposes some extra terms. This act of addition is not allowed under the GPL - but there are no specific terms that are being called out as unacceptable to us. Presumably also, anyone using any app store content would already be accepting of these constraints anyway.

4. Because of the above points, we propose to waive any objections to the fact that Apple would be violating the GPL in making Jamulus available on the app store. We'll do this by putting up a notice up to say we don't mind.

5. Apple reseves the right to change its terms. If they do that in a way that we don't like, we simply pull Jamulus.

6. A copyright holder objecting to what we propose would presumably be declaring their intention to bring a legal case against Apple (and those who obtain Jamulus from the app store?). I have been told informally by somebody who knows a bit about this kind of thing that a court would take our waiver (and our discussion and agreement to it) into account.

We'll do this by putting up a notice up to say we don't mind.

I think your summary above should be included in such a notice as an explanation of why it's believed to be required.

@pljones @gilgongo I think you both have access to the file. I‘m not a native speaker and just wrote this note based on the one from Nextcloud. You can both give proposals to this file (and ofc. link this PR)

OK I'll see if I can sugggest some more wording.

However, Apple's terms apply to those who obtain Jamulus from the App Store. It does not affect the copyright holders' assertion of the GPL, or otherwise affect the Jamulus project:

Are we 100% sure about that? Not a lawyer though…

@ann0see Could be wrong of course, but I can't see anything in their T&Cs that assert anything over app providers. At least, the use of the term "you" in their terms only refers to those who download stuff, not make it.

@ann0see Could be wrong of course, but I can't see anything in their T&Cs that assert anything over app providers. At least, the use of the term "you" in their terms only refers to those who download stuff, not make it.

This was my understanding of the T&C also. @gilgongo I really like the updated wording - it's much clearer as to why.

The wording could do with some amends for style maybe as it's a bit klunky in places, but I'll wait to see what others think.

@gilgongo I think it‘s ready then?

Ok. Now we’re missing an approval from some other @jamulussoftware/maindevelopers too ;-).