Great thanks. Two items: CLA and number of committees.
CLA Understanding that these are legal questions and you might not have all the answers - I will take any responses with a grain of salt and do my own diligence. 1. I don't see an issue with the switch since patent stuff isn't an issue today, but will double check. 2. Question, does the whole repository need the same license? e.g. including documentation and examples? 3. In the article you linked to, it sounds like OpenCV didn't need to get everyone to sign CLAs to switch, as they just preserved original copyright in the places that I think they didn't get CLAs. I believe I can do a similar approach: > The migration process > > Since BSD license only requires us to state that the code has been taken > from the certain origin and to preserve the original copyright, and it does > not require the derived software to be released under the same license, > this is just what we are going to do. > > After OpenCV 4.4 release (to be released this month), we are going to make > immediate internal “fork” of OpenCV in the same repository, with the > reference to the original license and all the original copyrights. Users, > who absolutely need BSD license for their products (we believe, there will > be not many such people), can continue to use OpenCV 2.x, OpenCV 3.x and > OpenCV 4.x, up to OpenCV 4.4 inclusively. > > Starting from OpenCV pre-5.0 (that will be developed in the newly created > “next” branch) and OpenCV pre-4.5 (“master” branch) the license changes to > Apache 2. Contributors of all new functionality will be required to agree > to include their code under Apache 2 license instead of BSD. > 4. Segmenting contributions (Hamilton has 67, Burr has 17): - core -> getting CLAs for core contributions should be straightforward 🤞. - examples -> not part of the packaged software, can get CLAs on best effort, else just preserve original copyright. If someone complains, is removal an option? - documentation -> not part of the packaged software, can get CLAs on best effort, else just preserve original copyright. If someone complains, is removal an option? Two separate committees versus one Clarification on the committees. We'd like Hamilton and Burr to be top level projects ideally, e.g. Apache Hamilton; Apache Burr. Does that require two separate committees then? Or can it be done with one committee that oversees both? Since if we can do one that would be simpler. Thanks in advance! Cheers, Stefan On Fri, Jan 3, 2025 at 1:33 AM PJ Fanning <fannin...@apache.org> wrote: > There might be a relicensing guide somewhere but in practice, I think > people avoid giving general guidance on legal issues because there might be > cases where the advice is problematic. I'm not working today so will find > it hard to search around for docs online. > > One article that I did find. It mentions patents and how BSD and ASL differ > in this regard. > https://opencv.org/blog/opencv-is-to-change-the-license-to-apache-2/ > > Copyright holders can change the license. > > Unfortunately, without CLAs, contributors could try to assert sole > copyright to the code that they contributed. > > Apache projects often don't require CLAs for small contributions but will > seek them from regular contributors and for large code changes. > > You could maybe start with announcing the possibility of a license change > to your users and contributors to gauge the response. > > I'm guessing but I would hope that most of the larger contributors will be > invited to join the new podling committees. They will need to sign Apache > Software Foundation CLAs to join the committees. > > There may be alternatives if changing the license becomes an issue. > > On Fri 3 Jan 2025, 09:11 Stefan Krawczyk, <stefan.krawc...@gmail.com> > wrote: > > > Thank you Kevin, Aysh, and PJ! > > > > It sounds like I should focus on getting CLAs first? I assumed with > BSD-3 I > > wouldn't need them... Is there a guide somewhere for that? E.g. what > > language to use? What doesn't require a CLA? What happens if I can't get > a > > hold of someone? etc. > > > > Regarding two committees versus one. I was thinking of two separate > > committees since the projects could go in different directions; though > > there is benefit from having them close to each other. > > > > Thanks in advance! > > > > Cheers, > > > > Stefan > > > > On Thu, Jan 2, 2025 at 10:00 PM Ayush Saxena <ayush...@gmail.com> wrote: > > > > > HI Stefan, > > > > > > I can even volunteer as a mentor for the projects during Incubation. > > > > > > -Ayush > > > > > > On Fri, 3 Jan 2025 at 02:18, Kevin Ratnasekera <djkevi...@apache.org> > > > wrote: > > > > > > > > Hi Stefan, > > > > > > > > These projects look interesting. I am interested in voluteering as a > > > mentor > > > > incubator process. > > > > > > > > Regards > > > > Kevin > > > > > > > > On Fri, Jan 3, 2025 at 2:04 AM PJ Fanning <fannin...@apache.org> > > wrote: > > > > > > > > > Hi Stefan, > > > > > > > > > > It looks like both projects (Hamilton and Burr) are in a healthy > > state. > > > > > > > > > > I can act as a mentor and help with championing if that suits. > > > > > > > > > > One item to decide on is if you want to create 2 separate podling > > > > > committees or if you want to create 1 committee that manages 2 > > > > > separate source repositories with independent releases. > > > > > > > > > > You would also need to get the existing code owners to agree to the > > > > > license change from BSD to Apache licensed. If the existing > > > > > contributors have signed CLAs giving DAGWorks ownership that would > > > > > make it easier. Otherwise, we will need to track down the historic > > > > > contributors to ask them to agree to the license change. > > > > > > > > > > After that, we will need to put together one or two proposal > > documents. > > > > > > > > > > Example: > > > > > > https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal > > > > > > > > > > I would prefer to be hands off on doing this sort of effort but can > > > > > help with reviewing the work. I think it is important that podling > > > > > committees can look after their own administrative tasks. > > > > > > > > > > Regards, > > > > > PJ > > > > > > > > > > On Thu, 2 Jan 2025 at 20:58, Stefan Krawczyk < > > > stefan.krawc...@gmail.com> > > > > > wrote: > > > > > > > > > > > > Hi Everyone, > > > > > > > > > > > > Happy New Year - just bumping this thread! > > > > > > > > > > > > Would love any and all feedback. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Stefan > > > > > > > > > > > > On Fri, Dec 27, 2024 at 1:14 PM Stefan Krawczyk < > > > > > stefan.krawc...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Dear Apache Incubator PMC, > > > > > > > > > > > > > > I hope this email finds you well. My name is Stefan Krawczyk > > > > > > > <https://www.linkedin.com/in/skrawczyk>, and I am reaching out > > to > > > > > > > introduce two projects Hamilton < > > > > > https://github.com/dagworks-inc/hamilton>, > > > > > > > & Burr <https://github.com/dagworks-inc/burr>, that I would > like > > > to > > > > > > > consider for the ASF incubator program. Currently, we are > looking > > > for a > > > > > > > Champion (or two?) to guide us through the incubation process > and > > > to > > > > > help > > > > > > > generate interest and engagement from the ASF community. We are > > > eager > > > > > to > > > > > > > learn from the ASF's vast expertise and to ensure the project > > > adheres > > > > > to > > > > > > > ASF's best practices. Details on the projects below. > > > > > > > > > > > > > > Hamilton is a lightweight *python DAG* orchestration framework > > > (think > > > > > > > pipelines) that comes with a self-hostable observability UI. > > People > > > > > use it > > > > > > > to wrangle pyspark code, through to pandas, and even LLM calls > > > within > > > > > > > web-services, Note: Hamilton is not an alternative to Airflow, > > > infact > > > > > > > people use Hamilton within their Airflow tasks. > > > > > > > > > > > > > > - GitHub repository < > https://github.com/dagworks-inc/hamilton > > > > > > > > (1.9K > > > > > > > stars, 500K+ downloads, 400+ community - users from banks to > > > > > start-ups) > > > > > > > - Documentation <http://hamilton.dagworks.io/en/latest/>, > or > > > > > > > https://www.tryhamilton.dev/ > > > > > > > - Blog <https://blog.dagworks.io/> for longer content > > > > > > > > > > > > > > Burr is a lightweight *python graph* orchestration framework > (an > > > > > > > alternative to langgraph if you've heard of that) with a > > > self-hostable > > > > > > > observability UI. Its primary focus is to help one structure a > > > state > > > > > > > machine as a series of actions and manage state -- which is > very > > > > > topical at > > > > > > > the moment with how one might design "agents". > > > > > > > > > > > > > > - GitHub repository <https://github.com/dagworks-inc/burr> > > > (1.4K > > > > > > > stars, 500K+ downloads, 100+ community) > > > > > > > - Documentation <https://burr.dagworks.io/> > > > > > > > - Blog <https://blog.dagworks.io> for longer content > > > > > > > > > > > > > > I believe both projects align with the Apache Foundation’s > > > commitment > > > > > to > > > > > > > fostering innovative, community-driven open-source projects > and I > > > > > believe > > > > > > > it is important that with this new wave of GenAI tooling that > > > there are > > > > > > > healthy vendor neutral alternatives. Hamilton & Burr can become > > > just as > > > > > > > successful as Airflow with the right support. > > > > > > > > > > > > > > If you or someone in your network might be interested in > > > championing, > > > > > > > mentoring, or collaborating with us, we would be delighted to > > > discuss > > > > > the > > > > > > > project further. > > > > > > > > > > > > > > Thank you for considering this opportunity to help Hamilton > > and/or > > > Burr > > > > > > > thrive within the ASF ecosystem. I look forward to any advice, > > > > > interest, or > > > > > > > questions from the community. > > > > > > > > > > > > > > Warm regards & Happy Holidays! > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Stefan Krawczyk > > > > > > > CEO & Co-Founder DAGWorks Inc. <https://www.dagworks.io/> > (sent > > > from > > > > > > > personal) > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > > > > >
