I predict a fork coming mongodb's way.
No need to thank me but I pressed the fork button again just to make your prediction come true.
281–290 of 487 posts
I predict a fork coming mongodb's way.
No need to thank me but I pressed the fork button again just to make your prediction come true.
Earlier quoted context omitted.
Ask the FSF yourself. Richard Stallman can be reached via rms@gnu.org and usually responds to emails within a day. The FSF defends the right for others to sell your software, and has wide-reaching political ambitions. Don't just take my word for it, ask them.
> Ask the FSF yourself YOU have asserted that the FSF has "wide-reaching political ambitions", therefore it is upon you to provide evidence for this. > has wide-reaching political ambitions I am asking what "political" ambitions does it have, beyond protecting free software. > Don't just take my word for it The thing is, you didn't provide any evidence of the "political ambitions" you speak of and so you're quite rig…
Earlier quoted context omitted.
But you can still offer it as a service, just as long as you opensource your infrastructure. The only thing it prevents you is profiting from lock-in of your services without sharing those profits with MongoDB. Very much in the spirit of open source.
Yeah, but how is that really supposed to work? I can see why MongoDB would want to do this, but how on earth is this really supposed to be implemented? Where do you draw the line? What I suspect is that you'll end up with a bunch of shell scripts for creating MongoDB instances...
Earlier quoted context omitted.
You don't own the term open source mate.
Your opinion isn't the only one out there. I recognize the OSI as the authority on the term open source. On a more practical level: who do you consider be the authority? If the answer is 'nobody' (except yourself) then that makes the term essentially meaningless because there is no standardization, which means that one should stop using that term.
Earlier quoted context omitted.
As OSI hasn't yet reviewed the license, perhaps it would have been better for the OSI VP to explain that "MongoDB may not meet the OSI definition of Open Source" than to announce (in CAPITALS, no less) that "MongoDB...IS NOT OPEN SOURCE".
If it doesn't fit the OSD ( https://opensource.org/osd ) it IS NOT OPEN SOURCE. The license has not been reviewed by the OSI, and there isn't any "Approved until shown otherwise" clause to refer to. So, in the OSI's eyes (and really anyone who knows what open source actually is) it's NOT OPEN SOURCE anymore.
Well, that presupposes that the OSD is the One True Definition of the term "Open Source"; although the OSD is widely accepted and respected, that's a rather bold claim over an English phrase.
> it's NOT OPEN SOURCE anymore
That claim doesn't seem justified at this point. It would be more accurate to say that it is not currently CERTIFIED BY THE OSI as being Open Source -- because the OSI has not yet reviewed the new license. Maybe it will turn out that it is Open Source (as per the OSD), maybe not. Until the license is properly reviewed, we simply don't know.
Earlier quoted context omitted.
AGPL requires you to share the changes to the licensed software you make available, that is, changes to the MongoDB itself. It was like LGPL in the local case: you alter the library and make it available through the software you link with it, so you have to share the changes you've made to the library, but not the rest of the linked code. With SSPL, it's like the full GPL in the local case: if you take the licensed s…
> if you take the licensed software, and link it (via rpc / network) to your other software, you must share not only any changes you've made to the licensed part, but the whole thing that uses it. Slight modification makes this accurate to the SSPL: if you take the licensed software, and link it (via rpc / network) to your other software which you use to offer the SSPL licensed software as a service , you must share.…
As we notice, all that SSPL would require to share is shared in this case.
Then a wholly-owned subsidiary could build various value-added services on top of that MongoDB-compatible thing without a commercial license. This of course would fail if the wrapper would need to be licensed under SSPL, too.
I hope OSI and the FSF don’t approve their new “SSPL” license. AGPL style licenses impose restrictions on usage, thus violating freedom 0 in the Free Software’s definition or Open Source’s rule 6. AGPL should have never been allowed, precisely because it opens the door for commercial entities to eat their cake and have it too, being the kind of license that can be effectively used to disallow commercial products buil…
This new license also gratuitously violates rule 9. Mongo just made a big mistake.
Earlier quoted context omitted.
> The result, however, is that at this moment, MongoDB is under a non-approved license and therefore IS NOT OPEN SOURCE. Perhaps you meant to say "is not OSI Certified", because the OSI don't appear to have a right to restrict use of the phrase "open source". See what's on your own website: https://opensource.org/pressreleases/certified-open-source.p... On the other comments in this thread, even though MongoDB have "…
> because the OSI don't appear to have a right to restrict use of the phrase You are really hung up on this. Where did they say they were restricting the use of the phrase? If they said: "MongoDB is not good software" would you be saying they aren't allowed to restrict MongoDB from saying they are good software?
As someone just above said open source for many simply means the source code is open (can be viewed).
Edit: Realizing now that "open source" may be a genericized trademark held by one of their board and we may need to ignore their assertions in this thread.
Earlier quoted context omitted.
The license you describe, while definitely useful, is not open source by any meaningful definition of the concept. I don't mean "not OSI open source", but "not open source as the term has evolved". Similar licenses have been tried (see Microsoft's Shared Source Initiative) and you can definitely devise one yourself and no-one can stop you. The "world" won't let you call your license open source for good reason: it's…
> The "world" won't let you call your license open source for good reason What is that good reason? Is prohibiting commercialisation of my work not in the spirit of open source? How is my "View and Internal Use License" bad for the open source ecosystem?
> Is prohibiting commercialisation of my work not in the spirit of open source?
Roughly (IMNHO) there's Stallman/gnu style Free software, which is about user freedoms (freedom to run the software being freedom zero). And the Raymond/cathedral vs bazaar "open source", which is about developer freedom - the freedom to learn from and build (in also a business sense) on other software (mit/bsd/apache etc).
The distinction isn't absolute, a gnu "user" is certainly a developer too - but "open source" isn't as concerned with user freedom - especially freedom zero.
With drm, signed bootloaders and trusted computing - it's easy to see a world where even access to source code and compiler tool chain doesn't guarantee the freedom to run a) binary software from a vendor, nor b) software binaries you make yourself.
So gnu/free software isn't primarily about preventing commercialization (see eg: walnut creek software and their CD rom/floppy shipping business) - it's about maintaining user freedom.
And many believe the only real way to legally protect end user freedoms is through means like gpl/AGPL.
In a sense gnu is pessimistic free software (what if I can't (legally) access a c compiler and kernel header files - how can I even build a new printer driver then?) - open source is more libertarian/free market optimistic: go ahead build a firewall appliance from this distribution and lock your customers out - there's plenty other folk that will keep sharing and caring. And if you develop a cool, high performance userspace network stack we'd love for you to share - but do as you please)
Neither is about preventing commercialization - both are about securing access and openness. Now, they do work against certain types of legal mechanisms that are associated with commercialization, like patents and copyright.
Lastly,in a world with copyright, "source available" can be very dangerous to developers (this include text books with unclear licenses for code examples). What happens when I copy your btree implementation? You did show it to me. Was I supposed to forget about it?).
Earlier quoted context omitted.
So, yes, technically, OSI does not own the term open source, and it could be that this license does comply with everything set out in the Open Source Definition ( https://opensource.org/osd ), and that means that, technically, "(the latest version of) MongoDB is not open source" is overstating the case. Except that, as a non-lawyer developer who generally agrees with the Open Source Definition, "under an OSI-approved…
Open source for most people means whether you can see and modify the source code. Not whether OSI gives it some arbitrary stamp of approval.
What you are describing is "source available", not "open source". And that's a huge difference in practice. https://en.wikipedia.org/wiki/Source-available_software