4 ms·

OP is wrong, SQLite does match the requirements outlined in the OSI's definition: https://opensource.org/osd https://opensource.org/osd It's not "open source l

by remram 2y ago

OP is wrong, SQLite does match the requirements outlined in the OSI's definition: https://opensource.org/osd https://opensource.org/osd It's not "open source licensed" simply because it is not licensed. There is no license document for OSI to approve. Relying on OSI approval does not necessarily make sense, they don't get to all licenses as your link points out. However arguing over their definition seems very foolish. People only do it when they want to pass their all-rights-reserved code as "open source" (e.g. "I can call it what I want"). Having adjectives that mean the same to everyone is very valuable, actually.

evanelias 2y ago
> Having adjectives that mean the same to everyone is very valuable, actually. Yes, and that's precisely why OSI should have invented a brand new term which they could trademark. But instead they co-opted "open source" which already had a clear, generic meaning of "the source code is available", previously without any connotations around specific license terms. And then due to that prior usage of the term, OSI can't trademark it. OSI created this terminology mess, and personally I don't think it is "foolish" to argue with their historical revisionism campaign around it. Edit to add: for numerous proven examples of the term being used for many years prior to the OSI's existence, read the link ezekg already posted below, https://dieter.plaetinck.be/posts/open-source-undefined-part-1-the-alternative-origin-story/ https://dieter.plaetinck.be/posts/open-source-undefined-part...
- rat87 2y ago
  That is not clear or generic. Source code available isn't that useful and isn't Open Source.
  - evanelias 2y ago
    I am saying that describing a code base as "open source" was intuitive and generically understood to mean "source available" prior to 1998, which is when the OSI co-opted the term and conflated it with a much more specific definition involving license restrictions. As for the pre-1998 meaning not being "clear", that's a matter of opinion. I would counter that OSI choosing to redefine an already existing term, and then falsely claim they invented that term, makes things far less clear. Please read the link I included above. That post author's findings completely align with my own recollection from discussions on BBS's and newsgroups in the 90s.
    - remram 2y ago
      The fact that you had to change your use of the term back in the 90s is deplorable but is it really any argument for going back? I for one like where we are (which is not an endorsement of OSI as an organization, just of their definition). The terms are short and universally understood, there is a wide range of licenses to choose from, some of them even got a yay/nay from lawyers.
      - evanelias 2y ago
        I feel that the current status quo around OSI-approved licenses is largely beneficial to incumbents ("big tech" / cloud providers) and is generally harmful for software innovation industry-wide. A fair number of vocal people in the industry express contempt for anything using a non-OSI license, even though many of these licenses are simply trying to empower a sustainable business model so the work can't be stolen and abused by cloud providers. If you independently create a truly innovative new infrastructure software product today (or during any other non-ZIRP / non-boom-time period) with the intention of forming a company around it, you are faced with several bad options around licensing and source availability: * If you adopt an OSI-approved license other than AGPL, and your product is successful, larger incumbents can and will steal your work and capture most of its value. You will either go out of business, or eventually need to re-license, causing mass outrage and accusations of rug-pulling. * If you choose AGPL, most VC-funded companies won't touch your software and statistically it will almost certainly fail commercially as a result. Additionally there are several concerning theoretical loopholes in the AGPL, as well as conceptual problems with a non-EULA nonetheless trying to enforce restrictions affecting end users. * If you choose an entirely close-sourced model, your chance of success is very very low, especially for B2B products. You're a small/new vendor, other companies won't trust you. So the logical conclusion is you should choose a non-OSI license which prevents the cloud providers from stealing the profits from your hard work. But then random people will attack you everywhere for "open washing" and not being "open source", even if you don't use the word "open" anywhere. People have seemingly been trained to have a knee-jerk negative reaction to SSPL, BSL, etc and that's a really bad state of affairs. It's especially problematic that the OSI is a closed-membership entity, and not an open-membership professional association. There is no democratic way for software engineers to influence its policies. As an industry we've effectively ceded control over what licenses are acceptable to a random small non-profit. And as a result of that, it's harder today to be a successful independent software vendor than it was in the 90s, which is an absurd state of affairs.
- remram 2y ago
  I understand your point, but I am not sure a new term wouldn't have been co-opted (if it was any good). It would certainly have hurt adoption (if it was not as good). I also like the current terminology better tbh ("open", "available").
  - evanelias 2y ago
    If they had invented a new term, then they could have obtained a trademark for that term, which would properly allow them to enforce their definition and ability to certify licenses as open source. That's usually how this works, for example POSIX is a trademark of the IEEE. (the other possible route is enforcement/certification by a government agency, for example organic food must meet certain farming practices to be called "organic".) Instead we have a situation where they didn't invent the term but they lie about it and said they did. They don't have a trademark and obviously aren't a government agency, so enforcement is left to random people acting as self-appointed terminology police on their behalf. And then we get huge subthreads like this one, where a bunch of people have to argue about whether one of the most successful open source projects in history is really even "open source" :)
