Re: [solved] Boost C++ source libraries are allowed to be used
On Thu, Oct 27, 2011 at 8:11 PM, Oliver-Rainer Wittmann orwittm...@googlemail.com wrote: Hi, the Boost C++ source libraries which we are using in our project can still be used under the Apache's rules. The Boost Software License Version 1.0 is now been classified as a category A license - see corresponding jira issue t and http://www.apache.org/legal/resolved.html#category-a (The legal community at Apache is self-organising and volunteer led. Karma is earned by contribution so it's essential that developers actively engage.) So thanks to Dennis for his analysis and to Oliver for reporting the issue. Robert
Re: Shutdown of the download.services.openoffice.org host and its Mirrorbrain instance
On Mon, Oct 24, 2011 at 2:08 AM, Marcus (OOo) marcus.m...@wtnet.de wrote: snip The problem is that the ASF do not want to host and provide services of special software for single projects. I can understand this as even the ASF infra is a team of volunteers and their time is limited as it is for all others. I think this is a little open to misinterpretation. Hopefully a Mentor will jump in but (until they do) I'll do my best to explain a little bit more about the way infrastructure works here at Apache... The infrastructure team at Apache is an independent, volunteer-led self-organising community of experts. Apache delegates infrastructure to this community, and provides resources to sustain their work[1]. When asking infrastructure for help, it's essential to remember this and engage with them as peers with special expertise. Anyone arriving with a solution or a request for a new service must expect to be challenged to defend and refine their choice of solution. To move back to the particular, this is a migration issue. A valuable service is about to be closed and needs to be migrated. Whether this is right long term solution is open to debate but accepting a service for a temporary period doesn't raise the issues that committing to provide a similar service for all projects forever would. Please explain the problem to infrastructure and ask for their help to find a solution. Robert [1] The team has a budget and some flexibility to bring additional resources - included hired help - when needed. Apache has adequate financial resources but is culturally resistant to committing to additional spending without good reason. Apache values independence. Dependency on funding risks that independence.
Re: Shutdown of the download.services.openoffice.org host and its Mirrorbrain instance
On Tue, Oct 25, 2011 at 12:36 PM, Christian Lohmaier cl...@openoffice.org wrote: Hi Dennis, *, On Tue, Oct 25, 2011 at 2:04 AM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: I read somewhere, and I don't know where, that ASF did not want torrents to be used. I'm guessing that the issue is related to ensuring the integrity and authenticity of packaged releases. That doesn't make sense - integrity is assured by bittorrent by providing sha1sums for each chunk. And authenticity can be assured just like it is with regular releases - just include a corresponding signature file within the torrent. Better to download the signature over HTTPS but yes, I see no reason why this approach could not be made to work I may have dreamed it or I am mixing this up with something else. If those were the only reasons, then they were made-up arguments. When engaging with Infrastructure, expect to be challenged and to have to defend any proposal. These lists are open, so expect a range of cluefulness from contributors. The best way to impress the core infrastructure team is for plenty of clueful people from a project to show up and defend the proposal with well research arguments. Giving up and going away is the surest way to lose the argument... Robert
Re: Shutdown of the download.services.openoffice.org host and its Mirrorbrain instance
On Tue, Oct 25, 2011 at 1:04 AM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: I read somewhere, and I don't know where, that ASF did not want torrents to be used. The meaning and force of this statement is hard to judge without a full context Apache has surprisingly and confusingly little policy, and most of that should be written down Apache encourages wide participation on open lists. Conventionally, opinions expressed on lists are just personal opinions - unless backed by evidence or clear marking[1]. So this is just my personal opinion ;-) Robert [1] wearing a hat :-) http://www.apache.org/foundation/how-it-works.html
Re: Shutdown of the download.services.openoffice.org host and its Mirrorbrain instance
On Tue, Oct 25, 2011 at 1:38 PM, Christian Lohmaier cl...@openoffice.org wrote: Hi Robert, *, On Tue, Oct 25, 2011 at 2:15 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: On Tue, Oct 25, 2011 at 12:36 PM, Christian Lohmaier cl...@openoffice.org wrote: [...] That doesn't make sense - integrity is assured by bittorrent by providing sha1sums for each chunk. And authenticity can be assured just like it is with regular releases - just include a corresponding signature file within the torrent. Better to download the signature over HTTPS but yes, I see no reason why this approach could not be made to work With signature I meant a real signature (gpg signature), not a md5sum or sha1sum file. When it is a cryptographic signature, it doesn't matter how you download it, as it cannot be faked. (of course the user has to get the proper key, but that's a different issue) FWIW it's a defense in depth measure[1] I may have dreamed it or I am mixing this up with something else. If those were the only reasons, then they were made-up arguments. When engaging with Infrastructure, expect to be challenged and to have to defend any proposal. These lists are open, so expect a range of cluefulness from contributors. The best way to impress the core infrastructure team is for plenty of clueful people from a project to show up and defend the proposal with well research arguments. Giving up and going away is the surest way to lose the argument... With OOo the tracker network[1] was run independently anyway and not hosted on the Oracle or OSUOSL hosted infrastructure. The main tracker was Mike's at utwente, and that mirror also was the initial/main seed for all the releases. There were other trackers linked together via a tracker-hub (backup tracker as well as the hub were provided by Harold). So it is not a matter of infrastructure, but a matter of policy. Where's the URL for this policy? Robert [1] Consider an attacker with some ability to fabricate convincing signatures. Downloading the signature from a trusted server means that such an attacker would need to replace an existing signature on secure hardware without detection. The small increase in traffic is a small price to pay for this additional defense in depth.
Re: Clarification on treatment of weak copyleft components
On Thu, Oct 20, 2011 at 10:41 PM, Rob Weir robw...@apache.org wrote: On Thu, Oct 20, 2011 at 5:27 PM, Sam Ruby ru...@intertwingly.net wrote: On Tue, Oct 18, 2011 at 12:08 PM, Rob Weir robw...@apache.org wrote: snip Now, for our SVN, we need to host the actual source of the MPL components, since we need to build the binaries on the platforms that we support. And in several cases we have patches the original source. Is this a problem? That normally is highly discouraged / not allowed. Archiving the compressed source of weak copyleft dependencies in some sort of repository[1] is something that Apache will need to become comfortable with sometime soon But developing downstream derivative works of weak copyleft dependencies is likely to be a major issue Why can't the patches be contributed back to the original projects? There is no intent to hoard. From talking to developers on this project I get the sense that they want to upstream patches more than was done previously. But contributing a patch is no guarantee that it will be integrated by the other project in a timely manner. Simply having it checked in by the 3rd party component, but not yet in their release, is also not optimal, for stability and supportability reasons. Release schedules don't always sync up. Downstream packagers face similar issues and typically cope by maintaining independent patch sets (applied at build time). Why not just use patch sets? Robert [1] Many weak copyleft licenses require distributors to maintain the code beyond the lifetime of the organisation which issued the original license. We need to get used to the idea that Apache is likely to be around much longer than commercial players.
Re: Clarification on treatment of weak copyleft components
On Sun, Oct 23, 2011 at 1:53 PM, Rob Weir robw...@apache.org wrote: snip There is no intent to hoard. From talking to developers on this project I get the sense that they want to upstream patches more than was done previously. But contributing a patch is no guarantee that it will be integrated by the other project in a timely manner. Simply having it checked in by the 3rd party component, but not yet in their release, is also not optimal, for stability and supportability reasons. Release schedules don't always sync up. Downstream packagers face similar issues and typically cope by maintaining independent patch sets (applied at build time). Why not just use patch sets? That is what we do. We store the original source in a tarball and then apply a patch at build time. But we store both the source tarball and the patch on our servers. Dependency managers frequently used elsewhere at Apache[1] typically use meta-data to describe dependencies for location. Does the current build system work in a similar way? Robert [1] eg http://ant.apache.org/ivy/ and http://maven.apache.org/
Re: License implications of build-time or test-time dependencies?
On Thu, Oct 20, 2011 at 9:37 PM, Rob Weir robw...@apache.org wrote: On Thu, Oct 20, 2011 at 4:07 PM, Sam Ruby ru...@intertwingly.net wrote: On Thu, Oct 20, 2011 at 12:08 PM, Pedro Giffuni p...@apache.org wrote: Hmm ... We have discussed some of the things that must be replaced but we have not drawn a roadmap about it beyond the initial migration list. I think we will have to open BZ issues for those. The gtk/qt issue is rather critcal: I do not think there is previous history among Apache projects depending on them but if we cannot consider those system provided libraries it would be a serious setback to an early Apache release. I would support allowing C/C++ code to link to gtk and/or qt, provided we don't distribute gtk or qt themselves. Both are LGPL. The LGPL is clear for languages like C, C++. Clear in what sense? Dynamic linking and such? Before Version 3, the meaning of the LGPL - when applied to many dynamic and interpreted languages - was sufficiently debatable to pose a definite legal risk. It would be surprising but not unreasonable for a court to rule that the license was strong (not weak) copyleft for some languages. Robert
Re: Please remove this unused header (was Re: Anti-grain Geometry)
On Tue, Oct 18, 2011 at 1:20 AM, Pedro Giffuni p...@apache.org wrote: Hello; This header has license issues: main/agg/inc/agg_conv_gpc.h It is part of the General Poligon Clipper and unlike the rest of AGG its free only for non commercial use. I would delete it myself but my desktop computer decided it wants vacations in some repair center :( AIUI I have OOo karma but I would prefer to have an issue to work from. Could you open one? Robert
[licensing] Re: License implications of build-time or test-time dependencies?
On Tue, Oct 18, 2011 at 4:55 PM, Rob Weir robw...@apache.org wrote: Another question that has come up based on review of OpenOffice code. If a 3rd party module is used as part of the build or test automation, but is not part of our release, do we care about whether it is copyleft? Or do we only care if the 3rd party modules is part of the release? Rules about releases apply only to the artifacts themselves A minority of build and testing tools have licensing impact, and care needs to be taken about them. In particular, some tools produce output which cannot be included within an Apache release. For example, our Windows builds use the Microsoft C/C++ compiler. It is not OSS at all. But installing it is a pre-req to build on Windows. But we don't include the compiler in our release. I assume this is OK. +1 On Linux we rely on available GNU/Linux build tools, almost all copyleft, but they are not part of the release. So I assume it is OK. +1 A trickier case: CppUnit. This is not a standard platform module. It is LGPL. We use it as a framework for unit testing. It is the C++ equivalent of JUnit. I think we should be shipping our unit tests with our source releases. This is really useful for downstream consumers of the code to use when enhancing AOOo, to check for errors. If we don't include CppUnit in our releases, then a consumer of the source releases would need to download CppUnit separately as a pre-req. So would we when building AOOo. Downstream developers working from a source release would need to download and install the package if they want to run unit tests. This is the price they pay for their licensing convenience. For the convenience of downstream consumers who want to build and test for their own use, it would be possible to either * provide an additional build script in the source release that downloads additional dependencies (though IMHO the user should be informed by the script of the licenses for the artifacts downloaded), or * provide a convenience artifact following the binary release rules aimed at this group Are the considerations here, for build-time and test-time dependencies the same as for any other 3rd party modules in our release? Have I covered this well enough above, or would it be helpful for me to expand? Robert
Re: License implications of build-time or test-time dependencies?
On Tue, Oct 18, 2011 at 5:41 PM, Pedro Giffuni p...@apache.org wrote: One observation, before it slips through. Depending on gpl#39;d compilers and tools that we don#39;t carry in the release is fine AFAICT. In our bootstrap procedure we use Dmake (gplv1), which we must remove in favor of the external package, just like other OpenOffice forks do. A more controversial point is our use of GTK and Qt. Have these observations been recorded in an issue tracker? Robert
Re: How to handle the native language lists?
On Thu, Oct 20, 2011 at 8:04 PM, Rob Weir robw...@apache.org wrote: This question came up a few months ago, when we initially started the podling. The legacy OOo project had many mailing lists which were for non-English list traffic. snip So that's my proposal. I have my asbestos underwear on. Feel free to start the flaming, :-) (In these sorts of circumstances, I tend to deploy the infamous strawman phraseology rather than proposal) Robert
Re: Is the JRE license OK for inclusing in AOO?
On Thu, Oct 20, 2011 at 5:23 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: snip It is not clear to me that either of those bundlings in binary releases is explicitly tolerated by the information that is provided at http://apache.org/legal/resolved.html. There seems to be no help in the older draft either: http://apache.org/legal/3party.html. I also note that if one is bundling the JVM or building Windows distributions, there are library dependencies and API dependencies too, somewhere deep in the works. (The LibreOffice folk have apparently stopped any JVM bundling but I don't know what they do about Microsoft redistributables.) It seems that there is more that needs to be said about binary releases and how non-source, restrictive-license redistributables are incorporated in those releases to satisfy installation requirements and also provide run-time services to an Apache release. I thought I saw how that was tolerable so long as no source was provided and the redistribution terms were honored, NOTICE was provided, etc. I can't find anything clear-cut on looking again. IIRC Apache has historically strongly disliked but tolerated releases containing non-open-source but appropriately redistributable artifacts. When there is no clear consensus, there will be no clear policy. Would any of the open source options for executing Java code (Harmony, OpenJDK, etc) work? Robert
Re: [licensing] On Apache Releases [WAS Re: Clarification on treatment of weak copyleft components]
On Thu, Oct 20, 2011 at 9:01 PM, Rob Weir robw...@apache.org wrote: On Thu, Oct 20, 2011 at 9:06 AM, Robert Burrell Donkin snip At Apache, a source release is (just) what's in version control when the release is cut, is canonical and mandatory. Other artifacts follow the binary release rules, are optional and secondary. OK. So obviously no weak copyleft source files in our source release, i.e., in our source tarballs. +1 snip The approach we currently have for these components, in OpenOffice, is: 1) The 3rd party components are stored in a separate repository, not with the core product's SVN. So we reduce the opportunity for contamination. 2) The build script downloads the source for these components and compiles them. So we avoid the pre-req/provisioning issue. And we don't need to include the MPL code in the source distribution. It comes down automatically at build time, That may satisfy the letter of what I'm reading. But I'd be interested to hear what you think, whether something like that had been done at Apache before. Most projects use this sort of approach (though there is a strong minority view that thinks that they are wrong to do so) There has been historic resistance to hosting weak copyleft source at Apache but there's now a consensus that requirements to supply source in perpetuity mean that we'll have to host it sooner or later, most likely in a separate repository. Maybe it would be better, for example, to allow two build modes, one with and one without the copyleft components, and force the downstream developer to explicitly enable the compilation with weak copyleft components by changing a flag or something? Always a good idea to let developers know what's happening Some downstream consumers (in particular, packagers) want to compile against their own system dependencies so IMHO it'd be cleaner just to switch on or off dependency download, preferrably with fine control. Robert
Re: How voting works...
On Tue, Oct 18, 2011 at 11:50 PM, Ross Gardler rgard...@opendirective.com wrote: snip In other words, make every action of the PPMC as inclusive as possible. +1 Projects developed the Apache way only stay healthy when there is a continual flow from user to contributor to committer to PMCer. IMHO a positive, inclusive and open culture is therefore essential. Establishing such a culture is critical to long term success. Robert
Re: Copyright Notices, Source Headers and Licenses (By Example)
2011/10/15 Jürgen Schmidt jogischm...@googlemail.com: On Fri, Oct 14, 2011 at 3:28 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: On Thu, Oct 13, 2011 at 9:54 PM, Rob Weir robw...@apache.org wrote: snip So, strategy Will Apache Rat help with this? I thought it had a mode that added Apache headers. But I don't know if it handles something like this, where we are removing existing headers as well. This is something where automated help is essential. But I expect some tinkering and script development will be required. yes i agree and i am volunteering to take care of the license header change based on the final SGA file list. Great :-) Rat collects scripts of this sort [1], and has some examples which may (or may not) be useful. You'd be very welcome to develop them - or just take pick people's brains - over in the Rat community[2]. Since I think we have reasonable active consensus about strategy, I'll break out a new thread to discuss tactics Robert [1] eg http://svn.apache.org/repos/asf/incubator/rat/eye/trunk/ [2] http://mail-archives.apache.org/mod_mbox/incubator-rat-dev/
On The Tao Of CLAs [WAS Re: Copyright Notices, Source Headers and Licenses (By Example)]
On Sun, Oct 16, 2011 at 8:41 PM, Pedro Giffuni p...@apache.org wrote: I think we discussed this before but it would be excellent if Robert can further clarify it once and for all. Apache process evolves :-) Opinions differ and consensus emerges forever but I'll add a few words to the mix... I think that since the code is being clearly contributed to us through bugzilla we can apply section 5 Submission of Contributions. of the AL2. Of course we still have to make sure the author and the submitter are the same person, but bugzilla does do some minimal identity check. snip Just to check ... The Croatian dictionary has been re-submitted under an Apache License 2 (bug 96705), however the zip file submitted still contains the LGPL in the makefile. We should try to get the author to sign an iCLA. (or do we need an SGA?) This is not just a small patch. The author is contributing an entire dictionary. The Apache License, Version 2[1] contains a contribution clause which might suffice but I'm going to step and take a broader view :-) From a community perspective, any contributor of a substantial work is a potential asset. Encouraging and mentoring a contributor along the path towards becoming a committer is a satisfying experience but it is also an essential part of the open development model used at Apache. In some other models, a small number of dedicated core developers review patches from a large number of contributors. An open development model instead spreads the load across more developers with varying levels of energy. Healthy projects need a continuous flow from user to contributor to committer (and onwards to PMCer and Apache Member) bringing in new energy and ideas. Encouraging people to submit CLAs - as part of wider contact about how development works at Apache - often proves a wise investment. Every committer must have a CLA on file, so submitting one is a step on that road. It is also a reasonable test about how serious a contributor is about So, I think a good first step would be for a volunteer to jump in and reach out to the contributor in a positive fashion. If the contributor is happy to file a CLA and work towards karma, that's great. From substantial works, the extra ceremony associated with a grant It's important to establish consensus about general conventions for contributions. It's unfair to pick on particular contributors or contributions. So, I'd like to talk now a little more generally. Building a work from a series of small patches recorded in a version control system creates a convincing and detailed audit record. From a provenance perspective, complete and substantial works are much more tricky. When this sort of work arrives, the community should ask itself Why?. Perhaps there is no easy route for contributors to start working in this fashion, or perhaps one exists but isn't clearly documented. The additional ceremony required for software grants brings the advantage of clearer visibility, and are (for this reason) generally slightly preferable to CLAs for substantial works. When a substantial work arrives and a CLA or SGA has been sought but cannot be obtained, the legal risks presented by the work should be weighed. In this case, raise on legal-discuss or ask mentors to obtain advice. Source code allows reasonable expressiveness. Dictionaries are (in some ways) more difficult and risky but I'll save that for a follow up post. Robert [1] http://www.apache.org/licenses/LICENSE-2.0.html
Re: [DISCUSS] Publishing the PPMC Roster
On Fri, Oct 14, 2011 at 11:47 PM, Rob Weir robw...@apache.org wrote: On Fri, Oct 14, 2011 at 6:25 PM, Kay Schenk kay.sch...@gmail.com wrote: I think this is a wonderful idea and I would like to add an additional item -- can we get a list of folks who have submitted iCLAs toward this project, assuming they've filled in the notify project item? Another great mystery that might be nice to have unveiled. When someone submits an iCLA, and after it has been processed by the Apache Secretary, then their name shows up here: http://people.apache.org/committer-index.html#unlistedclas Note that this is not specific to AOOo. +1 There is an optional notify project field in the iCLA. If the person enters that, then ooo-private receives a note when the iCLA is filed. We saw that a few days ago for Andre Fischer. This sort of stuff is usually very possible providing that there are volunteers willing to step up. If anyone with some scripting foo and a few spare cycles would like to work on this with Apache infrastructure, then I'd be happy to make some introductions. Robert
Re: We're on slashdot!
On Sat, Oct 15, 2011 at 1:14 AM, Shane Curcuru a...@shanecurcuru.org wrote: And I'm on El Reg! http://www.theregister.co.uk/2011/10/14/apache_openoffice_alive_well/ Hope I did OK in the interview. At least I got a good closing quote, even if it was a little tweaked in the story. Perhaps in The ASF ... said that there was no need for additional donations we should have been more compassionate. AIUI the business model used by TDF and TeamOOo requires donations. Statements like this damage our relationship with potential downstream consumers, and risk reducing ecological diversity. A key goal should be to encourage the development of a rich and deep office office ecosystem. I would feel much more comfortable adopting the position that Apache does not need or use cash donations to fund development but encourages exciting and innovative downstream efforts of all kinds and understands that some not-for-profit players need donations right away to get keep hacking. But maybe some good could come out of this. Why not get together to release a statement clarifying who needs donations right now, why and what cool stuff they are going to fund with the cash? (Something positive with as many potential players as possible...) (Personally, I would love to see the FSF enter the ring with a downstream GPL GNUberOffice integrating emacs, R, GIMP etc) Robert
Re: Copyright Notices, Source Headers and Licenses (By Example)
On Thu, Oct 13, 2011 at 9:25 PM, Pedro Giffuni p...@apache.org wrote: Thank you Robert you've been very clear, but ... --- On Thu, 10/13/11, Robert Burrell Donkin wrote: ... Please jump in where I've been unclear) ... It is vital that only the owner (or their agent) alters a copyright notice unless specific written permission been granted. We have been respecting this part, perhaps to the extreme. Ideally Oracle should've had replaced the headers but to ease up thing we imported their development tree with the old copyrights. Typically, the entity donating the code will have at least one committer who can act as their agent in this. Otherwise, the Apache legal team needs to be involved. In this case, we have an okay from Oracle [1] to relocate the copyright notices There is an initial SGA, so I guess any committer can take the list of transferred files and commit a license change, right? This is about the copyright notices (eg Copyright 2000, 2010 Oracle and/or its affiliates.), not copyright licenses. Changing copyright notices is - from a legal perspective - an important action. Never change copyright notices without checking with the legal team[2]. Apache's legal paperwork allows the Foundation to issue licenses for most of the source released[3]. The original source headers simply inform the user that Oracle grants an alternative license. When Apache has our standard legal paperwork covering the source, these source headers can be replaced by the standard Apache boilerplate without worry. It's a lot of files so I wonder how other projects have managed this. I thought of creating a new branch and merging the changes back but that didn't receive support. Do tell us if there is a magical perl script to do these type of replacements :). There are scripts but it's important to confirm that everything changed is covered before altering headers Robert [1] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201110.mbox/%3cf291de8d-c108-41f2-a094-f5141da9d...@gbiv.com%3E [2] A major priority for Apache is to protect committers and the Foundation from legal risk. This means following the rules. [3] Exceptional source *must* have a header with the original license
Re: Copyright Notices, Source Headers and Licenses (By Example)
On Thu, Oct 13, 2011 at 9:54 PM, Rob Weir robw...@apache.org wrote: On Thu, Oct 13, 2011 at 4:12 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: snip It is vital that only the owner (or their agent) alters a copyright notice unless specific written permission been granted. And since the SGA does not specifically say that, I'm understanding that the SGA alone is insufficient. Whether or not the software grant is sufficient would take a court to decide... But as a matter of Apache policy, asking for written permission is both courteous and ethical as well as giving legal clarity. (Maybe in future we should add a check box for that to the SGA, or something like that?) Revising standard legal documents takes a lot of energy. Not sure there'd be traction to revise just for this but yes, I'd support adding something next time the software grant is revision. Raise a legal JIRA :-) Process at Apache continuously evolves. Almost always, committers have been available to act as agents. In this case, the community and the copyright owner have no intersection. If anyone could find a few cycles to submit a patch for the IP clearance process [1] reminding that written permission is needed in addition to the grant, that'd be great :-) snip So, for Apache committer authored files, SVN is the canonical record of the copyright owners contributions, and the Apache ID's used in SVN can be traced back to iCLAs, etc. +1 When committing a patch submitted from another contributor, the CLAs requires that the original contributor is credited. It is conventional to include information about the source of the contribution as well. For example, a JIRA number or a link to the mail-archives. The ALv2 includes the legal paperwork required to accept patches from contributors[2] without further ado. Again this allows version control to audit provenance. snip It sounds like we're asking for permission to remove the Oracle copyright statements from the individual source files and to put a statement in the NOTICE file like your [6]. This will probably require that Oracle confirm their preferred form for this, in particular the range of years. We have statements in individual files, but it looks like we need a statement that applies to the entire codebase. Roy is happy that Apache has the permission required[3]. So, I'm happy. Unless someone jumps in sometime soon then IMHO we'll have enough lazy consensus to progress... A source header[5] is legal boilerplate included within a document, and (as Apache understands it) excludes the copyright notice. For our example, the source header is [7] which gives some general meta-data, disclaims warranty and refers to a public license (LGPLv3) for the file (and so is quite typical). The copyright owner (or anyone with a appropriate license) may issue any number of licenses[8] for a document. An appropriate source header allows a license to be bundled with the document[9] but does not prevent the document being licensed in other ways. So the fact that Oracle gave us the source file under Apache 2.0 does not undo its availability under the previous LGPL license Bit more involved than that. Oracle has provided source offering a LGPLv3 license. Apache is distributing (through subversion) this source but anyone who wants to take advantage of that offer is taking a license from Oracle (not Apache). Oracle has also granted (non-exclusive) rights to Apache under a software grant. These rights enable Apache (not Oracle) to offer an ALv2.0 license for the source to the public (and continue to develop derived versions). This is a subtle distinction but important for some downstream consumers. For someone with a suitable alternative license, modifying or removing a source header should not required additional written permission. In particular, source arriving at Apache under a CCLA, ICLA or software grant should have a suitable alternative license. So that downstream consumers are clear about the license issued by Apache (and to simplify maintenance), policy asks that source arriving under CLAs and grants is edited to replace the existing header with the standard Apache source header [10]. ...however, in cases where the code is outright given to the project under ALv2 via mechanisms like an SGA, we replace other license headers with ALv2 headers. Apache prefers copyright licenses to ownership. Code copyright is almost never given outright. Apache agrees with contributors (through CLAs, software grants and ALv2 clause 5) that they license their contributions to Apache. Apache then offers an open source license for the work to the public. And what about the part that says DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER? If I understand correctly, we will request permission to move the copyright from Oracle. And that we don't need additional permissions to remove the header, beyond the permissions we have via
Re: [legal] How to clarify, if usage of Boost C++ source libraries is allowed
On Wed, Sep 28, 2011 at 12:44 PM, Rob Weir robw...@apache.org wrote: snip Honestly, I see clear answers from legal-discuss for only a small fraction of the questions that are submitted. I don't know if we're misusing that list or what. But it does not appear to operate like a list where you submit a questions and get a definitive answer in a finite period of time, It's is a sign that demand exceeds capacity :-/ The last time we were this busy, the contributions of a small number of lawyers (at major tech companies) really made the difference. Looks like they've drifted away. If anyone knows a lawyer who might be interesting in contributing, then please ask them to join the list. I recommend noting the slow response from legal-discuss as an impediment in the next podling report (to let the board know). Do Mentors have have an idea on whether we're approaching these questions the right way? (I'm not a mentor but please forgive give me for jumping in) Apache is sometimes described as a do-ocracy. Submitting patches is the path to karma. In particular, should be forcing the questions by proposing a categorization and seeking lazy consensus? For example, If there are no objections within 3 days to treating the Boost Licence as Category A compatible, then we assume lazy consensus and go forward with that treatment Dennis seems clueful :-) If he were to start proposing patches to complement his analysis, that would increase the probability that someone would apply them (by reducing the time required to implement the policy clarification). Robert
Re: Foundation blog posting on Apache OOo
On Fri, Oct 14, 2011 at 7:32 PM, Simon Phipps si...@webmink.com wrote: snip The question that Simon is asking is simple. Some have read the best wishes to TDF and LibreOffice as being sarcastic and mean spirited. I certainly didn't read it that way. The issue seems to be that the paragraph expressing this wish was within the flow of a different story about people not giving AOOo its due. All that he was asking was for an official clarification that you were being sincere and not sarcastic because of course sarcasm isn't going to help the politics. I assume the blog was on the up and up and am representing it as such. Hope you can clarify... Apache believes in Software Darwinism. A key meta-goal for Software Darwinists is to foster a richer and deeper ecosystem: more players, more ideas, more disruptive creativity. That's why the Apache License allows and encourages downstream consumers to create interesting new products with diverse licenses and business models. Confidence in the efficiency of our open development model means we're comfortable with encouraging competition. (Apache even goes so far as hosting competing projects.) So, of course we are sincere in welcoming and celebrating innovation by other players in the space :-) Robert
Re: Blog Created
On Sun, Jul 10, 2011 at 4:09 AM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Ah well. I've seen those kinds of blogs, that are essentially announcements. So it is a notices mechanism with a syndication feed. I will have to go look at one of the ones that seems to get lots of hits according to the headline/summary aggregator. Wonder if they get much by way of comments apart from spam. (Some of the FOSS planets seem to work well but Planet Apache is [in]famously off topic) I'm from the Naked Conversations school of blogging, so I may have to take my crayons to some other place where I can ponder the fright, frustration, and outright fun on an Apache project, the OpenOffice.org podling in particular. Sounds just about right for the committers aggregator[1] All committers welcome :-) See [2] for how to add a feed Robert [1] http://planet.apache.org/committers/ [2] http://www.apache.org/dev/blogs.html#personal-blogs
Copyright Notices, Source Headers and Licenses (By Example)
(Using [1] as an illustration. I recommend [2] for further reading. Please jump in where I've been unclear) A copyright notice is a simple claim of copyright ownership: for example Copyright 2000, 2010 Oracle and/or its affiliates. It is vital that only the owner (or their agent) alters a copyright notice unless specific written permission been granted. Apache projects work in a highly collaborative fashion without assigning copyright to a single legal entity[3]. Copyright ownership is therefore complex. The version control system forms the canonical record of contribution authorship (when committers follow their CLA[4]). A secondary list of copyright ownership at the top of each document is difficult to maintain with the level of accuracy required by law. So, Apache policy [5] requires that copyright notices are removed or relocated (to the NOTICE document [6]). But the owner must either provide written permission or perform the changes themselves. In the case of our example[1], Oracle should be contacted ASAP and asked to provide written permission to either relocate or remove the copyright notices. A source header[5] is legal boilerplate included within a document, and (as Apache understands it) excludes the copyright notice. For our example, the source header is [7] which gives some general meta-data, disclaims warranty and refers to a public license (LGPLv3) for the file (and so is quite typical). The copyright owner (or anyone with a appropriate license) may issue any number of licenses[8] for a document. An appropriate source header allows a license to be bundled with the document[9] but does not prevent the document being licensed in other ways. For someone with a suitable alternative license, modifying or removing a source header should not required additional written permission. In particular, source arriving at Apache under a CCLA, ICLA or software grant should have a suitable alternative license. So that downstream consumers are clear about the license issued by Apache (and to simplify maintenance), policy asks that source arriving under CLAs and grants is edited to replace the existing header with the standard Apache source header [10]. For source that is not covered by CLAs or grants, different rules apply [11]. So the key question for every document is whether it is covered by the grant or it's inclusion relies on the application of an open source license. Questions? Want more details? Should I move on to strategy suggestions? Robert [1] /* * * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * Copyright 2000, 2010 Oracle and/or its affiliates. * * OpenOffice.org - a multi-platform office productivity suite * * This file is part of OpenOffice.org. * * OpenOffice.org is free software: you can redistribute it and/or modify * it under the terms of the GNU Lesser General Public License version 3 * only, as published by the Free Software Foundation. * * OpenOffice.org is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU Lesser General Public License version 3 for more details * (a copy is included in the LICENSE file that accompanied this code). * * You should have received a copy of the GNU Lesser General Public License * version 3 along with OpenOffice.org. If not, see * http://www.openoffice.org/license.html * for a copy of the LGPLv3 License. * / [2] http://rosenlaw.com/oslbook.htm [3] In contrast to the FSF who find that ownership is convenient for enforcement of strong copyleft license [4] http://www.apache.org/licenses/icla.txt clause 7 insists that committers clearly indicate any commits which are not their original work [5] http://www.apache.org/legal/src-headers.html [6] Add something like This software is based on code that is copyright 2000, 2010 Oracle and/or its affiliates. [7] * OpenOffice.org - a multi-platform office productivity suite * * This file is part of OpenOffice.org. * * OpenOffice.org is free software: you can redistribute it and/or modify * it under the terms of the GNU Lesser General Public License version 3 * only, as published by the Free Software Foundation. * * OpenOffice.org is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU Lesser General Public License version 3 for more details * (a copy is included in the LICENSE file that accompanied this code). * * You should have received a copy of the GNU Lesser General Public License * version 3 along with OpenOffice.org. If not, see * http://www.openoffice.org/license.html * for a copy of the LGPLv3 License. [8] Unless the owner is bound by
Re: How about a new branch for the legal changes? (was Re: A systematic approach to IP review?)
On Sun, Oct 9, 2011 at 7:42 PM, Pedro Giffuni p...@apache.org wrote: Hi; Looking at how big, and mostly cosmetic but necessary, a change it will be to bring in all the SGA license changes, and given that it requires manual intervention and is not something that can be done in one huge mega commit ... I think we should create a branch for this changes in merge them in two steps: corresponding to both SGAs. This way merging CWSs and bugzilla patches can go on without pain and people can get started on the header changes. I recommend separating review from (automated) execution. If this is done, a branch shouldn't be necessary... Robert
Re: Request dev help: Info for required crypto export declaration
On Fri, Sep 2, 2011 at 4:11 AM, Joe Schaefer joe_schae...@yahoo.com wrote: Off-topic. Please drop this line of inquiry and return to the Subject of this thread, which is about determining required info for the crypto export declaration. Which is collecting a list of sources [1] :-) OOo uses strong crypto so the OOo source will be in there One way to establish an initial source list is to go through OOo dependencies, separate out the cryptography libraries then find source URLs. This should be good enough to allow an initial notification to be sent. Robert [1] http://www.apache.org/dev/crypto.html#sources
Re: Request dev help: Info for required crypto export declaration
On Thu, Sep 1, 2011 at 7:38 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Please just do it this way: http://www.apache.org/dev/crypto.html ASF is very clear on what is required for *its* releases and this page appears to be comprehensive. The Apache rules break down into reporting to users and notification. Informing users is important but notification is urgent (making source available [1] counts as export). (I finally found where I saw this before. It has also been discussed here or on the ooo-private list before. I remembered it as being simpler than it is.) (It looks worse than it is) Following the instructions[3], step 1 is to work out whether OOo has any unusual cryptography beyond ECCN 5D002, which is: blockquote cite='http://www.apache.org/dev/crypto.html#classify Software specially designed or modified for the development, production or use of any of the other software of this list, or software designed to certify other software on this list; or Software using a symmetric algorithm employing a key length in excess of 56-bits; or Software using an asymmetric algorithm where the security of the algorithm is based on: factorization of integers in excess of 512 bits (e.g., RSA), computation of discrete logarithms in a multiplicative group of a finite field of size greater than 512 bits (e.g., Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve). /blockquote Does OOo rely on cryptography more exotic than this? Robert [1] http://www.apache.org/dev/crypto.html#overview [2] http://www.apache.org/licenses/exports/ [3] http://www.apache.org/dev/crypto.html#classify
Re: Request dev help: Info for required crypto export declaration
On Thu, Sep 1, 2011 at 8:00 PM, Rob Weir r...@robweir.com wrote: On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: On Thu, Sep 1, 2011 at 7:38 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Please just do it this way: http://www.apache.org/dev/crypto.html ASF is very clear on what is required for *its* releases and this page appears to be comprehensive. The Apache rules break down into reporting to users and notification. Informing users is important but notification is urgent (making source available [1] counts as export). (I finally found where I saw this before. It has also been discussed here or on the ooo-private list before. I remembered it as being simpler than it is.) (It looks worse than it is) Following the instructions[3], step 1 is to work out whether OOo has any unusual cryptography beyond ECCN 5D002, which is: blockquote cite='http://www.apache.org/dev/crypto.html#classify Software specially designed or modified for the development, production or use of any of the other software of this list, or software designed to certify other software on this list; or Software using a symmetric algorithm employing a key length in excess of 56-bits; or Software using an asymmetric algorithm where the security of the algorithm is based on: factorization of integers in excess of 512 bits (e.g., RSA), computation of discrete logarithms in a multiplicative group of a finite field of size greater than 512 bits (e.g., Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve). /blockquote Does OOo rely on cryptography more exotic than this? That is where it seems backwards to me. If I'm reading this correctly, we are OK if we use a symmetrical algorithm with key length greater than (in excess of) 56-bits. But if we use an algorithm, with less thanb 56-bits we're considered exotic? Really? Remember that we're only interested in strong cryptography :-) IIRC symmetric and asymmetric algorithms weaker than this are not considered strong cryptography, and so don't fall under ECCN 5D002. Cryptography which is neither weak nor covered by those definitions needs special handling. Robert
Re: Request dev help: Info for required crypto export declaration
On Thu, Sep 1, 2011 at 8:18 PM, Donald Whytock dwhyt...@gmail.com wrote: On Thu, Sep 1, 2011 at 3:00 PM, Rob Weir r...@robweir.com wrote: On Thu, Sep 1, 2011 at 2:51 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: Following the instructions[3], step 1 is to work out whether OOo has any unusual cryptography beyond ECCN 5D002, which is: blockquote cite='http://www.apache.org/dev/crypto.html#classify Software specially designed or modified for the development, production or use of any of the other software of this list, or software designed to certify other software on this list; or Software using a symmetric algorithm employing a key length in excess of 56-bits; or Software using an asymmetric algorithm where the security of the algorithm is based on: factorization of integers in excess of 512 bits (e.g., RSA), computation of discrete logarithms in a multiplicative group of a finite field of size greater than 512 bits (e.g., Diffie-Hellman over Z/pZ), or other discrete logarithms in a group in excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve). /blockquote Does OOo rely on cryptography more exotic than this? That is where it seems backwards to me. If I'm reading this correctly, we are OK if we use a symmetrical algorithm with key length greater than (in excess of) 56-bits. But if we use an algorithm, with less thanb 56-bits we're considered exotic? Really? For example, Calc has a ROT13() spreadsheet function, which undoubtedly is a weak symmetrical encryption technique, certainly not one with a key length in excess of 56-bits. So what now? In other words, I'm puzzled by the in excess part. They seem to be saying that strong encryption is regulated less than weak encryption. Could you explain where I'm getting this wrong? It looks to me like the key phrase is any unusual cryptography beyond ECCN 5D002, and the definition of that phrase is the cited block, as opposed to the cited block being a definition of ECCN 5D002. I am having a remarkably hard time finding a definition of ECCN 5D002. EAR 740.13(e) should be on http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfrsid=bad7a54a31430303e17ce648c13e51b3rgn=div5view=textnode=15:2.1.3.4.25idno=15#15:2.1.3.4.25.0.1.13 Robert
Re: Request dev help: Info for required crypto export declaration
On Thu, Sep 1, 2011 at 8:40 PM, Donald Whytock dwhyt...@gmail.com wrote: On Thu, Sep 1, 2011 at 3:25 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: EAR 740.13(e) should be on http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfrsid=bad7a54a31430303e17ce648c13e51b3rgn=div5view=textnode=15:2.1.3.4.25idno=15#15:2.1.3.4.25.0.1.13 Robert Thanks, Robert. IANAL, but on that page I see reference to the phrase publicly available encryption source code. ASF, by charter, is a repository of publicly available source code. If OOo is officially an ASF project, does that take it out of the category of a product for export and into the category of publicly available source code? As our source is publicly available, the TSU exception applies [1] Robert [1] http://www.apache.org/dev/crypto.html
Re: Request dev help: Info for required crypto export declaration
On Thu, Sep 1, 2011 at 8:59 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Let me see if I can help ground this. Currently, digest algorithms are used for a variety of things. The common case is SHA1. These are not themselves a concern, as I understand it, since their function is not directly related to encryption even though they come into play in the use of encryption methods. AIUI only encryption is of concern There is no support for *document* *encryption* via asymmetric keys. It is not specified in ODF and there is no way to do it in current implementations as far as I know. Ok There is *password-based* *document* *encryption*. The current default procedure generates a 128-bit (symmetrical, of course) key via PBKDF2 using HMAC-SHA1 and encrypts using Blowfish with 8-bit CFB. There are provisions, for ODF 1.2, to generate wider keys and use PBKDF2 with rng methods other than HMAC-SHA1. Substitutes for PBKDF2 and Blowfish are allowed but I don't know the status of any implementation-dependent variations in OpenOffice.org. I believe there are extensions in the builds but they are not currently enabled in the standard distributions. Sounds likely to be strong cryptography falling under 'Software using a symmetric algorithm employing a key length in excess of 56-bits' There is support for digital signatures using PKI methodologies and those do, of course, use *asymmetric encryption* as part of the signature procedure. We need to catalog what those flavors are that are accepted and that are produced. Implementations are allowed considerable license in this area and we need to inventory the actual support in OpenOffice.org. +1 It is not clear to me that the asymmetrical encryption used for digital signatures is a concern, but it is useful to have all of these methods profiled and catalogued concerning their implementation in OpenOffice.org. Comprehensive profiling of digital signature provisions is required to ensure interoperability in any case. +1 I am not aware of any other cases. There are proposals for some modest but valuable modifications in ODF 1.3 and as possible implementation-dependent introductions in products supporting earlier versions of ODF. Any such implementations would need to be identified too, although none of those I am aware of introduce additional encryption algoritms. So far, looks like OOo most likely has strong crypto but it's all fairly standard stuff. We should press forward with the notification required by law whilst auditing the code. Robert
Re: Request dev help: Info for required crypto export declaration
On Thu, Sep 1, 2011 at 9:03 PM, Rob Weir r...@robweir.com wrote: On Thu, Sep 1, 2011 at 3:59 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Let me see if I can help ground this. Remember, the export could be of code, not just the binaries. So if we have code that does asymmetrical encryption, then we are exporting that, even if in the binaries we call it only in the context of digital signatures. Or not. That seems obvious to me, but IANAL Also code intended to work with cryptography libraries (whether shipped or not) Robert
Re: Request dev help: Info for required crypto export declaration
On Thu, Sep 1, 2011 at 9:35 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Technically, this was to have been resolved before the code was put up on SVN. We need to audit specifically for this rather quickly, and including the places that Rob also identified (import-export filters and http TLS). I definitely recommend a full crypto audit but IIRC it's not necessary before sending the initial notification. AIUI (from [1] and [2]) all that's needed is a list of the cryptographic libraries used by OOo. If the results of the full audit differ then we can just update the details and send an updated notification. Robert [1] http://www.apache.org/dev/crypto.html#sources [2] http://www.apache.org/licenses/exports/
Re: Category B licenses
On Tue, Jun 28, 2011 at 11:42 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: For the magical case of binaries that are not built from the Apache code, what occurred to me first were shared libraries (.DLL or .SO, as well as CLASSPATH goodies and .JAR files) and also executables that could be operated silently from within the Apache-code built software (crude example: how TortoiseSVN installs SVN in some manner and which it is a form of shell for). Another example happens to be over font files, something which has had some folks exercised on LibreOffice lists recently. IMHO this is an area of shared interest where we should definitely be talking and working with those folks IMO this is essential a tooling problem. For projects as large and complex as office, comprehension of the code base, the build and assembly starts to become a major issue. A finely grained, loosely coupled component structure with a simple license for each component goes some way towards solving this problem by allowing each component to be small enough to be understood. But this still leaves tooling gap for a comprehension and verification for the assembled artifact shipped to end users. If the external material is statically linked or otherwise integrated into the Apache code in its build, I think there are concerns, of course I tend to think in terms of build and assembly as different activities requiring different tools and techniques. AIUI (from comments earlier in this thread) OOo already uses a compositional scripting layer for assembly which then choreographs the build. IMHO it's not such a long journey from that towards a compositional assembly tool that automates and reports the license and provenance wrangling. and with comingling in source compilations in some way even more-so. Mixing licenses in source causes major difficulties for developers and downstream consumers. Most successful FOSS projects tend to adopt a homogeneous regime. So FOSS tends to factor along license lines. One way to look at the Apache categories is that they specify which licenses are sufficiently compatible with the Apache License to be included within the source. My suggestion for here (ooo-dev) is that we focus on how to minimize the exposed surface to run-time access to non-Apache resources (that might be co-deployed) wherever we can, so that nothing is comingled into the build of Apache-source executable or library code itself. AIUI to ship artifacts for end users, executables are going to need to be assembled from a complex mixture of resources. Going forward, IMO separating these concerns by isolating the assembly is likely to make everything work more smoothly. And even then maybe we need to go to legal-discuss. Apache policy is evolutionary. OOo brings some new challenges and this means refinement is likely. It's best to start talking as early as possible... Robert
Re: Hauling in third-party code (was: Category B licenses)
On Wed, Jun 29, 2011 at 1:34 PM, Greg Stein gst...@gmail.com wrote: On Jun 29, 2011 7:54 AM, Jens-Heiner Rechtien jhrecht...@web.de wrote: On 06/29/2011 01:19 AM, Greg Stein wrote: ... This process sounds exactly like what the buildout tool[1] is designed to handle. It seems like a good opportunity to move from OOo's homegrown system to something that is supported, documented, and maintained by others. The system we currently have is effective - and it works now. I agree that there are better and more standard ways to do this but I guess it's not our first priority, maybe not even our second. volunteers scratch their own itches ;-) It's a whole lot of stuff and it has to work on Windows as well. Would python be good enough for this? Introducing something as buildtools will be the perfect time sink for someone overhauling the build process. And I would hate it if the change would stop somewhere in between - I've seen many tries to standardize stuff in OOo which ended prematurely leaving us with *two* ways to do things. Any replacement would need to be developed in parallel It's very easy to underestimate the effort given the sheer size of OOo. A PMC needs to be able to provide oversight and verify releases. The size of OOo is going to make this difficult. Is the current plan to integrate the release of the homegrown build tool with the rest of OOo? Of course if someone is willing to do this, that would be great. But it takes a lot of commitment to see the changes through. Right. Agreed! +1 Just throwing it out there. I think it could be a great way to reduce maintenance in the long run, but recognize there is a big hurdle to cross first. +1 I'm concerned about being able to verify official OOo releases. If switching to buildout (say) made automated auditing and oversight easier then it may well be worth the effort. Reviewing those patches would also be good. Try and get more of them upstream. For example, I saw some patches to Neon in there which should get pushed upstream, and also move to the latest version of Neon. Always a good idea to do this, but if I remember right especially neon was occasionally unresponsive regarding some of our patches. But I guess every downstream project complains about upstream being unresponsive :-). But I know that we've updated neon support regularly over the last years. Yeah. We'd always like upstream to love us :-) +1 Robert
Re: Getting to our first build
(Reintroducing myself, I'm an Apache Member with some knowledge of releases, builds and legal stuff. I signed up to provide some hands on help in these areas. I've also been involved with the Incubator for a while so I might also jump in with .) (At Apache, we conventionally avoid top posting and like to cut content whilst preserving context. Good subjects with renaming when necessary is also seen to be a Good Thing. This tends to produce more concise and inclusive discussion threads by preserving immediate context for a particular point. So please forgive my editing...) On Tue, Jun 28, 2011 at 12:34 PM, Rob Weir apa...@robweir.com wrote: On Tue, Jun 28, 2011 at 4:55 AM, Mathias Bauer mathias_ba...@gmx.net wrote: On 27.06.2011 22:06, Rob Weir wrote: moved I think one approach would be to start with everything, which should presumably build, and then subtract. So check in everything from OOo into SVN, verify that it builds. That establishes a known state. Then verify the IP. Maybe use SVN properties to tag the files that were covered by Oracle's SGA. Anything not tagged needs to be investigated. Some things lead to requests for amending the Oracle SGA. When we get those, we indicate so in an SVN property. Some things will be GPL/LPGL. These get also get tagged with properties before being deleted. We continue to iterate until all files remaining in the repository have a property indicating that we've proven their provenance. Ideally, as things are removed, we do so in a way that we can always still build. So we start in a well-defined state and stay in a well-defined state. I can't judge whether this approach is feasible. /moved I don't know whether my approach is feasible either. I know we can set properties on files in SVN. You can retrieve them individually, but I don't see a way to query them, e.g., list all files that don't have a license property, or download all files that have a license property set to Apache 2.0. IMHO new tools are going to be needed sooner or later. For example, the Jakarta Project led to Ant and Maven. So, if a query tool is needed for subversion, one can probably be written. FWIW Ant is a procedural build language. Maven is a declarative one. IMHO to sustain a rich and diverse downstream ecology, OOo will need a compositional build language layer. Robert
Re: Getting to our first build
On Tue, Jun 28, 2011 at 5:07 PM, Greg Stein gst...@gmail.com wrote: Top-posting is just fine for replies where you're talking about the message in general. If you're replying to specific pieces, then yeah: in-line comments are best. We have no rules against top-posting at Apache. We want to communicate rather than get all crazy about the *form* of the communication. +1 Robert
Re: Getting to our first build
On Tue, Jun 28, 2011 at 5:05 PM, Greg Stein gst...@gmail.com wrote: On Tue, Jun 28, 2011 at 07:34, Rob Weir apa...@robweir.com wrote: snip Of course, if you think you are close to having a clean version of OOo ready to check in, then I don't want to interrupt the fine work that you are already doing. But in that case I think it would help if we had a roadmap for the next couple of weeks, of what tasks remains, so others can help as well. I still believe that we would like *history* rather than simply copying over tip from the old repository. Having that history in one repository is so incredibly useful to so many people, that I cannot see why we would skip it. +1 Perhaps the history could be checked into a read only directory. As the IP is checked and cleaned, resources could be copied across into the new working directory structure. Scripting magic could be used to compose a build from these two sources. Opinions? Objections? Improvements? Robert
Re: Category B licenses
On Tue, Jun 28, 2011 at 9:10 PM, Michael Stahl m...@openoffice.org wrote: one thing that is currently unclear to me is whether/how Apache OOo may depend on code licensed under a Category B license. the most prominent specimen of this category is the MPL. (Apache is mailing-list centric and legal-discuss [1] is where good answers to questions on this topic are to be found but I'll do my best. It's also where discussions and decisions about refining policy happen.) snip while ApacheOOo can never ship Category X libraries, for Category B there is this: http://www.apache.org/legal/resolved.html#category-b Software under the following licenses may be included in binary form within an Apache product if the inclusion is appropriately labeled: [...] By including only the object/binary form, there is less exposed surface area of the third-party work from which a work might be derived; this addresses the second guiding principle of this policy. By attaching a prominent label to the distribution and requiring an explicit action by the user to get the reciprocally-licensed source, users are less likely to be unaware of restrictions significantly different from those of the Apache License. Please include the URL to the product's homepage in the prominent label. now, some questions: the sentence on including only the object/binary form i don't understand at all. if we ship a binary installation set, then of course it doesn't include the source code for anything (except perhaps Python/BASIC code...). so i guess this refers to a source code release. Conventionally at Apache, the source release is canonical and is identical to the tagged source in version control. The downstream ecosystem typically consumes this source and produces installations. A binary release is a (typically compressed) aggregation derived from the source by some build process and shipped as a convenience for end users. but that doesn't make much sense either: what exactly is gained by putting binary libraries for a bunch of platforms into a source tarball? _which_ platforms? all of them? that's going to be huge... is this sentence perhaps intended specifically for Java libraries? Not specifically but dynamic and bytecode languages are more likely to want to ship this sort of thing secondly, requiring an explicit action to get the reciprocally-licensed source, does our existing fetch_tarballs.sh script qualify? Running a script sounds like an explicit action to me but it's best to open an issue so the documentation can be updated [2]. I'm running out of my (limited) computer time for today, so hopefully someone will beat me to it and jump in with the number snip basically, how can we build an ApacheOOo binary release that includes Category B licensed libraries? Am I right in assuming that we're talking about shipping something that can be used to install ApacheOOo? Robert [1] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ [2] https://issues.apache.org/jira/browse/LEGAL
Re: Subversion history
On Sun, Jun 19, 2011 at 11:45 AM, Marcus (OOo) marcus.m...@wtnet.de wrote: snip When Oracle will shutdown the main server for distributing release files, then also the mirrors will delete them (except GWDG which I've asked to host the files longer). So, we have to rebuild a little mirror system if we want this structure back. But maybe it's enough to have all older builds on a single (non-Apache) server? IMO continuity of hosting and comprehensive archival (for the record) are important but orthogonal. Going back to the start of this thread, archive.org has long term archival expertise. I don't see any need for formality or ceremony before initial contact. IMHO it'd be cool if a volunteer at least let them know what was happening and discovered whether they might be able to help with long term archival. (This contribution would not require commit karma ;-) Robert
