23 ms·
A successful open-source project is also about building a community of third-party contributors. Or at least the possibility of one such community happening. Du
by bad_user 11y ago
A successful open-source project is also about building a community of third-party contributors. Or at least the possibility of one such community happening. Dual licensing basically kills off that discussion, because in order for dual licensing to work, then contributors need to sign a contributors agreement that licenses their work for whatever purpose the parent company sees fit.
And this is where I've always disagreed with FSF's stance. Many people claim that GPL is inadequate because of the "ASP loophole". But a much bigger loophole is dual licensing. This is because dual licensing happens (and is useful) only when the product is unusable as open-source. For example Gitorious is AGPL licensed and does not need dual licensing because you know, it's meant for people to have an on-premise solution for Git hosting and it's a take it or leave it thing. A Javascript library on the other hand is totally useless as AGPL. Dual licensing is also what made Qt and consequently KDE to be less popular than Gtk+ and Gnome in distributions such as Red Hat's or Ubuntu, or why popular project such as Firefox or LibreOffice are better integrated with Gtk+/Gnome, even though Qt has always been technically superior. Heck, Qt's licensing is why Gtk+/Gnome happened in the first place.
You see, the biggest advantage of open-source, its raison d'être if you will, is the possibility to fork. But if a fork cannot survive because of licensing reasons, maybe because it cannot be applied to the same projects as the original, then that's not really open-source.
Personally I prefer the open core. For example I currently work with Scala and the JVM and I use IntelliJ IDEA as my IDE. It has a community edition with everything I need. Yet I pay for the Ultimate edition anyway. If the community edition gets discontinued, I'll switch in a heartbeat.
- quadrangle 11y agoThe dual-licensing problem for software freedom is easily dealt with: just accept community contributions WITHOUT requiring a CLA. That is enough to legally guarantee the software will stay free for everyone. Dual licensing isn't otherwise a loophole since it is a decision the primary author organization makes for themselves, not something someone else can do to your copyleft code. Copyleft does protect the commons. https://www.youtube.com/watch?v=UneYZikN85Q https://www.youtube.com/watch?v=UneYZikN85Q
- jordigh 11y ago> A successful open-source project is also about building a community of third-party contributors. Not necessarily. Depends on your goals. You might want to free up your software because it's the right thing to do and it guarantees your customers have a way out should should your business ever fail. You might scare away a few contributors by requiring copyright assignments so you can sell GPL exceptions, but the whole idea that you should free your software so you'll get more contributors is (1) sometimes false as it is in the present case, and (2) part of the campaign slogans that OSI made when they tried to rebrand free software as "open source".
- mehrdada 11y ago> You see, the biggest advantage of open-source, its raison d'être if you will, is the possibility to fork It might be the raison d'être of open source, but the goal of free software is preserving users' freedom, not ensuring usefulness of software in some commercial proprietary context. That seems to be at the root of your disagreement with FSF. You simply care about different things and therefore prioritize differently; everything else is secondary. FSF does not aim for popularity, convenience, or playing well with one's commercial interests as its primary goal.
- bad_user 11y agoThe right to fork is a prerequisite for users' freedom and without it the software is not free. The right to fork is about having complete control over the software that you're using. And it's usually a fact - either you have that right, or you don't, instead of being a warm and fuzzy social ideal, like the issue of "users freedom" tends to be. Because the second you said "users freedom", you're in danger, because what constitutes a "user" is unclear. Is a user a person that pushes buttons providing input for your program to produce its destined output? Or can a user be a programmer as well? Because depending on its needs, different users want different freedoms. And for example I do not consider AGPL to be open-source (or free software for that matter) because modifying code without redistributing the binaries is simple usage for a developer, which means AGPL imposes restrictions on usage, being a freaking EULA. But going back to our subject, dual licensing, take a look at projects that are dual licensed and usually you'll notice that the choice of the license had nothing to do with users freedom, quite the contrary, after all, without serious constraints dual licensing wouldn't work.
- admax88q 11y agoWhat constitues a user is not unclear. A user is both someone who uses the compiled software (pushes the button in your example) or a developer capable of modifying the software. A developer doesn't need the freedom to redistribute the software to other users without also respecting their freedoms. Dual licensing does nothing to hurt freedom, as a user of the GPL licensed software your freedom is protect, both to use the software, and to modify it for your usage. Needing to assign copyright to make upstream contributions may hurt the rate at which the upstream project develops, but in no way hurts your freedom.