Hi, just wanted to add what I have learned during Stanbol incubation:
The ASF releases source code, only. The repo should contain only the sources - and no binary code (JARs) at all. This is fundamental to the idea of open source. Once you start hosting binaries the users can not be sure what they get. If your build needs additional JARs that are not available at places like Maven Central, then you should create a "-deps" package that contains the needed JARs. You can put this -deps package for download in your dist section and mark it as a download for convenience (i.e. be clear that it is not an officially released artifact). Do not host such JARs in your repo. And the JARs need to have a license that is compatible with the AL20 license. Best, - Fabian 2012/10/1 Upayavira <u...@odoko.co.uk>: > Here's my take: > > As I see it, anything that goes into SVN we need to be sure we have the > _legal_ right to redistribute, regardless of any compatibility or > otherwise with the Apache License (e.g. GPL in our repo is not a > disaster). > > It is a _policy_ decision of the ASF that anything that goes into ASF > releases is compatible with, and sublicensable under the Apache License. > > So long as it is legal to redistribute them, it is okay to have them in > SVN. If it is not legal to redistribute, we should certainly delete > immediately from HEAD, and whether we do more than that would, I guess, > be up to the copyright holder (assuming they knew it was there at all). > > Upayavira > > On Sun, Sep 30, 2012, at 11:14 PM, Daniel Shahaf wrote: >> If you've not released it and you've deleted it from HEAD of all >> branches, I think you're fine. >> >> Noah Slater wrote on Sun, Sep 30, 2012 at 23:09:45 +0100: >> > Okay cool. >> > >> > My root concern was that we have non-OS data in our repository. But if you >> > think that's an academic concern (i.e. we've not released it, so it doesn't >> > matter) then okay. >> > >> > On Sun, Sep 30, 2012 at 11:02 PM, Daniel Shahaf >> > <d...@daniel.shahaf.name>wrote: >> > >> > > Noah Slater wrote on Sun, Sep 30, 2012 at 22:50:48 +0100: >> > > > In relation to the non-OS jars, Chiradeep Vittal wrote: >> > > > >> > > > I am currently downloading them from the repository history. >> > > > >> > > >> > > If it's just one developer who does it in his own personal builds of >> > > HEAD, builds which don't leave his personal dev environment, I don't see >> > > the problem. >> > > >> > > > >> > > > Presumably he is doing this because he knew of their existence before >> > > they >> > > > were removed (they were part of the original import from Citrix), and >> > > finds >> > > > it convenient to snag them each time he's preparing a build. >> > > > >> > > > >> > > http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201209.mbox/%3ccc78b251.2ea43%25chiradeep.vit...@citrix.com%3E >> > > > >> > > > On Sun, Sep 30, 2012 at 10:46 PM, Daniel Shahaf >> > > > <d...@daniel.shahaf.name >> > > >wrote: >> > > > >> > > > > To clarify, are you saying that people download jars directly from >> > > > > version control history? Where do they find the references to their >> > > > > existence there? >> > > > > >> > > > > Noah Slater wrote on Sun, Sep 30, 2012 at 22:41:53 +0100: >> > > > > > Hey, >> > > > > > >> > > > > > It came up on the CloudStack list that we have non-OS (I don't know >> > > the >> > > > > > specific license, but I can find out if it's important) jars in the >> > > > > > repository, and some people (at least one) is downloading them from >> > > that >> > > > > > location for convenience. >> > > > > > >> > > > > > Obviously, we're not going to ship them, and we can certainly >> > > > > > delete >> > > > > them. >> > > > > > (This may've happened already.) But what I wanted to know was: do >> > > > > > we >> > > have >> > > > > > to do anything about the fact that they exist in the repository >> > > history? >> > > > > > >> > > > > > Thanks, >> > > > > > >> > > > > > -- >> > > > > > NS >> > > > > >> > > > >> > > > >> > > > >> > > > -- >> > > > NS >> > > >> > >> > >> > >> > -- >> > NS >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Fabian http://twitter.com/fctwitt --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
