m...@mbtype.com wrote on 09/07/2015 01:47 PM:
Speaking as a lawyer (i.e., someone who always reads licenses, at
whatever cost to my brain cells) I agree it would be nice to surface
this information within the package system, much like dependencies or
documentation.
But speaking as a package developer, the idea that the package system
could have heuristics to determine “compatible” licenses is sticky as
molasses. Let’s suppose someone violates the heck out of my license.
“But the package system said I could!” So who’s responsible — the
licensee or the package system?
Ultimately, responsibility for adhering to a license rests on the
licensee. Thus, making it easy to make informed choices: good; making
it easy to evade responsibility: not so good.
I think this is an excellent and important point.
Some metadata encoding of popular licenses is good. But any checking by
the system should be very conservative in its logic, as well as very
conservative in any arguably-reasonable expectations to which that any
such checking might reasonably lead.
One thing that would be very useful is a dump of all the transitive
package dependencies and their dependencies, for human interpretation.
Note that, right now, such dumps are specific to version resolution
(e.g., version 1.0.1 of a package might depend on package "foo", but
version 1.0.2 instead depends on package "bar", with cascading
implications).
Another thing that might *eventually* become useful is programmatic
constraints by systems and/or packages. For example, let's say that
you're coding to the documentation of package "bleep", which you see is
documented as LGPLv3, but it might depend on packages you don't know
about, and the license of one of those packages might be be (or be
changed to) "GPLv3" without your knowledge. You might want to specify
in the metadata for your system the licenses for third-party packages
that you'll permit. Similarly, the package author of "bleep" might want
to similarly restrict the licenses of direct&indirect dependencies
(though we don't put that legal burden on the author of "bleep").
Separately, the author of GPLv3 package "xyzzy" might want to encode
that the package can only *used by* GPLv3+ packages. (I started this
paragraph by saying "eventually". I sugggest not going too far with
this just yet, because there are other complications I didn't get into,
and it's potential over-engineering territory, and easy to hit the wrong
balance before there is more real-world experience. I just wanted to
suggest the possibility, for any implications for how we think about
license metadata today.)
Neil V.
--
You received this message because you are subscribed to the Google Groups "Racket
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-dev+unsubscr...@googlegroups.com.
To post to this group, send email to racket-dev@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-dev/55EDD404.4070208%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.
