Usually? I'm not sure really.

NOTICE and LICENSE files are fine in source bundles, but they don't seem to be put into the source jars with the current bundling process. They probably don't belong to the binary jars anyway (unless perhaps in the META-INF directory, somewhere?).

Anyway, I don't really have to look far for counter-examples, where this notice isn't present. Just taking the first one in alphabetical order <http://repo2.maven.org/maven2/abbot/abbot/0.13.0/>:
- No mention of licence
- No reference to the original project
- No licence file in the jar file itself

After looking it up on Google, it looks like this project's licence is this: <http://abbot.sourceforge.net/doc/CPL.html>. I'll draw you attention to section 3, which maven.org seems to infringe on: there are no disclaimers or information on how to get the source are present, as required.
I haven't looked through all of them, but it's not an isolated case.


I think the bundling process should make sure the licences are there, but it currently isn't. Even when the licence is referenced, as I was saying, putting the licence type isn't enough. For example, "BSD" really means "BSD-style"; not all software released under a BSD-style licence has the "Regents of the University of California" as copyright holders. What you find here <http://www.opensource.org/licenses/bsd-license.php> for example is a template, not the actual licence.


I don't think it's realistic to expect Sonatype to go through all the jars to make sure there's a licence file somewhere. The practicality of Maven is something that I really enjoy, and I wouldn't like to see this practicality affected. However, what could be done to make things clearer is to enable (and perhaps force) the inclusion of a LICENSE file (or similar) during the bundling process, so as to make sure it's published in Maven repositories. Otherwise, people who redistribute software by providing the central Maven repository (and mirrors) are in breach of those licences.

Again, the blog post you mentioned talks about "unrestricted distribution". No OSS is strictly compatible with "unrestricted distribution" except when it's in the public domain. All have restrictions stating that distribution must at least comply with their licence (which most of the time requires to quote the licence itself).

All I'm suggesting is to have a mechanism to improve that in Maven. I have no doubt that what's being done now is done in good faith with the reasonable expectations that people can Google to find the actual project page, but this situation could be made right, I think.


Best wishes,

Bruno.


On 15/05/2010 03:17, Brian Fox wrote:
Usually this is handled by inserting NOTICE and LICENSE into the jar
files themselves. In theory you could attach the license file to the
main artifact using the "license" classifier but normally this isn't
done.

On Fri, May 14, 2010 at 7:20 PM, Bruno Harbulot
<bruno.harbu...@manchester.ac.uk>  wrote:
Thanks for the link. Perhaps someone could put it on this page:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html


Nevertheless, this doesn't really answer my question. The point I was making
was that, with the current model, licences are missing in most projects as
far as I can tell. There's often at best a URL to a licence file hosted
elsewhere than the repository.
Most OSS licences are fairly clear: the licence must be distributed along
with the software, whether in binary or source form (depending on the
content of the licence).
The fact that "Sonatype will perform some due diligence to make sure that
the artifact has a license compatible with unrestricted distribution, and we
will then promote the uploaded artifacts to the Central Maven repository."
[from your link] doesn't make the text of those licences appear from thin
air, and the bundling process doesn't seem to bundle those files.

'<license><name>BSD</name></license>' often doesn't refer to the actual same
licence for example. The copyright holder will be different from one project
to another, and redistributing software released under such a licence, but
without it, is effectively in breach of this licence (and there are plenty
of those in the central repository). One of the main point of OSS licences
is to acknowledge the copyright holders, at the very least.

I suppose one way to solve it would be to put the actual text within the
<description/>  element of the<license/>  element in the POM file that's with
the jars in the repository.

I'm just suggesting there should be, along with the POM file and the jars, a
place for a LICENSE.txt (and perhaps NOTICE.txt as some licences use) to
make this clearer. (Downloading them along with the artifacts would be a
plus, again, for the sake of abiding by these licences.)
Does this mechanism already exist? How is it done?


Best wishes,

Bruno.


On 14/05/2010 22:39, Brian Fox wrote:


http://www.sonatype.com/people/2010/04/uploading-artifacts-to-the-central-maven-repository-diy/

On Fri, May 14, 2010 at 11:46 AM, Bruno Harbulot
<bruno.harbu...@manchester.ac.uk>    wrote:

Hello,

Is there a way to prepare a bundle to be uploaded to the central
repository
so that it also contains the licence file?

Ideally, I'd like a licence file along these files, for example:
http://repo1.maven.org/maven2/org/jsslutils/jsslutils/0.5.1/

My POM contains this:
        <licenses>
                <license>
                        <name>BSD</name>
                        <url>LICENSE.txt</url>
                        <distribution>repo</distribution>
                </license>
        </licenses>

The licence file is next to the POM in the source tree, but it's never
included in the bundle or any of its inner jar files. I guess it could be
an
absolute URL that points to it, but it would be good to have a licence
file
bundled and uploaded with the other files, at least to respect the terms
of
the licence itself.


Best wishes,

Bruno.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reply via email to