Skip to content

Add property code #25

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Add property code #25

wants to merge 2 commits into from

Conversation

ncbarta
Copy link
Member

@ncbarta ncbarta commented Feb 27, 2025

Opening this proposal for review

This PR does:

  1. Changes 1 sentence in code of conduct to make clear that bans are not the only sanctions for violations.
  2. Adds a new code for CSC property, which like the code of conduct, can come with sanctions for violations.

Why?

  • CSC manages a lot of resources. There are no expectations set in the constitution regarding proper use of these resources.
  • People who choose to donate/lend their property deserve systems to reign in how their property gets used and shared.

@timparenti
Copy link
Member

I'm sure you're already aware, but this is quite a legally thorny area. If donations of assets are solicited by the club, it seems to my eye that such donations could technically be considered property of the university, albeit wholly managed by the club in accordance with SORC guidelines. But it also seems like this draft is written specifically to keep the university, at their apparent request, entirely uninvolved in any transactions. And the club's desired role here is unclear: Is it (a) directly accepting resources for its own later distribution, (b) merely facilitating a community standard for peer-to-peer transactions, or (c) both?

My biggest question: Is this proposed language modeled off of university-approved language currently used by any other organizations? This is the sort of proposal where it is crucial to get key language correct from the outset, and this draft is fairly loose in several places that could cause issues down the road. Be fastidiously clear in the differences between ownership/owner, stewardship/steward, and custody/custodian. Spell them out in the document and never use one when you mean another. Define vaguer concepts like "access", "possession", "control", "become", "award", etc. only in terms of these roles wherever possible. Avoid words like "lease" which already have a well-defined legal meaning that isn't in line with what's actually intended here.

As a particular example: Consider whether the original owner of an asset seeking its return, faced with a non-responsive temporary custodian, may have rights to pursue direct legal action against said custodian; what responsibilities the club and its officers may have to the original owner in facilitating such legal process even if it is not party to them (such as providing the custodian's contact information or retention/discovery of original agreements); and whether the club actually desires to bear such an ongoing burden in the long-term. At the very least, it seems it may be desirable for declarations granting temporary stewardship of an asset to the club to explicitly disclaim liability of the university as an entity, the club, its officers as individuals, and possibly even its members as individuals; i.e., "we have some basic mechanisms in place to assist with accountability, but you understand and agree that we can't make any promises you will ever get this back, even if you ask. Here's how we will and will not help." In addition to writing such language into any individual transactional documents, this sort of default disclaimer should also be written into the portion of the governing document beginning "Unless explicitly agreed upon, all declarations are assumed to…".

If the club is to formalize its possession or stewardship of assets, it is also critical to explicitly spell out how those assets are to be distributed in the event of the organization's dissolution, whether voluntarily or by outside force. Based on my understanding of the intent behind this draft, I would suggest the following as a modest extension of a typical approach for clubs at universities:

  • There should be reasonable parameters providing for negotiation of timely return of such assets to their original owners if desired by the original owners.
  • If original owners do not want an asset to be returned to them or cannot be reached within a specified reasonable time period, such an asset can either be granted in full to its custodian, if there is one, or otherwise distributed to other groups with similar interest in or use for the asset, giving preference to: (1) other student-run clubs at Pitt, (2) other academic departments at Pitt, (3) other local community or professional organizations, (4) other charitable causes.

SORC may have further guidance and/or requirements for the disposition of assets upon dissolution. This all gets significantly messier given that assets may be lent out at any time: Consider again a custodian's failure to return assets and how, depending on the nature of the dissolution, such non-response might need to be referred to a higher remaining authority such as SORC, the university, or local law enforcement. (Of course, a club in the process of dissolution cannot force such a higher remaining authority to follow-up on such violations on their behalf. What then? Does the club have a signed agreement with the custodian? It should. Does the higher remaining authority have any actual interest in standing upon that agreement to try to recover the asset on behalf of a third party? It might not: Did the owner properly disclaim liability? etc.)

@ncbarta
Copy link
Member Author

ncbarta commented Mar 27, 2025

@timparenti Thank you for your through review

Is it (a) directly accepting resources for its own later distribution, (b) merely facilitating a community standard for peer-to-peer transactions, or (c) both?

C. In my head while I was writing I modeled it after a few situations: someone donates something to the club with use conditions, member rents something and allows CSC members to use, officer holds onto recruitment materials over the summer, member shares device with another member for a CSC event, CSC officers allow a member to use the social media for an 'Instagram Takeover/Ride-along', CSC members contribute to an open source CSC project. Then I attempted to come up with rules/structures to support these situations and allow the organization to sanction members for causing harm to other members or the organization through their misuse of property.

CSC enjoys a wide latitude in the things it is allowed to do since it is an independent organization (not officially affiliated with an operating unit of the university). There are some things that we are not allowed to do, such as claim to represent the university, use trademarked material without permission, open bank accounts, etc. These are enforced with a carrot/stick system, as they can't reach into our org without risking assumption of liability (at least this is my understanding).

I brought up the general concept of this proposal with SORC last year (I was calling it the 'CSC Equipment Policy' at the time) and they said that the idea was valid. I don't know of any clubs that have a policy like this, specifically sanctions mechanisms for equipment use/missuse. The constitution can't be adopted without their approval, so they will be looking over it once it's ready to submit.

The points you brought up about definitions is good - they're all over the place. The points about stewardship and enforcement are also good, CSC should not take on any responsibility for loss or recovery, especially since it's not even a real entity (so it cannot be a party in any agreement), so responsibilities would ultimately pass-through to.... someone.

Once again, thank you for the review. I will create a new draft once I have time, incorporating the substance of your comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants