Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch from permissive to free software license #3261

Closed
ghost opened this issue Nov 4, 2019 · 4 comments
Closed

Switch from permissive to free software license #3261

ghost opened this issue Nov 4, 2019 · 4 comments

Comments

@ghost
Copy link

ghost commented Nov 4, 2019

Hello friends. Hopefully this is a no-brainer, but please for version 1.0 switch to a freedom-respecting software license such as AGPL or SSPL. If you cannot switch to a free software license, please indicate why for the benefit of the community considering shifting away from NPM.

For a gentle introduction to the free software movement please read this short, informative and recent article from James Halliday titled [Open Source is Not Enough] (https://notesfrombelow.org/article/open-source-is-not-enough).

@rsp
Copy link
Contributor

rsp commented Nov 4, 2019

Deno is already released under a free software license.

You seem to be confusing a free software license with a copyleft license.

All MIT/BSD/X11/Expat etc. licenses are not only considered free software licenses by the Free Software Foundation, but they are also explicitly listed as GPL-compatible licenses by the Free Software Foundation. For more info, see: https://www.fsf.org/licensing

In short, Deno is licensed under a license that is:

  • open source
  • free software
  • OSI-certified
  • FSF-approved
  • DFSG-compliant
  • GPL-compatible

It basically means that what you are asking for is already true. You can take all Deno and act as if it was licensed under a copyleft license of your choice if you wish so. If, on the other hand, Deno was explicitly licensed under one of the copyleft licenses, then you would not be free to combine it with software released under an incompatible copyleft license, thus your freedom would be largely restricted (see for example why ZFS has not been integrated in Linux yet - not for technical reasons and not for the lack of will to do it, but exactly because those two free software projects have incompatible licenses and the mechanism to "enforce the freedom" is indeed restricting the freedom to use both of the projects together - thankfully Deno did not make this mistake).

@rsp
Copy link
Contributor

rsp commented Nov 4, 2019

Just to get you some more context:

Deno complies with all 4 of the Essential Freedoms defined in The Free Software Definition of the Free Software Foundation:

And it complies with all 10 points of The Debian Free Software Guidelines from the Debian Social Contract:

It also complies with all 10 points of The Open Source Definition by the Open Source Initiative:

It cannot really be more "free software" (and "open source" if you will) than that, at least in my estimation. But if you are concerned about not having some of the freedoms explained by FSF/DFSG/OSI then please be more specific.

@ry
Copy link
Member

ry commented Nov 4, 2019

We are sticking with MIT. Being able to link to Deno in commercial software is an important use case.

@ry ry closed this as completed Nov 4, 2019
@ghost
Copy link
Author

ghost commented Nov 5, 2019

First of all thank you for taking the time to respond to this important issue. It's clear license discussions are not what gets most of us out of bed in the morning. When leading a community project please consider prose and form in accepting contributions on GH such as this issue. The BDFL style issue close wasn't necessary and shutting the DOOR on discussion without hearing others out shows close-mindedness.

That said, I'd like to take this opportunity to bring what I've learned of the MIT to the community's attention in hopes of opening some eyes:

  • MIT was not designed for community projects. It's an academic license and assumes one institution holds the copyright – almost never the case with projects like Deno.
  • There is no express patent grant. In other words, if someone wants to sue later MIT leaves the door open as a result of its ambiguous language. Why settle for that ambiguity when clarity can be had in not using a 30 year-old academic license for a community project like Deno?
  • MIT is an attribution landmine. It expects no contributions from the community and what ends up happening is the license, as simple as it appears to be, often gets lost or munged the moment someone wants to copy a small piece of the project and not carry around a whole license for that, or doesn't want to contribute back as we often see in proprietary software. I'm sure many of you have seen this if not made the same mistake yourselves in the past.
  • MIT may be compatible with GPL but it limits freedom to incorporate freedom-respecting software. In other words, no GPL software may be used inside Deno while it's under MIT. And while this may seem OK right now it inhibits the usefulness of this software long-term. Why not address that now rather than later?

Last thing I want to mention right now (I'm typing this from a mobile screen) is @ry stated he wants to link Deno in commercial software later. That's great if later you plan on limiting freedom by closing the source code but there are more apt licenses for that such as Apache 2 (compatible with AGPL) and the LGPL itself.

I encourage contributors to this project to open your minds a bit more and think about these important facts as using MIT with this project is almost certainly a mistake and there's still time to correct it with the right mindset.

Cheers.

mmastrac added a commit that referenced this issue Jul 31, 2023
Includes a lightly-modified version of hyper-util's `TokioIo` utility. 

Hyper changes:

v1.0.0-rc.4 (2023-07-10)
Bug Fixes

    http1:
http1 server graceful shutdown fix (#3261)
([f4b51300](hyperium/hyper@f4b5130))
send error on Incoming body when connection errors (#3256)
([52f19259](hyperium/hyper@52f1925),
closes hyperium/hyper#3253)
properly end chunked bodies when it was known to be empty (#3254)
([fec64cf0](hyperium/hyper@fec64cf),
closes hyperium/hyper#3252)

Features

client: Make clients able to use non-Send executor (#3184)
([d977f209](hyperium/hyper@d977f20),
closes hyperium/hyper#3017)
    rt:
replace IO traits with hyper::rt ones (#3230)
([f9f65b7a](hyperium/hyper@f9f65b7),
closes hyperium/hyper#3110)
add downcast on Sleep trait (#3125)
([d92d3917](hyperium/hyper@d92d391),
closes hyperium/hyper#3027)
service: change Service::call to take &self (#3223)
([d894439e](hyperium/hyper@d894439),
closes hyperium/hyper#3040)

Breaking Changes

Any IO transport type provided must not implement hyper::rt::{Read,
Write} instead of tokio::io traits. You can grab a helper type from
hyper-util to wrap Tokio types, or implement the traits yourself, if
it's a custom type.
([f9f65b7a](hyperium/hyper@f9f65b7))
client::conn::http2 types now use another generic for an Executor. Code
that names Connection needs to include the additional generic parameter.
([d977f209](hyperium/hyper@d977f20))
The Service::call function no longer takes a mutable reference to self.
The FnMut trait bound on the service::util::service_fn function and the
trait bound on the impl for the ServiceFn struct were changed from FnMut
to Fn.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants