On 15/05/2010 21:56, Benson Margulies wrote:
I think that perhaps there's an important distinction being missed
here. Central doesn't vacuum up artifacts from unsuspecting authors.
Other people put them there. If the authors of code choose to deposit
jar files on central, then it's not central who is 'distributing' them
-- it's the authors. In this case, it's people who download from
central and then repackage on their own who are responsible for
worrying about tracking down and including licenses.
The tricky case here is the non-author publishers, as with the
recently-announced mechanism. If I take a jar of OSS from its author's
distro, and push it to central without a license file, I am probably
violating the license. It's not clear to me that Sonatype is.
Thus, what I take from this thread is that it would be a kindness for
Sonatype to add a feature to the new publication mechanism to upload
the actual license. It could then be added to META-INF or just
published as an accompanying artifact, either way, and then no one
would have anything to complain about.
I don't think I would have made the publisher/distributor distinction in
that order. If a publisher publishes a book, bookshops are the ones
distributing it. You are certainly right there's a grey area there,
though. To some extent, the central repository situation may be similar
to other services that host content (and practically, they can't always
check everything indeed, in my opinion).
This being said, I'm not sure it makes sense to argue that the central
repository does not distribute software; to me it clearly does.
I also think that it's not sufficient to say that because the authors
are the ones asking for it to be distributed, it's OK. It's not always
all the authors or all the copyright holders. Pieces of OSS often
include other pieces of OSS, from other projects, that may have been
included under the same or other licences. The full list of copyright
holders that may extend beyond the list of people being involved in a
particular project.
Coming back to a case I know well:
http://jira.codehaus.org/browse/MAVENUPLOAD-2293
Admittedly, it's a small drop in the ocean of open-source software.
Nevertheless, the bundle linked from the JIRA entry
(jsslutils-0.5.1-bundle.jar), which was produced with
maven-repository-plugin-2.0 did include a LICENSE.txt file (made
mandatory by that version of the plugin).
(a) This licence file never made it to the central repository.
(b) This feature was removed from maven-repository-plugin-2.1 and
following versions: LICENSE.txt files and no longer included in the
bundles as far as I can tell.
I'm allowed by my management to release this software under a BSD-style
licence, but the copyright holder still is my institution: the
institution is licensing users to do what the licence say they can do,
not me as an individual. One of the reasons I'm allowed to publish this
code and ask to have it placed in the Maven repository, is that there's
an expectation that the licence will be respected. The problem is that,
when copyright holders (individual or institution) realise that the OSS
licence they've granted isn't respected, they might be less keen to
publish OSS again.
It might be worth doing this just to avoid those voices in the wide
world who like to write alarmist postings about Maven distribution
(e.g. Saxon's author).
(Sorry, I'm not aware of the postings you're referring to.)
Don't get me wrong, I'm very happy to have the software I write
distributed on the central repository, and I'm happy to use the content
of the repository too. Maven isn't perfect, but it's very useful.
One of the main reasons it's useful is the amount of software available
in the central repository. It's a system that's good for authors (it
makes it easy to encourage usage of their work), good for whoever
promotes Maven (presumably Sonatype) and of course good for its users.
What I'd like to see is a bit more action towards the respect of the
licence, which is what makes OSS work in the end.
I'd therefore like Sonatype to improve the publication of licenses as
they were bundled and to put that feature (or something similar) back in
the following versions of the plugin.
Best wishes,
Bruno.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
