svn commit: r479263 - in head/science: . namd namd/files

[Yuri]

On 9/8/18 6:11 PM, Adam Weinberger wrote:
> I'm not sure that that's sufficient, because if they require
> registration to download the release versions of code as a bundle,
> then circumventing it from a public git server might not be
> sufficiently different.
>
> If you'd like to reach out to upstream and ask them whether it's
> permissible for FreeBSD to distribute a script to recreate released
> source code bundles without registration, then that would probably be
> the best way to protect ourselves. In the meantime though, the ports
> need to be removed until we're sure it's safe for us to have it.


I agree, this is a good way to proceed.

I have contacted them and asked this question.


> It's clear you put a lot of work into making those ports work, but we
> have to take the conservative path here, which unfortunately means
> removing the ports until we know it's safe.


The need to stay on the conservative side is a bit less obvious to me here.

This isn't a life and death situation where one can only make one mistake.

The normal way of handling licensing issues is sending a violation 
notice or a cease-and-desist letter.

Nobody acting in a good faith is sued for licensing or patent violations 
right away, and it isn't obvious that these ports are in violation until 
we get a reply from them.


I also have a precedent with different software that has a very similar 
license: UCSF Chimera software similarly requires registering and 
clicking "I agree". It also has the open subversion server and build 
instructions.

I specifically discussed the similar situation with them, and pointed to 
the Arch port https://aur.archlinux.org/packages/ucsf-chimera , and 
after reviewing this Arch port they agreed that it isn't in violation.

Arch community ports are almost exactly the same as what our ports with 
LICENSE_PERMS=no-auto-accept no-dist-mirror no-pkg-mirror.


Let's wait and see what will they answer.


Regards,

Yuri