Closed Poll: What's the optimal license, in your opinion?

Development
41

That certainly is an option for the Swift port. The only downside that I see at the moment is that I would then have to draft a second license for releasing to the app store, and I have no clue how to do that. Do you know whether anyone else has used such a dual-licensing scheme for the App Store successfully?

I really like the exception that you’re proposing to the Syncthing license. It would indeed allow me to look at newer versions of the Go version. But I’m not a lawyer, and I cannot forsee whether there are any legal pitfalls by adding this exception.

42

So I would say that attempting to draft any kind of addition or amendment to a license without involving multiple lawyers (in some suitable jurisdiction) is a bad idea. Sticking to something proven is better.

I don’t really get the point of multi licensing either. As an extreme example, GPL+MIT would grant you all the freedoms (let’s not argue terminology here) of MIT, rendering the requirements of GPL moot since you can just choose to not use that license. It also prevents us from pulling in contributions that are not identically multi licensed, or we get effectively stuck with just the one license.

Reassigning copyright to some suitable entity (the FSF, a newly created foundation, an ultimately trusted individual, …) also prevents us from pulling in contributions, since we can’t just reassign someone else’s copyright.

Changing to a less restrictive license, say MPLv2, allows reuse of the code in proprietary ways and distribution on the App Store and again prevents us from grabbing differently licensed code.

Note that I’m talking about pulling contributions here, as in “hey that patch on Pulse looks real nifty, let’s incorporate it”. Contributions actively made to us via a pull request are always explicitly licensed under whatever model currently in effect.

So I see two considerations here.

  1. Being more liberal than the GPL allows, thus enabling other implementations to look at and use our code without fear of breaching the license, and further distribution models, ie the App Store. This requires switching to a less restrictive license.

  2. Having the same license as Pulse to enable seamless code sharing.

The optimal solution here seems to be for both sister projects to adopt a less restrictive license. It’s known that I like MIT but MPLv2 also seems like a reasonable middle ground, gaining traction.

We can also do a unilateral switch, enabling point one above and a one way flow of code from us to Pulse but not vice versa. This could then be fixed at any time by indie by “re-forking”, since there’s thus far no functionality added on that side of the split.

Opinions? @aral for indie, contributors for existing code, others for the hell of it? (:

1 Like
43

If I could change one thing in open source software land it would be general awareness and understanding of copyright law and licenses plus their real world implications. People would save so much time discussing licenses. :smile:

Only the copyright holders can enforce their rights, so if anyone does something you don’t like you have to take them to court. You might get somewhere as a single copyright holder amongst many in a large project sending a cease and desist letter to a small-time infringer but if a well funded company decides to behave badly then you’re going to want a majority of copyright holders to agree to legal action and somehow fund that. If you’re not going to do that then basically either go with pure GPL so the FSF might find it worth taking up your case and covering the legal costs or accept that the license is just there to tell people acting in good faith what they can or can’t do.

The “bonus” with using the GPL, even if you add a narrowly scoped exception, is that most companies will simply not touch the code (at least that’s what their legal people will advise) unless the cost of building something similar is astronomical or they need to leverage an ecosystem of developers and tools that goes with the project (think Linux kernel).

Syncthing is very nicely designed but it’s not rocket science and it stands alone. A VC funded startup is going to prefer to build their own untainted IP than save the cost by using someone else’s. Similarly with a giant corporate. You’ll find most giant corporates actually play nicely with open source these days, even when it’s quite liberally licensed. If they don’t then they find they can’t hire any developers experienced with the code.

You are 100% correct that MIT+GPL dual licensing is pointless - it is effectively identical to just MIT but confuses people.

So, my personal view is that anything other than a GPL variant or MIT equivalent for a community developed project (e.g. non-corporate) that isn’t a library to be linked to is pointless. You’re not going to be able to afford to enforce your copyright in court anyway, so just make the license easy to understand for potential contributors and good faith actors wanting to use your code for something else.

1 Like
44

So here is how owncloud, a somewhat comparable project with a company as sole copyright holder deals with this. Maybe FSF could agree to such construction and play the same role for syncthing?

ownCloud Mobile App for iOS

In order to allow contributions, the ownCloud Mobile App for iOS is licensed under GPLv3 as of November 20th 2014.

At this time GPLv3 is incompatible to the terms and conditions Apple, sometimes together with 3rd party vendors, enforces on you as additional restrictions if you like to publish the ownCloud Mobile App for iOS or any derivatives thereof in the Apple Store, any Apple Enterprise Program, Enterprise Mobile Device Management Systems or the Beta Test program.

While you can use the ownCloud Mobile App for iOS in the iOS simulator on your Mac System, this is often not sufficient for development and testing purposes.

Therefor we do grant, as sole copyright holder, a license exception to the ownCloud Mobile App for iOS restricted to users of the „Ad Hoc Provisioning“ method provided by Apple to Apple Developer Account holders.

You are allowed to distribute the ownCloud Mobile App for iOS and any derivaties thereof to up to 100 iOS devices using this method.

In this case the ownCloud Mobile App for iOS will be governed by the license terms Apple provides to you and such device users.

see also http://owncloud.org/blog/want-to-add-a-feature-to-the-owncloud-ios-app-now-you-can/comment-page-1/
45

As a side note, I kind of suspect the FSF is the last organization in the world to grant non-free licenses to corporations like Apple.

Actually, I think we should just not worry about the app stores. The iOS one is off limits for technical reasons. The Mac one is not essential, as a lot of applications are being distributed the traditional way and will continue to be so for the foreseeable future. On the Windows side of things I have no idea how it works.

I’m slightly more worried about other open source projects, as I would those to be able to use code and ideas from here without worry.

But in general I’d say that since the specs are public domain, any implementation would look somewhat similar, and I’m certainly not going to be the one to lead the charge in a new wave open source projects suing each other for actually using the code that’s supposed to be usable…

1 Like
46

I think @aral did want to use Mac App Store distribution as an avenue for revenue generation but also to reach a wider audience. There are a lot of apps being distributed the traditional way but they’re typically tools for pros and power users, not social network clients aimed at the mass market. The general public are being educated to go to an app store to get new apps. I guess a MAS version could eventually use the Swift port, just like iOS.

Right, so since the copyright holders are the only ones that can take legal action and you really need a majority of them to go to court, since a solid case for infringement should involve a “substantial portion” of the work copied/derived from, there is a kind of precedent here. Although the most responsible thing to do legally is make a clear exception in the license, it’s understandable not to want to risk making a giant loophole to exploit with accidentally loose wording. The Linux kernel openly tolerates binary drivers, which unquestionably violate the GPLv2 but are actually in the interests of the project thriving. IIRC, Linus basically said binary drivers are much better than no drivers on the mailing list at some point. You could put something in the README to the effect of “Although the project is licensed under the GPLv3, the protocol specs are public domain and ports to other languages are actively encouraged. The lead developers will not support any legal action against projects providing alternative implementations of the protocol in other languages under different open source licenses, even if those implementations are clearly inspired by code from this project.”

1 Like