deleted 2y ago
[deleted]
graemep 2y ago
> OP is wrong, SQLite does match the requirements outlined in the OSI's definition: That is true for most of us, but there are jurisdictions that do not recognise the public domain in the same way. SQLite's license page mentions this and offers licensing for people who need to deal with this. https://www.sqlite.org/copyright.html https://www.sqlite.org/copyright.html
avinassh 2y ago
> OP is wrong, SQLite does match the requirements outlined in the OSI's definition: https://opensource.org/osd https://opensource.org/osd OSI also says Public Domain is not open source: Public Domain Is Not Open Source https://opensource.org/blog/public-domain-is-not-open-source https://opensource.org/blog/public-domain-is-not-open-source
- wakawaka28 2y ago
  I skimmed over both of those links and it seems that there are in fact no aspects of the definition that could be challenged with public domain software. The second one is all over the place (the author even says he's not a lawyer!) but it seems focused on the fact that public domain rights are not recognized the same in every country. SQLite has other licenses you can use for those situations. The idea that this project is not truly open source seems silly.
- remram 2y ago
  SQLite did do those additional steps outlined in your link.

by remram 2y ago

evanelias 2y ago

> Having adjectives that mean the same to everyone is very valuable, actually. Yes, and that's precisely why OSI should have invented a brand new term which they could trademark. But instead they co-opted "open source" which already had a clear, generic meaning of "the source code is available", previously without any connotations around specific license terms. And then due to that prior usage of the term, OSI can't trademark it. OSI created this terminology mess, and personally I don't think it is "foolish" to argue with their historical revisionism campaign around it. Edit to add: for numerous proven examples of the term being used for many years prior to the OSI's existence, read the link ezekg already posted below, https://dieter.plaetinck.be/posts/open-source-undefined-part-1-the-alternative-origin-story/ https://dieter.plaetinck.be/posts/open-source-undefined-part...

rat87 2y ago
That is not clear or generic. Source code available isn't that useful and isn't Open Source.
- evanelias 2y ago
  I am saying that describing a code base as "open source" was intuitive and generically understood to mean "source available" prior to 1998, which is when the OSI co-opted the term and conflated it with a much more specific definition involving license restrictions. As for the pre-1998 meaning not being "clear", that's a matter of opinion. I would counter that OSI choosing to redefine an already existing term, and then falsely claim they invented that term, makes things far less clear. Please read the link I included above. That post author's findings completely align with my own recollection from discussions on BBS's and newsgroups in the 90s.
  - remram 2y ago
    The fact that you had to change your use of the term back in the 90s is deplorable but is it really any argument for going back? I for one like where we are (which is not an endorsement of OSI as an organization, just of their definition). The terms are short and universally understood, there is a wide range of licenses to choose from, some of them even got a yay/nay from lawyers.
    - evanelias 2y ago
      I feel that the current status quo around OSI-approved licenses is largely beneficial to incumbents ("big tech" / cloud providers) and is generally harmful for software innovation industry-wide. A fair number of vocal people in the industry express contempt for anything using a non-OSI license, even though many of these licenses are simply trying to empower a sustainable business model so the work can't be stolen and abused by cloud providers. If you independently create a truly innovative new infrastructure software product today (or during any other non-ZIRP / non-boom-time period) with the intention of forming a company around it, you are faced with several bad options around licensing and source availability: * If you adopt an OSI-approved license other than AGPL, and your product is successful, larger incumbents can and will steal your work and capture most of its value. You will either go out of business, or eventually need to re-license, causing mass outrage and accusations of rug-pulling. * If you choose AGPL, most VC-funded companies won't touch your software and statistically it will almost certainly fail commercially as a result. Additionally there are several concerning theoretical loopholes in the AGPL, as well as conceptual problems with a non-EULA nonetheless trying to enforce restrictions affecting end users. * If you choose an entirely close-sourced model, your chance of success is very very low, especially for B2B products. You're a small/new vendor, other companies won't trust you. So the logical conclusion is you should choose a non-OSI license which prevents the cloud providers from stealing the profits from your hard work. But then random people will attack you everywhere for "open washing" and not being "open source", even if you don't use the word "open" anywhere. People have seemingly been trained to have a knee-jerk negative reaction to SSPL, BSL, etc and that's a really bad state of affairs. It's especially problematic that the OSI is a closed-membership entity, and not an open-membership professional association. There is no democratic way for software engineers to influence its policies. As an industry we've effectively ceded control over what licenses are acceptable to a random small non-profit. And as a result of that, it's harder today to be a successful independent software vendor than it was in the 90s, which is an absurd state of affairs.
remram 2y ago
I understand your point, but I am not sure a new term wouldn't have been co-opted (if it was any good). It would certainly have hurt adoption (if it was not as good). I also like the current terminology better tbh ("open", "available").
- evanelias 2y ago
  If they had invented a new term, then they could have obtained a trademark for that term, which would properly allow them to enforce their definition and ability to certify licenses as open source. That's usually how this works, for example POSIX is a trademark of the IEEE. (the other possible route is enforcement/certification by a government agency, for example organic food must meet certain farming practices to be called "organic".) Instead we have a situation where they didn't invent the term but they lie about it and said they did. They don't have a trademark and obviously aren't a government agency, so enforcement is left to random people acting as self-appointed terminology police on their behalf. And then we get huge subthreads like this one, where a bunch of people have to argue about whether one of the most successful open source projects in history is really even "open source" :)

deleted 2y ago

[deleted]

graemep 2y ago

> OP is wrong, SQLite does match the requirements outlined in the OSI's definition: That is true for most of us, but there are jurisdictions that do not recognise the public domain in the same way. SQLite's license page mentions this and offers licensing for people who need to deal with this. https://www.sqlite.org/copyright.html https://www.sqlite.org/copyright.html

avinassh 2y ago

> OP is wrong, SQLite does match the requirements outlined in the OSI's definition: https://opensource.org/osd https://opensource.org/osd OSI also says Public Domain is not open source: Public Domain Is Not Open Source https://opensource.org/blog/public-domain-is-not-open-source https://opensource.org/blog/public-domain-is-not-open-source

wakawaka28 2y ago
I skimmed over both of those links and it seems that there are in fact no aspects of the definition that could be challenged with public domain software. The second one is all over the place (the author even says he's not a lawyer!) but it seems focused on the fact that public domain rights are not recognized the same in every country. SQLite has other licenses you can use for those situations. The idea that this project is not truly open source seems silly.
remram 2y ago
SQLite did do those additional steps outlined in your link.