I've begun the implementation of the new license policy by re-licensing all of the packages that Lars listed in the stable/crypto category, re-licensing them in all four active trees. (I made them all Restrictive, but put a note in DescPackaging to indicate the original license.) I'll work on the others later.
As package maintainers make progress on the other approaches, they can revise their packages. I'll also put a statement about the new policy in the fink documentation. -- Dave Lars Rosengreen <[EMAIL PROTECTED]> wrote: > > I guess once we have this, for each package we'll need to: > > - Notify the upstream developers that they're sitting on a time bomb. > > :-) > > > > - Do one of the following, in order of preference: > > * Get permission from the upstream devel to link with OpenSSL > > * Link the package against OpenTLS > > * Link the package against the system OpenSSL (BuildConflict with > > Fink's version) > > * Remove the package from the bindist, possibly from unstable too. > > > > Any other options? > > To me the solution seems fairly simple: if a package has gpl (or lgpl) > in its license field and has a builddep on fink's openssl, then it > should no longer be included in the binary distribution, unless someone > can establish that the upstream authors permit linking against openssl. > We could change the license field of such packages to restrictive, or > better yet, create a new license category for cases like this where > fink may distribute source code but not binaries. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Fink-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-devel
