[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SSPL or server side public license, GNU better update the AGPL
From: |
Jean Louis |
Subject: |
Re: SSPL or server side public license, GNU better update the AGPL |
Date: |
Sun, 21 Mar 2021 12:55:28 +0300 |
User-agent: |
Mutt/2.0.6 (2021-03-06) |
* Alfred M. Szmidt <ams@gnu.org> [2021-03-21 11:36]:
> Saying something, and enforcing -- seeing that that offer is upheld --
> are two entierly different things. I can say that all non-free
> software should cease to exist, but I have no means of enforcing it.
Sure, those are discussions on what I said, though not related to real
problem.
Real problem is that several companies were not satisfied with
previous license, and have changed the license to something else, some
making it more free than with AGPL, some making it non-free software.
Problem related to GNU is when AGPL is not enough, so maybe there is
need to update the AGPL, and allow the author to demand source code to
be published, and not only offered to be given.
Those new licenses are better to be updated on the GNU page about
licenses, to tell if they are free software or proprietary non-free
incompatible software. There many implications with the introduction
of these new licenses.
According to the article:
1. Confluent changed to new license:
https://www.confluent.io/confluent-community-license/
they made software non-free by using the new license:
"Excluded Purpose" means making available any
software-as-a-service, platform-as-a-service,
infrastructure-as-a-service or other similar online service that
competes with Confluent products or services that provide the
Software.
2. MongoDB:
https://www.mongodb.com/blog/post/mongodb-now-released-under-the-server-side-public-license
Remains free software with stricter demand than AGPL to publish the
source code, not just provide an offer.
Quote:
The best current solution for an open source company is to license
their software under the AGPL, which requires a management stack
used to operate that software as a service to be made available
under the terms of the AGPL. This approach was believed to be good
enough, as most people understood their obligations to comply with
AGPL. However, as AGPL-licensed software like MongoDB has become
more popular, organizations like the international cloud providers
have begun to test the boundaries of this license. We would prefer
to avoid litigation to defend the AGPL but instead devote our time
to build great products for the community and our customers.
Since we own 100% of the copyright of MongoDB, one option available
to us was to convert our open source license to a closed source
license. We chose not to because we fundamentally believe in open
source software. We believe an open source approach leads to more
valuable, robust, and secure software, and it directly enables a
stronger community and better products. We also could have licensed
most of the code for the MongoDB server as AGPL while applying a
closed license to some critical files. We chose not to do that
because we believe that a uniform licensing approach, where all the
code in a repository shares a single license, makes it easier to
understand the obligations of using that code, leading to a
stronger development community.
The community needs an updated open source license that builds on
the spirit of the AGPL, but makes explicit the conditions for
providing the licensed software as a service.
The SSPL is designed to make sure that companies who do run a
publicly available MongoDB (or any software subject to the SSPL)
as a service are giving back to the community.
MongoDB thus remains free software with modified AGPL license
where they demand that source code must be published.
They have expressed clearly concern with the AGPL, so it may be
time for update.
3. Cockroach DB:
https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/
Is making Cockroach DB non-free software:
Why We're Relicensing CockroachDB
Quote:
"CockroachDB was conceived of as open source software. In the years
since it first appeared on GitHub, we’ve tread a relatively typical
path in balancing open source with creating a viable
business. We’ve kept our core code under the Apache License version
2 (APL), launched a managed service, and gated some features for
established companies under an enterprise license."
Competitors have always been legally allowed to offer another
company’s OSS product as a service. Now, we’re finally seeing it
take place. We’re witnessing the rise of highly-integrated
providers take advantage of their unique position to offer
“as-a-service” versions of OSS products, and offer a superior user
experience as a consequence of their integrations. We’ve most
recently seen it happen with Amazon’s forked version of
ElasticSearch, which Salil Deshpande neatly described in TechCrunch
as both “self-interested and rational.”
To respond to this breed of competitor, we’re introducing a change
to our software licensing terms. The full details of the change are
below and on Github, but the short version is this:
Today, we’re adopting an extremely permissive version of the
Business Source License (BSL). CockroachDB users can scale
CockroachDB to any number of nodes. They can use CockroachDB or
embed it in their applications (whether they ship those
applications to customers or run them as a service). They can even
run it as a service internally. The one and only thing that you
cannot do is offer a commercial version of CockroachDB as a service
without buying a license.
4. Graylog:
https://www.graylog.org/post/graylog-v4-0-licensing-sspl
Software remains non-free with the critical change compared to
AGPL.
Quote:
The SSPL is designed to protect open source projects from
international cloud providers that were testing the boundaries of
the GPL, potentially harming the open source community. As a part
of that community, we want to do our part to make sure those that
benefit from open source tools like Graylog also give back.
It should be noted that the new license maintains all of the same
freedoms the community has always had with Graylog under GPL - they
are free to use, review, modify, and redistribute the source
code. The only changes are additional terms that make explicit the
conditions for offering a publicly available Graylog as a service.
The only substantive modification is section 13, which makes clear
the condition to offering Graylog as a service. A company that
offers a publicly available Graylog as a service must release the
software it uses to offer such service under the terms of the SSPL,
including the management software, user interfaces, application
program interfaces, automation software, monitoring software,
backup software, storage software and hosting software, all such
that a user could run an instance of the service using the source
code made available.
Section 13 of the SSPL reads as follows:
a. “If you make the functionality of the Program or a modified
version available to third parties as a service, you must make the
Service Source Code available via network download to everyone at
no charge, under the terms of this License. Making the
functionality of the Program or modified version available to third
parties as a service includes, without limitation, enabling third
parties to interact with the functionality of the Program or
modified version remotely through a computer network, offering a
service the value of which entirely or primarily derives from the
value of the Program or modified version, or offering a service
that accomplishes for users the primary purpose of the Software or
modified version.”
5. Timescale:
https://blog.timescale.com/blog/building-open-source-business-in-cloud-era-v2/
Rendering the software proprietary, as they forbid users to use it
as a hosted database as a service:
Quote:
At the time, the TSL was a radical idea: a source-available license
that was open-source in spirit, but that contained a main
restriction: preventing companies from offering software licensed
under the TSL via a hosted database-as-a-service
6. Redis database:
https://redislabs.com/blog/redis-labs-modules-license-changes/
Rendering modules to be proprietary software:
Quotes:
Early in August 2018, Redis Labs was one of the first open source
companies to realize that the current open source licensing scheme
falls short when it comes to use by cloud providers. We wanted to
make sure open source companies could continue to contribute to
their projects, while still maintaining sustainable business in the
cloud era. That’s why we changed the license of our Redis Modules
from AGPL to Apache2 modified with Commons Clause.
It was not an easy move for us, and we probably didn’t communicate
the change clearly enough. This caused some confusion when some
people incorrectly assumed that the Redis core went proprietary,
which was never the case (see more here).
However, over time, other respected open source companies, like
MongoDB and Confluent, created their own proposals for modern
variants to open source licensing. Each company took a different
approach, but all shared the same goal — stopping cloud providers
from taking successful open source projects that were developed by
others, packaging them into proprietary services, and using their
market power to generate significant revenue streams.
RSAL is a software license created by Redis Labs for certain Redis
Modules running on top of open source Redis. RSAL grants equivalent
rights to permissive open source licenses for the vast majority of
users. With RSAL, developers can use the software; modify the
source code’ integrate it with an application; and use, distribute
or sell their application. The only restriction is that the
application cannot be a database, a caching engine, a stream
processing engine, a search engine, an indexing engine or an
ML/DL/AI serving engine.
Now as conclusion to above quotes, in my opinion the AGPL shall be
updated and help authors of software to easier enforce and demand
their rights.
Why?
If the AGPL provides hyperlink to corresponding source code, then it
is very clear and evident that license has been respected and users
and author may verify it straight.
The evidence is then easier given to courts and authors can enforce
their rights in the courts. There will be less license changes.
Authors have spoken, and have done actions and changed licenses, some
software became proprietary.
This tells that AGPL as of now is not enough, and has to be revised,
to help authors easier enforce their rights.
Jean
- SSPL or server side public license, GNU better update the AGPL, Jean Louis, 2021/03/18
- Re: SSPL or server side public license, GNU better update the AGPL, Alfred M. Szmidt, 2021/03/20
- Re: SSPL or server side public license, GNU better update the AGPL, Jean Louis, 2021/03/21
- Re: SSPL or server side public license, GNU better update the AGPL, Alfred M. Szmidt, 2021/03/21
- Re: SSPL or server side public license, GNU better update the AGPL,
Jean Louis <=
- Re: SSPL or server side public license, GNU better update the AGPL, shulie, 2021/03/21
- Re: SSPL or server side public license, GNU better update the AGPL, Jean Louis, 2021/03/22
Re: SSPL or server side public license, GNU better update the AGPL, Florian Weimer, 2021/03/21
- Re: SSPL or server side public license, GNU better update the AGPL, Jean Louis, 2021/03/21
- Re: SSPL or server side public license, GNU better update the AGPL, Florian Weimer, 2021/03/21
- Re: SSPL or server side public license, GNU better update the AGPL, Jean Louis, 2021/03/21
- Re: SSPL or server side public license, GNU better update the AGPL, Florian Weimer, 2021/03/21
- Re: SSPL or server side public license, GNU better update the AGPL, Jean Louis, 2021/03/21
Re: SSPL or server side public license, GNU better update the AGPL, Jacob Bachmeyer, 2021/03/21
Re: SSPL or server side public license, GNU better update the AGPL, Jean Louis, 2021/03/22