Move Torrust-Tracker to Apache License 2.0 to Match Aquatic Tracker

[da2ce7]

Hello @WarmBeer,

I would like to propose that we change the license of this repository (Torrust Tracker) to the Apache License 2.0.

My primary motivation for promoting this change is to have bi-directional license comparably with the aquatic: high-performance open BitTorrent tracker.

Currently our license permits us to take code from aquatic's repository, however, we are not able to return the favor of allowing our code to be copied by @greatest-ape.

It should be noted that we in-fact already depend on some of aquatic's code by using the crate: UDP BitTorrent tracker protocol to support our udp tracker implementation.

Other Contributors: @naim94a @Power2All @josecelano @da2ce7 @pataquets @Aimless321 @ftsimas @makefu
In-Copy @cgbosse

---

Question: Are there any real benefits for using the AGPL for Torrust-Tracker?

Question: Do you support the idea of moving Torrust Tracker to the "Apache License 2.0" and are also happy to change the license of your contributions in support ?

[mickvandijke]

Hey @da2ce7 ,

I fully support switching to either Apache 2.0 or MIT. Distributing binaries would be a lot easier without having to work out all the incompatible licenses with AGPL :). I think it would also be more inviting for other developers and companies to build upon Torrust if we had a less restrictive license.

[josecelano]

Related PR: #251

[josecelano]

Hi @da2ce7 since what we are using is very little I would propose doing our own implementation and remove the dependency from the aquatic_udp_protocol. I think there are at least two reasons:

1.- I could implement serialization for some structs. See greatest-ape/aquatic#172
2.- It would make our code easier. For example, we have a wrapper for the announce request:

pub struct AnnounceWrapper {
    /// [`AnnounceRequest`] to wrap.
    pub announce_request: AnnounceRequest,
    /// Info hash of the torrent.
    pub info_hash: InfoHash,
}

or we are using our InfoHash and the InfoHash in that package. I think that adds a lot of complexity and it's not a lot of code to maintain. I think the benefit of having our own struct is greater than the cost of maintaining that code.

cc @WarmBeer

[josecelano]

We can change the license anyway so other people can take advantage of what we do.

[mickvandijke]

Agreed. The duplicate structs are confusing.

[makefu]

Hey! I support whatever change you want to do, my contribution is minuscule though ;) Cheers!

[cgbosse]

• Reducing dependencies is good if it is not complicated to do so. I would go ahead with this @josecelano .

• Changing the license is not an issue in my opinion if others want to make use of our code, I think it is a good move since we are about sharing our code and adding value to the community. @da2ce7 Everybody is ok with this. In case nobody says anything in the coming 7 days I will proceed with this.

[Power2All]

Apart from this software, I'm currently working on my own framework, using Actix, to start a basis on the WebTorrent/WebRTC support, since WebTorrents use some more details that browser share between them in order to exchange data. I will be sharing that work with @josecelano when I got a concept working.

My own tracker code's purpose is to create both a Open tracker that currently handles roughly 650k to 750k connections per minute on both TCP (HTTP/HTTPS) and UDP, and private tracking support. Now I want to introduce as well the WebSocket protocol, but that needs it's own pocket of data (BTreeMap with SkipMap), since WebTorrent clients are unable to chat with normal BitTorrent clients.

[josecelano]

Hi @Power2All , I'm also interested in WebTorrent/WebRTC support. I will be more than happy to see any work related to that. We have not included it in the next releases because it's a big effort and we are still somehow "cleaning" things.

[greatest-ape]

I do feel that it's a bit of a shame if you end up dropping aquatic_udp_protocol, but I can see why you would want to have your own serde trait implementations suiting your particular use case. In the latest (currently unreleased) version, I'm also giving up some ergonomics for improved performance, which is a tradeoff that you might not be happy with.

If you end up copying the files, the standard method of attribution would be to prepend them with the following license notice (modify file paths if applicable):

// Copyright 2024 Joakim Frostegård
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
//
// Retrieved from the aquatic project (https://github.com/greatest-ape/aquatic),
// file path "/crates/udp_protocol/src/request.rs".

[josecelano]

Hi @greatest-ape yes, I think it's a pity that we all can't not share common packages. In this case, we have a wrapper and that adds complexity to our code. If the logic were more complex I would continue using the package but in our case maybe it's less effort for us to use ours.

We will add your license in case we copy it as it's but in fact, I think it would be different, just because we want something adapted to the rest of the code.

[greatest-ape]

Alright, I understand :-)

[greatest-ape]

An alternative would be for you to add Into implementations to convert to your own InfoHash or PeerId implementations. You could even add a trait to extract them and implement it for AnnounceRequest. And it seems from the serde issue you opened that you might not even end up needing serde support?

[da2ce7]

@cgbosse Either using Aquatic UDP implementation as a copy-paste or as a library, or even re-implementing it ourselves. I do not see any reason not to proceed with the re-licensing to Apache License 2.0. 👍

[cgbosse]

So we proceed and relicense to Apache License 2 as the main license, and also als mentioned in the readme dual together with, MIT-0.
Closing the discussion and opening an issue.