RejectedSoftware Forums

Am 14.05.2017 um 22:52 schrieb Andre Pany:

Hi,
If I want to run an own dub registry server at the moment I have to adapt the source code.
The port and the mongo db settings I only have as environment variables (cloud foundry) and also the github address is hard coded into the source code of dub registry.

While dub itself is boost, dub registry has lgpl license type. I wonder what is the reason and whether this can be changed?

Somehow I feel really uncomfortable to edit source code with this license type...

Kind regards
Andre

Since the registry is accessible over the net (no binaries need to be
distributed), anything except AGPL won't require publishing changes. It
probably could be changed to Boost without losing anything, but there is
little practical reason for it as far as I can see.

Am 19.06.2017 um 20:02 schrieb Andre Pany:

On Sat, 27 May 2017 11:49:43 +0200, Sönke Ludwig wrote:

Am 14.05.2017 um 22:52 schrieb Andre Pany:

Hi,
If I want to run an own dub registry server at the moment I have to adapt the source code.
The port and the mongo db settings I only have as environment variables (cloud foundry) and also the github address is hard coded into the source code of dub registry.

While dub itself is boost, dub registry has lgpl license type. I wonder what is the reason and whether this can be changed?

Somehow I feel really uncomfortable to edit source code with this license type...

Kind regards
Andre

Since the registry is accessible over the net (no binaries need to be
distributed), anything except AGPL won't require publishing changes. It
probably could be changed to Boost without losing anything, but there is
little practical reason for it as far as I can see.

It would like to run an instance of the repository within a company network. The company has an own github enterprise server and therefore I need to change the source code of the dub repository.

There are no problems with this. Changes are allowed and they don't even
need to be published if the executable is only accessible over the
network (no matter if internal or public).

Another reason: there is a tool called Nexus. I provides repositories for maven and npm. If they decide to include support for dub repositories they cannot have a look at the gpl code.

I'm not a lawyer, but the license specifically talks about "copy from or
adapt all or part of the work in a fashion requiring copyright
permission". Just looking at the source and making decisions based on
that (other than just reciting the source code) does not appear to be
covered by this. Are there any precedences for this?

At the moment I try to build a dub dumb server. A pure http server which has the same apis as dub repository but creates the metadata(json) from the folder structure/zip files.

Kind regards
André

That would actually be nice to have as a simple alternative for cases
where none of the supported git frontends are used.