4 ms·
> A dual license is not IF/THEN/ELSE, it's pick $mit or $commercial--your call. No, it can be both. As the originator of the work, you are free to grant licens
by pickingdinner 3y ago
> A dual license is not IF/THEN/ELSE, it's pick $mit or $commercial--your call.
No, it can be both. As the originator of the work, you are free to grant licenses based on qualifications. It's done all the time. I can't choose Adobe's student licence because I'm not a student.
So is this what's held back dual licensing and OS authors profiting? If the buyer could just freely choose of course it's broken.
(edit)
Just to add, even Oracle's license isn't completely free for the user to choose. Depending on the plans or policies of the buyer, they are restricted to their choices. So an IF statement exists.
- deleted 3y ago[deleted]
- ghaff 3y agoIf you release something under an open source license, of course I get to choose to use it under the terms of that license. That's the whole point. If that's not acceptable, don't release it under an open source license. Like Adobe's proprietary software, you can release it as free for educational or non-profit use only under your own license. Can be hard to define and hard to enforce but that's your problem. Do open source or don't do open source. I don't care. But it's tiresome to have people who want the "open source brand" but don't actually want to release open source software. Most of the actual advantages of open source don't accrue to tightly controlled products anyway. And, yes, I don't consider it a problem but dual licensing, at least outside of open core (which has its own problems), is fairly useless in the general case. So in that sense it's broken. But that is open source working as intended.
- pickingdinner 3y ago> of course I get to choose No, you are wrong here. Maybe it's semantics or whatever but a rights owner can impose restrictions based on conditions.
- ghaff 3y ago>Maybe it's semantics or whatever but a rights owner can impose restrictions based on conditions Yes. But what we seem to be going in circles on is that IF the rights holder wants to release the software under an OSI-approved license, they don't get to change that license, which is what you're doing if you want to say the software is only available under that license to some subset of users. Of course, they have the right simply not to use an OSI-approved license at all. But OSI-approved licenses all say you CAN'T impose certain restrictions if you're going to use them. What they CAN do is to dual license the software under an all rights reserved license and their own "source available" license (for eligible users). So long as an OSI-approved license isn't involved, they can do anything they're legally permitted to. If you want usage restrictions, just don't use an OSI-approved license. It's pretty simple and the result is effectively the same. They can even just cut and paste the MIT license and add a usage restriction clause. They just can't call it--and it isn't--the MIT license anymore.
- pickingdinner 3y agoThis is in response to your latest response. Not sure why the reply link isn't showing. Take adobe student discount. They license at a discount if you're a student. The rights holder can restrict who gets what license. If you're trying to be able to say "released under OSI approved rubber stamped" then sure, maybe duel licensing is not ok. But you don't need the two licenses to be in agreement, and if you're not a student you don't legally get the student discount just by identifying as one. So you could easily and legally do, free for not-for-profit, $50 otherwise with source.